[CityGen] User Selection of Building type
-
Assuming there are numerous types and styles of buildings available to choose from, how will the user select what to build where?
The road generator is able to create blocks which I assume become real estate for building on. From a code perspective, I am thinking of a Block as being a Ruby class which contains a list (Array) of plots (Sketchup::Face's) In SketchUp, a Block is a Sketchup::Group.
For quick building-up, the user could assign "zones" to entire Blocks - i.e. residential, commercial, industrial, etc. The use of colors for the assignment would be consistent with how the roads are being selected. Or the user could manually divide a Block into plots, and assign a building type to each plot (using color again?)
So a Block could contain from zero to many plots on it depending on its zone, or other attributes. Plots can be manually created, or automatically created and assigned a Building type.
-
That's what I had in mind as well.
I'll hopefully soon get a webdialog up and running that will define road types.What I was wondering was if the plots would be another module? Seems that it quite a bit of work a plot generator would have to do to divide the blocks into plots depending on the type.
In order to detemine the building type to build, say we have a ID string for each generator. When you define a Plot Material you then include that ID string in the name. When the building generator traverses all the plots it will know which building module to run for each specific plot.
Just throwing some ideas out there.At the moment, when the Street Generator generates any geometry, it tags it with the module ID and version. That way it's possible for other modules to determine if a group is City Generator content and also what the content is. It can also determine the version of the generator in case you need to check for features by a specific version.
-
Would using Layers and color-by-layer have any advantage over using colors? It's easy to select and put things on layers, and color-by-layer is a good check to see if you have missed anything.
Also, how about putting created object on layers by default - a Roads layer, Blocks layer, and so on.
-
@jim said:
Would using Layers and color-by-layer have any advantage over using colors? It's easy to select and put things on layers, and color-by-layer is a good check to see if you have missed anything.
Also, how about putting created object on layers by default - a Roads layer, Blocks layer, and so on.
That's an interesting idea. I think I like it.
Then I think that the core should have a layer manager that defines the layer name and colour so the user can configure to fit peronal preference. We then use an attribute attached to the layer with a layer type ID.Question is, should definition by layer be optional? Some might prefer not to create layers?
-
Ive actually never used color by layer, so I'm not too familiar with any benefits it would add, but it sounds good to me. Does it make it so that you can have materials/colors assigned to an object in regular mode. Then switch over to color by layer, and it will recolor everything by the color of the layer? So you could switch back and forth quickly to go from "realistic" view to a color coded view of the built buildings? THat would be very interesting to me. I'll ply with it to see if it does what I am imagining.
And I think that grouping things is a solid idea. And probably tag all groups with some attribute library, like thom is doing with the cty_gen core version.
Would it also be interesting to populate a global array (or not global if possible), maybe its an attribute library on the main model object. But populate arrays or libraries of say all blocks. So that instead of the core having to iterate over the entire model looking for "blocks", it already has a list that has been populated for it. Maybe that is redundant though because of all the coloring system. Maybe it just gets in the way. I haven't thought it through entirely (obviously).
Hereis what my vision has been for the building generator core.
It should be a web dialog that has a list of all building types (High Rise, Low Rise, Residential, Castle, whatever). That list would be populated by the folders inside the Buildings folder. So if a new developer wants to create a new building type - just create a new folder for it.
Then you can assign a color to each building type in the list. Or not assign some building types, so you don't have to build castles and lunar skyscrapers in your contemporary city.
Then you click on a building type - say High Rise. And another list next to it is populated with all the different high rise modules that you have installed. And lets say you assigned red to high rise. So now you have a list of all building modules that will be randomly assigned to the red building footprints. You ca turn off or on these modules. Also a slider for the random percent that the building should be generated. So some buildings can be more common than other types.
Then as you click on each building type, you also have a series of drop down menus for each module - whatever they install. These could control the min/max heights, the colors? I don't know. Whatever settings the module creator can think to put into a menu that would control how their buildings genearte themselves.
And that is how I am envisioning the core for the building modules to work. I am planning on making like 5 VERY QUICK modules for 4 building Types (5 of each - High Rise, Mid Rise, Mixed Use, Inudstrial, Single Family home). Just so we have some more modules to play with while attempting to make a web dialog that can accomodate them.
How does all that sound. Does it fit in with what you folks are thinking of? Am I waaaay off base?
Chris
-
I just tested color by layer and it does what I was hoping. It lets you quickly switch back and forth between the colors/materials assigned by the module and back into the color coded view.
Can the layer color be controled through the API? I'll go check.
I didn;t see it in the API. Is it possible in an attribute library attached to the layer object or something? I might only like this if it lets us change the colors through the API. Maybe its not the end of the world if we can't - as long as the user can change it in the layers menu maybe thats enough.
Chris
-
@chris fullmer said:
Would it also be interesting to populate a global array (or not global if possible), maybe its an attribute library on the main model object. But populate arrays or libraries of say all blocks. So that instead of the core having to iterate over the entire model looking for "blocks", it already has a list that has been populated for it. Maybe that is redundant though because of all the coloring system. Maybe it just gets in the way. I haven't thought it through entirely (obviously).
Since the DoubleCut plugin I'm very hesitant to keep references to SU elements. AdamB even warned me about that.
We wouldn't have to loop through the whole model, we could just check the definition table.
@chris fullmer said:
Can the layer color be controled through the API? I'll go check.
I didn;t see it in the API. Is it possible in an attribute library attached to the layer object or something? I might only like this if it lets us change the colors through the API. Maybe its not the end of the world if we can't - as long as the user can change it in the layers menu maybe thats enough.
RenderingOptions['DisplayColorbyLayer']
http://code.google.com/intl/nb/apis/sketchup/docs/ourdoc/renderingoptions.htmlI'm thinking a Toggle Construction mode could be useful to set up the Style correctly. Core feature?
-
When I think about buildings, I am beginning to think that they should be .skp files in the buildings folder. Then instead of drawing building using Ruby, you load the component, add the instance, rotate, and scale. They can still have custom attributes/contraints attached.
Think of making them Dynamic Components which can then be manipulated via ruby after being placed. In fact, DC's are redrawn upon insertion in the model, and if it is programmed with some random methods, quite a lot of diversity can be obtained simply by inserting the same component.
It would also make for a whole lot more building types because there are a lot more people who can draw a building than can program a ruby to draw one.
Just a thought I had.
-
@unknownuser said:
RenderingOptions['DisplayColorbyLayer']
I meant I was hoping to be able to control the color of each layer through the API so we could do it in our webdialogs. I don't think its possible though.
@unknownuser said:
I'm thinking a Toggle Construction mode could be useful to set up the Style correctly. Core feature
Yeah, I think that would be nice. Could be a button in the toolbar.
@unknownuser said:
We wouldn't have to loop through the whole model
Ok, as long as we don't do large loops through the model.
And goodnight, its 1:26 here and I have been making Apricot Jam all night. I'm finally done and I'm going to bed!
Chris
Edit: Dude, Jim just posted. and its like 3:30 or 4:30 in the morning there. Are you just getting up or haven't been to bed yet?
-
I can't/don't sleep anymore.
The down-side of color by layer is that the colors can not be set from a plugin.
-
@jim said:
The down-side of color by layer is that the colors can not be set from a plugin.
That's annoying... hm...
-
-
@jim said:
When I think about buildings, I am beginning to think that they should be .skp files in the buildings folder. Then instead of drawing building using Ruby, you load the component, add the instance, rotate, and scale. They can still have custom attributes/contraints attached.
That's an option. But that will limit their shape. If you have an irregular street layout you'll end up with irregular parcels and buildings. So some generation from scratch would be needed.
But if it's pre-fabricating buildings to they'll have more details then cut-out glue-to window/door and detailing components is also an option. That way you can generate the volumes and populate it with detail components.
-
I see benefits both ways. What about leaving it so that its rubies that make the buildings, but what about one module that instead of making its own buildings, just loads building models from a directory. Or even multiple directories if people want to be able to subdivide that module into different building types.
Is that just overly - complex? I am imagining making it as simple as possible, but perhaps its just too much.
Chris
-
I had imagined that there's be building generator the made everything from scratch and then there's be ones that used Components to build buildings. All depending on what type of building you want.
-
@chris fullmer said:
Is that just overly - complex? I am imagining making it as simple as possible, but perhaps its just too much.
I don't think it is overly complex. The control program would not have to know how the buildings are being added. What matters is that all Building types respond_to? a .build() method.
So the controller just calls the .build() method on any type of Building, and all Buildings must repond_to? the .build() call. But each type of Building will do something completely unique in its build method.
-
So building class should be based upon a Building class maybe?
-
Arg!!
You can't modify the material name via the API.
Nor can you delete a material.With layers you can set the name. But then there's the problem of colour. Guess the user have to manage the colours completely. ...but I'd rather have different materials per street/building type than a layer...
I saw that VfSU uses some hack to work around renaming and deleting materials. They replace the existing with a new material and then apply all unused materials to a dummy group before they purge the materials. ...I don't want to use such a hack...
grumble
-
With the good quality selection of tiling building textures over at http://www.cgtextures.com/ it would be very cool to have a building generator that let you generate building with different textures.
-
Can we package those materials ourselves? Or are you thinking more like just make a generator that will place any specified material onto the walls?
Chris
Advertisement