I've been working on creating a simple Cityscape with ZGE; it's supposed to be procedurally & randomly generated (of course) and contain basic collision detection (since it's going to be the level for the game). I've already made some small progress that I'd like to share here.
The first program generates a set of building blocks, each containing 9 randomized buildings, separated by sidewalk & street; I just tried to get a nice variety of looks from similar source materials. Apart from some blend-mode related glitches and the uniformity of the scene, I quite like the look.
The second is a simple implementation of a recursive area-splitter (this probably has a specific name to it, which I don't know); it starts out with a single square area and splits it into 2 uneven halfs everytime the Space key is pressed. The next time the space key is pressed, each of these is halfed again ... until there is a nice fractal (?) landscape. With some tweaking and conditioning, I've already gotten it to produce results that are very close to what I need.
The issue I am currently facing is performance, mostly; the building block-demo starts to impact performance at a size of 5*5 blocks ( 225 buildings, each with several nested conditions in the OnRender-component), the splitter starts acting up at around 512 areas (each one using 3DBox collision mode). My laptop is admittedly quite weak on the chest, but I guess these kinds of problems will appear everywhere at some scale. Having the entire City rendered & collided at once will probably be impossible at reasonable framerates, so I've been thinking about workarounds. I would be glad for some input here, since some of you are even familiar with ZGE's source and could put them in perspective more easily. They are:
- 1) using fully renderd & collided models only for the buildings immediately around the player, replacing all other buildings with dummy-models(that spawn the corresponding building when the player get's close)
2) using billboarded sprites instead of 3d geometry for those dummy objects that are close enough to still be viewable (all other dummy objects would just be empty)
3) separating collision & rendering: using actual models for the collision-detection of every building, but using only one single unified model for rendering all the geometry (by cycling through an array and rendering on demand). This one sounded better when I thought it up - the basic question is wether the amount of Model-objects actually impacts performance, and if any of that can be saved by some method.