[CityGen] City generator
-
@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.
-
I like your tihnking
-
.
-
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
-
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.
-
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?
-
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. -
@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.
-
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.
-
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
-
@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.
-
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
-
@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...
-
@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.
-
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.
-
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
-
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.
-
@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.
-
I really wish there was an MaterialObserver event that returned the entity being painted...
-
Its ok, we can do it without it. I'm a little scared of observers currently. Maybe I'll get over it, but I feel like they are so shaky....
I see it as a process like this:
Paint road centerlines
click "Generate Roads"Paint or auto-paint faces
click "Subdivide Land into Parcels"Click "Generate Buildings"
And done.
Each of those windows would have an available simple interface, or also an expoert mode with lots more bells and whistles.
So there's no need to watch what is being painted one at a time, you can jsut iterate through everything in the "generate" process.
Chris
Advertisement