City Generation

[Daniel Brassard]

Maybe a divide and conquer attitude need to be adopted, example

a node for a bottom floor attributes
a node for the walls attributes
a node for the door attributes
a node for the ceiling, roof, windows, etc.

The role of those nodes would be to hold the number attributes and pass them to the main system.

I have no idea how complex you ice tree/compounds are and how it is organised, so just guessing here!

Dan

[Bullit]

What about per material instead?
I mean a wall made of wood is similar to rooftop or floor.
A wall made of stone is very different from a wall made of wood or concrete.

About trigger by strings i have got this answer http://www.si-community.com/community/v ... =15&t=3510

Maybe a list of keywords related to building might help:

No particular order:
material
facade
floor
windows
door
balcony
roof
ornament?

Facade designed black and white/color intensity image? ex. darker more distant brighter more upfront. Going for city generation this could also be employed to draw roads. Crazy idea but if ICE could recognize a number or a string in an image it might be able to use it. Or a number in 3d put over the respective color or brightness.

[Chris_TC]

Thanks to you both! Very interesting ideas there which I will definitely look into.

[Mathaeus]

Caution: Lots of text ahead. Also, I could use some input from smart people

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

Just as reference, don't know does it apply to your stuff. Anyway:

2 - I've played a lot with "encoding" for Kristinka Hair, for transferring data between point clouds. Maximum was "packing" four scalars into 4d vector. This worked nicely. However, big no no seems to be packing into array, this made about 20% slower playback, in some cases.

Anyway, in last version I think there's nothing of "encoding". General structure is to set data by compound, whenever has sense, then there is pass through. Somewhere in middle of execution chain, it's possible to plug another compound into execute input, which does something with some attribute - or it does nothing, if not present.
Even it's not visually pleasant to have a lot of custom attributes, some complex structure in Kristinka Hair can create about twenty - I didn't noticed problems with this.

1 - "select case", nothing wrong with this, as long it has simple input. If input is something computationally expensive (let's say, concatenated array of all strands in point cloud), it make everything even more slower. I've read somewhere, that "select case" is if-else chain under hood, that is, everything seems to be compared.

Long story short, as long you're with ICE - only, there is no way to please everyone, so.. don't please everyone ( someone will kill me for these words, right now). Instead, I think it's much better idea to be focused on modularity, as much clean structure, so on.
Scripted procedures, this seems to be solution for artist friendly stuff.

[Chris_TC]

Anyway, in last version I think there's nothing of "encoding". General structure is to set data by compound, whenever has sense, then there is pass through. Somewhere in middle of execution chain, it's possible to plug another compound into execute input, which does something with some attribute - or it does nothing, if not present.

I'm a bit confused about the chaining. If you have a compound with an Execute output (presumably to Set Data), how can this plug into another compound? I understand that the other compound might have an Execute input. But it has no way of reading the "Execute data" that comes in through that input, or does it?

Last night I had a few additional ideas of how to handle everything. Regarding attributes, I figured that I might work with an attribute array for every building element (so it would be a 2D array). I could pass this 2D array from one compound to the next without having to use Set Data anywhere. It would still require encoder and decoder compounds to deal with efficiently reading and writing the array, but it seems pretty user friendly. Not sure if it'll work though.

Bullit's post also made me hope that it may be possible to work with strings instead of integer IDs. I'll have to take a close look at the string nodes ICE currently has. It would be amazing if it were possible to have a compound with these input ports:
"Element"
"New element"

And for users to then add ports like so:
"Ground_floor"
"Ground_floor_entrance"
"Top_floor"
"Top_floor_window"
"Top_floor_balcony"
"New element"

I'm thinking that a Build Array (type string) inside of a compound, coupled with Find in Array (type string) might give me want I want.

Long story short, as long you're with ICE - only, there is no way to please everyone, so.. don't please everyone ( someone will kill me for these words, right now). Instead, I think it's much better idea to be focused on modularity, as much clean structure, so on.

Oh absolutely. Modularity is my number one goal. I've already got something pretty cool there - I can chain together a few compounds and make the most complex structures - but it's not user-friendly enough. My own facade trees confuse me (what did element 8 split into again??), and that's definitely not how it should be, so I must fix this.

[Mathaeus]

Anyway, in last version I think there's nothing of "encoding". General structure is to set data by compound, whenever has sense, then there is pass through. Somewhere in middle of execution chain, it's possible to plug another compound into execute input, which does something with some attribute - or it does nothing, if not present.

I'm a bit confused about the chaining. If you have a compound with an Execute output (presumably to Set Data), how can this plug into another compound? I understand that the other compound might have an Execute input. But it has no way of reading the "Execute data" that comes in through that input, or does it?

Set data goes into execute node, of course. Something along line of "execute on emit" on factory particle emitter, but not the same. If I'm correct, compound is just visual package (I might be totally wrong).
So... maybe it won't help to your stuff, but just in case:
On top is mentioned "execute" construction, bottom is for allowing multiple geometry inputs, each one activates the copy of blue node. Column of "pass_through" nodes, is to allow copies of another, value inputs, too. "execute" node after blue compound should be alone, to allow additions.

[X-said]

What? End of story? Why Christian did not post the source?