Shadows

Everything about development and the OpenMW source code.
User avatar
werdanith
Posts: 277
Joined: 26 Aug 2011, 16:18

Re: Shadows

Post by werdanith » 05 Nov 2017, 23:28

Great work people, just spent a few hours walking around, enjoying the scenery. :)

User avatar
AnyOldName3
Posts: 564
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 06 Nov 2017, 01:28

Right, does anyone know where I should start looking for code pertaining to the minimap and character preview rendering?

User avatar
AnyOldName3
Posts: 564
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 06 Nov 2017, 03:20

Also, I can't exactly see any reason why the VDSM technique needs to be hardcoded to two splits. It looks like the only bit that's actually not got all the code there is the shader, and that's a simple case of just adding more samplers conditionally on whether the setting is set or not.

I think the current to-do list is as follows:
  • Stop the whole minimap being shadowed
  • Stop the whole character preview being shadowed
  • Parallel split/cascaded shadow maps. (I'm becoming increasingly sure that these are the same thing and the unused shadow settings function to toggle between them is stupid.)
  • Make sure interiors aren't being ruined by there being no sun.
  • Stop the ridiculous fake nighttime light source (that I'm assuming we can't do without) casting shadows in stupid places.
  • Hook things up so that there are settings and changing those settings changes things.

User avatar
werdanith
Posts: 277
Joined: 26 Aug 2011, 16:18

Re: Shadows

Post by werdanith » 06 Nov 2017, 13:40

AnyOldName3 wrote:
06 Nov 2017, 03:20
  • Stop the ridiculous fake nighttime light source (that I'm assuming we can't do without) casting shadows in stupid places.
Can't we get it to align with masser?

User avatar
AnyOldName3
Posts: 564
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 06 Nov 2017, 14:26

I imagine that would be one possible solution. The meat of the problem is that people tend to like to be able to see in games even when it's nighttime, so an extra pretend light source is added that has far more power than anything at night does in the real world.

User avatar
AnyOldName3
Posts: 564
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 07 Nov 2017, 01:41

Parallel split shadow maps were easy to get working. They didn't help as much as I was expecting, though. Someone else can compare the improvement. The split only seems to land about a metre in front of the player, so we'd almost certainly benefit from adding a second split. At that point, some discussion about setting up the shaders dynamically instead of hardcoding them might be pertinent.

I've not pushed these changes to the sky fixing branches, just the main one.

User avatar
AnyOldName3
Posts: 564
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 07 Nov 2017, 17:46

The PSSM changes are pushed to the fixed sky branches.

Weirdly, the method-one branch seems to have stopped working properly even when I rebuild commits that I know used to work (as I originally thought it was a merge conflict). I'd blame the driver update I did this morning, but it's more like NodeVisitors have started ignoring their nodemasks.

The driver update does seem to have reduced the number of erroneous OpenGL state errors that OSG reports, though, which is nice.

User avatar
scrawl
Posts: 2085
Joined: 18 Feb 2012, 11:51
Contact:

Re: Shadows

Post by scrawl » 07 Nov 2017, 20:04

I actually had a 'method 3' idea for disabling sky shadows (oh noes, one more?). Just don't put the Sky node under the ShadowedScene node, put it above. However, the annoying thing with this is that extra render targets like the reflection and refractions will need to explicitely add the Sky node as it's no longer part of the Scene node.
Right, does anyone know where I should start looking for code pertaining to the minimap and character preview rendering?
The files would be localmap.cpp and characterpreview.cpp. I suggest to bind some kind of dummy texture that is fully white causing any shadow test in the shaders to fail. We can apply this same solution to all RTTs (i.e. also the water reflections/refractions). Although, it might actually work (and be desirable) for the refraction to have shadows in it.
Make sure interiors aren't being ruined by there being no sun.
Interiors have a sun (or a fixed directional light, anyway), which is now invisible because of shadows on everything. I think what we want to do here is leave shadows enabled, but only for actors. To do so we would probably need to introduce a new node mask first because Objects don't have any node mask at the moment.
The split only seems to land about a metre in front of the player, so we'd almost certainly benefit from adding a second split.
It might be possible to tweak the algorithm that says were the split is. Back then with Ogre3D there were a few settings for this. But yes, 3 textures are probably best anyway.
At that point, some discussion about setting up the shaders dynamically instead of hardcoding them might be pertinent.
Well, I've tinkered with 'generated' shaders in the past and I can tell you that it's absolute hell for a lot of reasons.

It might be possible to bind the uniforms to an array. In that case the duplicated code becomes a for loop which would be a bit more managable.


I haven't gotten any further with my performance optimization idea, but I measured the theoretical gain by disabling shadow-casting textures altogether like so (which will of course break the shadows of anything transparent):

Code: Select all

diff --git a/apps/openmw/mwrender/shadow.cpp b/apps/openmw/mwrender/shadow.cpp
index 915979b..e13cf0f 100644
--- a/apps/openmw/mwrender/shadow.cpp
+++ b/apps/openmw/mwrender/shadow.cpp
@@ -665,6 +665,7 @@ namespace MWRender
                 // 4.3 traverse RTT camera
                 //
 
+                _shadowCastingStateSet->setTextureAttributeAndModes(0, new osg::Texture2D, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
                 cv.pushStateSet(_shadowCastingStateSet.get());
 
                 cullShadowCastingScene(&cv, camera.get());
The thing is, I didn't notice a performance difference, or at least it was within the margin of error. But different machines may vary, and if we use 2 or 3 shadow textures the impact will of course be multiplied by that number. I'd be curious if others see more FPS with this.
Hook things up so that there are settings and changing those settings changes things.
Toggling shadows at runtime will actually be a little tricky, because we don't have a nice method to re-generate shaders for the entire scene at once. Currently there's a recreateShaders(Node*) method which is used in a few cases, but it does cause any affected StateSets to be cloned which means there is no longer any state sharing which means the performance will be bad after 'recreating' things at runtime, and the OSG state sharing routine can't be used on things that are already placed in the scene because its interface sucks. I think I'll have to think on this one for a bit.

User avatar
AnyOldName3
Posts: 564
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 07 Nov 2017, 20:43

I actually had a 'method 3' idea for disabling sky shadows (oh noes, one more?). Just don't put the Sky node under the ShadowedScene node, put it above. However, the annoying thing with this is that extra render targets like the reflection and refractions will need to explicitely add the Sky node as it's no longer part of the Scene node.
I thought of this and decided that it was a bad idea, so didn't even bother implementing it.
At that point, some discussion about setting up the shaders dynamically instead of hardcoding them might be pertinent.
Well, I've tinkered with 'generated' shaders in the past and I can tell you that it's absolute hell for a lot of reasons.

It might be possible to bind the uniforms to an array. In that case the duplicated code becomes a for loop which would be a bit more managable.
This is what I've spent today working on, and it seems to be mostly fine so far. I've not got it far enough to actually test it, but it compiles and doesn't crash with the changes partially applied. Except from two lines, osgShadow::VDSM seems to be set up as if dynamically created shaders were always a planned feature.
Hook things up so that there are settings and changing those settings changes things.
Toggling shadows at runtime will actually be a little tricky, because we don't have a nice method to re-generate shaders for the entire scene at once. Currently there's a recreateShaders(Node*) method which is used in a few cases, but it does cause any affected StateSets to be cloned which means there is no longer any state sharing which means the performance will be bad after 'recreating' things at runtime, and the OSG state sharing routine can't be used on things that are already placed in the scene because its interface sucks. I think I'll have to think on this one for a bit.
I was thinking settings.cfg settings rather than hooking them up to the GUI. I hadn't considered making the settings configurable at runtime, and am not convinced that osgShadow::VDSM can cope with that.

User avatar
AnyOldName3
Posts: 564
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 07 Nov 2017, 21:25

I just pushed the first chunk of making the shaders get set up dynamically. There are a couple of tweaks that need making to the MWShadow class, and then we should be able to do up to seven splits (although we'll obviously get artefacts if we go for that many as we start running into texture units that were already being used).

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest