Hey everyone,
A few months ago I created a topic concerning a new shadow rendering system. I have since shifted my focus over to the shadows generated by terrain on objects and on the terrain itself. I will continue my work on the more general approach, and have even developed some algorithms during the unique terrain shadow generation which should help streamline the generation of shadows for arbitrary surfaces.
Because I have not yet fully streamlined this process, the framerates will be a bit low. There are several possible optimizations available with precalculation, and I will look into developing those after I have gotten the implementation right. Currently it works as long as the sun is orthogonal to the squares of the terrain map, though it should not be too difficult to generalize this for all positions of the sun. Certain substantial optimizations (ie: ~50% fewer texture reads and instructions per cycle) are available only when the sun is orthogonal, and this should suffice for most implementations. I am working on generalizing the shader for all positions of the sun as a joint project I am working on.
Now, the pictures:
http://i45.tinypic.com/345odw6.jpg
http://i49.tinypic.com/a43nt0.jpg
http://i47.tinypic.com/20t5kyf.jpg
http://i49.tinypic.com/35ho5tv.jpg
It looks amazing so far! Good luck on this, I hope it ends up in the core!
Nice!
How does it work?
This is great. I like to use open terrains like this but the PSSM-shadows don’t look so good when shadowing polygons that are getting close to parallell with the light direction. Especially the temporal aliasing is breaking the illusion with flickering shadows and moving moire patterns in the PCF-dithering.
Edit: Just wanted to clarify, the problems I describe are inherent in the shadow-algorithm, it’s just one of those tradeoffs. Nothing wrong with the implementation, nehon did wonderful work in implementing the shadows in jME.
Nice work, I’m interested in the details aswell 
Count me in fo rthe details as well, also if possible could you make a short video, showing how it works dynamicly?
That looks really interesting. Would it play nicely if combined with other shadow renderers in order to get shadows from objects in the scene?
@jmaasing said:
Edit: Just wanted to clarify, the problems I describe are inherent in the shadow-algorithm, it's just one of those tradeoffs. Nothing wrong with the implementation, nehon did wonderful work in implementing the shadows in jME.
lol, you don't have to handle me with kid gloves you know ;)
But you're right....PSSM does what you say and ....yeah, I did a wonderful work :D
nehon said:
lol, you don't have to handle me with kid gloves you know ;)
But you're right....PSSM does what you say and ....yeah, I did a wonderful work :D
:D
I will post a video detailing how it works when I get the chance. I have a final tomorrow, but I’m hoping to develop this more over winter break. I am currently working with a professor at my university to get a paper published on this topic.
Anyway, it works in a similar manner to the self-shadowing generated with by POM or relief mapping - it will read in a 2D array of heights encoded as a texture and then it uses an angle test to determine which ones are completely, partially, or not occluded. It does not require the normals, binormals, or tangents of the mesh to do this (I don’t even use normal mapping in my implementation) but does require the specific coordinates of each vertex to be read into per-pixel space. It then reads in the heights between that pixel and the sun within a reasonable margin (this varies depending on the angle of the sun, I currently use the heightmap size times the inverse of the angle relative to the horizontal axis).
I’m sorry for this somewhat incomplete explanation, I should be able to post a more complete one on Monday. I’ll try to post the video by then as well.
Oh, this should be completely compatible with any jME3 code out there because it does not use any buffering or stencil-based techniques. This is all a one-call GLSL 1.0 implementation, though all of the texture lookups might make resource managing a challenge. Theoretically, the resource consumption could be cut back by about 80-90% with precomputation (sending only the relevant vertices to a given shadowed or partially shadowed triangle), though this removes the ability to use a fast-moving dynamic light source. Of course, with a directional light source about 90% of our implementations will be static or slowly moving, so precomputation is probably the way to go for most applications.
Better late than never, I guess.
[video]Terrain Shadows with Penumbrae on Static Terrain and a Dynamic Object - YouTube
That’s pretty good !
The shadows are very soft.
How does it performs compared to “classic” shadow mapping?
Nice. Does it only work on terrainquads or can you use it on a mesh-based terrain as well?