I've added the name poll, and I'll be starting work on the renderer fairly soon. The code will be stored in a mercurial repository on BitBucket here:
https://bitbucket.or...-engine-project
Right now, I'm thinking the renderer can be split up into a few systems:
- Draw Pools
- -- Opaque Drawpool
- ---- Renders all opaque objects to a geometry buffer
- ---- Special considerations for static geometry for light mapping (later on down the road)
- -- Alpha Drawpool
- ---- Handles pretty much any kind of alpha-sorted (back to front) geometry
- ---- Would handle lighting using "forward" rendering; could be a viable fallback basis for hardware that can't support deferred
- ---- Same special considerations for static geometry for light mapping as Opaque
- -- Effects Drawpool
- ---- Handles things that may not need to be rendered in the correct order
- ---- Good for particles, and other effects
- ---- Computationally cheaper than proper alpha blending
- Material Manager
- -- Uniform management
- -- Shader management
- ---- Manages what shaders need to be loaded at runtime
- ---- Interprets the material format to assemble shaders that are capable of executing faster at runtime (to mitigate runtime compilation overhead)
- ---- Assigns shader Uniforms as needed to linked shaders
- Post Manager
- -- MRT management
- ---- Would (eventually) assist with geometry buffer size
- ---- Could be used to manage more complex post processes that require multiple sources of data
- -- Effect management
- ---- More or less something to simplify managing what kind of effects should be enabled or disabled and when
- Capabilities Manager
- -- Checks which extensions are available on a system
- -- Enables or disables features as needed depending on hardware support, and known driver issues (I.e., mixed FBO color attachment formats on some known older drivers doesn't work, or uniform buffer objects being disabled on drivers that don't have complete support for them)
- ---- Would be used as a fallback system of sorts in some cases where a particular piece of hardware doesn't support a particular OpenGL feature for a feature
- ---- Could also possibly lower settings on some systems that just can't perform very well with some features
This is just a really rough outline of my idea for a rendering system.
The very beginnings of it will focus on getting a working deferred renderer going with OpenGL. The deferred renderer will be following a minimal geometry buffer design, opting for light-prepass instead of full blown deferred shading.
The buffers for all of this will look like this:
+------------------------------------------------------+
|RED | GREEN | BLUE | ALPHA |
|Normal X | Normal Y | Normal Z | Spec. Exponent | Geometry Buffer - 32-bit render target
|Red Light | Green Light | Blue Light | Specular | Light Buffer - 32-bit render target on some hardware, 64-bit render target on capable hardware
+------------------------------------------------------+
The light buffer will either be compressed into a range of 0..1 likely using exp2/log10 compression on hardware that can't support mixed FBO formats, or be stored in a 64-bit floating point render target (16bpp). It will then be multiplied against an object's diffuse texture, producing the proper lighting across a surface without the need to use a larger G-Buffer to store geometry information. This approach will work a bit better for hardware where memory bandwidth is an issue.
The specular technique used will likely be blinn-phong, possibly even energy conserving blinn-phong. Gamma correction will be taken into account from the very beginning for diffuse and specular textures.
You can effectively consider me the Graphics Programming Lead at this point.
This post has been edited by Gen: 24 February 2012 - 04:03 PM
Twilightzoney 
03
(I.e. lightsource contribution in relation to surface albedo, etc.)
