New demo

[Humus]

I've been experimenting a little the latest days with stencil shadows and Carmacks reversed algoritm. I've got it working quite well now and have uploaded a demo of it on my site. It's got dynamic per-pixel lighting with with proper shadow overlapping. Source is included too for those interested. I'll try to move this stuff into my primary project to get some shadows there too. Will probably kill framerate though

Anyway, get it here:
http://esprit.campus.luth.se/~humus/?page=OpenGL

 

[psurge]

Humus, what do you mean by Carmack's reversed algorithm?
(is this described in the source code?). on topic: i would check out your demo if i had the hardware to run it

 

[Humus]

Carmacks reversed algoritm is a way to implement stencil shadows. The convential method is to use volumes that stretch to infinity, and then increment the stencil when you enter the volume (front facing polygons) and decrement it when you leave (back facing polygons) if the depth test passes. If you end up with zero you're not in the shadow, otherwise you are. It's quite intuitive. However, it has the problem that it doesn't work if you're within the shadow volume, and to make it work properly you'd need to cap the volume to the near clipping plane, which is a quite complex task and prone to glitches.
Carmacks reversed on the other hand takes a similar but not as intuitive approach, it's sort of doing everything the other way. When the depth test fails for back facing polygons you increase the stencil, and decrease for front facing polygons. This way the problem is moved from the near clipping plane to the far clipping plane, but if you're using attenuated light you can just cap the shadow volumes far enough where no shadows from that light would go. This makes this approach much simplier to implement and is more robust. It's was described in one of nVidia's whitepapers. Here's link where Carmack himself describes hes algorithm:

http://cvs1.nvidia.com/OpenGL/doc/whitepapers/CarmackOnShadowVolumes.txt

 

[Reverend]

I get a corrupted file message upon opening after full download (tried this twice).

 

[Kristof]

Seems to crash with a GF3, runs fine with Radeon8500.

K-

 

[Simon F]

Carmacks reversed algoritm is a way to implement stencil shadows. The convential method is to use volumes that stretch to infinity,

..I always used to limit them for fill rate reasons...

and then increment the stencil when you enter the volume (front facing polygons) and decrement it when you leave (back facing polygons) if the depth test passes. If you end up with zero you're not in the shadow, otherwise you are. It's quite intuitive. However, it has the problem that it doesn't work if you're within the shadow volume,

I'm just going to be pedantic here for the sake of the listeners. It's easy enough to adjust if the camera is "entirely" inside the volume. The problem Humus is describing occurs if the front image/clipping plane is only partially inside the volume.

and to make it work properly you'd need to cap the volume to the near clipping plane, which is a quite complex task and prone to glitches.

Actually there are two easy ways to "cap" a clipped volume. One was described by Deipenbach in his Phd Thesis - this simply duplicates every post-clipping polygon and 'flattens' the copy onto the front clipping plane.
The second method is cheaper and is used in Elan - only the chopped off sections are modified. I think that method will be public soon.

Carmacks reversed on the other hand takes a similar but not as intuitive approach, it's sort of doing everything the other way. When the depth test fails for back facing polygons you increase the stencil, and decrease for front facing polygons. This way the problem is moved from the near clipping plane to the far clipping plane, but if you're using attenuated light you can just cap the shadow volumes far enough where no shadows from that light would go. This makes this approach much simplier to implement and is more robust. It's was described in one of nVidia's whitepapers. Here's link where Carmack himself describes hes algorithm:

http://cvs1.nvidia.com/OpenGL/doc/whitepapers/CarmackOnShadowVolumes.txt

I haven't read that, but it seems like an interesting approach. I suppose as long as you stick to either "indoor" type lights or can guarantee a "perpendicular" cut-off point for "sunlight" it should be ok. Obviously you'd have to make sure that your far clip plane is further away than any of your volumes' far cap/limits or else you'd be back to the same problem as the near plane clipping , but I suspect that wouldn't be much of a limitation.

 

[Reverend]

Okay, ignore my previous post (didn't install Winzip, just used WinXP's).

