[2.1+] complete static ESM node setup

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
rujialiu
Goblin
Posts: 230
Joined: Mon May 09, 2016 8:21 am
x 24

[2.1+] complete static ESM node setup

Post by rujialiu » Thu Aug 30, 2018 6:57 am

Hi!

I'm having trouble setting up ESM shadow mapping with completely static shadow maps (I'll mark shadow maps as dirty manually).
Here is my current setup:

Code: Select all

compositor_node_shadow DefaultShadowNode
{
    technique focused
    texture atlas 2048 4096 PF_L16 no_fsaa uav
    texture tmpGaussianFilter 2048 4096 PF_L16 no_fsaa depth_pool 0 uav
    texture tmpCubemap 1024 1024 PF_L16 cubemap no_fsaa

    shadow_map 0 atlas uv 0.0000 0.0000 0.5000 0.2500 light 0
    shadow_map 1 atlas uv 0.0000 0.2500 0.5000 0.2500 light 1
    shadow_map 2 atlas uv 0.0000 0.5000 0.5000 0.2500 light 2
    shadow_map 3 atlas uv 0.0000 0.7500 0.5000 0.2500 light 3
    shadow_map 4 atlas uv 0.5000 0.0000 0.5000 0.2500 light 4
    shadow_map 5 atlas uv 0.5000 0.2500 0.5000 0.2500 light 5
    shadow_map 6 atlas uv 0.5000 0.5000 0.5000 0.2500 light 6
    shadow_map 7 atlas uv 0.5000 0.7500 0.5000 0.2500 light 7

/*
    target atlas
    {
        pass clear
        {
            colour_value 1 1 1 1
        }
    }
*/

    shadow_map_target_type directional spot point
    {
        shadow_map 0
        {
            pass clear
            {
                colour_value 1 1 1 1
                shadow_map_full_viewport yes
            }
        }
    }

    shadow_map_target_type directional
    {
        shadow_map 0 1 2 3 4 5 6 7
        {
            pass render_scene
            {
                visibility_mask        0x00ffffff
            }
        }
    }

    shadow_map_target_type point
    {
        shadow_map_repeat 0 1 2 3 4 5 6 7
        {
            target tmpCubemap +X : cubemap_target_shadow {}
            target tmpCubemap -X : cubemap_target_shadow {}
            target tmpCubemap +Y : cubemap_target_shadow {}
            target tmpCubemap -Y : cubemap_target_shadow {}
            target tmpCubemap +Z : cubemap_target_shadow {}
            target tmpCubemap -Z : cubemap_target_shadow {}

            shadow_map
            {
                pass render_quad
                {
                    material Ogre/DPSM/CubeToDpsmColour
                    input 0 tmpCubemap
                }
            }
        }
    }

    shadow_map_target_type spot
    {
        shadow_map 0 1 2 3 4 5 6 7
        {
            pass render_scene
            {
                visibility_mask        0x00ffffff
                overlays            off
                rq_first    0
                rq_last        250
            }
        }
    }

    shadow_map_target_type directional spot point
    {
        shadow_map 0
        {
            pass compute
            {
                job ESM/GaussianLogFilterH
                input 0 atlas
                uav 0 tmpGaussianFilter write
            }

            pass compute
            {
                job ESM/GaussianLogFilterV
                input 0 tmpGaussianFilter
                uav 0 atlas write
            }
        }
    }
}
Notes:
1. I'm not using pssm even for directional lights because there maybe no directional lights, and I don't want to waste memory because other types of lights can't use these shadow_maps. Is it ok?
2. The special visibility_mask is used to exclude certain internal objects like PCC's proxy geometry.
3. Only shadows of spot lights seem to work. For point lights, it looks like the whole point is occluded, but with RenderDoc I can see the shadow map looks good (looks like a normal dual-paraboloid thing).
4. When only one directional light is casting shadow, the pixel shader for rendering shadow receivers even did not use any shadow maps (I confirmed in RenderDoc that there is no shadow map in texture input, and there are no shadow map sampling code generated for those pixels)

