The engine's called "OctoPort", originaly it was to combine Octrees and Portals technologies.
Coding style is "weak hungarian", required parameters are references, and optional are pointers, at least for the public interface.
The engine have different modules:
-IOModule, which is responsible for I/O operations and is plugin based, easy to extend. It works with OP (short for OctoPort) by filling memory slots, so it's critical that plugins are well coded to avoid memory corruption.
-OctoPort have the following "interfaces":
As a 3D engine user you have a very simple interface to create objects and nodes (need some work BTW)
As a 3D effect coder you write "RenderPath" which are DLL files controling the rendering for a Mesh. (Easy to extend)
As a 3D engine coder, you have insight of the engine itself which have the following "Items":
*SceneGraph : Direct Acyclic Graph (DAG), it's a combination of spatial and hierarchical structure, with different base class to derive from depending what you want to do (spatial clustering, new mesh types...)
*Model management : The engine uses Models that are instanced as Objects exclusively, Objects have the smallest subset of data possible. (Share as much as possible through the Model)
*Cache mechanism : All resources are loaded on demand. Textures are managed in a simple Memory Pool given priority. Buffers are managed in a "sliding slot cache" which auto adapts given load. FrameBuffers (RenderTargets) are managed in an Array (not flexible, have to redesign it)
*RenderPathManager : This manages the RenderTree which is state change optimized, and also allow a 'broad' ordering of the scene. It does a depth first pass, but it needs some changes. (Make it simpler and combine lights/shadow maps per Pass).
ATM, it lacks any GUI, I have a design and it has a place set in the RenderTree already, but I never coded it.
Not too keen on giving it away for free, but can definetly grant a free licence for that game.
Coding style is "weak hungarian", required parameters are references, and optional are pointers, at least for the public interface.
The engine have different modules:
-IOModule, which is responsible for I/O operations and is plugin based, easy to extend. It works with OP (short for OctoPort) by filling memory slots, so it's critical that plugins are well coded to avoid memory corruption.
-OctoPort have the following "interfaces":
As a 3D engine user you have a very simple interface to create objects and nodes (need some work BTW)
As a 3D effect coder you write "RenderPath" which are DLL files controling the rendering for a Mesh. (Easy to extend)
As a 3D engine coder, you have insight of the engine itself which have the following "Items":
*SceneGraph : Direct Acyclic Graph (DAG), it's a combination of spatial and hierarchical structure, with different base class to derive from depending what you want to do (spatial clustering, new mesh types...)
*Model management : The engine uses Models that are instanced as Objects exclusively, Objects have the smallest subset of data possible. (Share as much as possible through the Model)
*Cache mechanism : All resources are loaded on demand. Textures are managed in a simple Memory Pool given priority. Buffers are managed in a "sliding slot cache" which auto adapts given load. FrameBuffers (RenderTargets) are managed in an Array (not flexible, have to redesign it)
*RenderPathManager : This manages the RenderTree which is state change optimized, and also allow a 'broad' ordering of the scene. It does a depth first pass, but it needs some changes. (Make it simpler and combine lights/shadow maps per Pass).
ATM, it lacks any GUI, I have a design and it has a place set in the RenderTree already, but I never coded it.
Not too keen on giving it away for free, but can definetly grant a free licence for that game.
p) and RenderTree/RenderPath mechanism.
