Deeplayer 3D code - /root

Documentation generator.

LiteSQL could form the basis of persistent containers. Say, for instance, many space stations modules are available, and stations around planets are all different aggregates or composites of such modules, which may evolve in time. How do we save the structures to disk? We could write serialization functions for each class, but if we evolve all our composites into SQL databases, then we can use liteSQL as a general storage back-end.

I’m thinking of using STLport for the sake of portability. Yes, the STL is a cross-platform standard; but extensions to it are not, such as hash_map<>.

We’ll need to rationalize shader management, somehow. It occurs to me we could have abstract template classes for vertex and fragment shaders. Variant set, for example, could be a type-list type that’s given as a template parameter, to ensure matching between vertex and fragment intefaces. Each classification of shader features could have an associated template parameter. Then, each template parameter would cause the inclusion of code to enable its associated feature. Special combinations could be handled through template specialization. The idea, of course, being: To have shaders auto-generated.

feature.h

interpolant.h

interp_list.h

vert_feature.h

frag_feature.h

light.h

color.h

pixel.h

texture.h

material.h

Geometry here is dealt with in abstract units and representations. Numeric types are template parameters. Dimensions are unit-less. Notice that the Ogre .mesh format is unit-less, as well, so these classes could represent a loaded .mesh file.

However, for Deeplayer3D meshes, I suggest we create a new format: Pretty similar to Ogre’s .mesh, except in at least three respects: Progressive meshes, instead of LOD’s; the mandatory units and scale; and highly compressed. We could call it “.dform”, and add vertex deformation shader code to the format. Food for thought: Might also contain physical bonding, and other physics-related data, plus references to “real materials”.

Idea: As a scene is put together, elements are indexed by x, y and z. These indexes facilitate the fast generation of draw orders and other queries requiring sorted access along any arbitrary line. Again, Ogre has a scene ray query mechanism that returns an ordered list of elements hit; but I’m not sure how fast is it, or whether it would do for all purposes.

Autopilot evolutions: