Shadows and lighting model

We are at 21th century and still we haven’t an ultimate shadow algorithm.

  1. Shadow volumes requires a lot of fill rate, are CPU expensive, provides “hard shadows” and too slow soft shadows. Silhouetting is too complex and tedious…And more if tesselating is required!
    Auto-shadowing should be disabled in order to prevent bad casting artifacts.

  2. Shadow maps haven’t good quality at reasonable dimensions ( 256x256 or 512x512 pixels ). A glReadPixels it’s slow, and glCopyTeximage2D functions doesen’t work in certain cards. Biasing it’s a problem, like “perspective adjusting” whe you render at light-view. Also, requires multitexturing or multipass rendering…

  3. Projected planar shadows are good for portals-room-walls but not for a landscape-exteriors 3D engine. Auto-shadowing is too difficult. Double blending could occur.

  4. Anyone knows a GOOD ( realistic, fast and not complex )algorithm for shadow casting? I wonder why NVidia, ATI, SGI, etc… doesn’t offer a solution via light model. Don’t you?

Well, I guess last year card vendors’ advertising about “realtime toy story” is still several years away.
I believe shadow maps will be the key, since they depend in the ever-growing fillrate more than in processing the geometry in your app, like with volume shadows (complex).
I believe that SGI Onix2 stations had an OpenGL extension to create an alpha channel bassed on the depth buffer from the light source or something similar (SGIX_shadow), so they used it to do shadow maps, but dont now much about cheaper cards. The other way would be to have fast offscreen buffers, so your rendering of the shadowmaps can be used without having to ever draw to the frame buffer (no glReadPixels, like with SGI’s pbuffer extensions).
I guess the will still be a trick that depends very much in the application.

i used to think there should be a glEnable(GL_SHADOWS) but i dont anymore well anyways.

>>3) Projected planar shadows are good for portals-room-walls but not for a landscape-exteriors 3D engine. Auto-shadowing is too difficult. Double blending could occur.<<

what stops u from using the same technique in an outdoor scene as u would use in a indoor one?

Originally posted by santyhammer:
[b]We are at 21th century and still we haven’t an ultimate shadow algorithm.

  1. Anyone knows a GOOD ( realistic, fast and not complex )algorithm for shadow casting? I wonder why NVidia, ATI, SGI, etc… doesn’t offer a solution via light model. Don’t you?[/b]

The problem with shadows and OpenGL is that shadows are a global effect: to render a shadowed polygon you need to know about the polygons the cast a shadow on it. OpenGL has no concept of a scene, which IMHO is one of the strengths of the design, as it allows you to create your scenes on the fly and to do infinitely complex scenes. But it makes global effects pretty much impossible. So no

glEnbale(GL_SHADOW);

for OpenGL.

In general shadows and especially soft shadows are hard, that’s why there are no good, fast and simple algorithms. If there are, I’d be very interested to know, though. :slight_smile:

Originally posted by zed:
[b]i used to think there should be a glEnable(GL_SHADOWS) but i dont anymore well anyways.

>>3) Projected planar shadows are good for portals-room-walls but not for a landscape-exteriors 3D engine. Auto-shadowing is too difficult. Double blending could occur.<<

what stops u from using the same technique in an outdoor scene as u would use in a indoor one?[/b]

Nothing. But the poster is referring to projected planar shadows, and if that’s what I think it is, it only works for throwing a simple shadow onto a planar ground. See the GLUT shadow-dino demo for an example.

Very simple algorithm, pretty esasy to code. But planar ground is pretty rare in terrain. At least in natural terrain.

just break your shadow ‘texture’ up into smaller pieces that hug the terrain thats what i do and it looks pretty good. its not 100% accurate of course but then again what is

When the grpahics cards get faster, it will be a possibilty to use shadow maps. I mean, put the least LOD models on the screen from the positions of light, put that into shadow maps, clear the color buffer and apply the shadow maps to the object. Of course you’d have to have a shadow map for every light-object pair, but their are some good optimizations possible…

