[CityGen] City generator

thomthom

What I was thinking was something that looks fine, not a simulation. Something to quickly bulk up the major features.

As I mentioned before, I was thinking it could be in modules, each doing it's own thing.
One creating a city street map (just centre lines)
One creating roads and blocks out of centre lines
One populating blocks with pavements and buildings.
etc..etc... this could be expanded

You could execute each of these modules separately, or you could put together a macro.

I was thinking that the starting point could be large faces, where you define the type and style of what's being generated there.

Not sure what's best to visualise this as a UI, But I wondered if using Applying special materials with the paintbucket would be a easy way to defines area types. Also for roads, when you have just the centre lines - one colour would mean main roads (wider), another colour sideroads, alleyways etc...

A suggestion for organizing the modules:



module SU_City_Builder

  # Common sub-menu in the menu bar

  module Street_Map_Generator
    # Generates the street centre lines
  end
  
  module Street_Generator
    # Generates the street geometry
    # And blocks in between
  end

  module Building_Generator
    # Generates buildings on a block
  end

  module Transport_Generator
    # Populates streets with transport
  end

  # etc etc etc...

end # module end

remus

Personally i dont particularly like the idea of having the user define the road types. It seems like it would require a fair bit of work/thought on the users part which doesnt seem to fit with the 'quick bulking up' thing. Then again it would be pretty tricky getting a plugin to work out which roads are large/medium/small ponder

I like the idea of modular structure a lot Lots of room for adaptability and adding new bits.

thomthom

@remus said:

Personally i dont particularly like the idea of having the user define the road types. It seems like it would require a fair bit of work/thought on the users part which doesnt seem to fit with the 'quick bulking up' thing. Then again it would be pretty tricky getting a plugin to work out which roads are large/medium/small ponder

The user would only have to specify the road types if desired. Default settings could be a uniform type.

If the user used the Street Map generator, it would do this for the user. I was thinking having a few lines running long that's be the main roads, which would be wider that normal, then most others would be normal roads, with a few alleyways. If you use materials to define road types then it's easy to work out what's a large/medium/small road. When the module that generates the street from the streetmap reads an edge, it'd read the material of each edge segment representing a piece of road. The benefit here is that the user can visually see the type of road and quickly make changes if desired.

The idea what that the user only adds as much information as desired. It can be very simple, but further controls is available.

remus

I like your tihnking

kwistenbiebel

Chris Fullmer

Excellent! I agree 100% with everything said. That is all very much what I had in mind too. I also think the color coding idea is ideal.

So say a user provides a base city map with building lots and roads already in place. They could color each parcel for its land use - high rise, mid-rise, park, plaza, subdivide residential lots, etc. I think these land use types should be integrates somehow sot hat someone else with some ruby knowledge could crete their own and incorporate it into the plugin, and distribute them for otherrs to use if desired. Because the examples I gave are great standard ones, but maybe someone else would like to build 5 differentl castle types to use, etc, etc. And it all works based on just coloring flat faces, and then running the building generator with your own set of buildings/landuses.

This is great, and I like that we are all thinking the same level of visualization The LOD idea is great too Remus! I have no idea how to implement it, but it sounds cool!

Chris

Marian

About the LOD, if it's possible ruby wise, this is how i imagine it; the buildings should be built in basic shape, without any components or textures, and any details like windows added should be other coponents. The user then can provide an area for render, and buildings in the are keep their tetxures and details, while the others outside it would be stripped off of textures and any extra geometry, leaving only the basic bulding shape.

remus

Digging in to the architecture of the whole thing: what do you think to having each module as a separate ruby script and then using global sets to communicate between the modules?

thomthom

The LOD could be increased by adding sets of glued components.
When you have a scene you want to set up, you can determine the distance of each building from the camera and add detailing components to the buildings closer to the camera. Though, the challenge I see here is how you define the rules for where these detailing components are added.

thomthom

@remus said:

Digging in to the architecture of the whole thing: what do you think to having each module as a separate ruby script and then using global sets to communicate between the modules?

