WebGL range errors when creating thin instances of mesh clones

Bugs
1

Hi, I found a case where certain kinds of thin instance creation causes range errors in WebGL (or in babylon, if various operations are done afterwards).

The trigger seems to be:

  1. Start with a source mesh,
  2. Make two clones of the mesh
  3. Add thin instances to one clone
  4. Add thin instances to the other clone, using a smaller matrixBuffer than in step (3)

Here is a reproducing playground. The code for step (4) is commented out at the end; uncomment that code to see the WebGL errors.

2

Clones share the same geometry and thin instance buffers are tied to the geometry: updating the buffers for one clone automatically update the other clone.

So, when using thin instances, it’s safer to not use clones (or call makeGeometryUnique to create a unique geometry for the clone - in effect making the mesh not a clone anymore but a copy of the mesh).

I think it’s the expected behaviour: @Deltakosh ?

1 Like
3

Totally we have that documented here:
Instances | Babylon.js Documentation

4

Actually, I think that this does not apply anymore for regular instances in 5.0:

If you want to create an instance from a cloned mesh, you have to first make
sure that you call clonedMesh.makeGeometryUnique().
5

Oh. Couldn’t babylon throw an exception or a warning on this?

6

Every test we do at runtime is a hit on perf
Here we need to figure out if the geometry is shared (and if it has or not instances) before accepting the thin instances.

7

you are right, I’ll update the doc

8

Hi, I understand that it could affect performance if babylon went and exhaustively checked to see whether the operation was going to be safe. But couldn’t it, for example, set a flag on newly cloned meshes, clear that flag if the clone’s geometry is made unique, and then throw an error if thin instances are added while the flag is set?

I mean, if adding thin instances to a clone isn’t a safe thing to do, surely it’s best to just disallow it? It’s not great for it to work sometimes, throw WebGL exceptions other times, and then direct people to the documentation after they lose a day figuring out what happened…