Weird Actives faces count in the Inspector

How is this guys possible? I did some changes (don’t know which one is causing this :slight_smile: yet) and started to get this value:

And this error:

Any idea what can be wrong? Can the faces value be incorrect because of the Insufficient buffer size or vice versa?

Thanks a lot!


I don’t know for the WebGL error, we would need a repro for that but it seems you hit some limit for your GPU (but I don’t think the error is related to the number of faces).

Regarding the number of active faces, I think it’s simply Active Indices / 3 and if you are using fill modes other than triangle fill (triangle strips or fans, for eg) it won’t be accurate because those modes don’t use 3 indices per face.


My guess is you really try to have a buffer to big :slight_smile:

1 Like

Actually everything seems to be drawn correctly :stuck_out_tongue: I don’t miss anything on the scene. This is why the error is bugging me :smiley:

Thanks for the response! Unfortunatelly I can’t make a PG for this, it’s burden too deep in the project, however I’m not aware of changing any modes. Could it be an invalid mesh from a glb? Could the Insufficient buffer size caused by trying to allocate an invalid size because of invalid mesh data?

1 Like

No idea…

You should try to load the gltf in the sandbox and see if you get the same error (try also another gltf viewer), in which case we would be able to dig a bit further to try to pinpoint the problem.

You could try your glbs in the sandbox independently and share the broken one with us if it is this as it might highlight a loader bug ?

I’ve tracked this down to thin instances. I’m trying to draw exactly 399 instances of a very lightweight mesh (I have 21 000 instances of another mesh) when getting the error however I can see the instances on the scene so the error message confuses me :stuck_out_tongue: Removing the 21 000 instances doesn’t change the situation. I’ll try to track it down more precisely. :vulcan_salute:

1 Like

On Firefox I get this error. On the first run and on every refresh:

On Chrome I don’t get any errors on the first run, but on refresh (F5 or CTRl+R) I get:
I need to close Chrome to get rid of the error.

I’m not doing anything funky just using thinInstanceAdd on a mesh.

I’ve tried to replace the mesh with the default cube from Blender (finally it didn’t get deleted! :smiley: ) and now I’m getting this error in Chrome right on the first run and on all consecutive refreshes:

This is getting craaazy :smiley: Never had this problem with thin instances. Actually I never did thinInstancesAdd to a cloned mesh. I was always using the one returned by the loader however now I am loading the mesh, cloning it several times, making the geometry unqiue and the adding instances to the clones. Maybe the cloning is the guilty one here? Or making the geometry unique?

Please note: the thin instances are correctly displayed in all cases…

Would be great if you could repro with a clone in the playground the simple cube and thinInstanceAdd ?

1 Like

@sebavan, this PG demonstrates the issue. The thin instances alone are not a problem. When I add some lines I get the WebGL error message.


If you comment one of these lines, there is no error but if you call both functions there is an error in the console.

Edit: the number of active faces is not an integer because of the lines

There is another issue with this. Look at the lines rendered on my PC:

And the same lines on my phone:

Do we know what can be the issue here?
Thank you!

The second error is coming from auto computing the normals which is impossible on line of 1 px only as the derivatives will have trouble to be computed.

This is one of the reason lines are usually using a static color.

I ll let @Evgeni_Popov take a look at the thin instances issue :slight_smile:

Why is it rendering correctly on mobile? :speak_no_evil:

EDIT: This is how I can see the lines (same code) rendered in my project. I’m on alpha.63. Quite a difference :slight_smile:

Guys, as @sebavan suggested, using the color property of the LineSystem and dropping the material solves the problem and there is no more buffer related errors. It is working with the material property set as well, but I need to reduce the number of lines.

    const grid = BABYLON.MeshBuilder.CreateLineSystem('grid', { lines, updatable: false }, scene)
    grid.color = new BABYLON.Color3(0, 1, 0.2)
    grid.alpha = 0.2

The mixed results in the PG on desktop and mobile should be checked though :slight_smile:


1 Like

Mobile might compute dfdx differently it is all GPU specific I would think.

Final question I promise😎
Why are the lines on the screenshot from my project correctly rendered and the PG fails them to render? It was rendered on a desktop GPU.

Can we switch the PG to a specific version of BabylonJS?

This all comes from how dfdx are computed so not much we can do and it will be subject to the GPU, the canvas size, ratio and dpi setup on the engine :slight_smile: so a lot could impact I guess but basically anyway a line does not have normals so it is completely weird it even provide a result :slight_smile:


Thanks for the explanation! :vulcan_salute:

1 Like