City Generation

[Chris_TC]

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!

[Matic]

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.

[Chris_TC]

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]

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:

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.

Good explaination of row and column vectors here:

http://www.cse.ttu.edu.tw/~jmchen/cg/do ... #transpose

P.S. OpenGL is column vertors based

[Chris_TC]

Thanks for the links, Daniel!

[Kerro Perro]

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! ;)

[Chris_TC]

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.

[gustavoeb]

hey Chris this is looking awesome! I'll sure keep up reading this thread for updates

[milanvasek]

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]

any news.!?

[Chris_TC]

I don't want to give ETAs anymore, but I'll show something soon.

[sant0s]

awesome stuff!

[Maximus]

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

[Chris_TC]

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.

[dwigfor]

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....

[Chris_TC]

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.

Perhaps you could use Select Case, but expose it as String names. ie Lower Floor, Upper Floor

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):
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.