V6 wish: static shadows and even light mapping


#1

Could it be possible for V6 to analyze the scene at redraw and check if the objects or the lights have been moved, and if not then reuse the shadow maps? In my mind adding 10 lights to a scene should be possible with out a drop in framerate if it was possible to reuse the data.

And I would also love to see a lightmapping ala Unitys:
Good old Flamingo 1 had a vertex lit Radiosity preview that also would be nice to see evolved into todays standards.


(Brian Gillespie) #2

@jeff, what do you think?


(Jeff Lasor) #3

This would be possible if every light stored its own shadow map… Unfortunately, that is not the case…and I believe that Jorgen and I have had this conversation before… The shadow map is a huge resource hog (GPU resource), it’s a floating point depth buffer whose size is determined by the Shadow Map Memory Usage setting, and get up over 0.5 GB in size.

In order to support multiple light sources, and therefore multiple shadows, Rhino cannot (physically) store a shadow map per light, and must reuse the single map for each and every light.

It might be possible to allow a minimal configuration that will allow users to say: “I only want these 5 lights to cast shadows, and I only want them to use XXXX memory”, or perhaps I could automatically divide up the memory among all specified lights … I could then cache the maps for each light as Jorgen suggests here.

-Jeff


#4

Hi Jeff, yes we have discussed this before, but I am afraid I don’t remember to well the details.

So excuse my lack of knowledge but why, in a theoretical situation like this, does the shadow map need to be a floating point depth buffer, and not just a simple 16 colored “black and white” image? Compressed to one of the supported formats for the GPU? Maybe we could live with some visible “jpeg” artifacts in the shadows too, if it would at all be possible to store lossy fomats on the vram-buffer-thing :wink:


(Jeff Lasor) #5

No worries…

The shadow map is a floating point depth buffer because that’s how shadow mapping works… The shaders perform depth table look ups within the shadow map to determine if a point on a piece of geometry is actually “within shadow” of a given depth buffer value…I won’t go into the technical details here, but you can easily find articles on real time shadow mapping and how it works.

As for your idea about caching only the viewport rendered results…Hmmmm, that’s actually pretty doable…my only concern is that I don’t think you can cache a static image that represents ALL shadows from all light sources and use it to get “correct” results. Shadows within shadows sort of thing… Technical display modes actually do something like this, and I know the results aren’t correct in many cases…but maybe it’s good enough while you’re tumbling the viewport around. Or perhaps I can store a light-shadow-texture per light per camera…all sorts of possibilities are coming to mind atm.

I’ll put it on my list for things to look at… Storing a viewport size texture for each light per camera/view is certainly more feasible than storing the shadow map for each light.

For future discussions, lets create some terminology here so that you and I both know what’s being discussed:

The “Shadow Map” - is the floating point depth buffer data generated when rendering the scene from the point of view of the light. The size of this item is determined by the Memory setting within the display mode’s “Shadows” section.

The “Shadow Texture” - is what I’ll call this new cached image that represents the shadow pixels within the viewport when rendering the scene from the camera using the “Shadow Map”… This can vary in size and is dependent on viewport size and not any of the Shadow settings. Therefore, any time the viewport size changes, I will need to regenerate the Shadow Texture…as well as any time a light position is changed.

Lots to think about on this now…Thanks for the distraction :wink:
-J


#6

You know me, I am more than happy to be of distraction :smile:

Just so you know I had no idea how this works, and the idea I described is based on how I thought render programs like 3DS max and Cinema 4D actually stored what they call “shadow maps”. It is a faster alternative to ray traced shadows and are based on a per light setting and are usually 512x512 px or up to 2048x2048 px. And these can be cashed for rendering animations so they don’t need to be recalculated. And shadow maps gives us the ability to have fast and soft shadows.