look at nehe’s 28th tutorial for an example of how to do shadows. Although this will be really slow a card without h/w stencil buffers, it still creates proper shadows. if you cant understand the code, then here is a brief rundown.

  1. render the scene as normal
  2. change the camera position to the light’s position. do the same witht he angle.
  3. enable stenciling, disable depth and colour buffer reads
  4. draw scenary again
  5. enable colour, enable stencil testing
  6. draw a black polygon with a chosen alpha value accross the screen, only updating where the stencil buffer has been marked.
  7. disable stencil testing, enable depth buffer

i use this all the time and it works like a charm. the shadows are accuratly mapped over objects (even spheres) and look great. not sure what the correct term for this technique is.

MENTAL

AFAIK You’ll get black hard shadows.

stencil shadows have a number of problems… they can drastically increase the number of polygons in a scene, they require a stencil buffer (not really a problem with todays hardware), doing soft shadows with them does not look very good and is very expensive, and when the camera is inside the shadow volume, you have a problem. still, they’re pretty nice for demos and small objects.
and what is a “proper shadow”?

A proper way, I guess, would be to make ray-traced shadows in HW. I’m not exactly sure how this would work, but it IS possible. If somebody made a videocard with HW accelerated ray tracing, that would rock!

Tim

there have been dedicated ray-tracer machines. i saw a demo of a flight sim running on a transputer that had an admitadly simple processor per pixel. (“Simple”, because all it did was trace rays=). Very, VERY amazing stuff. ungodly expensive, i’d imagine, tho’

er, but ray=tracing ISN"T necessarily the BEST way to do shadows. Ray-tracing only considers light sources when it’s decided its hit a surface, and then computes visibility between the point and all light sources. this is why you get sharp-edged shadows. Radiosity, on the other hand, is a technique for modelling energy transfer about a closed enviroment and can model soft shadows. My point is: ray-tracing isn’t the ideal solution, but a hybrid ray=tracer radiosity solution MIGHT be. =)

cheers
John

Raytracing is not an option in OpenGL. Simply because when doing raytracing, you must know the entire scene. OpenGL does not know anything about previous primitives, nor about comming primitives. It only knows about the single primitive it’s cuttently drawing.

A raytracer, and radiosity aswell, belongs to a scenegraph API, OpenGL is an immediate API.

Even though a raytrace-radiosity combination might be the ultimate solution, it won’t fit into OpenGL. We have to remember that OpenGL is mostly used for realtime, or at least semi-realtime, rendering, and in realtime we have to approximate and make shortcuts to get as close as possible to the “perfect” result.

If it would be possible after all to do fast hardware accelerated raytracing shadows, with radiosity, then to hell with opengl and praise a new api. But it isn’t realistic.

er, i never said radiosity nor raytracing should be PART of opengl. All i said was that ray-tracig isn’t the ultimate rendering tool (because it can’t do pneumbra shadows, for example, yadda yadda yadda).

cheers,
John

From my experience, raytraced shadow look too sharp, radiosity are too blurry. What are pneumbra shadows?

Penumbra (not pneumbra) is nothing but shadow that isn’t completely black. Never seen or heard of a ray-tracer with such a limitation.

Actually, a penumbra is the part of a shadow that isn’t completely shadowed from a particular light source, not just a shadow that isn’t completely black.

The reason for this is because from that part of the shadow, only part of the light source is visible. Raytracing supports only point and directional lights in general, so this doesn’t work for them. A point is either in shadow, or out of it, not partially in it. Raytracers simulate lights that actually have area by having multiple lights in almost the same location, much like jittering shadow volumes in a sense.

j

Sorry, I know the meaning of the word but didn’t know how else it could apply to 3D graphics.
In truth it still escapes me as typically light sources in 3D graphics are infinitely small…

By reading earlier posts I now understand what you mean. The ray-trace/radiosity solution…
It seems I should have followed the thread more attentively.