Are Dynamic Shadows Coming Back In a Month or So?

[raevol]

OpenMW is open-source, feel free to implement the support of what you want yourself

On the one hand I understand and agree with your sentiment, on the other hand, we as a team really need to figure out how to get this issue closed. I was talking before about working on code documentation and then putting out a call for new developers. Any other suggestions on this?

[mikjames]

OpenMW is open-source, feel free to implement the support of what you want yourself

Yes, we've all seen this sort of response before. The good old "how dare you ask a question about progression of development unless you are contributing to the development team"
To clarify I'm not requesting, pushing for, nor demanding anything at all. I was curious to see where the team was at with development, nothing more.

Didn't realize they had already ditched shadows and distant land with .38, I thought that was only due to the engine swap? Guess I'll try .37 then

[lysol]

Didn't realize they had already ditched shadows and distant land with .38, I thought that was only due to the engine swap? Guess I'll try .37 then

Haha. Sorry, you're out of luck again, 0.37 was the first OSG version. Go with 0.36. It still uses Ogre3D and therefore still has the option to activate distant land and dynamic shadows. But do know that you'll have a lot of other features missing that, at the time, hadn't been implemented yet. And the performance on 0.36 with water shaders, shadows and distant land activated is frankly rubbish.

[sjek]

or you can use the unoptimised distand land in 0.40 and 0.41

my settings.cfg looks like this on that:

Spoiler: Show

[Cells]
exterior cell load distance = 2
preload enabled = true
preload exterior grid = true
preload fast travel = false
preload doors = false
preload distance = 1000
preload instances = false
preload cell cache min = 12
preload cell cache max = 20
preload cell expiry delay = 5
cache expiry delay = 5

[Camera]
field of view = 70
viewing distance = 25000
small feature culling = false

where basically you need to change exterior cell load distance (2 makes 5x5=25 grid) and viewing distance (radius) to suit your needs. one cell is roughly 4500

shaders in normal/specular/parallax can be toggled with these althought others know better

Spoiler: Show

[Shaders]
auto use object normal maps = true
auto use object specular maps = true
auto use terrain normal maps = true
auto use terrain specular maps = true
force shaders = true
force per pixel lighting = true
clamp lighting = false

normal map pattern = _n
normal height map pattern = _nh
specular map pattern = _spec
terrain specular map pattern = _diffusespec

then if you want other available options

Spoiler: Show

[Saves]
timeplayed = true

[Input]
allow third person zoom = true
always run = true
toggle sneak = true

[Game]
show owned = 0
show effect duration = true
prevent merchant equipping = true

[GUI]
scaling factor = 1.0
menu transparency = 0.84

there's documentation on https://wiki.openmw.org/index.php?title ... ile_tweaks and in settings-default.cfg shipped to openmw installation folder : )

[sjek]

OpenMW is open-source, feel free to implement the support of what you want yourself

On the one hand I understand and agree with your sentiment, on the other hand, we as a team really need to figure out how to get this issue closed. I was talking before about working on code documentation and then putting out a call for new developers. Any other suggestions on this?

there has been multiple docs over the times, what i know:

"official" : viewtopic.php?f=6&t=3644 ---> http://openmw.readthedocs.io/en/master/index.html
doxycen : viewtopic.php?f=6&t=3501 (0.39)
include dependancies : viewtopic.php?f=6&t=3205 (0.38-39)
opengrok : viewtopic.php?f=6&t=3031 (down)

otherwise would say it's on good direction

[raven]

OSG has a shadow module I think. So theoretically it should be pretty simple. Practically it probably depends on the level of rendering code customization in OpenMW?

[psi29a]

"official" : viewtopic.php?f=6&t=3644 ---> http://openmw.readthedocs.io/en/master/index.html
doxycen : viewtopic.php?f=6&t=3501 (0.39)

The RTD uses doxygen, so that second link is (almost) redundant.

[damiel]

OSG has a shadow module I think. So theoretically it should be pretty simple. Practically it probably depends on the level of rendering code customization in OpenMW?

Yes, OSG has something called "NodeKit" for shadows which implements several different Shadowing implementations like ShadowTextures, classic ShadowMapping, SoftShadowMapping, ShadowVolumes and some fancier stuff like PSSM.

I was looking a couple of weeks (or even month by now i think) ago at the shadow issue but i got carried away by RL stuff, but in theory its just creating a Node for Shadows, assign one of the shadowing techniques to this node and then drop this node in OpenMW's scenegraph but as you might imagine, this is not all of it. Just simply dropping this shadow node in our scenegraph will result in quite poor performance and it's not really flexible we gotta have to be a bit smarter about that. Scrawl already gave some hints in some of his comments in a older forum thread: viewtopic.php?f=6&t=2775&hilit=osg+shadow&start=30

I tried wrapping my head around this issue and i can totally see why scrawl didnt wanted to go through this stuff a second time

[Aussiemon]

OSG has a shadow module I think. So theoretically it should be pretty simple. Practically it probably depends on the level of rendering code customization in OpenMW?

Yes, OSG has something called "NodeKit" for shadows which implements several different Shadowing implementations like ShadowTextures, classic ShadowMapping, SoftShadowMapping, ShadowVolumes and some fancier stuff like PSSM.

I was looking a couple of weeks (or even month by now i think) ago at the shadow issue but i got carried away by RL stuff, but in theory its just creating a Node for Shadows, assign one of the shadowing techniques to this node and then drop this node in OpenMW's scenegraph but as you might imagine, this is not all of it. Just simply dropping this shadow node in our scenegraph will result in quite poor performance and it's not really flexible we gotta have to be a bit smarter about that. Scrawl already gave some hints in some of his comments in a older forum thread: viewtopic.php?f=6&t=2775&hilit=osg+shadow&start=30

I tried wrapping my head around this issue and i can totally see why scrawl didnt wanted to go through this stuff a second time

The main problem with osgShadow is that all of their default techniques are incompatible with parts of OpenMW (multiple lights, fog without forcing shaders, vertex lighting, etc.). Like Scrawl said in that post; we're given the tools we need to implement shadows, but we'd have to write a technique that fits our specific requirements.

[damiel]

The main problem with osgShadow is that all of their default techniques are incompatible with parts of OpenMW (multiple lights, fog without forcing shaders, vertex lighting, etc.). Like Scrawl said in that post; we're given the tools we need to implement shadows, but we'd have to write a technique that fits our specific requirements.

Are there more details available in what ways osgShadows is incompatible with openmw or to phrase it better, is there a requirements list what a proper technique needs to fullfill to make it a good fit for openmw? Maybe if we actually have it phrased out properly we have a better idea what needs to be done. Like how do the go on with this problem, implement our own shadow implementation, completly ignoring what osg offers us or do we try to work around the issues with already existing techniques?