How does addGroup work with InstancedBufferGeometry?

Hi! Could someone explain to me how groups work exactly with InstancedBufferGeometry? I’ve also read somewhere that the count must be a multiple of 3, is this true? I am trying to create a particle system with different shaders applied for particular particles (to get around the 16 tex per shader limit). So let’s say I have 10 particles I do something like:

…addGroup(0, 2, matIdx0);
…addGroup(2, 5, matIdx1);
…addGroup(7, 3, matIdx2);

Is this the correct usage with InstancedBufferGeometry? It’s not working correctly for me (some particles don’t render or have the wrong material) and I’m not sure what the bug is. So my question here is to make sure my assumptions on how to use addGroup for InstancedBufferGeometry is correct.

P.S. My position attribute is just a non-indexed quad, and all my particle data are put in InstancedBufferAttributes. Every requestAnimationFrame I update the InstancedBufferAttributes with new values, clearGroups and calculate the new groups.

I don’t think instanced geometry can use multiple materials or internal groups. ( I could be wrong ). They don’t go through the same pipeline as regular mesh+geometry. You can get single material + instance matrix + color per instance and that’s pretty much it.

If you need to get around some sort of texture count limit, consider using a texture atlas, or texture arrays?

I think you are right. I had to go through the source and in the WebGLrenderer.js file I found it uses the position attribute. Maybe we should update the docs or something to mention this? I’ve wasted 5 hours trying to get it to work :joy:

The problem with 3D data texture etc is that my particle textures all can have different sizes and they don’t allow for this as far as I can tell. In the end I’ve chosen to create a new material, geometry and mesh for every Math.ceil(numTextures / 16). It uses more memory because the buffers have the same sizes and I can’t just make them smaller but it seems to do the trick.