Instanced mesh: pushing new instance to array of instances causing position glitch

[leone6]

hi all

i am having a problem with a workflow i am trying to use to keep my # of draw calls low. i need to instance some glbs on demand. so maybe there is 1 instance until a user causes another instance to be created in a new position by clicking something, so then there are 2 instances with their own unique positions. then another click would add another instance, and so on up to the limit i have set.

i'm using drei's Instances and Instance by the way, so the limit is passed directly to Instances like this for example: limit={100} and each Instance receives its own position (via mapping through the array of Instances). so i know i am not going over the instance limit.

it is kind of working- instances are being added to the scene, but a glitch is causing the new instance to initially render at (0, 0, 0) a.k.a. the world origin instead of the correct position that has been given to it. the new instance will SOMETIMES stay at (0, 0, 0) until i interact with one of the instances, and then the incorrect instance will teleport instantly to the correct location. other times, the new instance will render at (0, 0, 0) but almost immediately snap to the correct position. i can't tell what causes the difference in these behaviors.

so my first approach to fixing this was to call invalidate() from useThree in an effect that has the Instances array as a dependency. i figured if the Instances array changes, the effect would cause the component to re-render and all instances would be in the correct position. but it didn't fix the problem calling invalidate, so i also tried assigning a ref to Instances and using ref.current.instanceMatrix.needsUpdate = true; before calling invalidate() but these two combined still isn't working.

so i'm really stuck for now. is changing the number of instances and their positions on demand possible without glitching? i'm sure there must be a way...

thanks!

edit:

in case it helps anyone, i noticed that removing the limit arg i was passing to Drei's Instances and switching from using useLayoutEffect to useEffect for the invalidate() calling effect seems to help with new instances that were stuck at (0, 0, 0) until i interact with them. now the only issue i am having seems to be the first few frames after creating a new instance where the instance is at (0, 0, 0) until snaps to the correct location.

[mwmwmw]

On, the instance, are you updating the matrix?

instanceMesh.instanceMatrix.needsUpdate = true;

Shoot, sorry I see that you tried this.

[mwmwmw]

Oh yes, I see the issue.

I was like "hmm, it's probably using a useEffect to do an update on mount so it's rendered a frame too late. "

That's definitely the issue.
https://github.com/pmndrs/drei/blob/dba18d430b1214db34cb2e5dcd67b0fa35954461/src/core/Instances.tsx#L75

[mwmwmw]

I forked your code, and grabbed the source for Instances from drei.

Even if I hack in an update it still at 0,0,0 for a frame. It's updated every frame in useFrame anyways.

https://codesandbox.io/s/instancing-glitch-test-forked-vcwp0j?file=/src/Instances.tsx

Check the console and click, you'll see two updates. 🤔

[leone6]

that sandbox link isn't working for me. but thanks for linking that code snippet for drei/Instances.tsx, i should have looked at that earlier but i will play around with it now. i might be wrong but should that useEffect be a useLayoutEffect? i think i remember @drcmda mentioning that layout effects can help with the first frame paint. i will try to test it.

[mwmwmw]

Sorry, updated the sandbox link. I always forget to make it public.

There already is a layout effect in there, and I did try moving the matrix update to it.

After messing with it, I'm less convinced it's a matrixUpdate issue.

I think that the Instance is mounting before property has a chance to be set.

[leone6]

ok so i just discovered that this is a confirmed problem

pmndrs/drei#815

there is a cool little workaround in there. i haven't tested it yet and it's not ideal but could work temporarily. in the meantime i might try to build my own instancing process. but i'll be following this topic to see if anything gets updated to the official Drei tools

[leone6]

pmndrs/drei#815 new version of drei fixes this issue