I only used ESM + static shadow maps once 1 year ago, I think at that time both point lights and spot lights are working, though I didn't test directional lights back then.

I also did some quick experimenting with fully dynamic lights (removed all code to fix shadow maps to lights and copied ShadowMappingDebug's ESM node), but no shadow (even for spotlights) are shown.

Maybe I did something stupid, but I'm very unfamiliar with shadow related codes so I don't know how to debug... Thanks!
0 x

User avatar
Kaylx
Greenskin
Posts: 123
Joined: Sun May 22, 2011 10:45 pm
Location: Scotland

Re: [2.1+] complete static ESM node setup

Post by Kaylx » Tue Jan 15, 2019 3:08 pm

Did you ever get this working properly? I'm trying to do the same thing.
0 x

rujialiu
Goblin
Posts: 230
Joined: Mon May 09, 2016 8:21 am
x 24

Re: [2.1+] complete static ESM node setup

Post by rujialiu » Tue Jan 15, 2019 4:08 pm

Kaylx wrote:
Tue Jan 15, 2019 3:08 pm
Did you ever get this working properly? I'm trying to do the same thing.
Later I discovered that the missing shadow has something to do with my modifications to the Hlms Pbs. Our point lights are using a custom attenuation function so the parameters (attenuation.*) have different meaning, which messed up a few things. Our spot lights are not modified so they're working.

I guess point lights should also work if you didn't modify Pbs but I never tried. What's your problem?
0 x

User avatar
Kaylx
Greenskin
Posts: 123
Joined: Sun May 22, 2011 10:45 pm
Location: Scotland

Re: [2.1+] complete static ESM node setup

Post by Kaylx » Tue Jan 15, 2019 5:00 pm

I'm trying to setup ESM static shadows with a single directional light but it isn't working.

I just found this post which may suggest it doesn't work.
A new feature also part of the Shadow Mapping rewrite was the introduction of static shadows. This doesn’t work well for directional lights (something is being thought about that, though).
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4116
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 243
Contact:

Re: [2.1+] complete static ESM node setup

Post by dark_sylinc » Tue Jan 15, 2019 8:48 pm

Directional lights require constantly adjusting the shadow map to maximize the quality based on what's visible by the camera. Due to this, directional lights are not static, thus making them static is not going to work right.
If we were to ignore the quality adjustments (i.e. force directional lights to be static) the quality would be really poor.

Static directional lights could be used for the last PSSM split, or in very specific situations, however Ogre 2.1+ does not yet currently support that.
0 x

User avatar
Kaylx
Greenskin
Posts: 123
Joined: Sun May 22, 2011 10:45 pm
Location: Scotland

Re: [2.1+] complete static ESM node setup

Post by Kaylx » Wed Jan 16, 2019 11:44 am

Thanks dark_sylinc.

To give you some background, in the application i'm working on (basically an OSM scene viewer/editor) there is only 1 directional light, the sun.
Its position is controlled by the user via date/time controls, so updating shadows every frame isn't really needed.
All objects in the scene are basically static too, again as the user controls them.
The app uses an orbit camera which allows the user to view the enitre scene or zoom into just a single object etc.

With ESM shadows on, the FPS takes a significant hit and I was looking to optimise where possible.
The scene size can vary wildly, from 10m to 100km, and i'm having trouble finding the best shadow setup.

I thought about making the sun a very distant spotlight and using static shadows that way, but it didn't work out very well.

What kind of shadow setup would you recommend?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4116
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 243
Contact:

Re: [2.1+] complete static ESM node setup

Post by dark_sylinc » Wed Jan 16, 2019 3:18 pm

When it comes to terrain shadows, my recommendation is to follow what I show in the Terrain sample: a raytraced shadow map for the terrain, thus the terrain is not a caster in the PCF/ESM technique.

Traditional shadow mapping techniques struggle too much due to the large size of terrains, variability of the LOD techniques used, and vertex count; which is why a specialized solution works much better.
0 x

Post Reply