Thin Instances : cloning without clone.makeGeometryUnique() will render transparent

Bugs
, ,
1

Hey,

After a quick search here on the forum, I found some previously fixed ThinInstance+clone issues, but not this one

Here is a repro :

  • Take a mesh (box) and clone it (for example changing material)
  • Set ThinInstance on each clone
  • Except the last mesh, this won’t render unless forcing a clone.makeGeometryUnique() on the mesh after clone : Working PG VS Not Working PG
    image
    image751×750 3.61 KB
  • First, it’s surprising that clone.makeGeometryUnique() is mandatory
  • Second, when clone.makeGeometryUnique() is not called, the mesh will actually render transparent, but will still be pickable ! (Move the mouse and see the hover on the Not Working PG )
    image
    image751×750 33 KB
2

I also found another issue, I was about to create another topic, but since this second bug seems related, I’ll write about it here

An Error: Last accessed byte is out of bounds will happen when you call makeGeometryUnique() after setting ThinInstance buffers (instead of before)

Repro PG :

  • Set a ThinInstance buffer on a Mesh
  • Clone it
  • Call makeGeometryUnique() on the clone

image
image1053×177 39.4 KB

4

This PR will fix the second problem:

Regarding the first one, it is the expected behavior.

When cloning meshes, the geometry object is shared between the clones. Because the thin instance vertex buffers are part of the geometry object, all clones see the same buffers.

So, if you change them for one mesh, it’s changed for all of them. In your PG, you only see the thin instances corresponding to the blue mesh because their data is copied to the vertex buffers last.

Picking still works because it’s based on bounding boxes calculated on the CPU when you set the buffers, and they are not stored in the geometry object but in the mesh itself. So, even if visually you only see the blue instances, picking continues to work.

1 Like
6

Thanks @Evgeni_Popov for your fix and explanations !

Ok. Maybe adding a warning would make sense ? For example when calling Mesh.thinInstanceSetBuffer, checking if the Mesh has shared geometry (used by another Thin Instance) and warn that Thin Instance must run on unique geometry ? :slight_smile:

7

Well, it’s not an error per-see, it could be a valid use-case to use the same thin instances for multiple meshes (for eg, displaying the same set of thin instances but at different locations, by just updating the postion/rotation of the meshes that share the thin instances).