Anyway, crashed on WinXP/GF4 Ti4600

 

[Humus]

Try redownloading it. I've just updated it. There was a bug causing it to call the glBlendFuncSeparateEXT() function instead of the normal glBlendFunc(), and since nVidia doesn't support the GL_EXT_blend_func_separate it caused a NULL pointer exception. I've fixed that now though.

Anyway, do you guys get very bright screen on GF3/4? I was sent a screenshot that clearly indicates it's very bright on GF3's, but this time it can't be the same as the extreme brightness bug in my previous demo.

 

[ERP]

"Obviously you'd have to make sure that your far clip plane is further away than any of your volumes' far cap/limits or else you'd be back to the same problem as the near plane clipping , but I suspect that wouldn't be much of a limitation."

This is the crux of the reversal basically you take the problem at the near plane and turn it into a problem at the far plane where it's easier to basically ignore the issue.
Geforce 4's allow you to clamp Z/W values at the near or far plane in order to make the capping problem easier. Which in effect will give you something similar to what you described as the Elan solution.

 

[pcchen]

It is also supported under GeForce 3, but unfortunately there's no way to use it under Direct3D 8.

The new whitepaper from NVIDIA talking about pushing far plane to infinity looks promising. I'll try to modify my omnidx program (which uses preset far clip plane and shadow volume length) with that method if I have some free time.

 

[pascal]

Humus,

It is not working for me.
Some white screen with noise and after that a black screen with some frame counter blinking (43fps) .

Using GF3Ti200 and testing the nvidia reference drivers 23.11.

 

[Althornin]

I'll test it when i get home on my GF3, but pascal, try it with aniso off, becaue that hosed humus's other demo also....

FOR GF3 TURN ANISO OFF TO PLAY DEMO.

 

[Althornin]

looks great, works fine as long as aniso is off, just like with your other proggy. (on my GF3)
I get framerates from ~50 to ~65, hovering around ~55
with 2xAA, i get framerates from ~38 to ~50, hovering around ~43

 

[Teasy]

I tried it on my Kyro II and it turned my monitor off, what resolution is this app set for by default?

 

[Humus]

Odd this anisotropic issue ... guess the driver has some problems with the way I do the bumpmapping then when anisotropic is on.

 

[Humus]

I tried it on my Kyro II and it turned my monitor off, what resolution is this app set for by default?

1024x768x32 @ 85Hz.
It'll pick the closest available if it's not supported and priorities bpp first, then width, height, and last refreshrate.

When you say "turned off", does that mean the monitor actually turned off or did it just go black? It can just be that it goes into software mode and you'll have to wait like 20 seconds for the first frame to appear.

 

[Reverend]

With your updated demo, it runs fine on WinXP/GF4Ti4600/DX8.1 . Framerates ranges from 80 to 90s with the occasional hiccups down to 70s.

Looks very nice... if only we have the horsepower (or some realy smart programmer) to do this in an actual game with all the entitities.

 

[Simon F]

The new whitepaper from NVIDIA talking about pushing far plane to infinity looks promising. I'll try to modify my omnidx program (which uses preset far clip plane and shadow volume length) with that method if I have some free time.

Are you saying that Nvidia are now suggesting moving the far clip plane to infinity? That's been done on on PowerVR since before PCX1.
I wrote a white paper on this ages ago which shows that you only lose a fraction of a bit of Z accuracy (i.e. insignificant) but save clipping and projection costs. Apparently this is available on the 'devlopers' part of the DevRel site.

 

[pcchen]

The main reason to put far clip plane to infinity in that whitepaper is to extrude and cap the shadow volume at infinity. This solves the far plane clipping problem. The downside is that it works only with perspective projection, and may waste some extra fill rate.

Unfortunately, there is no way to specify W component of a pre-transform vertex in Direct3D 8 without using a vertex shader. This is a bit annoying.

 

[pascal]

Thanks Althornin !!!!

It is working GREAT

GF3Ti200 at 1024x768x32x75 with 43 fps. I wish I could see it in a game