Thanks for your patience ;-). I hope everyone working in the software industry understands why projects get delayed or postponed. Especially in a small team we sometimes have to commit to third-party-projects for financial reasons and that takes away time and key personnel from our own projects.
About the current state of DigitalRune Graphics:
We try to make it extensible, so that users can write custom pipelines, new shaders and post processing effects. Users should get access to the same engine values and buffers as the predefined effects.
Things that are currently working:
Scene-graph like structure with perspective/orthographic cameras, lights (ambient, directional, point, spot, projector), models, etc.
Frustum and light culling
An extensible shader binding system that uses standard annotations and semantics to automatically bind shader parameters to predefined or custom engine values.
Predefined shaders and effects:
lighting, normal mapping, parallax occlusion mapping, environment mapping
Shadows (with regular PCF Filtering, jittered sampling, ESM, VSM, CSM/PSSM, omni-directional/cubemap shadows)
State sorting for materials
Post-processing framework using:
blurs (box, Gaussian, Kawase, radial blur), motion blur (camera-based, object velocity-based), depth-of-field, god rays, grain, SSAO, sharpening, and more.
HDR with bloom and adaptive tone mapping
Windows Interop:
Controls to display graphics in Windows Forms and WPF (for game editors)
Other stuff:
Skyboxes, atmospheric scattering, lens flares, procedural noise, debug renderer (for primitives, text, shapes, …), shader editor, ...
Things that are still in progress (in arbitrary order):
volumetric lights, offscreen particles and soft particles, occlusion culling, decals, mesh instancing, rain/snow, terrain/water, ...
(Some of these might not be in the first version.)
Some more background info and thoughts:
Last year, DigitalRune Graphics was postponed for an unfortunately long time because our graphics specialist (MartinG) was kept busy by third party projects, and the other modules (GUI, Animation) were needed for side projects or customer requests.
On the other hand, since we finished the non-graphics modules first, this has lead to a clean and modular design of our game engine. In my opinion, many game engines are too graphics-centric because engines usually starts as a graphics engines and later new features are added onto the graphics core.
In the last year we have also learned a lot about API design which lead to a redesign of the graphics API. Now we know how things like particle systems, animations and GUI need to be integrated with the graphics engine.
Btw., let us know if there is any feature that you would expect from our graphics engine that we have not mentioned so far.