Is there a way for Unity to merge meshes as it renders their location?

As mentioned in a different thread, a good way to add variety is to make randomly generated levels. It would take up quite a lot of storage and it would be very time consuming if I made every conceivable combination of these different tiles that stretch in every direction, but I also want them merged so that the creases between them aren't visible and so there are less glitches in collision detection.

Is there some way Unity can merge mesh tiles to create new triangles or vertices at their intersections or bridge their gaps?

 

Not in the way you are suggesting.

If you want to have a go at doing this yourself however, here is a relatively straightforward solution that you could try. If you are feeling more adventurous, then take a look at this series.

 

you can parent your tiles to a base tile on the fly?
if modeled correctly, and positioned correctly, there "shouldn't be seams?

 

But then that would be the same as having redundant interior polygons which have their own surfaces and are separate objects.

 

Generated terrain is always an option, but there's less control in how a level is built when applying it all to a plane. The terrain I want can't be generated with a simple bitmap because there are all kinds of caves, edges and crevices that fold in and out multiple times over a single z axis. If they can't be merged in Unity, is there a way to set them up in 3D modeling software so that they can at least be combined as simple blocks?
Say you have a simple cube. Could Unity at least merge simple cubes? If so, then that means there is likely a way to modify that script to merge any vertices that share the same location, not just the ones in a cubical shape.

 

Not as far as I'm aware. Probably the closest thing is combine meshes but this does not mention removing redundant vertices. The only thing to recreate in a mesh is bounds, normals and tangents.

I'm not sure I understand that. Surely it gives you complete control - just with all the difficulties that it also entails.

 

You can't build a scene with generated terrain, they all rely on simple algorithms that ultimately simplify to bitmaps. The goal of this is for multiple objects, not just a simple terrain with grass or hills, but something like icy caves with icicles or cavernous volcano with lava flows, something that an algorithm can't simply generate but that can still be broken down into distinct tiles. An island sure, but I doubt a generator could even make a rough textured island with cracks tangent to the smooth surface, you'd need at least a separate normal map for that, and normal maps also rely on the bitmap concept.

 

You must be referring to a particular type of scene then? I linked to 2 tutorials above that programmatically generate scenes.

Which would mean they can be generated, would it not?

Ok, fair point. So the key here is 'simply generated'. Otherwise, it sounds like you are after something akin to Minecraft maybe?

 

Not necessarily. A: (double check me on this) but I don't think interior gons matter? I think all that matters is what the camera can see.
but also...
open up blender(or whatever you use). New project. you have a cube. duplicate that cube, align the second cube right up against the other. .5 blender units I think. now select both, ctrl+j, go into edit mode. and delete all but the two on top.
imagine each of those as a tile that will be created in unity like that. no interior faces. it will be non manifold, but not look non manifold because they will be right up against each other.

anyone else got input about this in reguards to best practices?

 

That's semi true. It takes far less processing if the engine doesn't need to render an object, but when you're talking about thousands of blocks that go into building a level, you have thousands of unnecessary polygons draining the cpu, and that's before the graphics engine tries to render lightning and shading and textures for those unnecessary faces if a tiny sliver of them ever manages to be within the camera.
Most of the time that I manage to extract scenes and objects from games or look around in no-collision mode, I see that the designers got rid of as many interior polygons as possible, it's almost shocking how much of an illusion all the scenery is and how little depth there is to it.

I know how to merge faces in 3D software, but what I am referring to is some kind of script for Unity to do it itself so I don't manually have to make every conceivable combination of merged blocks, which would take up a lot of space and time. Blender is open source so maybe some python script can be copied and wrapped for something in Unity.

 

Given that this would be by no means be impossible, I would question the need for it on 2 grounds :

First, Unity is a real-time rendering engine. Python is not designed for raw performance. It would just seem an odd move to start importing Python into the Unity runtime.

Second, whilst the problem as posed in the title of this thread is, indeed, incredibly fiddly, we really aren't talking rocket science here. Why would someone spend the time and effort taking Python code out of Blender, importing it into Unity and making any necessary changes- rather than simply coding the solution directly in C#? As linked in my original response (#2), the 2nd link I gave there is a tutorial covering basically this very scenario.

 

If you have a solution then go for it, otherwise it's because no one has presented an actual solution in Unity. The examples you provided don't address this problem as it can't be solve simply by generated terrain and it can't be solved by simply grouping objects together.

 

Ok, so I think I'm not fully understanding the requirement here then. It was not for the terrain generation that I included those links, rather it was the 'stitching' together of the next generated blocks of the mesh that they were demonstrating.

Now both the examples I posted were using perlin noise. Whereas, if I understand you correctly, you want to have 'hand crafted blocks' of mesh that you want to 'stitch' together?

My thinking was, if there is a 1-to-1 correspondence between vertices along the 2 meeting edges of these hand crafted blocks, then joining them together will be fiddly but quite achievable. But you seem to be suggesting this is not so?

 

Yes I am making them from scratch, and I want them stitched together without seams and ideally also without interior polygons.

If the vertices perfectly align between blocks, I would expect merging them to be readily achievable as well. The problem however is that then I am limited to very few blocks, or, that I still face the same dilemma of having to make every conceivable combination of different blocks in different directions to ensure they all perfectly align which then limits the shapes of the blocks. Instead what I am looking for is more like Blender's Boolean -> Union modifier.

Otherwise if you have examples of how people have solved this in the past I would be interested in looking into that. Minecraft uses blocks, so I'm thinking somewhat along the lines of minecraft except where every block has jagged edges and spikes. How can such a block system be designed to merge everything perfectly so that a spike doesn't stick into another block and the walls don't have seams? If you look in Unity's asset store, there's nothing like that, all the tiles are very simple shapes.

 

Unfortunately, not to my knowledge. As far as I can tell, you have something of a unique use case here (although happy to be proved wrong if anyone else knows better).

I would suggest that a consideration here is that for Blender, FPS is not an issue. For Unity it absolutely is. In all honesty, I am not that familiar with the Boolean->Union modifier. But if, for complex geometries, this is even a slightly time consuming task, then it could impact game play performance rather noticeably in a way that may be hardly apparent at all in Blender.

This would seem to be the very nub of the problem. It is the spikes and irregular edges that I am wondering about. If there really are no tools to handle this, then I would suggest you are left with 2 options - (1) create such a tool, or, (2) find an alternate solution.