Doom3 a TWIMTBP game?

A clip plane culls based on the geometry you're rendering. Depth bounds test clip fragments based on the depth value of the pixel in the frame buffer.

 

Thank you!

My biggest problem with buying and downloading software is the annoying habit of the company only allowing one (or maybe two) downloads per purchase, unless you specificly buy a "download many times" extra.
(Had a lot of hassle with Norton because of this, since my download would fail around 60-80%)

 

In that case the chip would need to support one reference value to check against. Of course I don't know exactly, but I doubt it can do that. Besides, it would need its own, more restricted OpenGL extension.

I'm not sure I understand the question. Doom3 does one stencil and one "shading" pass per light. Right before the stencil pass, it transforms the light position into clip space (?), adds and subtracts the effective radius of the light to get a depth range, and passes this range to the depth bounds extension. Now the GPU will never touch those pixels which are outside the range.

Almost the same thing can be done for X and Y axes with a scissor rectangle.

 

The DOOM 3's lights have a radius which is laid down by the level designer. Since ultrashadow works per-light, I was asking if it used this radius from the level information or if it was a general implementation like

For all (shadow casting) lights:

zmax = light.z + constant
zmin = light.z - constant

Instead of:

zmax = light.z + light.rad
zmin = light.z - light.rad


It's just that if it was constant, that could be the reference value used by R3xx cards right? Or is the problem the lack of a hardware register* to actually store this value?

*sorry if I'm insulting anyone with my lack of low level hardware term knowledge

 

I'm sure JC is clever enough to use the latter, but you can pass any depth range with 0 <= zmin < zmax <= 1 (normalized window space depth values) to glDepthBoundsEXT().

Either R3x0 lacks a register (yes, that's the right word) to store the reference value and a comparator to perform the comparison (and a few other little things). Or ATI simply chose to not expose the functionality in an API.

 

I see, thanks again for your explanations Xmas.

 

I don't think so. Imagine a plane that is parallel to the screen with a spotlight on it. The whole plane is at the same depth value but you need to attenuate the light... Your method doesn't help here.

 

From a Carmack Q&A in the latest issue of German mag PC Games Hardware: "The testing phase might last till summer or even later this year."

That doesn't sound too good for an NV40 bundle deal.

 

I don't understand what you're arguing here. Of course you need to attenuate the light. But you don't need to calculate the lighting/shadows for pixels which you already know are outside of the range of the light.

Imagine the light source as a huge "sphere of effect". Everything inside this sphere may be affected by the light. Everything outside this sphere can not be affected by the light source because it's too far away.

Now, if you know that a certain pixel/surface is outside of the sphere, you can instantly drop any shadow calculations for that pixel/light source pair.

This sphere of effect has min/max extents on all three axes. For X and Y, you can use a scissor rectangle to limit the calculations only to those pixels that are possibly within the range of the light. For Z this is more difficult, because you don't have to check the depth value of the shadow volumes, but the depth values of the scene that's already laid out in the depth buffer.
Remember, you use stencil shadow volumes to count how many times an eye ray crosses shadow volume boundaries before it hits a visible surface. If you know beforehands that this surface is too far away, you don't have to render stencil shadows at this position.

 

What I am getting at here is that the depth range information doesn't help in this example. You can do x/y scissoring on cards without depth range, yes?

 

Yes, you can. But you cannot do 'Z scissoring'. That's what UltraShadow is for.

Imagine you try to render a simple scene with just one big room, one light source and one occluder that's positioned 'left' of the light source, so it casts a shadow only on the left wall of the room. Now imagine the light source's radius of effect is less than the distance of the light source to the back wall. So the light will never affect the back wall.

Normally, you would have to render the stencil shadow volume, both front and back side, although the back wall is too far away to be affected by the light source. With UltraShadow, those parts of the shadow volume that are in front of the back wall of the room won't be rendered.

 

Todd Hollenshead (id CEO) said that that entire article is pure BS....

 

Yeah I saw that on PlanetDoom a couple of days after. Can be seen as both a good and bad thing.