[SOLVED] Shadows ON/OFF how?

[javalang]

Sorry for asking, maybe trivial, but I found nothing in the source...

How can I switch the shadowgenerator on/off during runtime?

Thanks

[Wingnut]

Hi JL.  This might be a "wrong way to do that" -answer, but you CAN use shadowGenerator.bias.

http://www.babylonjs-playground.com/#1CMD3G#46  See line 30 area.

BUT... the shadow MIGHT BE still there, just un-seen.  In other words, changing bias might not gain-back used resources.

Perhaps fill/empty shadowMap.renderList, as wanted, instead.  Other ways are possible, too.

Perhaps wait for smarter people than I. 

But you make a good point.  No obvious shadowGenerator on/off switch... is available.  hmm.

 

Here's another:  http://www.babylonjs-playground.com/#1CMD3G#47

This time, I toggle shadowGenerator._light between 2 different lights.  One is normal .intensity, and the other is .intensity = 0. 

It works, but there is a minor problem.  When light2 is used (.intensity = 0)... there is still a small shadow beside right foot.  Could be a bug... not sure.

Darned good question, JL.  Issue remains open - need more input from forum friends.    (thx, everyone)

[javalang]

Hi @wingnut , yes, my idea was to free ressources and speedup, i.e. in some settings the user can decide to swich on/off. So I'll waiting for more inputs. Btw. , if you want to make realistic shadows not only for a small portion of your scene, you have to increase the map dimension and going beyond 2048 the framerate drops dramatically at least on my system.

But anyway, thanks a lot for your answer

[jschwuch]

Hi @javalang you could first disable the shadow by switching to another light like @Wingnut said and when the shadow is gone, disable the redrawing by setting the shadowMaps refreshrate to 0.

shadowGenerator.getShadowMapForRendering().refreshRate = 0;

Hope this helps

[javalang]

@jschwuch thanks for reply, but how can I set the refreshrate to 0?

[jschwuch]

Included it in the playground.

http://www.babylonjs-playground.com/#1CMD3G#48

[javalang]

superb, thank you

[jschwuch]

Wow I just feel stupid now. There is actually a switch for enabling or disabling shadows without the need for an extra light or anything.

scene.shadowsEnabled = true/false

Updated the PG

http://www.babylonjs-playground.com/#1CMD3G#49

[Wingnut]

Cool solves and good work, @jschwuch!  All good ideas.  (I really like that refreshRate find... good prop-digging, there!)

I was thinking that JL wanted one shadowGenerator turned-off, not necessarily all sG's in the scene.

But yep, all shadowGenerators on/off.... good to know, too.

On 4/8/2017 at 6:39 PM, javalang said:

if you want to make realistic shadows not only for a small portion of your scene, you have to increase the map dimension and going beyond 2048 the framerate drops dramatically at least on my system.

Green area below... feel free to ignore.  Wingy was confused.  See next post for more info.

This sounds to me like JL is going traveling to distant terrains, and wants no-longer-required shadows to turn-off, but shadows ahead... to stay active, or possibly COME-active when approached.  Perhaps we should do some test playgrounds on the OTHER part of the issue (camera-distance-from-shadow vs. FPS speeds).  It's nice that JSCH found the scene shadows on/off master switch.  That might help with the new tests.

javalang, I have a few questions about the 2048 test. 

- When you put camera > 2048 from origin, was the camera's cone-shaped "frustum" (defined within camera.maxZ and .minZ) looking-at the distant shadowGenerator, or was it looking-away-from it?  Did it matter?

- Was there "new" mesh introduced into the camera frustum... at/near your 2048 test area?  Did new mesh enter camera view, or perhaps LOD levels on mesh... changed (increased resolution) as you approached >2048 areas? 

I am looking for OTHER-THAN-OLD-SHADOW -reasons why FPS dropped @ 2048+ positions.  IF new mesh were introduced or went LOD higher-rez out there, and they were shadowLight.includedMeshes and/or already within the renderList of the distance shadowGenerator... then that could explain some things.  But JavaLang might have already proved it to BE the shadowGen, because when he turned it off, the FPS recovered.

Although some/all BJS lights have a .range, I'm not sure if that .range is used in shadows.  ie. CAN a mesh cast a shadow... if it is out-of-range of the shadowLight?  hmm.  ShadowGen code-sniff would probably tell us the answer.

Anyway, if anyone makes a camera-mover playground/test, we can watch FPS as it travels beyond 2048 distance (ideally, include a canvas2D/Text2d on-screen readout/label of camera .position.  That would be cool... and handy.)

Those darned webGL lights tend to illuminate forever-distance, eh? 

We MIGHT be writing Advanced Shadow Considerations Tutorial... right here and now, as we discuss this solved issue.   

Perhaps we'll learn about the "right foot artifact" during our explorations.  I have some curiosity about that, too.  Re-activating the bias line (line 34) is a workaround for that, but THAT is just watering-down the black pixel ink... until it is clear/transparent.    Here's one more test on the foot artifact... where I added line 22 (.forceBackFacesOnly) and I lowered the ground.  The artifact changed, somewhat.  hmm.

Other forum users... climb aboard.  It's a solved thread, which means... after-issue party time!  We still have curiosities, though.    Tell us what you already know (about shadows/perf//LOD/light ranges,etc), and anything new, too.  Thanks!  Let's give Admiral @Deltakosh a puppy-ping, too, just for kicks.  He definitely knows much about shadows and lights, and he loves being around "I wonder how this works" -explorers. 

[jschwuch]

Hi @Wingnut,

 

I think you misunderstood the problem with the 2048. @javalang was referring to the size of the shadowmap not the distance of the camera from the origin.

So let's break the problems into two seperate ones:

First: FPS drops when shadow map size increases above 2048:

This is to be expected. You are in fact rendering the whole scene (at least those meshes casting shadows) to a texture of 2048x2048px (or more). This is never a good idea and is not specific to BJS. To get "nice" Shadows we either have to apply some filter to our shadow map or use a different shadowing technique (e.g. shadow volumes) which BJS doesn't have as far as I know.

When applying exponential filtering and setting up a good bias value you can for example get this result:

http://www.babylonjs-playground.com/#1CMD3G#51

with a shadow map size of only 1024x1024.

 

Second: Shadows look ugly when camera moves around in a large scene:

The Problem here really is, that the distance from the light source (which is actually the camera for shadow mapping) is too high, which then results in a way too stretched out shadow map. This again, is not a problem of BJS but of computer graphics! The solution here would be to switch to another light source when you move around the scene, so you always have a light source that is close enough so the shadow map isn't stretched out too much.

 

I hope this clarifies some of the things going on with the shadow maps.

 

[Wingnut]

Ahh, yep, I got confused with "map dimension".  Good catch, JSCH!  Thanks for fixing me, and thanks for that excellent info!  Cool!