vor allem die GC memory leaks und dergleichen probleme

Using shaders, you can bypass huge chunks of the GL Api. You can use uniforms to do your own transformations, bypassing the whole glMatrixMode/glMatrix thing, and use your own vertex attributes to send color, normal etc instead of the standard glColor, glNormal calls (although these can still be used inside a shader). In fact, this is one of the first things I did - kick out the API!

You can also query the variables used by a shader - ie: enumerate the names and types of all uniforms and attributes a shader uses. This could be very useful for allowing a shader to 'drive' the vertex attributes stored in a mesh, or the uniforms stored in something like a brush. Currently, my test Mesh system is shader driven like this and I quite like it, but I haven't really approached the more complex uniform/state stuff yet. Most of what I'm doing is really 'throw away' stuff, although I am building up quite a nice 'geom.bmx' for general geometry processing.

The second thing I wanted to sort out shader wise (after kicking out the API!) was 'surface space'. Surface space is basically a step 'down' from model/local space - the way model space is a step down from global space. In surface space, you're always looking directly 'at' the surface, and therefore also the texture/normal maps. I though it was gonna be a mission, but it turned out to be pretty easy.

My main reason for bothering with surface space was bump mapping (once your vertex-to-light or halfway vector is in surface space, you just need to dot it with the texture-based surface normal to do your lighting) but it actually turns out to be useful for other things - eg: the ultra cool parallax mapping effect! This effect gives surfaces a freakily 'solid' 3D feel - you can see things 'parallax' as they go past the eyepoint!

I also had a play with shadows. I tried texture based shadow maps, but these look pretty crap. There are 2 main problems with these. First, the texels on the shadow map may not (generally don't) map nicely to the pixels on the screen. An area of the shadow map that, from the lights point of view, may only cover a few texels, may (generally will) end up being mapped to large number of on screen pixels - and it looks awful. Increasing the size of the shadow map helps, but you have to make it *huge* to have any great effect. The second problem is with edges that separate in-light/in-shadow surfaces. These generally end up with a 'diamond' shadow pattern on them, again due to the mismatch of shadow map vs screen resolution. All-in-all, I can't see how to make these work unless they were applied to a very small part of the scene and used a very large shadow map.

So next up it was stencil shadows - and I had much more success here! After a few false starts, I ended up implementing the infamous 'Carmack's reverse' algorithm. And it works really, really well. There is added overhead - you have to draw (from the lights point of view) both front and back facing polys (to 'cap' the shadow volumes) and a quad for every edge in silhouette (for the sides of the shadow volumes) - but the results are ultra stable regardless of what you do with the light/camera. And with a preprocessed mesh, the final capping and silhouette detection loop is pretty tight. You're also only drawing to the stencil buffer, so all-in-all I think it's a keeper!