koobas.hobune.stream
Can I move just some of the verts on a mesh?
I would say "terrain," but I don't think I want to use Unity's built-in Terrains for this. What I am trying to avoid is setting every single vertex's position every single frame when there are only a handful of them that are actually being moved. I think being able to do this is make-or-break for the feasibility of a new game concept I'm kicking around.
I think I should have an array (dictionary) of vertex numbers vs world space x-z coords. Then another of vertex numbers vs an array of all the numbers of that vertex's closest neighbors. (Which is probably harder to calculate than it is to say.) Am I on the right track though?
The procedural examples all iterate through every vertex in a temporary array and then set the mesh's vertex positions (or colors) all at once. Is there some reason why you "have to" do it like that?
Are yous using this mesh for physics as well (ala $$anonymous$$eshCollider)?
I'm not using it for anything yet, it's just in my head. But I'm going to say no, I don't want there to be a mesh collider.
of course you can ! go for it. are you already familiar with manipulating mesh in realtime ? if not expect a learning curve of a few months
as Eric pointed out recently - I can't find the damn question - it's critical to note that it is very slow to update a mesh collider, you can't do it in real time, so forget that if that's your plan.
(other alternatives for you could just be selecting from a random selection of 50 or whatever surfaces, depending on your game?)
may be relevant ..
http://answers.unity3d.com/questions/315059/how-to-improve-performance-while-generating-extrud.html
you mention vertex neighbors in passing .. note ...
http://answers.unity3d.com/questions/193695/in-unity-is-there-a-fast-way-to-find-nearby-triang.html
you mention "The procedural examples.." I find them all to be not very good really! heh! i'd kinda recommend just completely ignoring them
You must update every vertex in a mesh even if you only are changing a few. However, you don't need a temporary array. You can use a permanent Vector3 array for the vertices, and only change the relevant entries, but doing "mesh.vertices = myVertices" copies the entire array to the mesh, and is the only way of updating meshes.
Ok; that's what I was thinking. I guess I can test it myself, but is doing that every frame a big framerate hit and is "mesh.vertices = myVertices" expensive in direct proportion to the number of vertices being copied? (If so might just say "#$@*% it, I'm going voxels.")
is doing that every frame a big framerate hit
Depends on the size and number of the meshes, and how fast the hardware is.
is "mesh.vertices = myVertices" expensive in direct proportion to the number of vertices being copied?
Yes.
