- The manual talks about stencil shadows and texture shadows, but am I correct that Ogre2 only supports texture shadows?
- Does that mean that one can't have a shadow-casting point light that is within the viewing frustum?
- Is there any small maximum number of shadow-casting lights that can be used at one time? (If you wonder why I'd ask, I was looking at another rendering engine that permits at most 6 shadow-casting lights at a time.)
Basic questions about shadows in Ogre 2 Topic is solved
-
- Goblin
- Posts: 224
- Joined: Thu Aug 12, 2021 10:06 pm
- Location: San Diego, CA, USA
- x 17
- Contact:
Basic questions about shadows in Ogre 2
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Basic questions about shadows in Ogre 2
Hi!
The porting manual documents the changes between 1.x and 2.x and should not mention stencil shadows as being supported. If it does, please tell us so we can fix that.
You may also find the FAQ useful.
More lights means more VRAM and performance hit.
If you set the limit to e.g. 6 lights and have 10 lights; then the 6 'closest' lights (closest to camera) will cast shadows, the other 4 wont cast shadows (and you'll need to enable Forward+ to have those lights visible, see the FAQ)
Eventually you'll hit HW limits like running out of VRAM (or the scene running too slow). If you have a lot of shadow mapping lights (>20), you'll have to call HlmsPbs::setShadowReceiversInPixelShader( true ) to avoid running into a HW limit on some GPUs.
That is correct, only texture shadows.
The porting manual documents the changes between 1.x and 2.x and should not mention stencil shadows as being supported. If it does, please tell us so we can fix that.
You may also find the FAQ useful.
I'm not sure I understand that question.
The limit is imposed by you based on how you setup your shadow node.
More lights means more VRAM and performance hit.
If you set the limit to e.g. 6 lights and have 10 lights; then the 6 'closest' lights (closest to camera) will cast shadows, the other 4 wont cast shadows (and you'll need to enable Forward+ to have those lights visible, see the FAQ)
Eventually you'll hit HW limits like running out of VRAM (or the scene running too slow). If you have a lot of shadow mapping lights (>20), you'll have to call HlmsPbs::setShadowReceiversInPixelShader( true ) to avoid running into a HW limit on some GPUs.
-
- Goblin
- Posts: 224
- Joined: Thu Aug 12, 2021 10:06 pm
- Location: San Diego, CA, USA
- x 17
- Contact:
Re: Basic questions about shadows in Ogre 2
To clarify my question #2 about shadow-casting point lights: The manual, in discussing texture shadows of point lights, says:
By the way, I can't resist mentioning that 4 renders would suffice, if you think about the faces of a tetrahedron instead of a cube.
I was just wondering whether any of that has changed in Ogre 2.As mentioned above, to support point lights properly would require multiple renders (either 6 for a cubic render or perhaps 2 for a less precise parabolic mapping), so rather than do that we approximate point lights as spotlights, where the configuration is changed on the fly to make the light shine from its position over the whole of the viewing frustum. This is not an ideal setup since it means it can only really work if the point light’s position is out of view, and in addition the changing parameterisation can cause some ’swimming’ of the texture. Generally we recommend avoiding making point lights cast texture shadows.
By the way, I can't resist mentioning that 4 renders would suffice, if you think about the faces of a tetrahedron instead of a cube.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: Basic questions about shadows in Ogre 2
Oh! Nope!
None of that applies in 2.x
Point lights are rendered in a cubemap (all 6 faces) and then converted to dual-paraboloid maps to save VRAM and make receiver code simpler.
This makes them "slow" (as in, their perf hit is large) for each additional point light you've got; if you need to update these lights every frame (if they're static then you get a massive perf boost).
None of that applies in 2.x
Point lights are rendered in a cubemap (all 6 faces) and then converted to dual-paraboloid maps to save VRAM and make receiver code simpler.
This makes them "slow" (as in, their perf hit is large) for each additional point light you've got; if you need to update these lights every frame (if they're static then you get a massive perf boost).