Thoughts on shadows

After studying some parts of the jME source code, I would like to speak of shadows implementations.

There are plenty of shadowing methods for OpenGL, but the best one out there is using Shadow volumes with ZFail (soft shadows are very cool but I don’t think you want to implement shadows that will only run on high-end hardware atm). Including shadows into jME won’t be so easy…


  • It requires a big change into the renderer, because we need multipass rendering if shaders are not used.
  • We’ll need to cast the shadows for each lights that apply on the object (so one more pass per light), but hopefully, the utility to sort lights in jme will be very helpful !
  • There’s another big problem : the camera’s frustrum culling… There’s a possible solution to that, creating each shadow volume as a trimesh and putting it into a specific node, but whereas this could work nicely with a few objects, on larger scene it will kill performances… I don’t really know how to handle culling there…



    And finally, the speed problem… The best way to make shadows fast is to use shaders (I’ve got some Cg code on my drive that do shadow volumes), but this would limit shadow usage to people who have a recent card (ATI9500+/GeforceFX 5200, or at least ATI8500+/Geforce3 depending of the shaders used).



    So, does someone have ideas on how to correctly implement shadows in jME ?



    Chman

Awhile ago, I looked into shadows myself, and specifically looked at Eberly’s stuff to figure out how mult-passing would work, etc. His solution is Shadows are nodes. They control the rendering of the shadows and objects completely, i.e. a Spatial scene is passed in (that does the shadowing) a Quad for the plane that recieves the shadows (yes, his solution is planar shadows), and the light source. He then overloaded the drawing methods to handle the multipass (stencil pass, render pass).



This would take care of the multipass and culling. However, it handles a single light source and is only planar shadows. But perhaps that will give you some ideas?



http://www.magic-software.com/Graphics.html

My personal opinion in the question of using shaders for shadows is that when i will start to develop a game it will take at least one year, so for me the use of shaders with its advantage of speed (as Chman said) would be fine. But people who have allready a game in the pipeline or want to make their game compatible with older graphic-cards will probably have other needs.

mojomonkey> seems to be interesting… I’m gonna take a closer look to the source…



justin> well, we could add a boolean value for using shaders or not, so as developpers would have the choice…



Chman

I was thinking about how to implement multipass rendering in jme. The only way I could come up with is letting each spatial have more then one of each of the states. The first pass would be rendered using the first set of states, the secent pass would be rendered using the secent set of states and so on.



Each pass would also have it’s one locale traslatiion scale and rotation.

Badmi’s idea seems very good to me !

This could make multi-pass rendering easier and more powerful, without the need of tweaking the renderer code each time we need to implement a new feature that required multipass rendering…



Chman

Feel free to hack away at things to experiment. If there is a limitation that needs to be resolved to move forward with features, I’m open to all suggestions on how to remove that limitation.

Ok, I will work on multi-pass rendering before making shadows. Here’s my current todo list for jME (tell me is something is useless or doesn’t need to be implemented) :


  • Multi-pass rendering
  • Shadows (volumes)
  • GLSL support
  • Cg support

FWIW, dont use zfail technique. A similar technique is patented by Creative.

"Matzon" wrote:
FWIW, dont use zfail technique. A similar technique is patented by Creative.

?!?
Isn't that just a normal everyday technique for shadow volumes, described in a zillion resources? How can they patent this? It's a question of prior art, isn't it?

Well, matzon can be true…



Using ZFail for shadow volume IS the Carmack’s Reverse method… And this method is patented… I don’t really know if we can use Zfail or not, I’ve seen so many demos on the web that use this technique so… :? :? :? :?



But what would we use if we don’t use ZFail ? It’s a very important part of shadow volume because it resolve some problems (like “what to do when the camera is in the shadow volume ?”), and I don’t know any other method that do the same…



Chman

FYI:

http://www.theregister.co.uk/2004/11/03/game_cos_3d_lawsuit/



This to me sounds even worse. :’(



Software patents are killing software.

lol, I’ve seen this paper two monthes ago… But it forgets to say that the patent has been rejected… According to this law, ALL art (2D and 3D) hit the patent violation, that’s totally absurd… It would be the same in real life if you create a patent on cold water for example :stuck_out_tongue:



So don’t worry about this one :slight_smile:


Software patents are killing software.

... that's true unfortunately :'(... That's why Open-source exists (with GPL and BSD-like licenses).

Chman
"Chman" wrote:
It would be the same in real life if you create a patent on cold water for example

Hmm, you'd need brilliant lawyers, but if it works.... XD

Chman and I spoke today about multi-pass. To keep my hands busy and out of trouble, I proposed taking on that part and he graciously agreed. (Thanks chman!) I’ll try and get something out on this before the holidays!

Great renanse :slight_smile:



I’ve almost finished the GLSL state… I’ll released it soon, after fixing some bugs and adding some features :stuck_out_tongue:



Chman

I have a prototype mutipass rendered working for jme on my laptop that works well. I can not access it now. I recommend that you wait until I can give you my code before you start your own. Or if you want I can finish mine and post it on the code review section and you can build the shadow effect form there.

Go ahead and send it my way and I’ll have a look. This is a section I’m personally concerned about getting right, so please bear with me as I’ll be a bit picky… I don’t want us losing the speed and ease of use we worked hard to obtain at this point.

My prototype is simple to use and should not be that slow. I will try to email it to you today or tomorrow.

Sent- remember it is just a prototype.