hmm... I'd like to have it contained in some manner. If we have one base module name, which all the other modules are wrapped in, then we ensure that we don't contaminate anything else.

Edson

why not endow this with features that could allow it to be used as an urban design tool to boot? some kind of parametric capability could make it useful for 1000s of architects.

remus

Could you be a bit more specific edson? What sort of tools would you like?

Im not sure design tools would fit very well with the current visualisation slant, but a more design oriented plugin could be explored in the future.

Thom, wrapping the whole lot in a module is a good plan

thomthom

@remus said:

Thom, wrapping the whole lot in a module is a good plan

I think that if we agree on a base module name and set up a core script that contains a common menu and toolbar I think we could start exploring some practical examples.

I love how this thread has developed.

Chris Fullmer

I think the tool should work for certain tasks for urban designers and architects. All the roads and buildings should have parameters so that they are all built parametrically, using pre-defined allowances for height, floor height, window coverage, etc.

Thats all wonderful and important so that a single building type can be use to create random buildings using pre-set paramters.

But I don't want to get into designing urban design tools into the thing. Not at this point anyhow. Thats what modelur is for, right?

Chris

remus

@chris fullmer said:

I think the tool should work for certain tasks for urban designers and architects. All the roads and buildings should have parameters so that they are all built parametrically, using pre-defined allowances for height, floor height, window coverage, etc.

I like your thinking, although i think it would be good to hide these nitty gritty details in a similar manner to skindigo i.e. have one panel with a big 'make city' button and one panel with all the variables in.

Thom, how about City_Gen as a base module name? nice and simple...

Edson

@chris fullmer said:

But I don't want to get into designing urban design tools into the thing. Not at this point anyhow. Thats what modelur is for, right?

Chris

chris,
you and the others, as the authors of the soon-to-be great plugin, should be the ones to decide in which direction it goes. it is just that i have been craving for an easy and cheap urban design tool for long. modelur is still a WIP; it is not a full blown UD app yet.

i can hardly wait what you guys will come up with.

regards.

thomthom

I think modelur will be released before this project will have its first release.

But feel free to express your ideas. One of the main things here is that due to modular design, things can be added by anyone. So if you describe your idea it could be picked up by someone that'd be interested in contributing.

Chris Fullmer

ok, its taken longer than expected (due to some modeling snafus on my part) but here is a quick mock up model that shows a possible workflow. It starts at the user drawing road cetnerlines (which really could also be automated) and continues on to a full built city using some of the idea's we've expressed here.

And even if I didn't specifically say it, everything in my mind is modular also. So the road creation is only one possible way to create roads. Same with the block subdividing, and the buildings. The buildings were made quickly using my greeble script. It would be more interesting to seem them with real textures on or made with real architectural detail to them. But that will come in time.

Chris

city builder.skp

thomthom

Nice presentation Chris.

I've been wondering how you define what the colour coding means.

Take the street building module for instance:
Default colour, means default settings of your average street. (Some dialogue would be required to set this I guess.)
Custom colours define more specific types - let say we use red for main roads. Do we bring up a new dialog to define these, or can we provide the info in the material name?

Example: CG_Street_Main_W15000
CG -> [Constant] City Generator. Initial tag to mark a material as a CG material.
Street -> [Constant] Refer to the module, or type which it's used for.
Main -> [Variable] String identifying the type of street.
W15000 -> [Variable] W = Width - variable name. 15000 is the variable number.

Is this a bit too technical? Would an average user find this an easy way to set up custom street types?

Or maybe it should have a dialoge to generate the appropriate material? It could still be a nice feature to keep the data in the material name instead of an attribute dictionary as it could easily be modified.

Chris Fullmer

@thomthom said:

Or maybe it should have a dialoge to generate the appropriate material? It could still be a nice feature to keep the data in the material name instead of an attribute dictionary as it could easily be modified.

I think it might be too technical to expect someone to be able to manually input that info into the material name. So a nice dialog would probably be beneficial. And it can name the material itself.