OctoPort
Forewords
I
originally planned to make a small game based in my RPG gaming world
"Fédia", then I have been swallowed by the wonderful world of 3D chips,
and worked to make a "high-end" 3D engine...
I intended the engine to be Simple, Fast, Efficient and Elegant, which should lead it to be easily extended.
Simple and Fast work often together, Efficient is a continuous tradeoff
between CPU time & memory consumption, and Elegant means it has a
complete and minimal interface, making it easy to use :)
The name of the engine was built up combining two words together (Octree & Portals), now I'm used to it and even though it's a lot more flexible than simply managing Octrees and Portals (and Sectors [convex areas]) thanks to its potent SceneGraph.
Current Status
OctoPort is discontinued as of version is 0.9d* (0.9 Development *), my efforts are now on the FlExtEngine.
The 3D rendering engine counts around 45 000 lines of code (50 000 with utilities), for around 315 class.
(Number of lines evaluated by counting newline ('\n') characters in all of the .h & .cpp files.)
Brief Version History
The engine went through several rewrites, some from scratch, others were significant changes. I started with version 0.1 which was basically a NeverWinter Nights renderer, then I moved to something a bit more capable to reach version 0.3 which added both "scripted shaders" and Quake III rendering capabilities. That was good, but there were some ideas I had since the beginning I hadn't implemented, and it wasn't flexible enough to me, so I moved to DLL based 'RenderPath" (named after programming paths used for different chips in rendering engines), enhanced RenderTree and "adaptative" cache slot mechanism (I melted my original ideas together with those described by people on GameDev.net [Most notably Yann Lombard]), that lead straight to version 0.6, version 0.7 got a "full fledge" SceneGraph.
Version 0.8* effort was on debugging and adding features, most important was the Shadow Map management I wrote and generalised to "FrameBuffers", so that any RenderTarget (a FBO is made of 1-n RenderTarget(s)) was managed alike, with a priority mechanism and RenderTargets being distributed accross resources (be it Meshs for Relfection/Refraction or Lights for ShadowMaps).
Features
Use of an IOModule (Virtual File System) which have a PlugIn architecture, making it painless to add new file formats support, and streaming/multi-threaded I/O operations.
Effect PlugIns, allowing easy extension of the rendering effects available to the engine, with fallback mechanism to select the best Effect PlugIn given the hardware capabilities.
API Indepenant Renderer PlugIn, allowing to choose the Renderer and add Renderers for new platforms.
SceneGraph, allowing easy internal extension mechanism, add geomipmap, chunkedlod, new spatial subdivision algorithm (Quadtree, kDTree...), new objects...
RendeTree, for optimal (reduced) state changes rendering.
