Cubic or 6-viewports-on-1-texture shadowmaps

[nullsquared]

The one big "issue" with shadow mapping is that it's hard to shadow map point light sources since the light would go in all directions. Other than that, shadow mapping is fast, hardware-accelerated, and... easy. And very possible of MANY things.

Solutions? Rendering to a cubic texture (or, possibly, rendering all six directions on one texture).

Personally, I'm a total graphics newbie. Total. Newbie. Ogre is amazing, totally amazing. Thus, amazing (open source) engine + newbie != cubic shadow maps.



Does this sound feasible?

[Falagard]

Been discussed a few times.

http://www.ogre3d.org/phpBB2/viewtopic.php?p=245296

I personally used a hack that worked with 6 point lights without modifying Ogre's internals as discussed here:

http://www.ogre3d.org/phpBB2/viewtopic.php?t=37128

[nullsquared]

Right, being my stupid self I just glanced at this forum quickly and saw nothing related, so I posted . I see... so it's all hacks . I was thinking of something more "united" with Ogre itself .

Given today's graphics cards' vertex processing power, I don't really think it'd be a problem to use a cube map for shadowing.

[Wolfmanfx]

I agree with nullsquared it should be a core feature. I think the main drawback of the hack is that there are 6 point lights which could affect materials which iterate through all lights.
Maybe a flag in the scenemanager option which could enable the cubic shadows?

[nullsquared]

Hm. If we want cubic shadows, think about it - Ogre preallocatoes shadow textures for each light - meaning, if you want to shadow 7 lights, you need 7 textures. If these are point lights, then 7*6 = 42 shadow textures! A better solution is to use a shadow map, render to it, render the light, and then continue the iteration using the same shadow map. This is where multiple shadow maps come in useful, though - you can render 2 lights at once with 2 shadow maps, and then use 1 pass, for example.

Deferred renderers fit really nicely with this. Since each light is automatically a separate pass, it's really easy to have per-light properties, only 1 shadow map for every light (thus even 10 lights can use 4096x4096 shadow maps, without running out of memory), and so on.

[iloseall]

you can render 2 lights at once with 2 shadow maps, and then use 1 pass, for example.

How can I render 2 lights at once with 2 shadow maps?
Because Only has one depth buffer,I think I can only output one projection space position from vs.

[sinbad]

Hm. If we want cubic shadows, think about it - Ogre preallocatoes shadow textures for each light - meaning, if you want to shadow 7 lights, you need 7 textures. If these are point lights, then 7*6 = 42 shadow textures! A better solution is to use a shadow map, render to it, render the light, and then continue the iteration using the same shadow map. This is where multiple shadow maps come in useful, though - you can render 2 lights at once with 2 shadow maps, and then use 1 pass, for example.

Deferred renderers fit really nicely with this. Since each light is automatically a separate pass, it's really easy to have per-light properties, only 1 shadow map for every light (thus even 10 lights can use 4096x4096 shadow maps, without running out of memory), and so on.

Yes, adding a path where each light shares the same shadowmap is something I've considered, although without deferred rendering it's not very efficient, since as you say it's much better to do all your lighting in one pass (with a fixed maximum number of shadow casting lights, I've rarely found more than 3 to be necessary in most scenes to be honest).

It's possible to do deferred rendering with Ogre already, I've done it before. But it does require driving the render sequence much more manually than I would like. So yes, a core deferred rendering option would be good, again this is something on my pondering list. Won't happen before v1-6 though.

[nullsquared]

Hm. If we want cubic shadows, think about it - Ogre preallocatoes shadow textures for each light - meaning, if you want to shadow 7 lights, you need 7 textures. If these are point lights, then 7*6 = 42 shadow textures! A better solution is to use a shadow map, render to it, render the light, and then continue the iteration using the same shadow map. This is where multiple shadow maps come in useful, though - you can render 2 lights at once with 2 shadow maps, and then use 1 pass, for example.

Deferred renderers fit really nicely with this. Since each light is automatically a separate pass, it's really easy to have per-light properties, only 1 shadow map for every light (thus even 10 lights can use 4096x4096 shadow maps, without running out of memory), and so on.

Yes, adding a path where each light shares the same shadowmap is something I've considered, although without deferred rendering it's not very efficient, since as you say it's much better to do all your lighting in one pass

Again, it's much project dependent. Even as some people say, you can do point light shadows by drawing each "side" separately, using only 1 shadow map and aggressive frustum culling.

(with a fixed maximum number of shadow casting lights, I've rarely found more than 3 to be necessary in most scenes to be honest).

Come on now, what is this?!? You actually don't want DoomV to have at least 50 fully-soft-self-shadowing point lights?

It's possible to do deferred rendering with Ogre already, I've done it before.

Of course, it's completely what powers Portalized's lighting and shadowing through portals .

But it does require driving the render sequence much more manually than I would like.

Once again, much truth. But then again, I don't really mind it - having control is always nice. Besides, I got infinite (well, speed-limited) soft shadowing lights at with 2048x2048 shadow maps now - and it took me about 1 day to integrate, which was rather more with Ogre's in-built shadow mapping (not sure if you remember some of the extremely odd issues I've had). There was an annoying "gotcha", though - tell me, why is PROJECTIONCLIPSPACE2DTOIMAGESPACE_PERSPECTIVE so conveniently hidden within the auto parameter sources? Took me quite a while to figure out how to align my shadow map to the scene right, and then all of a sudden I see Ogre's little handy matrix hidden deep within the sources

So yes, a core deferred rendering option would be good, again this is something on my pondering list. Won't happen before v1-6 though.

Not so sure about making it a core option. I'd say its much scene specific - different people lay out their G-buffer differently, materials differently, and so on.

[sinbad]

So yes, a core deferred rendering option would be good, again this is something on my pondering list. Won't happen before v1-6 though.

Not so sure about making it a core option. I'd say its much scene specific - different people lay out their G-buffer differently, materials differently, and so on.

I was thinking more of the sequence than down to the level of the G-buffer format. But you're right, it would need mcuh thought to keep it generalised & flexible like the non-deferred modes, which is why it's still on my list. Not everyone is as smart as you when it comes to figuring out how to do it on their own