Horde3D

Very good


This recent blog post could be interesting for you: http://mynameismjp.wordpress.com/2010/01/10/inferred-rendering/. And thanks a lot that you plan to share your work with the community!


All deferred shading/lighting techniques have a higher cost at first since the G-Buffer needs to be generated. Usually that cost is amortized rather quickly when you start adding light sources. But most advanced renderers are doing some z-prepass anyway these days to make better use of early z-rejection and since the depth buffer is required for post processing, so the additional cost should be acceptable.

Almost finished the pipeline today, just a bit of tweaking, and then cleaning up the code (coz it's full of commented out "experiments" at the moment!).

Specular is working as well as it can for a light-pre-pass type pipeline --
With the LBuffer, it accumulates the diffuse lighting in the RGB channels and the specular lighting in the Alpha channel (so that materials can mask out alpha later and keep diffuse).
In the final pass, I can only guess at the colour of the specular contribution (by looking at the diffuse light colour), which is close, but not exactly the same as the current forward/deferred pipelines.

Stippled LBuffers for alpha are working too

Love the retro look! Do you have any shots of the final image using this transparency technique yet?

_________________
Tristam MacDonald - [swiftcoding]

This is with RGBA8 GBuffer/LBuffers. 50% LBuffer resolution (which means 25% resolution for alpha polys).
The guys in the background receive very few usable lighting samples, and because they have strong specular highlights in this demo the highlights flicker on and off as they pass between LBuffer texels might have to add a "specular distance fade" uniform...


[edit - moved forward-alpha stuff to a new thread ]

Really impressive stuff. Getting access to node ids was definitely a great idea.

I cannot really see the benefits of this technique compared to deferred depth peeling (with the exception of speed of course). The lightning done at low resolution impairs the scene and specular most notably, i'd hate to see what it does to normal maps. And anyway, if you are going to half the resolution why not half the normal map texture resolution too?

I must admit the alpha support is pretty impressive, could someone explain it to me?

You don't have to use 50% res if you don't want to -- at 100% LBuffer res, it's basically the same technique as a "light pre pass" deferred renderer (except with transparency support). In my final implementation, I'd like to expose this % value as a setting that the user can tweak to see the performance/quality tradeoffs.The LBuffer is split up into "blocks" of 2x2 pixels. Opaque surfaces write lighting results into all 4 pixels of a block, but transparent surfaces only write into one of the pixels in a block. This gives you up to 4 "layers" of lighting information, but means that transparent objects are only lit at half resolution (and if you're using a 50% LBuffer, that's half of 50%, or 1/4 resolution). Also, if an opaque surface is covered by alpha layers, then it's lighting quality also degrades (because the alpha lighting info overwrites most of the opaque lighting info).
When reading lighting values from the LBuffer, some shader magic is used to ignore any samples that are from other objects/layers, and perform linear interpolation from the nearest 4 valid samples.

hmm impressive alpha but then you should fix your alpha objects i.e. your alpha objects would have messed up alpha, depth order.

How come?
The alpha objects are depth-sorted as usual and rendered back-to-front so all the ordering and blending-logic is correct.

back-to-front??? (FPS diving down)

yeh i'd expect that when you interpolate a pixel you take into account other occluders, so sorry. You are right the blending logic is fine.