Light Gem approaches

[nbohr1more]

Me:

 

Doesn't the current method sample some screen-shots and evaluate them on the CPU?

 

If so, then being able to abstract that out to a simplified mathematical model would definitely be a boost.

 

I always thought that "in the future" the renderer would be freed to be 99% GPU driven work while you could keep some of the CPU based light evaluation mechanics as part of your Light Gem calculation.

 

You could probably cover the outlier lighting properties right now with encoded spawnargs for the light entities.

 

Basically make a tool that takes the size and shape of the light volume and calculates how the light textures will fill it then cuts the data into a low resolution volumetric grid. You could then use that data like any other table structure that can be accessed via SDK\Script. You would create a spawnarg that could call that table at run-time. For moving lights you would perform matrix translations based on the movement. So the key would be to have Dark Radiant pre-process all these lights into their simplified light-grid volumes. Actually you could be even more clever and have prebaked templates for a standard volume size then just translate the values to the volume size at run-time too.

 

If only I knew how to code it...

 

New Horizon:

 

That Would all likely be overkill.

 

The current light gem system takes alternating top and bottom snapshots of a white, diamond shaped object. I believe the snapshots are only 32 x 32 pixels. Each snap shot has 4 sides...and the light value is averaged between the two shots. The original lightgem system simply runs a trace to the lights from alternating points at the player position. Our original system is how they did it in Thief 1,2, and 3. Unfortunately, we didn't have deep enough access to the renderer to be able to read all types of shadow.

 

If either the current system could be further streamlined...or the old system brought across the finish line, it could provide a nice performance boost to the low enders.

 

 

Me:

 

Right... but those simple samples that are taken come from slices of the light volume.

 

Inside the Doom 3 engine, the whole light volume is tracked of course and it's intersection with objects get entries in the Interaction Table but Doom 3 doesn't really "know" how the volume is filled because that is done on the GPU via texture translation and shader operations. Tracing to lights won't work for animated textures or variable lightFalloff Images because the "real" shape of the light will not be preserved only the cube that represents it's radius (etc). Simplifying the volumes into low resolution 3D grids (blocks) would retain a great deal of the precision without needing to do a feedback loop to the CPU to examine pixels (which is bogged-down due to inefficiencies in reverse traffic from the GPU).

 

I still believe a simple array look-up will be faster than capturing those pixels and sending them back to the CPU.

 

Actually, since the Light Volumes are really 1D+2D you could just have simplified arrays that represent each texture type (2D Projection vs 1D Falloff) but I am really hoping for 3D texture support for lights so that would be a future-proofed method.

 

Of course, source code access will be great for inheriting dynamic shadow locations without having to let the engine paint them first (etc).

 

Edit

 

The down-sides:

 

Animating textures would need to be synched with array translations for the simplified grid-cube. (not too bad because the materials for animating textures often already have translation time factors in them...)

 

Developing the pre-processor that makes the grid-cubes. ... Pretty big undertaking...

 

 

Does this look like a good way forward for the future?

 

Should I tracker this concept?

Edited October 5, 2011 by nbohr1more

[New Horizon]

I think as long as we could get the current gem system 10fps hit closer to the weak gem system hit, on lower end systems, it would be a huge improvement. No need to completely reinvent the system when there are two systems in place already.

[nbohr1more]

If the sample tiles are captured during their portion of the render rather than "after a frame has completed" that goal seems reasonable.

 

Actually, the more I think about it... If a totally GPU based shadow generation system is in-place (after GPL release), capturing the render or part of the render might be the only practical solution. I don't think you could simplify the shadow volume projection the way you could the light volume content. I guess you could make a hybrid system where a GPU based shadow is rendered in the distance but a CPU calculated volume is rendered when the player is near...

 

Maybe like?

 

LOD 3 = No shadow

LOD 2 = Low resolution shadow map

LOD 1 = GPU Stencil Shadow volume

LOD 0 = CPU Stencil Shadow volume

 

Edited October 5, 2011 by nbohr1more

[sparhawk]

Not sure if I understand this correct, but do you want the light gem to be replaced with a mathematical model? If yes, there are several problems involved, so that's why I took the rendering approach.

 

If the source is available, then this problem might be more easily resolved because I think that Doom already does this caluculations anyway, as the player model is also shadowed accordingly. So if the complete source is available it might be as easy as hooking into the appropriate code getting the lightgem for free.

[nbohr1more]

Well...

 

Yes and No.

 

My idea was to make a simplified low resolution Voxel renderer in the SDK that renders only the light volume data. Your voxels would have X, Y, Z offset from the light origin and a brightness level. So it's not purely a mathematical distance-based falloff function but instead can include animation and non-linear variation just like the real renderer but scaled-down to very low resolution (and only including lights). The "yes" part is if you have to calculate the dynamic shadow locations from scratch... I thought there was an SDK way to collect the shadow calculation result before it renders though

 

If all the lighting calculations move to the GPU in the future, this is about as simple as I could imagine for the AI framework to realistically track lighting without having to sample the render.

[New Horizon]

We'll see what happens with the SDK. As Spar says, we may get the light gem for free.

[sparhawk]

The "yes" part is if you have to calculate the dynamic shadow locations from scratch...

 

Well, this is very hard, because of the flexible way of how Doom 3 can setup lights. Basically you have to do the same as the renderer does anyway, and then you haven't even included the scripting and animation, which also can affect lights. I tried this approach in the beginning, but when I realized how big and futile a task this is, I aboondoned that idea.

 

I thought there was an SDK way to collect the shadow calculation result before it renders though

 

Well, if there were, we would have used it.

[nbohr1more]

Thanks.

 

I was confused and thought that your math-based lightgem had a shadow calculation method and the problem was more about the simplicity of the light representation itself.

 

Just out of curiosity, did you ever try:

 

1) Compile the Shadow algorithm source code from Id's Intel SSE document http://software.intel.com/file/37730

2) De-compile and capture the pattern

3) De-compile the Doom 3 executable

4) Find the matching pattern from 2

5) Develop an inline injection to replace that code with one that has a virtual handle (etc)

 

?

[sparhawk]

1) Compile the Shadow algorithm source code from Id's Intel SSE document http://software.intel.com/file/37730

 

Nope. Never heard about that.

 

2) De-compile and capture the pattern

 

Nope.

 

3) De-compile the Doom 3 executable

 

Yes.

 

4) Find the matching pattern from 2

 

Nope.

 

5) Develop an inline injection to replace that code with one that has a virtual handle (etc)

 

That would have been a logical consequence of 2, if that would have yielded something usefull. I only decompiled D3 though, because I often do that with apps, just to snoop around. Reverse engineering the render engine would be a long and tedious job.

[nbohr1more]

Thanks again. I love getting this kinda feedback .

 

If you like that document and are interested in other similar ones from Id, check out the pdf links at the bottom of this article:

 

http://software.intel.com/en-us/articles/optimizing-the-rendering-pipeline-of-animated-models-using-the-intel-streaming-simd-extensions/

 

I know you said you're rusty at C++ but I hope to see your name in Bug Tracker after Doom 3 goes GPL (eventually)