Shadows

Everything about development and the OpenMW source code.
Post Reply
User avatar
scrawl
Posts: 2076
Joined: 18 Feb 2012, 11:51
Contact:

Shadows

Post by scrawl » 09 Jul 2017, 21:02

Since I won't have time to work on shadows anytime soon, I might as well post what I tried a while ago:

https://github.com/scrawl/openmw/tree/osgshadow

This was a very basic test of osgShadow's ViewDependentShadowMap (supposedly their most advanced, and full featured, shadow technique). But here's where everything went wrong (that I can remember):

- Due to a bug introduced with OSG 3.4, Drawables not attached to Geodes (such as OpenMW's) are not considered for the shadow frustum, this has been fixed in the OSG git master (and possibly a point release, can't remember).
- The ViewDependantShadowMap is, for some reason, hard coded to just 2 splits. Most games use at least 3. This may or may not turn out to be an actual issue, if the other issues can be resolved?
- The terrain's multi-pass material is not integrated properly so the terrain looks white.
- Polygons facing away from the light source display a flickering effect (this is normal, and can be resolved by using a shader so that back-facing polygons are always shadowed).
- From certain camera angles, the shadow projection goes totally wonky and all blurry. I have no idea why this is. I tracked down the change to some magic calculations with 1-letter variable names that I could make no sense of.
- Note that if you turn on shadow map debugging, the scene's shadow rendering will break; due to a bug (or missing feature?) in the debugging feature.

It's really hard to say if it's worth continuing with osgShadow or should we try making our own shadow module from scratch.

raven
Posts: 47
Joined: 26 May 2016, 09:54

Re: Shadows

Post by raven » 09 Jul 2017, 21:58

- From certain camera angles, the shadow projection goes totally wonky and all blurry. I have no idea why this is.
If it is some type of perspective shadow mapping the quality will vary with the angle between the view and light.

For stable shadows you are probably better off with simple parallel split, even if it is more wasteful.

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

Re: Shadows

Post by raevol » 10 Jul 2017, 00:12

Thank you for posting this scrawl!!

User avatar
AnyOldName3
Posts: 541
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 10 Jul 2017, 01:20

I'm working through some OSG tutorials at the moment, so hopefully, in a few days, I can take a look at this and actually be able to tell what's going on.

User avatar
psi29a
Posts: 3432
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Shadows

Post by psi29a » 10 Jul 2017, 08:43

To be fair, OSG-3.4 was never meant to be long-lived in Debian (and Ubuntu) as the maintainers were waiting for OSG-3.6 to drop.

Is there anyway we can back-port the fix for OSG-3.4 since we have a fork anyway? In reality, what is being maintained in Debian now is really Scrawl's fork plus some other patches from me. ;)

User avatar
scrawl
Posts: 2076
Joined: 18 Feb 2012, 11:51
Contact:

Re: Shadows

Post by scrawl » 10 Jul 2017, 10:03

If it is some type of perspective shadow mapping the quality will vary with the angle between the view and light.
I know that, but the effect was much much worse, like a small camera rotation of 1 degree would suddenly change the shadows from perfectly crisp to completely unusable.

raven
Posts: 47
Joined: 26 May 2016, 09:54

Re: Shadows

Post by raven » 10 Jul 2017, 20:30

scrawl wrote:
10 Jul 2017, 10:03
If it is some type of perspective shadow mapping the quality will vary with the angle between the view and light.
I know that, but the effect was much much worse, like a small camera rotation of 1 degree would suddenly change the shadows from perfectly crisp to completely unusable.
I can imagine a sudden change due to a shadow caster close (behind the camera?) expanding the light frustum. Just a guess of course.

Chris
Posts: 1286
Joined: 04 Sep 2011, 08:33

Re: Shadows

Post by Chris » 10 Jul 2017, 22:05

raven wrote:
10 Jul 2017, 20:30
I can imagine a sudden change due to a shadow caster close (behind the camera?) expanding the light frustum. Just a guess of course.
The typical shadow mapping technique I read about has the big caveat that it will not work with things like a first-person camera because the math just falls apart when the main and shadow cameras have certain relative orientations (e.g. a light source behind the camera). It seems quite a few "easy" shadow methods just assume you can control the camera and/or light source(s) enough to avoid the problem cases, and suggest finding something else if you need something more general.

User avatar
scrawl
Posts: 2076
Joined: 18 Feb 2012, 11:51
Contact:

Re: Shadows

Post by scrawl » 14 Jul 2017, 22:36

I'm working through some OSG tutorials at the moment, so hopefully, in a few days, I can take a look at this and actually be able to tell what's going on.
Just in case you are serious, maybe this will help: OpenMW Rendering Architecture
I think I'd skip the tutorials though, many of them are using deprecated features or just aren't very interesting.

User avatar
AnyOldName3
Posts: 541
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 » 14 Jul 2017, 23:23

Everything else I've done with graphics has either been a CPU raytracer or some basic stuff with raw OpenGL and so not with a proper scene graph system. I still think some of the stuff I'm picking up from the tutorials isn't a terrible idea and there's still stuff I know I should know but don't.

Thanks for the rendering architecture link, though.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests