How do textured instances work? Is there a better way to reparent instances in batches?

[projectBreakableAccAPI]

Hello again, I've been hard at work optimizing my voxel engine and it seems that the new thing causing major lag spikes is re-parenting voxels. When I disconnect a section of voxels from an object, I need them to do just that, disconnect, so I re-parent them to a new instance with the positioning of a rigibody, and they fall away. The issue is obviously that, the larger the group, the slower this re-parenting is. That's why I was wondering if it would be possible to group the voxels into large cuboids, and just change the texture of the instance based on the color of the voxels along its edge. This would mean, however, that I would need to use textures created at runtime and use a different one for each instance, as well as change them as I go. So, my question is, would these different textures differentiate the instances on the GPU and defeat the purpose of using this library, and if so, is there some way to re-texture them without doing that? Finally, if none of that's possible, how should I re-parent these instances more efficiently?

Thanks for your continued help, -Max

[mkrebser]

If each voxel you have is a a single cuboid then you would need to write a fragment shader to make special textures. Voxel games like minecraft solve this problem by using texture atlas and having 2 triangles per square- which allows texture atlasing over a mesh.

This library maintains a hierarchy tree depth for every instance in the object hierarchy. When you take an object with 1000 children and delete its parent- the depth of every child changes. The depth has to be recalculated for every child recursively. This is required so the compute shaders will perform world2Object, object2World calculations in the correct order. Ie, it batch calculates relative positions using the depth ordering. Depth 0, 1, 2, etc...

In the parenting function, it should not recalculate the depth if it does not change. Ie, you reparent your root object to be at the same hierarchy depth- it does not do a recursive depth adjustment. I would recommend that you do not change the hierarchy depth of your root objects or other objects with many children.

See https://github.com/mkrebser/GPUInstance/blob/3bb1545be1760422e6706b2659f67c37a2642ca6/Assets/Resources/GPUInstance/scripts/InstanceHierarchyMap.cs#L423

I don't know enough about your use case to provide more than this. I would also suggest using the unity profiler and add samples to relevant locations in the code to track down which functions are causing performance issues.

[projectBreakableAccAPI]

Okay, well I'm not changing the hierarchy depth, it's always one parent deep, so I don't think that's the problem. My question is mainly, if I give every instance its own texture, and change it as I go, will that interrupt the instancing and defeat the purpose of the whole library, or will it behave the same way it would without any textures?

[mkrebser]

As long as you are reusing materials you have previously created, you will see a benefit from instancing.

There is a guaranteed draw call for every unique (mesh, material).

Assuming you are just using the same cuboid for every voxel, this means you would get a minimum number of 1 draw call per unique material.

If every voxel has a unique material you will see no benefit from instancing

[projectBreakableAccAPI]

Ok thanks for clearing that up! My next question would then be, would a unique uv map per voxel cause an additional drawcall as well? I assume it counts as a different mesh and therefore yes, but I just want to make sure.

[mkrebser]

If you are using a single texture atlas for all voxels and packing the uv coordinates into the vertex data then no, it would just be one draw call since the only thing changing is the offset/scaling on the shared texture.

[projectBreakableAccAPI]

Oh ok then, well I guess I'll give that a shot, thanks!

[mkrebser]

Sorry misunderstood the question, yeah if you have a mesh which has different vertex data then it is guaranteed to be a unique mesh and cause a new draw call.

[projectBreakableAccAPI]

Oh ok, nevermind then. It doesn't really matter regardless, as I realized that the texture would have exceeded the maximum size in unity, and been absurdly inefficient. I think I'm going to focus on optimizations other places, and then worst case scenario, write my grouped meshes to the render buffer without instancing. Thank you for being so helpful as always, and I'll be sure to let you know if I have any other problems :)