Are Dynamic Shadows Coming Back In a Month or So?

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
raven
Posts: 66
Joined: 26 May 2016, 09:54

Re: Are Dynamic Shadows Coming Back In a Month or So?

Post by raven » 14 Dec 2016, 23:07

Shadows are eye candy. I'd say go for the shader based variant only.

User avatar
sjek
Posts: 441
Joined: 22 Nov 2014, 10:51

Re: Are Dynamic Shadows Coming Back In a Month or So?

Post by sjek » 15 Dec 2016, 17:56

is there a requirements list what a proper technique needs to fullfill to make it a good fit for openmw?
one that comes to mind is that exterior light doesn't have direction set in vanilla files so would also vote for shader based solution. that way it would need (non-programmer here) for shaders or gamefiles ability to define in-game variables ?

MGE XE GPL2 needs hrnchamd permission:
Spoiler: Show
if remember right, before switching to osg there was issue about making shadows transluent or lighter on the edges and how the prajectory were calculated with lights
"life is crazy"
"craziness has beauty which only crazies understand" some movie clip in the head.
https://wiki.openmw.org/index.php?title=Testing

CMAugust
Posts: 273
Joined: 10 Jan 2016, 00:13

Re: Are Dynamic Shadows Coming Back In a Month or So?

Post by CMAugust » 16 Dec 2016, 05:43

Speaking of which, has anyone been in contact with Hrnchamd lately? He's been gone a long time.

tormeh
Posts: 6
Joined: 11 Mar 2014, 03:28

Re: Are Dynamic Shadows Coming Back In a Month or So?

Post by tormeh » 23 Dec 2016, 02:31

Aussiemon wrote:
damiel wrote:
raven wrote: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.


Long-time lurker here. Why would requiring shaders instead of vertex lighting be bad? Didn't GPUs switch to being shader-based a long time ago? Or is there another reason besides compatibility with old cards?

User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: Are Dynamic Shadows Coming Back In a Month or So?

Post by raevol » 23 Dec 2016, 04:38

tormeh wrote:Long-time lurker here. Why would requiring shaders instead of vertex lighting be bad? Didn't GPUs switch to being shader-based a long time ago? Or is there another reason besides compatibility with old cards?
I have all of these same questions.

mikjames
Posts: 22
Joined: 08 Dec 2016, 06:00

Re: Are Dynamic Shadows Coming Back In a Month or So?

Post by mikjames » 22 Jan 2017, 01:22

Funny story, I had actually never played much of Morrowind. So I decided it was better to do my first play through on the original engine and come back to openmw after the full release.

Mgexe actually isn't too performance heavy without hires textures and distant land set conservatively. I think openmw handles hires textures/memory a lot better, but I'd rather wait for the final product rather than spoiling the surprise.
I have no doubt Openmw will eventually be faster and smoother in every way but for now mgexe gives me some good looking shaders without a significant performance hit. I can always get a ramdisk up and running to "fix" the hires texture stuttering and distant land.

User avatar
sjek
Posts: 441
Joined: 22 Nov 2014, 10:51

Re: Are Dynamic Shadows Coming Back In a Month or So?

Post by sjek » 22 Jan 2017, 13:12

yep
there's always a way

have read a bit..
on mge xe i think it isn't 1/1 conversion in a degree as it's mixing possibly alpha blending and testing and other hacky stuff to work around morrowind lightning implementation. while openmw uses transparency sorting for overlaying textures. also hcrhamp have written that mge xe PBR shader pipeline will need to be rewritten for openmw so same PBR textures won't necessarily work.

http://forum.openmw.org/viewtopic.php?f ... 53&p=19535 3D shader stuff

http://forums.bethsoft.com/topic/161534 ... p=25302388 vtastek on the point xP

what looked on the shadermanager and visitor it seemed to iterate over textures and shaders on what to apply but otherwise the shader functions being linked in the compiler kinda in a same way as with mygui layout files.

on shader lighting does having it defined in lighting.glsl make it shader based ?

otherwise is the main problem somewhere near a point that making shadows need some way or another fetch info from nif loader or making separate module to loading code to get shape and stuff out ?

mge xe / vanilla shadows are notorious as the bulk polygons are taken so it hits performance quite hard

edit: just getting my head around this http://trac.openscenegraph.org/projects ... troduction so the standard way could be to define nif, asset loader, scenepraph or where it fits without interfering with threading, as stateset with or for glProgramObject and that would render it with shaders. then glShaderObject can compile shaders at runtime and apply them to given statesets via glProgramObject.

as those aren't in the code, it's probaply loaded individually to work with vanilla files ?
include dependancies xP

edit2: that 3D shader stuff as there can be alpha layering problems with depth of field or other shader methods in mge xe so technicality..
"life is crazy"
"craziness has beauty which only crazies understand" some movie clip in the head.
https://wiki.openmw.org/index.php?title=Testing

mikjames
Posts: 22
Joined: 08 Dec 2016, 06:00

Re: Are Dynamic Shadows Coming Back In a Month or So?

Post by mikjames » 24 Jan 2017, 13:14

sjek wrote:yep
there's always a way

have read a bit..
on mge xe i think it isn't 1/1 conversion in a degree as it's mixing possibly alpha blending and testing and other hacky stuff to work around morrowind lightning implementation. while openmw uses transparency sorting for overlaying textures. also hcrhamp have written that mge xe PBR shader pipeline will need to be rewritten for openmw so same PBR textures won't necessarily work.

http://forum.openmw.org/viewtopic.php?f ... 53&p=19535 3D shader stuff

http://forums.bethsoft.com/topic/161534 ... p=25302388 vtastek on the point xP

what looked on the shadermanager and visitor it seemed to iterate over textures and shaders on what to apply but otherwise the shader functions being linked in the compiler kinda in a same way as with mygui layout files.

on shader lighting does having it defined in lighting.glsl make it shader based ?

otherwise is the main problem somewhere near a point that making shadows need some way or another fetch info from nif loader or making separate module to loading code to get shape and stuff out ?

mge xe / vanilla shadows are notorious as the bulk polygons are taken so it hits performance quite hard

edit: just getting my head around this http://trac.openscenegraph.org/projects ... troduction so the standard way could be to define nif, asset loader, scenepraph or where it fits without interfering with threading, as stateset with or for glProgramObject and that would render it with shaders. then glShaderObject can compile shaders at runtime and apply them to given statesets via glProgramObject.

as those aren't in the code, it's probaply loaded individually to work with vanilla files ?
include dependancies xP

edit2: that 3D shader stuff as there can be alpha layering problems with depth of field or other shader methods in mge xe so technicality..
Um, yeah I don't know what any of this means. In any case I get ~110 avg fps on a 980 with base mgexe (nothing enabled except widescreen, native res and very basic water shaders that can't be disabled). I get around 90 avg fps with the HQ SSAO, all of the water effects, HQ Bloom, and Dynamic Solar Shadows enabled.

If I start bringing in the greenery from MGSO, and the higher quality textures (still not up to todays standards for texture res) I can easily tank the framerate down another 30-40 fps, and that's before I even enable distant land.
I think shadows shaders is the least of Mgexe/Morrowind's engines worries. The engine just wasn't built to handle high resolution textures and long draw distances effectively, and they didn't improve it much in Oblivion for that matter.
I would assume that shadowing is actually disabled beyond a certain distance in game, but I could test it out and see if Distant land is still as much of a performance hog without dynamic shadowing.
The only solution I know of beyond hacking apart the engine to code in better ram utilization, is skipping the ram utilization altogether and booting the entire game off a ram disk.

Post Reply