Jump to content

high camera.maxZ disables shadows [may be a bug]


Recommended Posts

Hello, in my scene (not finished at all) : link to my scene (you're on the moon)

I use a very high value for camera.maxZ , this disables my shadows, is it a normal behavior ? What can I do ?

- is it possible to reduce camera.maxZ but force very far objects to be shown ?

- is it possible to keep a high value for camera.maxZ but enable shadows ?



Link to comment
Share on other sites

Hi DJ!  Pretty scene!  Nicely done.  I made a playground from your (modified) demo... to help forum users troubleshoot the issue.  It still needs some tweaking.  DJ or anyone, feel free to adjust and re-save, and send us fresh URL's that better illustrate the issue.


BUT... I WAS getting "out of memory" errors, often.  (Perhaps it was because I had your non-playground version... open in another window.)

Maybe you or others can adjust that playground, and then we'll 'get down' with some serious experiments and learning.  :) 

When playgrounds are made, discussions happen and things get fixed, and we ALL get to see/hear how.

Link to comment
Share on other sites

Hi again, DJousto.  Thanks for the nice testing playground.  That's the way we like 'em.  Minimum code, issue is easy to see, perfect.


Line 37 ...  .useVarianceShadowMap = true;  ...seems to work-around the issue.  Line 38 works, too. 

For high MaxZ playgrounds such as this, Poisson isn't working, nor is filter=none (the default).  

Ignore the docs when they say that 'useVarianceShadowMap' is true by default.  That is incorrect, and I/someone needs to update the docs.  But, I am having problems getting a Pull Request to the docs curators.  I have had a PR open for the animation tutorial... for about 2-3 days, now.  No merge, yet, but maybe they are busy.  More likely, I screwed-up the PR by making some github mistake.  That is a different subject.  :)

ANYway... shadowGenerators are set this._filter = ShadowGenerator.FILTER_NONE by default, these days.

There might be a problem with DirectionalLight.shadowOrthoScale... not sure yet.  I'm still looking it over.

Maybe experts will look, and report their thoughts  (please/thx).  Camera maxZ is used only in certain places... for shadows.  I'm still investigating... but I'm scared.  :D   

Link to comment
Share on other sites

:) Cooool! 

After you get done playing on the moon, you COULD come into the sewers of the framework with me, and poke things with sticks, trying to figure out WHY the Poisson and no-filter shadows failed with high MaxZ. 

Your call.  I'm not a very good coder... but I poke things with sticks... quite well.  Poking things with sticks is one of the very earliest child experiment/discover methods... so child-Wingnut still uses this method.  :D  (sometimes on humans, too)  :o

To be brief, if you want to help me find out WHY the shadowGenerator or DirectionalLight.shadowOrthoScale is being "a turd"... please feel free to come stick-poking with me.  Maybe see if you can get DirectionalLight.shadowOrthoScale to work at all.  From the shadows docs...


For directional light, you can control the size of the projection window by modifying light.shadowOrthoScale (0.1 by default which means that the projection window is increase by 10% from the optimal size).


Apparently, dirLight.shadowOrthoScale is set 0.5 by default.  I changed it to 5 in line 17... no change seen.  I don't see shadowOrthoScale mentioned at all... in https://github.com/BabylonJS/Babylon.js/blob/master/src/Lights/Shadows/babylon.shadowGenerator.js .  Maybe it is an obsolete property... no longer used.  *shrug*  

I haven't gotten it to EVER work, yet... but... I'm slow and not very bright.  If you feel like doing some tests on stuff, and reporting discoveries (if there ARE some)... that would be great.  I can use all the extra intelligence that I can get.  thx! 

Update:  DJ... ever seen a piece of BJS framework... "hijacked" into a playround scene?  I "hijacked" the entire shadowGenerator code... into a playground scene. http://playground.babylonjs.com/#1GUOCF#7   It's EASY to poke things with sticks, now.  :)

Link to comment
Share on other sites

5 hours ago, Wingnut said:

  But, I am having problems getting a Pull Request to the docs curators.  I have had a PR open for the animation tutorial... for about 2-3 days, now.  No merge, yet, but maybe they are busy.  More likely, I screwed-up the PR by making some github mistake.  That is a different subject.  :)

You can have many PR at the same time, do not hesistate to send a new one when needed, even if a previous one is still waiting. Curators will merge when less busy, don't worry.

Link to comment
Share on other sites

you're right wingnut, you gave me a workaround, but the undelying problem is still under analysis

with your shadowgenerator function "hack" it should be easy to analyse, .... i mean easy for babylonjs ninjas, if you wait for me to lead the investigation, it will take a litle more time (it's in middle of my todo list)

Link to comment
Share on other sites



Is it resolved?  Shadow still disappears when using Poisson or no-filter... when camera maxZ is over 62000.  *shrug*  Normal behavior?

I just quoted ME.  Felt weird, I got a little shiver.  :)

I'm trying to get someone smart to work on this shadow issue for me.  :) 

Do we see what happens when an issue gets marked resolved?  It's like we wiped a booger on it.  Nobody wants to get near it.  heh

I'll come back to this if nobody else checks it out.  (like I know how to troubleshoot shadows - oh boy)

Link to comment
Share on other sites

the problem lies certainly in the shaders program, in a function named computeShadowWithPCFCube(), this functions uses depht value (camera.maxZ and camera.minZ), but the code is not commented, I don't understand why depht value is considered to compute the shadow value.

Perhaps we should move this topic to bug section ?


Link to comment
Share on other sites

I guess the solution would be scale everything down... But then you will run into the problem of bad physics if your scale is not big enough... So yea this may be something that needs to be addressed, cause we shouldn't have a "range" that we have to comform to in order to get the best render and physics... That will really limit things in the future. 


I've also noticed some weird clipping effects and large distances and when minZ is set too low.

Link to comment
Share on other sites


Lines 36-39. 

camera.maxZ < 50000  - then all shadows work.

camera.maxZ > 70000  - then only variance and blurVariance work.

@Deltakosh If this seems normal to you, then I'm happy with [resolved].  I wanted to be sure. 

Maybe I/we will add a note about this... in the shadows tutorial.  It is related to depth buffer precision, you say?  Roger that, thanks!

Also, thanks to DJousto for trying to find the reasons, and to Pryme8 for considering future ramifications.  I learned MUCH with this thread.  Hopefully, future shadow users will learn from this thread, too.  Thanks, everyone!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...