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:

Truly, a hack of auto_ptr<>, dark_ptr<> is an identical clone, but its pointer is declared mutable, in order to make its release() function const, in order for the assignment operator and copy ctor to declare their rhs argument const &, in order for the copy ctor and assignment to be recognized as standard copy ctor and assignment, so that dark_ptr<>’s can be placed in STL containers. (You can’t place auto_ptr<>’s in STL containers.)

dark_ptr.h

Just a set of macros that allows you to write,

    $  < some code >;

instead of

#ifndef NDEBUG
    < some code >;
#endif

dollar.h

Just a hack that allows you to write

 _ensure_ s && ::strlen(s);

instead of

 assert( s && ::strlen(s) );

the point of it being rather cosmetic: “ensure” is an Eiffel keyword I miss

ensure.h

Invariant is a poor man’s implementation of Eiffel’s “invariant” keyword and semantics. It allows you to define a debug mode function for a class that checks its state for consistency. An invariants-checking type (”trigobj”) is also defined, which you place instances of as the first variable of any non-const public functions. When these instances go out of scope, their destructors trigger a check of the invariants. Helps catch bugs. I say it’s a poor implementation because it cannot easily be made to check parent class invariants from within derived classes, and so on, the way Eiffel does. Comes chock-full of macros to ease typing.

invariant.h

invariant.cpp

invariant.doc

Simply a pair of macros to wrap the opening and closing of namespaces, so that they don’t mess with the editor’s auto-indenting.

namespace.h

A header file that includes other header files that are always needed, or often enough to warrant their unconditional inclusion in all header files elsewhere.

prerequisites.h

Many parts of our engine design seem to be evolving towards batching. The galactic sky to be rendered in batch mode to a cube texture; systems generated initially pseudorandomly, but then simulated in batch mode to weed out unstable elements; planets generated in the cpu and bodies of water modelled heuristically in batch mode, in anticipation of approach... Probably the same will happen with npc spawning, simulated traffic and trade and economies. With so much batching going on, we should start thinking about some template utilities that will make the job easier. Essentially, some constructs that ease implementation of co-routines.

Template class that abstracts sharing and usage of unique items. Example: Textures take up room in a videocard; you wouldn’t want any texture loaded twice onto the videocard. But how do you know whether it is already there or not? Findshare internally uses a hashmap. Use texture filenames as the key, Ogl names as the value. All you do is call get_handle with a filename. Findshare does the rest. Bad example; Ogre already has something like this for textures; but can be used for other things.

This implementation, I believe, was using SGI’s STL’s hash_map<>...

findshare.hpp

Test file:

findshare.cpp

To do: I’ve had to change this code 3 times due to differences of hash_map implementations; I think it would be best to change it one last time: port it to stlport.

The Brook/Spirit thread-safe library will serve the gpu-computable needs of more than one thread. I’m calling it “Brook/Spirit” with the idea that perhaps a simplified Brook language parser can be implemented with the compile-time boost::spirit library.

Controls the generation, updates and retirement of imposters. Imposters are billboards that replace 3D objects with sparsely updated off-screen rendering updates.

This is a boost::filesystem class wrapped in a findshare class, wrapped in a prefetching and retiring queue. fetch(fpath) causes a file to be fetched from disk in advance; get(fpath) opens the file, which, hopefully, has already been prefetched. Writes are queued and given lower priority.

The main thread’s mission is to run Ogre3D, and to get the other threads started. But it will also be in charge of initializations, and monitoring thread balance and work scheduling.

Physics includes collisions. The two things, IMO, should go together, because they share too much data to be separated, and because during a collision, physical simulation steps may need to be reduced, and physics and collision take feedback from each other. But I could be wrong.

Shouldn’t AI be thrown in with the physics, then? Raycasting is akin to collisions; shares the same data...

My current idea is ‘not’, though it might change. My rationale is this: There’s a fundamental difference between physics and AI: Physics needs to be continuous and consistent at all scales in space and time. From planets to pebbles in dimensional scale; and if we have a complex collision of numerous objects, the physics may need to use micro-stepping, or even iterative processing to find out the exact time and place the collision happened between any two frames, to do a decent job, for example. None of this is necessary with AI. In fact, the nature of neural paths is such that signals propagate at a finite speed, and probably one raycast per A-eye per frame would suffice. In other words, the AI can live with the paradigm of queue-ing up queries for the physics, and wait for the results in the next frame, or even the frame after that. No big deal. And if the AI can be decoupled from the physics via message passing, that’s a big plus in many ways:

• Helps decouple dependencies.
• It allows more threading.
• Helps, in the future, adapt the sources to use independent physics and AI accelerators.
• Makes it easier for modders, who can then write a dll for physics overrides and another dll for AI overrides, independently.