Doom3 a TWIMTBP game?

[micron]

Forgive my ignorance, but how is this different from a clip plane? Place one clip plane at depth min and another at depth max...

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.

 

[MrGaribaldi]

It looks like that once HL2 is made available over Steam, it seems like if you're marked as having "purchased" HL2, you'll have permanent access and redownloads to that title, and that you won't have to repurchase it again if you choose to redownload it (case in point: people with the HL1 pack active are allowed to redownload HL/CS/TFC/etc as many times as they want, as long as they're marked as being owners of said pack). So, even if you download it and it fails, you can just start again whenever you want because you're marked as 'owning' it.

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%)

 

[Xmas]

Thank you Xmas,

You made me think of something, r3xx can only store a value instead of a range, but can't they implement just one of the depths? Say... zmax? Then just check if a pixel is beyond that and discard it or if within compute the light value?

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.

Also, about your reply to OpenGL guy, DOOM 3 lights always have a radius, you mentioned ultrashadow works on a per-light basis, then I take it that ultrashadow uses this level information, or is it derived (as you put it) by an algorithm, if you know.

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.

 

[Richard]

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.

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

 

[Xmas]

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.

 

[Richard]

I see, thanks again for your explanations Xmas.

 

[OpenGL guy]

A surface that is far away from an attenuated light source will never be affected by it. From the position of the light source, you can derive a depth range outside of which you don' have to check whether a pixel is in shadow. It will simply always be in shadow.

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.

 

[Fodder]

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.

 

[Xmas]

A surface that is far away from an attenuated light source will never be affected by it. From the position of the light source, you can derive a depth range outside of which you don' have to check whether a pixel is in shadow. It will simply always be in shadow.

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.

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.

 

[OpenGL guy]

A surface that is far away from an attenuated light source will never be affected by it. From the position of the light source, you can derive a depth range outside of which you don' have to check whether a pixel is in shadow. It will simply always be in shadow.

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.

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?

 

[Xmas]

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.

 

[Johnny Rotten]

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.

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

 

[Fodder]

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.