koobas.hobune.stream
Performance procedural terrain
Hi there,
I'm currently working on a simple terrain engine. The problem I'm facing is that I want to be able to manipulate the terrain at runtime. The terrain is a custom generated mesh which recalculates on mouse click. It works fine, but terribly slow as I'm using a mesh collider and every time the mesh recalculates, so does the mesh collider, resulting in a dramatic framerate drop.
When doing a deep profile on this in the profiler it shows the biggest CPU usage is the recalculation of physics for the new mesh in the mesh collider (97%). The only thing I really need the mesh collider for is to capture the mouse click, I don't want the terrain to have any other physics. A mesh collider is just the only way I can think of to get the precision I want when capturing the mouse click. I need to be able to pinpoint where the terrain was clicked..
Now my question is: does anyone know an alternative to a mesh collider to capture mouse clicks on a custom made terrain mesh? I basically want to be able to tell if the terrain was clicked and where, that's all, it does not need any other physics..
Thanks in advance :)
P.S. Before this I worked with the marching cubes algorithm and got that working but there I got stuck on normal recalculation (between the different chunks there would always be a visible line..). I was never able to solve that so I'm abandoning the marching cubes way for now. So I know that's a good alternative but I kinda gave up on that one..
$$anonymous$$aybe you can split the terrain up in segments so that it doesnt need to recalculate everything?
Thanks for the suggestion, that was something I thought of too but it still leaves me with having to recalculate the physics behind the mesh colliders.. which is normally something you shouldn't do because of the bad performance (even in smaller chunks).. I was wondering if there's a way that doesn't use mesh colliders at all where you're still able to capture mouse clicks. Or some way to use mesh colliders without all the physics that are being calculated, as I don't need any physics besides a raycast..
But if neither of those exist you're right, splitting it up in chunks would be the only way. However that probably brings me back to the normal recalculation problems I've had in the past.. As described in my question, I just can't seem to figure out how to align normals between chunks of mesh..
I have exactly the same problem, and am eager to see what solutions are provided.
Regarding normal calculations : I've recently been exploring the new tutorials from CatLikeCoding. The module on Noise actually covers calculating normals. I've yet to see if this method makes the chunks appear 'seamless' with similar/same normals at the edges. Here's the link, scroll down to Calculating Normals (approx 1/3 down the page) : http://catlikecoding.com/unity/tutorials/noise-derivatives/
Thank you for sharing that link, looks like a really interesting article and I will definitely dig into it!
I too recommend splitting the terrain up into chunks. You could also try to use simpler mesh modifiers(greedy mesh colliders, as I think they are called) that don't follow the exact triangles of the terrain but still cover all surfaces. Assigning a mesh collider is generally the most resource-intensive part of procedural mesh generation.
As for sharing normals, I assume that you are sharing vertices between polygons; this is bad for the normals and as you indicated, probably now possible when using chunks. The way games like $$anonymous$$inecraft do it is to just make each face a seperate polygon with it's own vertices, so that if two polygons are next to each other, each would have three seperate vertices. For simple cubes (again, like in $$anonymous$$inecraft), it's also acceptable to share the two vertices between the two triangles that make up one of the cube's sides. As soon as two polygons are not planar, they need top have their own vertices, however, in order to ensure correct normals.
