Are Dynamic Shadows Coming Back In a Month or So?

[raven]

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

[sjek]

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

otherwise MGE-XE with quick look (not including cript functions)
http://forums.bethsoft.com/topic/158635 ... lopment-2/
(shaders library and development, lots of good info althought scattered)

"Available variables:
texture: lastshader, lastpass, depthframe, watertexture
float: fov, time, waterlevel, sunvis, fogstart, fogrange
float2: rcpres
float3: eyevec, eyepos, sunvec, suncol, sunamb, sunpos, fogcol
float4: HDR
matrix: mview, mproj
bool: isInterior, isUnderwater"

https://github.com/Hrnchamd/MGE-XE source might be for latest stable release or so.
don't know enough to say how much of the rendering is done outside of shaders but might as well be engine specific

edit2: on the GPL2 licence
"10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. "
https://www.gnu.org/licenses/quick-guide-gplv3.en.html
"GPLv2 is compatible with GPLv3 if the program allows you to choose "any later version" of the GPL"

for implementing MGE XE variables and PBR pipeline hrnchamd needs to give his permission so the engine stuff leaves for uss. reverse engineering morrowind and modding hints

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

[CMAugust]

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

[tormeh]

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?

[raevol]

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]

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.

[sjek]

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..

[mikjames]

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.