Our meshes don’t use nanite due to various issues. But everything you’ve told me so far has given me a few ideas; I’m going to dig a little deeper and see what comes of it.
Hey, it’s been a while since the last time, but I’m here to say how I finaly do this !
So, I use some c++ code to do it : at the beggining when I contacted you, I already had a subsystem where position are packed in one uint32.
After that I create another script “RenderTargetAssignator”, where I create a RenderTargetArray. We already talk about render target and we were saying that there were some problems with compression etc. but I discover that in c++ there is some hiden parameter that allow to just ignore the compression of data.
So I create it in c++, I used the array of uint32 to create an image that I send to a shader, which will update the render target array at the good slice.
Finally, the subsystem will create during the initialization a MID which have a reference of the rendertarget (and some index to link the chunk with the good slice). And I use a mesh component, put on all paintable meshes, which will set the MID to all the meshes. After that, I use a hlsl custom node to unpacked the uint32 in the render target without any compression or modification ! (N.B. : the uint32 were “transform” in float32 to be put in the render target, and transform back in uint32 in the material (the float is just like a bitmask))
So if I read all that correctly, you were able to build it such a way that the slice of uncompressed data you want from the one thing(s) make it efficiently to the stack of RTs.
but I discover that in c++ there is some hiden parameter that allow to just ignore the compression of data.
Well, that’s handy… 
Exactly !
So now everything is running quite efficiently, without any significant loss of performance !