Re: Shadows
Posted: 05 Nov 2017, 23:28
Great work people, just spent a few hours walking around, enjoying the scenery.
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.
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.
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.
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.