make shadows part of of the API

make shadows part of of the API

Kind of vague! Do you mean projective shadows? Stencilled shadow volumes? Shadow maps? There’s a lot of different techniques, all with different quirks and tradeoffs.

I think you’re at the wrong level here, TBH. OpenGL is an immediate-mode API; shadowing is a retained-mode feature. Besides, shadows aren’t a “solved” problem - there’s a lot of activity and research in the area at the moment - so locking the API in to one paticular approach isn’t really desirable.

agreed; added to this is the fact that shadows are a higher level than an interface to the graphics hardware (which is the design rationale behind opengl)

ahh, but romedial lighting functions are built into OpenGL. Light causes the casting of shadows, thus some means of shadow casting built into OpenGL may be worth looking at? I dunno, but shadows are a very important feature to creating a realistic looking 3D scene, and it is something that can be a pain to do by hand.

“Romedial”?

Light is different. The OpenGL illumination model allows the renderer to light a primitive based ONLY on the primitive itself plus the current renderer state. This fits perfectly well in an immediate-mode API. Shadows, OTOH, require the renderer to know about the entire scene in order to shadow a primitive, so it belongs in a retained-mode API.

Features will certainly appear to support shadowing, or to make it easier. But you aren’t going to see glEnable( GL_SHADOW ) anytime soon, nor should you.

Couldn’t one make a program then that would take the code as the parameter, figure out all the shadows, add produce the desired output as code which one could then paste into the program code and the end user would have shadows and the program wouldn’t take forever to figure out how to shadow the whole scene, it would have the shadow descriptions right there.

please, be realtime !!

just some thoughts:

why don’t find some way to automatically generate shadow volume polygons, on a per-polygon basis…

to generate a single triangle shadow volume, we have only to do standard 3D frustum calcs.
THEY add some functionality to select a bunch of gl lights as shadow volume generators, something like

byte lights={0,1,4,6};
glEnable(GL_SHADOW_VOLUME);
glShadowFuncbv(GL_SHADOW_VOLUME,GL_LIGHTS,4,lights);

could be a first step.

then, the shadow volumes generated need to be optimized by merging them together when necessary…

Dolo//\ightY

Dmy, that’s retained-mode functionality. No way can you do it in an immediate-mode API without breaking the model in horrible ways.

Just one example - stencil volume polys are only generated for silhouette edges, not for all polygons. To determine whether a triangle edge is part of the silhouette outline you need to know about the adjacent triangle that shares that edge. OpenGL just doesn’t have this information. Sure, you might be using vertex arrays where it wouldn’t be too hard to figure out edge sharing, but you might not, and trying to specify the behaviour here would turn into a gigantic rats’ nest of what-ifs and special cases.

Just my 2 verts. I want automatic shadowing too, I just can’t see a way to get there at the moment.

yes, i know how to, and i agree with all previous points.
i’m just having fun at thinking ways to let shadows break through the opengl model…

Dolo//\ightY

There is no reason why there can’t be more direct support for shadows in opengl. PowerVR chips have support for shadow volumes in hardware so there is no reason why it can’t be included in the state machine. If openGL stays tied to the way SGI did it 15 years ago it will die.

There should definitely be support for modifier volumes of some kind in openGL.

Originally posted by foobar:
There should definitely be support for modifier volumes of some kind in openGL

There’s nothing stopping PowerVR from creating an OpenGL extension; that’s the standard way of exposing any hardware-specific features.
After seeing the modifier-volume shadows in Jet Set Radio, I’d definitely try and use it.

Mike F