Shadows
Re: Shadows
Great work people, just spent a few hours walking around, enjoying the scenery.
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Shadows
Right, does anyone know where I should start looking for code pertaining to the minimap and character preview rendering?
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Shadows
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:
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.
Re: Shadows
Can't we get it to align with masser?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.
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Shadows
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.
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Shadows
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.
I've not pushed these changes to the sky fixing branches, just the main one.
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Shadows
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.
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.
Re: Shadows
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.
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):
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.
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.Right, does anyone know where I should start looking for code pertaining to the minimap and character preview rendering?
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.Make sure interiors aren't being ruined by there being no sun.
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.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.
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.At that point, some discussion about setting up the shaders dynamically instead of hardcoding them might be pertinent.
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());
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.Hook things up so that there are settings and changing those settings changes things.
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Shadows
I thought of this and decided that it was a bad idea, so didn't even bother implementing it.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.
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.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.At that point, some discussion about setting up the shaders dynamically instead of hardcoding them might be pertinent.
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 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.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.Hook things up so that there are settings and changing those settings changes things.
- AnyOldName3
- Posts: 2686
- Joined: 26 Nov 2015, 03:25
Re: Shadows
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).