Adding / Destroying point lights (maybe it shall be in Bugs section ?)

Hello guys, I have ran into weird problem after upgrading Babylon from v3 to v4 (latest preview version). I have done this update when I came back to my Babylon project after several months.

I am not sure whether it is bug or not, but it has three attributes that from my point of view qualifying it as a bug.

  1. It didnt happen on previous version of Babylon (3.x) and after upgrade it does.
  2. It behaves differently in Chrome and in Firefox.
    3 It behaves differently across v4.1.0-alpha versions

Now to the problem itself

Problem occurs when I add / remove point lights to / from my scene and it behaves differently accross versions of Babylon and browsers

Chrome behaviour v4.1.0. 23

Adding light works perfectly without new-light-lag that was caused by shader compilation. I guess that parallel shader compilatrion works nicely ?

Removing light this causes screen to “blink” and WebGL error appears in console It is undefined behaviour to have a used but unbound uniform buffer

Firefox behaviour v4.1.0. 23

Both adding and removing of lights is working as it worked in version 3.x - it lags (no parallel compilation for FF ?) but it doesnt produce any error or screen bliinking.

Chrome behaviour v4.1.0. 27

Adding light works sometimes causes screen to “blink” a little - not always, but usually it does. Parallel shader compilations seems to be working (no noticeable lag). No error in console even when blinks occurs.

Removing light this is as it was on version 23 - blink + error

Firefox behaviour v4.1.0. 27

This is the same as version 23 (no errors or blinks but lags are present).

========================

One more problem in FireFox - apparently it works differently with heightmaps than it worked in Babylon v3. I am using heightmaps to create cavern walls and now it is broken in FireFox (ok in Chrome). Previously it worked correctly in both browsers. It is surprising, I thought that it is pure mathematics and no WebGL magic and it should work the same way in all browsers :slight_smile:

Take a look at the following screenshots - firts screen is from FireFox with noticeable “empty space” between walls. Second one is from Chrome where it is ok. In Babylon v3 it was ok in both browsers.

Thanx for some insight !! I can put my app to my hosting if needed or create video with these “blinks”.

Hi @stealman

I think @sebavan might help with blinking screen. I guess it has to do with shader compilation and sync for rendering.

For the “empty space”, can you try 2 things:

  • render with white ambient lighting
  • render ground in wire frame

The ground mesh is computed on CPU. I’m thinking of 2 potential issues: holes in the mesh or wrong normal computation. The geometry might be there with a black lighting or not present at all. The 2 tests will help us figure it out :slight_smile:

I will try these tests hopefully later today. Thanx very much !!

@stealman This indeed looks like a bug, you could workaround it in v4 by settings engine.getCaps().parallelShaderCompile = null; but it is only a workaround…

Could you create a repro in the PG by adding removing pointLights on a scene ??? this might help solving the issue which I bet is indeed coming from the parallel shader compilation and the state bot being fully ready during the recompilation.

Ping @Deltakosh FYI.

Hello there, I think that I have isolated that problem. I have used light.setEnabled(false) to disable lights and then I have called dispose(). This apparently caused this error.

When I use scene.removeLight(light); then it seems to be working without problem (in case of shadow casters I need to set Intensity to 0 before destroying).

I am ok with removeLight but still it seems weird that disable caused problems.

Could you create a repro in the playground ?

I have tried more bright ambient color and it is evident, that geometry is wrong here in Firefox. Event light can go through these gaps. Probably normals does not cause this problem too, because it is the same when I turn-off bump mapping via inspector.

Hello I have replicated that “blinking” in chrome - here is the playground (it also blinks when you remove shadows, but with them, it is more noticeable).

https://playground.babylonjs.com/#TZ8QYE

There are 10 spheres, 5 pointlights that casting shadows on the ground. Lights are then disposed one by one. First disposal seems to be ok, and other causes blinking of screen. It only happens in Chrome and not in FF (cos FF doesnt have parallel shader ?).

In this playground there is just this “blink” and no error in console, but I believe that it is because I have no texture on my spheres.

