City Generation
Re: City Generation
I need to keep all these value arrays in sync. Every rule needs to update every array. I figured that maintaining only one matrix array is the best solution, but maybe separate arrays are better. I'll take a look, thank you!
Re: City Generation
I wouldn't store data in the transformation matrix, it seems predestined to bite you in the butt later on. And in doing so you will have moved from storing all data in an open, shared way to essentially storing data in a custom format that requires a translation layer.
Also, you may want more than three or four scalar values later on, or to store data of different types. You are almost certainly better storing data in multiple arrays and using an ID to keep everything in sync.
Also, you may want more than three or four scalar values later on, or to store data of different types. You are almost certainly better storing data in multiple arrays and using an ID to keep everything in sync.
Re: City Generation
Yes, I think you're both right. That's how I'll do it. It's good that I cleared this up right away, because it's such an important part of the system, and having to change it all way down the line would be a nightmare.
- Daniel Brassard
- Posts: 878
- Joined: 18 Mar 2010, 23:38
- Location: St. Thomas, Ontario
- Contact:
Re: City Generation
Chris,
The 4 x 4 Matrix is called Homogeneous Transform Matrix. Here are some information concerning the matrix and its use in graphics:
http://blogoben.wordpress.com/
http://www710.univ-lyon1.fr/~jciehl/Pub ... G/apf.html
http://math.hws.edu/graphicsnotes/c3/s1.html
http://www.cs.iastate.edu/~cs577/handou ... nsform.pdf
http://graphics.ucsd.edu/courses/cse167 ... 167_03.ppt
Cheers!
Dan
BTW, word of caution concerning matrices from Matt Lind at XSI List:
http://www.cse.ttu.edu.tw/~jmchen/cg/do ... #transpose
P.S. OpenGL is column vertors based
The 4 x 4 Matrix is called Homogeneous Transform Matrix. Here are some information concerning the matrix and its use in graphics:
http://blogoben.wordpress.com/
http://www710.univ-lyon1.fr/~jciehl/Pub ... G/apf.html
http://math.hws.edu/graphicsnotes/c3/s1.html
http://www.cs.iastate.edu/~cs577/handou ... nsform.pdf
http://graphics.ucsd.edu/courses/cse167 ... 167_03.ppt
Cheers!
Dan
BTW, word of caution concerning matrices from Matt Lind at XSI List:
Good explaination of row and column vectors here:When looking for references on Matrices, one thing to pay attention to is whether the equations use row or column vectors as that will impact computations. Softimage is row vectors. If you find an equation that uses column vectors, you will have to transpose the matrix to make it row aligned.
http://www.cse.ttu.edu.tw/~jmchen/cg/do ... #transpose
P.S. OpenGL is column vertors based
$ifndef "Softimage"
set "Softimage" "true"
$endif
set "Softimage" "true"
$endif
Re: City Generation
Thanks for the links, Daniel!
- Kerro Perro
- Posts: 306
- Joined: 20 Mar 2011, 01:01
- Location: Leiden, the Netherlands
- Contact:
Re: City Generation
Oh my god this is so great!! I too was thinking it would be possible to generate cities with ICE and was a bit dissapointed when i saw the videos on youtube that just deal with floor numbers.
I originally got really inspired when i saw this: http://www.youtube.com/watch?v=-d2-PtK4 ... re=feedlik wich has nothing to with ICE - but is just damn cool.
You're really far along already!!
I'm gonna read your post more carefully and try to reproduce it but i just had to respond immediatly when i skimmed it - it's just great when someone has the same vision and has already done a lot of the legwork! ;)
I originally got really inspired when i saw this: http://www.youtube.com/watch?v=-d2-PtK4 ... re=feedlik wich has nothing to with ICE - but is just damn cool.
You're really far along already!!
I'm gonna read your post more carefully and try to reproduce it but i just had to respond immediatly when i skimmed it - it's just great when someone has the same vision and has already done a lot of the legwork! ;)
Re: City Generation
Yes, it's been a while since I posted an update. But I have kept on working on this. I've done a ton of stuff under the hood to ensure proper usability. I don't know how often I've modified my split compound now, but it's become a powerhouse, so that was worth it.
I'm planning on showing the current functionality in a video hopefully on Monday.
I'm planning on showing the current functionality in a video hopefully on Monday.
Re: City Generation
hey Chris this is looking awesome! I'll sure keep up reading this thread for updates
Gustavo Eggert Boehs
Blog: http://www.gustavoeb.com.br/
Blog: http://www.gustavoeb.com.br/
-
- Posts: 143
- Joined: 09 Jun 2009, 12:12
- Location: Czech Republic
- Contact:
Re: City Generation
Chris_TC wrote:Yes, it's been a while since I posted an update. But I have kept on working on this. I've done a ton of stuff under the hood to ensure proper usability. I don't know how often I've modified my split compound now, but it's become a powerhouse, so that was worth it.
I'm planning on showing the current functionality in a video hopefully on Monday.
hey Chris, any news?
- farhaad_yousefi
- Posts: 178
- Joined: 08 Jun 2009, 22:45
- Location: tehran-iran
- Contact:
Re: City Generation
any news.!?
Re: City Generation
I don't want to give ETAs anymore, but I'll show something soon.
Re: City Generation
awesome stuff!
Re: City Generation
hey chris, just hope you didnt stop workin on this! i'm deeply interested even in a commercial release!
This is just awesome. Any news about it?
Max
This is just awesome. Any news about it?
Max
Re: City Generation
Caution: Lots of text ahead. Also, I could use some input from smart people
We've had (and still do have) tons of work, so I couldn't put much time aside for these compounds. However, over the past weeks several clients have required us to put facades on CAD buildings. The CAD people seem to have trouble with this, so we take care of it. This kind of thing comes up more and more because we get good and very fast results, all thanks to the building generator compounds.
We've used them on some rather high profile projects, including a $40 million building, which we received as a simple box layout and outfitted with fully procedural facades based on architect drawings. Unfortunately, I'm not allowed to show any of the work we did
So I now have production experience with the system, and apart from a few missing features, there are two main problems: performance and usability. Usability is the biggest issue: You can get almost any result you want, but the node tree gets complicated on anything but the simplest facade. Because of these problems, I'll rework a lot of the system. In its current state I don't think anybody except for myself could make somewhat efficient use of it.
I'm wondering about a few core questions, and it'd be great if someone had any pointers in the right direction:
1) The system uses integers for a lot of things. Select Case nodes then make decisions based on these numbers. Unfortunately, numbers are not very user-friendly. Are there ways to do more with strings? I would love to be able to write "lower_floor" into my custom attribute, rather than "1". Anybody have any tricks up their sleeve?
2) Nodes need to pass a lot of attributes between them. I believe I had previously brought up the idea of using a 4x4 matrix to encode and decode up to 16 attributes (at least 7 of which I need for actual SRT information). I still like this idea because I could have an encoder compound with 16 inputs and one output. This one output is easy for users to connect to other nodes, which is great. Unfortunately, 16 attributes will likely not be enough. However, if I were to use custom attributes, I'd have to also use Set Data nodes, which require Execute ports. I don't see how I could then have a simple encoder compound with one output port that can be connected to another compound. I think I'd need two output ports: one to Set Data, the other to connect to other compounds (Edit: actually, this wouldn't work. I'd need one output port per attribute. That's awful!) Usability would be shot to pieces. Any ideas?
3) Regarding performance, are there any decent ways to bring scripting into the mix? A lot of the math that happens in the ICE trees is recursive, and code would be much faster to execute this stuff. Of course ICE is very cool in how it allows users to just connect my compounds together, so I don't want to drop it alltogether. Custom C++ nodes are my best bet I think, but is this the only option? I'm fine with Python and Jscript, practically no experience with C++.
Sorry for the wall of text and no pretty pictures. I'll see if I can post something during the next days.
We've had (and still do have) tons of work, so I couldn't put much time aside for these compounds. However, over the past weeks several clients have required us to put facades on CAD buildings. The CAD people seem to have trouble with this, so we take care of it. This kind of thing comes up more and more because we get good and very fast results, all thanks to the building generator compounds.
We've used them on some rather high profile projects, including a $40 million building, which we received as a simple box layout and outfitted with fully procedural facades based on architect drawings. Unfortunately, I'm not allowed to show any of the work we did
So I now have production experience with the system, and apart from a few missing features, there are two main problems: performance and usability. Usability is the biggest issue: You can get almost any result you want, but the node tree gets complicated on anything but the simplest facade. Because of these problems, I'll rework a lot of the system. In its current state I don't think anybody except for myself could make somewhat efficient use of it.
I'm wondering about a few core questions, and it'd be great if someone had any pointers in the right direction:
1) The system uses integers for a lot of things. Select Case nodes then make decisions based on these numbers. Unfortunately, numbers are not very user-friendly. Are there ways to do more with strings? I would love to be able to write "lower_floor" into my custom attribute, rather than "1". Anybody have any tricks up their sleeve?
2) Nodes need to pass a lot of attributes between them. I believe I had previously brought up the idea of using a 4x4 matrix to encode and decode up to 16 attributes (at least 7 of which I need for actual SRT information). I still like this idea because I could have an encoder compound with 16 inputs and one output. This one output is easy for users to connect to other nodes, which is great. Unfortunately, 16 attributes will likely not be enough. However, if I were to use custom attributes, I'd have to also use Set Data nodes, which require Execute ports. I don't see how I could then have a simple encoder compound with one output port that can be connected to another compound. I think I'd need two output ports: one to Set Data, the other to connect to other compounds (Edit: actually, this wouldn't work. I'd need one output port per attribute. That's awful!) Usability would be shot to pieces. Any ideas?
3) Regarding performance, are there any decent ways to bring scripting into the mix? A lot of the math that happens in the ICE trees is recursive, and code would be much faster to execute this stuff. Of course ICE is very cool in how it allows users to just connect my compounds together, so I don't want to drop it alltogether. Custom C++ nodes are my best bet I think, but is this the only option? I'm fine with Python and Jscript, practically no experience with C++.
Sorry for the wall of text and no pretty pictures. I'll see if I can post something during the next days.
Re: City Generation
Thanks for the update, Chris.
EDIT: Perhaps you could use Select Case, but expose it as String names. ie Lower Floor, Upper Floor. Your building project is probably much too complex for that though; Select Case would probably be too limiting....
EDIT: Perhaps you could use Select Case, but expose it as String names. ie Lower Floor, Upper Floor. Your building project is probably much too complex for that though; Select Case would probably be too limiting....
Re: City Generation
Sure, since word about our quick facade output is getting around, I'll probably have to get these compounds up to speed in order to maintain my own sanity while working with them. So there's a really good chance I'll get them to a point where I can actually release them.
Split every base facade into a ground floor and a top floor.
Split every ground floor into three windows and a door.
Split every top floor into five windows and five balconies.
All of these elements are currently represented as integers, then interpreted by Select Case nodes. So users have to specify not the above, but this:
Split every 0 into a 1 and 3.
Split every 1 into three 8s and a 9.
Split every 3 into five 8s and five 12s.
When working with this, all the numbers quickly get confusing.
Just to expand a little bit on the problem: Users who want to make a custom building need to generate the ICE logic for that particular building. I would love for this process to just require the connecting of compounds. However, I don't think that's possible. So the user has to specify a splitting structure, for example (simplified):dwigfor wrote:Perhaps you could use Select Case, but expose it as String names. ie Lower Floor, Upper Floor
Split every base facade into a ground floor and a top floor.
Split every ground floor into three windows and a door.
Split every top floor into five windows and five balconies.
All of these elements are currently represented as integers, then interpreted by Select Case nodes. So users have to specify not the above, but this:
Split every 0 into a 1 and 3.
Split every 1 into three 8s and a 9.
Split every 3 into five 8s and five 12s.
When working with this, all the numbers quickly get confusing.
Who is online
Users browsing this forum: Bing [Bot] and 39 guests