Best practice for a dynamic mesh

Troubleshooting graphics
1

I want to be able to effectively create and handle dynamic meshes. What is the recommended way? Currenly I am calculating a new vertex position buffer each frame and set it on the mesh. But framerate decrease is dramatic. Like when having a polyline with 1000 vertices updated each frame, I drop down to below 24 FPS…

2

Reuse the same buffer.

2 Likes
3

Just implemented it! Although, the speed increase does not seem to be noticeable… I have fixed other bottlenecks and FPS gone higher. Turned out to be the real problem was with my code.

4

Yeah, i had thought about another problem which also related to Best practice for dynamic mesh and buffer.

Let’s say I make another kind of terrain:
At first it combine of quads with heightmap and can be splatted, optimized to render pretty like our orginal terrain.
– So if i had 64x64 quads, I know exactly the height of a quad by lookup in its height map by “rows and cols index”, fine!

Then I want to introduce Warcraft style terrain, which has cliffs, and here come the tricky part that I cant get over:

  1. How can i add those side quads of a top quad into an existed buffer?
  2. Cause in a Mesh, every elements in a buffer know the relationship between them via an index, right?
  3. How can i index these kind of side faces, for ex, with “integer” and still know which top face them attached with?
    May be i have to use other kind of data structure to save this topology and then merge into a real buffer later, but then I have to nearly update a whole buffer…

I know to “smarty update just changed data” is pretty tricky problem, now with the “index constrainst”, a plus.
Is it a data structure for that job which I can look into. Thanks.

5
@noncom said: Just implemented it! Although, the speed increase does not seem to be noticeable.. I have fixed other bottlenecks and FPS gone higher. Turned out to be the real problem was with my code.
Sometimes it's faster to write data in a temp array an bulk put it to the buffer instead of doing put(blah) in an iteration.
1 Like
6
@noncom said: Just implemented it! Although, the speed increase does not seem to be noticeable.. I have fixed other bottlenecks and FPS gone higher. Turned out to be the real problem was with my code.

The speed increase that you will see is that the garbage collector won’t have to reclaim all of those direct buffers… which normally just build up and build up and build up until GC has some other excuse to run. You are also less likely to run out of direct memory because of this.

That’s why reuse is good when possible.

7
<cite>@atomix said:</cite> Yeah, i had thought about another problem which also related to Best practice for dynamic mesh and buffer...

This is a big math problem I think. Since in general, terrain has no rules of generation, the data of the mesh is completely arbitrary and handling different cases of manipulating it is a mathematic hell. In most games I have seen, no modification of the amount of vertices or faces is done.

However, I can think of a way to handle this - you have to somehow simplify the terrain representation. There is a wide field for experiments, but some of the common approaches include using fractals. I would advice creating the terrain mesh data from some mathematical function data, like a fractal or an L-system. In general, IMHO, the best approach is to re-generate the whole terrain mesh from some other data, say, topography.

Or you can somehow determine the region in which the modification occurs, takes those polygons, tesselate them or the region they’re taking anew. But you deal with pre-defined size buffers, so you have to think ahead here…