solved highlight layer creating additional draw calls bug

[thrice]

https://github.com/BabylonJS/Babylon.js/issues/2624

This is still an issue for me. Was unable to reproduce on playground, however adding some additional information, maybe someone will have a clue as to what's going on because as of now I can't really use the highlight layer.

When the scene is first loading up (and my meshes are being created for the first time), and a highlight layer is created while this is happening, I see a ton of undefined meshes stored in the highlight layer, which I have no idea where they are coming from. 85 to be exact. (note that at no point am I manually adding any meshes to the highlight layer) - The draw calls are now going from 110 to 220, so there are 110ish additional draw calls being added, even though the highlight layer isn't doing anything.

These mesh ids, also don't appear to be valid anymore.

[thrice]

If however, I add the highlight layer after the scene is going, it won't add the initial draw calls initially. - Additionally, the dispose behavior I cited in the issue is still causing it to trigger, however it does seem semi sporadic, i.e. sometimes the first dispose call after adding the highlight layer triggers the additional draw calls, sometimes it takes a couple disposals. -

BUT the important thing to note about all this is: As soon as the additional draw calls are triggered by the 1-2 tries of disposing meshes, even though only 1-2 meshes are being disposed, the draw calls are spiking from 110 to 210ish, everytime, consistently (regardless of the number of meshes destroyed). I.E. there are a bunch of invalid mesh references in the above screenshot, but if Iazy load the highlight layer and trigger the issue, it will look fairly correct, though there will still be an entry for the last disposed mesh. Since I am unable to reproduce on playground, please see my console logging of the behavior below:  (the play_game.highlight_manager.rebuildHighlights() method is creating the highlight layer initially).

 

Also note, clearly I have an issue with the mesh id property on the destroyed mesh, but don't think it's related. Also note: both meshes I disposed in this session are either instances or clones. The behavior doesn't appear to be specific to one or the other either, just sometimes takes a couple of disposals before I see the increased draw calls

[thrice]

ping @Sebavan [

[Sebavan]

Hello, 

I am sorry but I still can not repro the issue locally. You could try placing breakpoints in the highlight layer code to see why it is rendering. or try to isolate the issue from your code so that we can have a smaller repro to work on.

 

[aWeirdo]

@thrice
@Sebavan

engine.drawCalls was deprecated  that's why it returns 0.

the bug can be seen here;

if ANY mesh is added to the HL layer;
Scene starts at 33 drawcalls, doesn't matter if 1, 2 or more meshes are highlighted.
disposing a mesh(any mesh, with or without HL) drawCalls goes from 33 -> 31.
disposing another mesh and it goes 31 -> 29
https://www.babylonjs-playground.com/#1KUJ0A#93
 

if NO meshes are added to the HL layer, but HL layer exists;
Scene starts at 14 drawcalls.
disposing a mesh: drawCalls jumps from 14 -> 31
disposing another mesh and it goes 31 -> 29 again
https://www.babylonjs-playground.com/#1KUJ0A#92
 

if NO HL layer exists, issue is gone;
Scene starts at 14 drawcalls.
disposing a mesh: drawCalls goes from 14 -> 13
disposing another mesh and it goes 13 -> 12
https://www.babylonjs-playground.com/#1KUJ0A#94

seems like something is happening with the HL layer even if no meshes are added to it ^^

[Sebavan]

@aWeirdo This is a nice repro. It is fixed and will be deployed shortly: https://github.com/BabylonJS/Babylon.js/pull/3250/files

 

[thrice]

@aWeirdo Thanks for reproducing!

@Sebavan and thanks for fix

[thrice]

@aWeirdo

@Sebavan

I think this issue is larger than just the dispose trigger. I monkey patched your change into my local project and realized, I'm now actually seeing the draw call multiplication as soon as I add a mesh to the highlight layer (not disposing any meshes, so that code doesn't get called yet). I'll have to dig into it further tonight or this weekend likely, but - created a brand new sphere at center of my scene and did, highlight_layer.addMesh(mesh, play_game.BABYLON.Color3.Red())

Jumps up from 91 draw calls to 186

[thrice]

Actually:

@aWeirdoNow that I'm looking at your playground/reading your post closer, it kind of proves my point above. No mesh is being disposed in the first playground, therefore dispose isn't being triggered.

It seems to be happening upon adding a mesh to the highlight layer, so looking at the changed code, I'm not sure how that fix would have fixed it, since that code path shouldn't even be getting hit at that point (and that's the same behavior I am seeing in my local project as well)

@Sebavan

[aWeirdo]

@thrice 

i'm sure there are still optimizations to be done,
but after the fix,
if no meshes have an active highlight, or the last mesh with a HL is disposed,
drawcalls are correctly reduced. (this was the fix)

but if just one mesh has a HL, a drawcall is added for each mesh in the scene, it doesn't matter if it is actively added to the layer or not.

i believe this is what you are refering to, and due to how the HL layer works, i'm not sure there's any quick-fix.
you can however add your non-HL meshes to the excluded array for now..

hl.addExcludedMesh(Mesh);

maybe @Sebavan has a better answer or solution.

Side-note;

As mentioned above,
You can reduce drawcalls by adding meshes to the excluded array,
But, doing so adds two observers to each excluded mesh (before and after render), those observers first disables then enables the engine stencil buffer for every single excluded mesh.

which might actually do more harm than just accepting those very quick drawcalls. (profiling needed)

Either way, best of luck with your project  

[Sebavan]

As @aWeirdo said, this is by design in the HL. Think is those draw calls are pretty fast cause they are against a smaller render target and do not use the same shader at all.

But they still imply some gpu work