Coming back to Road Map

I've been asked many times to diffuse the source code or to distribute a licence of my engine. In one hand, I feel very proud with it but in the other hand, it's clear that the engine is not ready to be diffused in it's current state.

As you may have noticed, I dodge bugs instead of resolving them. Every exception is detected by the engine and is flagged as "not working", then abandonned or used for other thing. For instance, a Lot on wich the offset opperator generate a bug is isolated, and the engine try no more to use the offset operator on it. Instead of a building, you'll have a beautiful Parc :)

So I've worked on the engine to resolve the most ennoying bugs. And the more sensible part is the road map generation. There were coincident or collapsed segments, short angle or length that generate, many layer later, tons of bugs.

I've enhanced these exception detection and managed the cases where theses bugs appears. I also worked on the highway pattern, changed somes rules with minor and major, and change the graphics for a more "google maps" one.

This road map of 20 000 lots (a fifth of inner Paris) is generated without any bug, in two or three seconds.

Shapes optimisation, Episode II

One of my main difficulty now is to "group" shapes in the scenegraph, because there are to many objects to manage. I can't group an entire building when modeled because of two reasons :


 - My scenegraph JMonkey Engine can't group objects with different textures.
 - As I said before, all shapes are manipulated by the scenegraph and can't be grouped before the rendering.

So I made an algorithm in my modeler, that looks for shapes with identical attributes and post-process like same textures, same rotation axes, same altitudes... and group them in real time during modelisation.

This method is very light and save a huge amont of memory, especialy with big buildings. But the code is not that simple and requires some more work to be implemented.

Here are some visuals of the grouping system in action.

 

The Highways

Here is some news of the road network generation with the implementation of a new pattern : the Highways.

This pattern is quite specific because you can't grow a highway randomly like the other roads, considering only the population density. So I've updated my population density management with an interpolated randomly generated map. It works exactly like a basic landscape generator.

When the population is in place, the engine "casts" a highway in direction of the future city, but when the highway touches high population area, it choose between passing through, or turning around. Algorithms are still to be enhanced but the result is interesting.

Navigator and different level of "on-the-fly" generation

The navigator is implemented, and thanks to the graph of the road network, I can grab the containers near the camera without searching in all the road segments list. It is quite fast and efficient.

The navigator grab containers in many circles with different radius. Each radius has a generation level assigned. So I created the Context Updater which is a thread running in background, and generate/degenerate the shapes of the grabbed containers in fonction of their distance to the camera. This thread updates each time the camera moves.

The Context Updater can be late or killed because of the time and memory necessary to generate shapes. For exemple, in the video above, I can't get into the city centers because there are too many shapes to compute (100mo needed for only one high building). I will have to optimise my shape structure to avoid that problem.

For now, the Context Updater seems to work fine. It does the same job than a LOD system, but while a LOD show and hide different detailled versions of a model, my thread creates the content from a seed in real time, and degenerates it when it's not needed anymore.

Organisation of shapes

For a long time now, I'm working on the optimisation. Not to get some more performance or more fps, of course, but to make the program work in the future modelisation complexity.

As we saw a few posts earlier, the road network generates ground divisions which are the initial shapes of all my city elements. Some rectangles representent sidewalks or street lanes, concave polygons are used to get crossing area, and generaly convex 4 cornered polygons are lots. Each shape store its own rule of modelisation, and each rule generates new shapes, assigning new rules. This system can grow up any kind of model by recursive call.

But in this architecture, all shapes have the same canvas and belong to a unique level of definition : "city element". This is not enougth for my needs cause I need to store data like building type, number of stages, etc. So I created shapes containers.

The containers are organised in a tree, like a hierarchical visualisation of the city elements. For exemple, lots contain one park and many buildings, buildings contain a number of stages, stages store their facades and interior design, facades link to border walls and wall tiles, etc. While modeling shapes, the tree of containers is generated on demand. For exemple, when a lot rule is applied, it creates a park and a footprint, which will both create their containers and declares associations.

The system is quite strange to manipulate, because there are some bilateral interdependances (shapes own container that own shapes) but now the framework is done, it is transparent and works fine. Every shape organizes itself in the parent container, or creates its own that is declared to the parent. Every connexions are automaticaly managed while modeling.

Now, I get containers that store all necessary seeds and data about what to generate, and I can grow or erase any generation level that I need for any container.

Next step :  get a navigator that find nearby containers.

More rules, less bugs, new design !

Here are some visuals of the app after core modification to avoid generation of bugging polygons, and some few work on modelisation. My first video is also available on youtube (see below), showing the generator in action.

Performances

I've done some tests of optimisation with JME3 to increase fps and low necessary memory usage. The first step was to merge the geometries together and it worked well, my framerate increase dramaticaly.

Their is still two problems : the quatity of materials will certainly growup with rules addition and JME can merge only objects with same material, so I will have to test this optimisation method with more realistic rules, and the memory is still overflown because of the number of geometries generated before optimisation, but JME is no culprit for that (as Normen said).

My little 2D extruded system have one big inconvenience : I need to make one mesh for each object before optimisation, because the scenegraph is the only one capable to move and rotate my extruded polygons. So I do many meshes, transform them, then merge them together as much as possible. It takes a long time and memory space. This is a large failure in the object architecture, because formaly, the view code is reponsible of the model modification.

I should get my own 3D prisms and transformation code in the model, so I can manage my objects and merge them as much as possible in one unique mesh, that should be given to the view. Whatever the scenegraph or rendering method I use, this is what I need to do.

Here is a pic to see JME optimisation method : it's not perfect (Ardor, for exemple, makes a global merge and store different materials in a unique packer) but it does the work : 800 000 triangles and 50 fps.

After somes tests and tries, I finaly get my way out and get a correct result with some hundred meters radius full generation and rendering. Of course, I will need to merge vertices and to use a LOD system, but for now, JME performances are quite good. 3 millions of traingles, 4 thousand objects and still 18fps. Thanks to the community for its help !

But my architectural problem still exists and I need to add a transformation layer in my model, and to rewrite some parts of the 3D framework to manage rotation and other stuff myself. Due to the big specialisation of my geometries, I think there are very good optimisaiton opportunities, so I now what to do now.

(This city made of  250 000 shapes occupy 600 mo in the memory : 50 for the model, 500 for the view, 50 for the control)