Horde3D

This seems like a very useful technique:

http://graphics.cs.uiuc.edu/~kircher/in ... _paper.pdf

A very short summary:
Low resolution light-prepass rendering using an object/normal id buffer for discontinuity sensitive filtering

Now I think this technique (esp. the DSF filtering) could be very useful. For example SSAO is usually done at a lower resolution as well, and this could solve the filtering along discontinuities in a nice, clean, low-cost way.

Is there any way in horde3d to draw some kind of pseudo-unique ids per object? For the normal-group id's it should be possible to either bake it into the normal map, as afaik (but I'm new to horde) there are no vertex colors which could be "abused" for this. Or maybe the bitangent vector could be overwritten with other data, as it can be computed from normal and tangent vectors.

Yeah I skimmed over that paper recently and was very impressed!

I haven't had time to go back and study it in detail yet, but I remember they use stipple-patterns (or something along those lines) to interleave alpha and non-alpha objects into the same G-buffer. This might be only limited to one layer of alpha (can't remember, have to read it properly!), but it's really great to integrate alpha-transparency into a deferred set-up like this.


Unique object IDs could be assigned using shader uniforms, and normal-group IDs could be stored as a color attribute in the vertex steam. AFAIK horde should support multiple color attributes (maybe with a little bit of tweaking to the collada converter?), but I've not done it myself yet.

Multiple layers are supported (up to 3 if you still want lighting information for the layer behind it)



This means cloning the material for each of the 256 ids correct? I was hoping for some more elegant method. About the color attribute: I got the impression that Horde3D used a fixed vertex format for all meshes, or am I misunderstanding the api?

From what I remember, earlier versions of Horde allowed you to specify uniforms per-model-node, as well as (or maybe instead of?) per-material.
If it's going to make a technique like this that much easier to implement, it probably wouldn't be too hard to patch per-model-uniforms back into Horde

I attended the Inferred Lighting talk at Siggraph. It has definitely some interesting ideas...


Yeah, I guess we should think about reviving that "old" feature
It was removed after material cloning was introduced since setting the uniforms directly on a material is the cleaner and more generic approach. But I agree that in some cases it is just very convenient to have per-mesh or per-model uniforms. Maybe we could introduce the concept of per-instance uniforms that each scene node can have.

That would be ideal for this technique (and a few others as well)

I was talking to Jimbo about Horde3D pipelines, and it seems Inferred might be a decent solution for many people as it supports HDR, MSAA, transparency, deferred lighting and allows you to choose between more lighting detail and performance. The main problem with it that I can see is that with transparent objects, you've got to find a way to allocate them to one of the N "layers" (i.e. overlapping objects have to be assigned unique stipple patterns somehow) -- the paper doesn't give much info on how they solved this problem.

I've started working on an Inferred pipeline this weekend and it seems to be going pretty well so far. Although, at this stage it's pretty much just a light-pre-pass pipeline, but with 75% LBUFFER resolution and no specular lighting or transparency support yet.
In my test scene (the Chicago demo, modified to have 60 lights with 5 of them casting shadows) the new pipeline is 3.75 times faster than forward rendering.
For comparison, the default deferred is 2.5 times faster than forward (20fps) on this scene.
This would be very handy for assigning the object IDs and the stipple-pattern-indices *wink* *wink*.

