And the winner is: shadow mapping

Shadows projection can be tricky. I knew it before beginnig my stage at CNR, and had only confirmations so far: there's a lot of complications you've got to consider before developing. The greatest limit remains, of course, the cost of computations.

My first choice and proposal were shadow volumes a là Carmack: definitively intriguing and kind of ideal trait d'union of my universitary life: they were perfect.

Analyzing the technology, it turned out that they were not. The software module I'm asked to develop will be placed in high-polygon contexts; shadow volumes require a lot of time for each object: time to place the supplementary geometries in the pipeline, time to compute the silhouettes (checking every triangle of the mesh!!), time to extrude the cones that will be depth-checked to fill the stencil buffers. Many polygons kill performances; many polygons and many lights means killing real time rendering.

So, after a brief talk with chief, we took the decision to simulate shadows by shadow mapping: not so accurate like shadow volumes, but really faster! In addition, they have less issues, like volumes bounding and silhouette recognition.

I'm gonna try to develop them both using and not using shaders, because of accuracy and scalability.

My module is supposed to be arbitrarily activated, and selective shadowing must be guaranteed. Again, both things are easier to be achieved with shadow mapping:

• I don't have to do any invasive manipulation to the existing geometry loader classes (because of additional squares for shadow volumes), so one could turn off shadows just by not calling my procedures;
• when I render "from the light view", I can just don't place objects in the scene if I don't want them to project a shadow. Again, this could be obtained without in-depth modifications of existing routines and placing my functions in a strategic way.

Everything's nice and exciting... I hope I'll be able to do it! ^^