mardi 17 mai 2011

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.