Another option would be to add a new predefined GLSL uniform, such as "nodeHandle" (just the current model node's internal ID), which I could use to generate semi-unique IDs inside the shader.
...Actually, this might be a better option because it'd mean you wouldn't need any application-side code (giving out semi-unique ID numbers) to support inferred rendering!

Very nice, it's great to have an inferred implementation hat can be compared against the other rendering techniques.

When drawing any conclusions, we need to be aware though that the current deferred pipeline is meant as an uncomplicated sample implementation. It uses fp16 render targets, though a lot of bandwitdh could be saved by using an 8 bit layout. Also, the way in which deferred lights are rendered at the moment leaves room for optimization (drawing light volumes instead of projected quads, depth bounds testing, stencil testing, or even using a tile based approach as in Uncharted). However, inferred lighting would benefit from these optimizations as well.


I think this is a good idea and could be realized quickly. I would propose though that we add a per-node uniform "nodeID" which can be set with the API to increase flexibility. The default value of this uniform could be the node handle as you propose.

I've noticed that this causes quite a bit of slow-down in the deferred pipe. For this one I'm trying to fit the Normal/Depth/ID pass into two low-res RGBA8 buffers, and the Lighting pass in another low-res RGBA8. The final pass will be done in a full-res MSAA RGBA8 buffer.
At the moment because I don't have any IDs yet, I'm packing normals/depth into a single RGBA8 target! However I think I'll probably end up using 24 bits for depth and 16 bits for normals (which leaves 24 bits for material data / IDs with 2xRGBA8)
To get "high range rendering" (light values outside 0 to 1) I'm just halving values that go into the LBuffer and doubling them again when used, which lets lights be "over bright" up to a point without having full HDR buffers. Because material colours (e.g. albedo) aren't stored in the LBuffer, this "compression" doesn't degrade texture quality Yeah, the inferred light pass still uses <DoDeferredLightLoop /> as in the usual deferred pipe (the lighting pass is just regular deferred lighting, with less GBuffer data), so any improvements to deferred should 'just work' for both.Good idea

[EDIT]I'm really starting to like this inferred technique (if you want LOTS of dynamic lights)
100 dynamic lights, 16x MSAA, 50% LBuffer resolution (Final render is 1600x1200, lighting is done at 800x600) == 10 times faster than forward lighting!

I've only hacked in DSF really quickly though (using depth values only), so you can see some aliasing in places (like the edge of the platform) where depth isn't enough to tell different objects apart. Comparing normals, or normal-group-IDs (like in the paper) should fix this.

DarkAngel, in case you need it, the uniform nodeId is available in the latest trunk now


Do you already have an idea how to realize that? We don't store any smoothing group info for the meshes...


The performance of inferred lighting seems to be impressive. But I'm a bit concerned with the quality of a quarter resolution normal buffer. It would be fine for low frequency albedo or specular data but for normal maps that contain high frequency details a good resolution is important, otherwise features like detail normal mapping would suffer.

Excellent! I'm doing this work on the trunk at the moment, so I'll do a SVN update soon. This should make the DSF algorithm almost perfect.The paper doesn't seem to mention smoothing groups, so I think they're generating their own groups by defining a threshold for the change in normal from one face to the next. Either the colladaconv tool, or a new tool that uses H3G files as input and output, could be used to perform this step. In the paper, they store these IDs in the .w component of the tangent vector.

However, I don't actually need these normal-group IDs for the technique to work -- they're just an optimisation!
Instead of checking normal-IDs, I can decode the normals from the GBuffer and use these in the DSF test. The IDs are used in the paper to avoid the cost of decoding the normals (which isn't actually that expensive).

In fact, checking the normals is working so well for DSF in my latest test that I don't need to do use the depth information any more. There's only a few occasional errors, which nodeId should fix Yeah that is a problem with it, but in a PC game you could even expose the GBuffer/LBuffer resolution to the user as a "lighting quality" option.
Currently, I'm getting good results on Chicago with 50% resolution, in the paper they use 62.5% resolution, and it even works fine at 100% resolution (at 100%, you can disable DSF and it becomes a light-pre-pass pipeline).
On my "100 lights" test, Inferred with 100% resolution is still faster than forward lighting

Not everything that uses normals has to use the low-res data from the GBuffer though -- for example, when reading from the ambient cube map (in the final/material pass) you can use the actual normal-mapped normal.

One thing I'd like to try is, when getting an LBuffer sample, I could multiply it by the dot product of the actual normal and the GBuffer normal. This isn't quite correct, but it might allow a high-frequency normal map to "imprint" it's pattern at full resolution a bit more...

DSF works great now using the nodeIDs Thanks for the patch Marciano!

Same test as before (1600x1200, 100 dynamic lights, 16x MSAA, 50% LBuffer resolution):


Visualisation of IDs:

However, I'm only half-way done... Next, I need to add proper support for specular lighting, and then the stippling technique for alpha-transparency support. Then it should be ready to be shared around

Nice work. I was just going to ask why the batch count was different then I realised you were using different pipelines! DUH!!

Good stuff.

That's a huge jump, congratulations!

This is much faster for greater numbers of lights but do you pay any cost which makes this slower for small numbers of lights?