Im struggling with a complex shader that when similarly used for instanced objects I can reliably get the index of each object with instanceIndex however with BatchedMeshes I cant get any kind of index or way to ID which object it is to be able to do things like transforms, colorize, discard etc from options in a buffer.
The drawId isn’t reliable as its view dependent and I’m ripping apart guts of other nodes trying to find the right setup to get the same ID that we get on the CPU side when we call addInstance() on the mesh itself.
The batchedMesh webgpu example doesnt use a material beyond a basic one using setColor() (which I think is a mesh attribute?)
Did you tried using .addGeometry() first then .addInstance( geometryId )
I feel the documentation is more clear than the example in this case
three.js doesn’t support multiple materials, across the whole library. You may change their attributes per instances, but that’s as far you can get. For transform .setMatrixAt() should work.
But InstancedMesh is often more optimal for repeated geometry with per-instance transforms (real time). Why? because you don’t need calls on the the whole batch. Mesh are managed independently.
BatchedMesh is designed for static or rarely-updated geometry.
If this is the case for you, yes push it further. Otherwise you may complicate your structure/calls for no benefits.
drawId is view-dependent because it maps to draw call index, not your instance ID. The fix is to build a storage buffer attribute on the CPU side that maps drawId → your logical instance ID, then sample it in TSL. This is exactly what setColor() does internally with _colorTexture - replicate that pattern with your own buffer for color, discard, transforms, whatever you need per object.