Removing Triangles from surface

BlitzMax Forums/MiniB3D Module/Removing Triangles from surface

TomToad(Posted 2013) [#1]
I have a Surface which contains quads. Each quad is made up of 4 vertices and 2 triangles. I want to remove one of the quads from the surface. I've looked in the B3D docs and I cant find a RemoveTriangle or FreeTrianlge function. I did find a ClearSurface function, but that would eliminate all triangles and vertices which require an entire rebuild of the surface. Is this the only way or am I missing something?


Polan(Posted 2013) [#2]
Sadly, rebuilding is the only way.
Even if there was Remove/Free triangle function, it would end up rebuilding mesh.


ima747(Posted 2013) [#3]
As polan said, rebuilding is the only way. You can't remove vertices or triangles directly.
It should be possible to create a DeleteVert and DeleteTri methods as the data is just stored in arrays if I'm not mistaken... but it's not built in and you would need to figure out what other modifications would be needed afterwards (rebuilding normals or whatever else to push the updated data through).
Personally what I do with meshes that I'm working on on that level is try to re-use the data. Stash the verts somewhere or find a way to disable the tri. Consider putting things that will be modified into their own surfaces so you can trash the surface (sometimes this can even give you performance improvements since you can handle the surface differently, sometimes the oposite of course, depends on what you're doing). Determine what the issue is:
1) Display: If it's just visual you can cheat by hiding the verts somewhere where you won't see, or reducing the tri to a single point etc.
2) Memory: Consider using more surfaces so you can actually kill things off entirely when needed.
3) Modify mesh performance: You're probably best off going with surfaces since you shouldn't need to recalc the whole mesh when deleting them (if I remember correctly, which I probably don't...). Or consider caching the points so you can just move them into position as needed.
4) Drawing performance: If every vert counts, and adding more surfaces would cause slowdown then you need to look into your own direct data access (delete the points yourself and figure out how to make that work), or i you're adding AND deleting then consider cacheing the points again to minimize the amount of things that need actual modification (arrays can take a while to rebuild so adding a new point is a lot slower than moving an old one, you need to update either way but when moving you don't need to rebuild the array).


Kryzon(Posted 2013) [#4]
You can also pool those quads.
If you don't need one now, you disable it by moving all its vertices to the exact same location - the hardware figures this and doesn't render it.

But this keeps it "available": whenever you need a new quad again, you can recycle it as one of the inactive quads (change vertex colors, UVs etc. to what this new quad needs).
So when you need a new quad and have quads inactive, you can recycle. When you need a new quad and have no quads to recycle, you can create a new one.


TomToad(Posted 2013) [#5]
I'm thinking that recycling the vertices are the best way to go. Shouldn't create any major performance issues since this is for a level editor and there will probably be more quads added than will be taken away as the level gets more complex. And if performance ever gets to the point of being intolerable, I could just add an option to completely rebuild the level and get rid of all the unused quads.

Just one question, If I set all the vertices to the same coordinates, would it affect collisions if an entity bumps into it? Thinking it might be better to set the vertices to some huge coordinates where my level will never reach.


Polan(Posted 2013) [#6]
Recycling vertices will cause you problems with most of models. It's common for triangle to share vertex with another triangle.
Unless you are building mesh yourself, and you are sure there are no shared vertices.


Kryzon(Posted 2013) [#7]
Considering that a degenerate triangle (with collapsed vertices) has no area and no normal, I don't think it will influence collisions. But I speculate.
It will influence the mesh's bounding box (as the calculation for that simply checks the most distant vertices, it doesn't regard triangles). Though if you clean the inactive quads when you're exporting the level, this shouldn't happen in the actual game. You're more concerned now with the flexibility of editing rather than the performance.

Thinking it might be better to set the vertices to some huge coordinates where my level will never reach.

That is a good idea.