This blinking is expected as we need to compile a new shader with less lights (and while we compile the object cannot be displayed and we cannot use previous shader as there is one light less)

To fight against this effect, you can precompile the shaders:
https://playground.babylonjs.com/#TZ8QYE#1

An even better option will be to not render before the forceCompilation is done

Thanx ! This seems to be working, it is difficult to manage in application when both lights and meshes comes and goes dynamically, but I have done that for largest meshes and it improved overall experience greatly ! Thanx for this advice :wink:

1 Like

We cannot help more unfortunately :frowning:

Well … right before sleep I tried latest Babylon version and on 4.1.0.-beta … blinking is back and with some shadow-like artifact all over screen :frowning: on the same code but version 4.1.0-alpha 23 it was ok.

I will probably stick with that alpha version for quite some time because it works nicely on it :slight_smile: Maybe it will be ok in some later version. It is difficult to “quantify” as it behaves little bit randomly (sometimes it blikns more wildly than another time) so never mind, I will continue with my project and will try to solve this later :wink:

well the PG is using beta and has no issue :frowning:

I see, but it is difficult to replicate my whole application in PG. I dont say that you have bug there :wink: jsut saying that it worked on older version and on alpha - in my case and my configuration.

I actually thought that this parallel shader compilation will do that “magic” for me that I will not need to track every light and every mesh manually and do the force compilation - it is rather difficult in dynamic environment and probably I have some fault there.

unfortunately that’s the opposite: parallel shader compilation does not block rendering anymore (So not lag) but leave the engine with objects that cannot be rendered for a few frames (hence the blink)

Thanx for clarification I would like to know what is the correct workflow for creating / disabling of lights and meshes. Dont you know about some place where I can seek that information ?

I am decent JS developer but I am actually only noob in 3D thus I might not understand some fundamentals correctly. At first I thought that I will just create and manipulate meshes and that will be it but it is much more complicated even on amateur-level.

I would like to know what is the correct step-by-step approach for creating new light / disablong it, creating new mesh / destroying it.

I think it should be like that:

  1. Create Light => disable => loop through all already existing meshes and call forceCompilationAsync on material of that mesh and as parameter serves the mesh itself right ?

If I have mesh A with material M, then I will call M.forceCompilationAsync(A) ?

and finally => Enable that light (after all async compilations are done)

  1. To destroy light I dont have to do anything special if I have done 1. step correctly right ?

  2. To create new mesh, is it simillar as for light ?
    Create mesh => disable it => call forceCompilationAsync on its material => enable mesh after compilation is done

  3. To remove mesh just dispose it ?

  4. Bonus point - If I need to create more than one light, then I shall do it one after the another as you did in my playground ? Thus compile all meshes for one light and when it is complete, compile all meshes for another one ?

I know that it might be nooby questions but this whole workflow is not clear for me and I believe not only for me :slight_smile: Your nice BabylonJS brings WebGL to users without 3D fundamental knowledge and I am one of them. It is getting better but I feel that for me there is still long way to go :slight_smile:

So what is the root here is that Babylon.js (for perf reason) will compile shaders for each specific case instead of having a ubber shader that handles everything with conditions.

This means that if you add or remove lights (as they are impactful for shader rendering) we need to build a new shader if the combination of lights was not already encountered.

So ideally you should compile all lights combinations (like 1 active light, then 2, etc…)

So 1 is true
So 2 is true
3. Meshes are not a problem as they do not trigger new shader compilation
4. Same as 3

Other radical option: turn off parallel shader compilation :slight_smile:

Oh and this problem will only happen when you remove lights. By default when a material needs to be recompile we try to use its previous version in the meantime. But when a light is disposed we cannot reuse the previous version of the material as it is relying on a disposed light

Hopefully that makes sense

Thak you very much !! I will try this approach and then implement it into my app. Thanx for this description it made it way more clear :slight_smile:

Now I know why it always blink only once-per-light - because when lights are reused, then already existing shader are reused too :slight_smile: It was one of that missing puzzle pieces (missing by me, you have it in documentation - now I can remember that I have read it before but at that times I didnt understand it correctly).

1 Like