Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / @AGK team(or anybody else who knows) - regarding shadow mode 2: bug or limitation?

Author
Message
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 11th Dec 2018 17:00 Edited at: 11th Dec 2018 17:51
Hi guys,

I've come across a little oddity in the shadow system while working on my WIP.

In mode 2 there seems to be a *lot* of displacement of the shadow when doing a 360 degree turn, in comparison to mode 1 and 3.
It's so much that it actually comes loose from the model and it appears as if the model(s) has moved upwards(optical illusion).

I understand there are quality differences between modes 1, 2 and 3, since the help file says:

Quote: "SetShadowMappingMode
Description
Turns shadow mapping on or off, by default this is off. Shadows are only generated by the the global directional light, which can be controlled with the SetSunDirection command. Note that this is not guaranteed to be supported on all devices, you can check for the current device by calling GetShadowMappingSupported. There are currently three shadow modes that can be used, mode 1 uses Uniform shadow mapping which has lower but consistent quality. Mode 2 uses Light Space Perspective shadow mapping (LiPSM) which has higher quality in most cases but if the camera is looking in the same direction as the light then it is no better than Uniform shadow mapping. Light Space Perspective also suffers from shadow shimmering as the camera moves whereas Uniform is more stable. Both have about the same performance. Mode 3 uses Cascade shadow mapping which uses multiple shadow maps to maintain high quality near the camera whilst still allowing lower quality shadows in the distance. This method has much lower performance than the previous two methods but results in better quality shadows in all cases.

Note that when using modes 1 and 2, texture stage 7 on all objects receiving shadow is reserved for the shadow map. When using shadow mode 3 (cascade shadows) then texture stages 4, 5, 6, and 7 are reserved for the shadow maps. "


But it doesn't say that in mode 2 it's actually doing this displacement, decreasing it's quality advantage over mode 1. Is there a way round it, or something you guys can fix - for instance depending on the cam orientation, move the shadow more close to the object that's casting?


I've done some research(with pictures) under this thread:
Universal 1st/3rd person AppGameKit framework(without physics)#msg2634585
*A link to the source can be found in last post if anybody wants to test, shadow modes are switchable using F7.

Hope you guys can explain or if necessary fix, for mode 2 works best performance/quality wise.
[EDIT: corrected typo]
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 11th Dec 2018 22:20
Mode 2 uses some funky perspective projection matrices that get incredibly inaccurate when the camera and light are pointing in the same direction. The only things I can think of to work around it is to limit the extent of the projection matrix by using SetShadowRange to set the range smaller than the camera view range, or switch to mode 1 when the dot product of the light direction and the camera direction reaches a certain value. i.e. (Lx*Cx + Ly*Cy + Lz*Cz) > 0.7 where (Lx,Ly,Lz) and (Cx,Cy,Cz) are normalized, and 0.7 is a value between 0 and 1, where 1 is looking in exactly the same direction and 0 is perpendicular to each other.
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 12th Dec 2018 09:58 Edited at: 14th Dec 2018 00:08
@Paul Johnston

Hi Paul, thanks for answering / explaining.

I've already tried setting the shadow range to smaller than camera view range(in the code I supplied under "setup_and_update_world.agc" lines 28 and 72), but unfortunately that didn't solve it, as you can see in the last GIF picture(rotating around a pole model).
I did notice that if I decrease the shadow range drastically, then it *does* affect the issue positively.
Mind you I'm using a fairly large scale as I intend to retain compatibility with the AppGameKit physics system, for easy implementation afterwards.

Your 2nd suggestion might be worth while investigating, as mode 1 doesn't seem to suffer from the shadow displacement as much, so I'll look into it.
It does complicate things bit further and is less elegant though.
[EDIT: tried the 2nd suggestion(switch to mode 1), but the transition is way too apparent, ugly even, so unfortunately not really an option i'd say.]


As it does happen to each and every shadow in the scene at once, it might be easier to just increase or decrease the shadow texture position under certain angles/distances, so that it stays more closely to the models, but we do not have control over this right now.
Would such a command be feasible?

Grtz,

Rick
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 12th Dec 2018 12:27 Edited at: 12th Dec 2018 12:29
Update:
Switching shadow mode 2 to 1 probably could look ok in a well shaped environment, but looks very ugly in a simple environment with basic shapes, especially on the surroundings(most noticeable on the left round object).

Mode2 - with shadow to object gap:


Mode1 - without shadow to object gap, but very noticeable, especially on the environment primitives..
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 12th Dec 2018 18:32 Edited at: 12th Dec 2018 18:33
Noticed something else: when shadow is directly in front of the object and cam goes overhead, the shadow changes as if in mode 3. This only happens when directly looking at the shadow when in front of the object in mode 2.

Just an observation I found interesting, doesn't really have anything to do with the issue I guess.

Login to post a reply

Server time is: 2024-03-28 09:09:58
Your offset time is: 2024-03-28 09:09:58