Shadows

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

Re: Shadows

Post by scrawl »

Using a minimal setup for now sounds like a good idea. Probably won't work for extended distances like split shadow maps do, but is better than no shadows at all.
Some shadows seem to end up rendered on the skybox, but I can probably solve this really easily once I know how far the skybox is.
Right, forgot to mention the sky on my list of issues.

The sky isn't far at all (around 100 units away from the camera AFAIK). It just appears far because it renders first and 'under' everything else. We'll need to make the sky not receive any shadows. For the non-shader path, disabling the texture unit should be enough (i.e. set the shadow texture unit explicitely to 'OFF' in the sky's StateSet)

Keep in mind that if you're not using shaders,
- 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).
is going to be an issue. I have no idea if that explains the rest of your glitches, though.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 »

There are a couple of other things that seem to be casting or receiving shadows when they're not supposed to, so I'd like to make LispSM take notice of the shadow casting and receiving nodemasks if at all possible rather than hacking around it.

Also, none of the 'advanced' shadow techniques OSG supports work without shaders (if you're not already using shaders, default ones are used for the specific shadow technique), so we may have to just force shaders when shadows are used. If we really need fixed-function support for shadows, then we have to use the ShadowTexture technique, and that will probably produce its own artefacts which we'll have to deal with separately.
User avatar
DestinedToDie
Posts: 1181
Joined: 29 Jun 2015, 09:08

Re: Shadows

Post by DestinedToDie »

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

Re: Shadows

Post by AnyOldName3 »

I made that? That worked a lot better than I expected.
User avatar
lysol
Posts: 1513
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Shadows

Post by lysol »

AnyOldName3 wrote: 20 Sep 2017, 18:45 I made that? That worked a lot better than I expected.
Quote of the year.

Haha, it looks great! Great work scrawl and AnyOldName!

And thanks for the video, Destined.
Last edited by lysol on 20 Sep 2017, 20:09, edited 1 time in total.
magamo
Posts: 109
Joined: 28 May 2016, 17:28

Re: Shadows

Post by magamo »

For those of us that are poking at this branch, what recommended settings do you have to get the shadows to work?
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 »

With my branch, all I've got in particular is shaders turned off. I should be able to tweak the shaders to work soon as I've done it for a different shader already when trying to get one of my experiments to work.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: Shadows

Post by scrawl »

There are a couple of other things that seem to be casting or receiving shadows when they're not supposed to, so I'd like to make LispSM take notice of the shadow casting and receiving nodemasks if at all possible rather than hacking around it.
IIRC, the shadow receiving masks don't really work with any technique. It's hard to make them work, anyway - if a custom shader is used, we'll need a variant of that shader without shadows, which only the shader writer can do.

The shadow casting mask, on the other hand, is much easier to handle, and should already work as far as I'm aware.
Also, none of the 'advanced' shadow techniques OSG supports work without shaders (if you're not already using shaders, default ones are used for the specific shadow technique)
Without a receiver shader or without a casting shader? IIRC the caster shader is always provided by osgShadow with no way to override it(?), while the receiver shader is optional.
so we may have to just force shaders when shadows are used.
We probably should do that. Using shaders will also make the lighting more accurate (i.e. shadows block out the diffuse lighting instead of being a generic modulation on the final color), and fix that flickering issue with the polygons not facing the light.

Regarding performance, there's at least one thing we could do to improve it. In the shadow caster pass, OSG will bind the object's primary texture and uses its alpha channel to reject shadow fragments. This is required to make things like transparent leafs cast their correct shadow, but for non-transparent meshes, binding the texture is totally redundant so we'd probably want to find some way to avoid that.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 »

Every shadow technique except ShadowTexture replaces the fixed-function rendering of receivers with a (supposedly) equivalent shader with shadow support, except that it might not be equivalent if, for example, fog is on, as the shader used can't access fixed-function state. It does look like they all are clever enough to keep ambient light unaffected by shadows, though.

Right now I'm converting our shaders to work with shadows, which would be a really simple job except I had the bright idea of making the shadow only affect light from the light source the shadow is from.

I also found an issue with Git for Windows' bash shell - the cp command replaces existing files normally but doesn't do so when copying the entire contents of a folder. This means actually testing my shaders is a pain as the prebuild script can't put the new versions in the right place without tweaking.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Shadows

Post by AnyOldName3 »

Actually, that doesn't seem to be quite what's happening with the prebuild script. The cp command is being even more retarded than I thought, but I think I've figured out an alternative approach.
Post Reply