Question How can I detect interaction with a specific object in a combined mesh?

So I'm trying to create a level with 3D tiles that the player can add or remove. Sort of like Minecraft but much simpler generation.

It quickly became apparent that having a bunch of cube tiles in the scene was slowing things down like crazy, so I'm experimenting with combining all the 3D tiles into one mesh as shown in this link: https://docs.unity3d.com/ScriptReference/Mesh.CombineMeshes.html

The issue is, how would I detect what tile the player is interacting with at that point, and how would I modify the combined mesh to adjust?

Adding a new tile seems easy enough, but removing an existing one is going over my head right now.

Also if this isn't the right approach for 3D tiles, please let me know what a better idea to experiment with would be.

 

When combining meshes, the meshes become submeshes (unless you use mergeSubMeshes feature). Submeshes are all laid continuously in memory, so you have a start and an end triangle. See subMeshCount, GetSubMesh, and SubMeshDescriptor.

 

Thanks for the response! It seems my subMeshCount is coming back as 1 though which is not what I would expect. Unless I'm misunderstanding something

 

Make sure you're setting mergeSubMeshes to false.

 

Gotcha! For some reason I assumed it would be false by default.

Of course now it's giving me the right number of submeshes when I Debug out the count but it's only rendering the first tile that's generated rather than all of them... Any ideas?

EDIT: It's worth mentioning that the mesh collider is working as if all the tiles were there, only the rendering seems wonky.

 

Though I'm not 100% sure, you should probably assign a material to each of the submeshes, you're now dealing with materials. That's the greatest benefit of having submeshes, you have a multi-material setup.

Could also be something else, don't know for sure.

 

Yep that did it! Unfortunately, with a large number of tiles, the framerate is dropping down to the single digits just like when I had a bunch of separate objects each with their own mesh.

I take it this approach is wrong for what I'm trying to do. I'll post again if I see any changes as I dabble, and if anyone has suggestions for a good approach (or how to optimize this) for a 3D tile based terrain I'd love to hear it.

 

On Minecraft I'm gonna guess they don't have individual colliders.. they probably have a notion of "what you hit" or "what you are raycasting at" and they just divide by cube size, since all are the same, and they instantly have their integer x,y,z cell and can look up what is in that cell.

Are your "tiles" uniform? Then just use math!

If not then you might need some hybrid of combining the meshes for visual purposes but not combining the original meshes and instead leaving them in the original colliders so you can find what you hit.

 

Indeed, for regular cubic voxel representations, we pass rays through a fast voxel traversal algorithm to detect collisions, and completely bypass having to interact with colliders. This is useful for mouse and "physics" interactions. Inversely, having a volumetric model allows to quickly find a surface height for mobs and item placement.

 

Thanks for the tips. To clarify, I'm trying to make a system similar to the terrain system in Animal Crossing New Horizons.

So it's much smaller scale and simple to interact with than Minecraft, but still has the ability to remove and add tiles up to a certain height.

I thought about how I would tile such a project and it makes sense to use some sort of multi dimensional array with tiles having data attached at coordinates.

The problem is I still can't wrap my head around how I can render this while still allowing the player to add/remove terrain tiles in real time.

@Kurt-Dekker your suggestion of combining meshes but keeping original colliders is interesting. I still have the original tiles (I'm not destroying them, just deactivating them).

So I could actually rebuild the mesh differently with one less or one more tile.

The issue is, the performance with the submeshes is not good, and I can't detect what the player is clicking on if it's all one merged mesh seemingly.

Maybe I'm misunderstanding, I apologize if so.

 

Two things, really.
First thing: You make everything designed around a model in memory. Including the rendering.
Second thing: You render everything in chunks, which are like limited mesh blocks. That can be cached and toggled on or off as needed.

It's usually a big system to make all of this, dynamic frustum occlusion, chunk generation, dirtying, mouse interaction. But it is otherwise very rewarding to work with and infinitely expandable.

And normally this is a must if you want a sandbox world, a level editor, if you plan on having maps of greater or even infinite size, or you want to enable modding, or whatever.

 

Though I did mine from the paper I can't seem to find (it's not the one from 1987), here's a couple of good primers on interacting with cubic/square tiles without colliders.

Super Fast Ray Casting in Tiled Worlds using DDA
Voxel Traversal Algorithm (Ray Casting)

 

Thanks for the tips and the resources, I'll check them out and hopefully learn some new stuff!