Some time in the future (after pyweek) I want to make a new version of my terrain editor and I looking for a way to update (deform) the terrain mesh faster.
In the last version any change in the terrain was made by painting to a heightmap and regenrating the mesh every time - this took up to a few seconds. I was thinking about doing this on the gpu, but there’s the vertex texture fetch problem (with cg/amd/ati) and somehow I don’t think making an all-gpu-terrain is a good idea (generate it each frame? how I’d do collisions?).
Can the buffer protocol help here? I wouldn’t mind skipping the heightmap and moving the verts of the mesh directly (and maybe adding new verts on the fly, like in sculpting software - but maybe that’s an overkill, something for later).
Would this new feature allow to change verts in an array by index and keep that index for later use (and it would still point to the same vert)?
Can this be used to change the pos of 100+ verts of a ~2k vertex mesh at realtime speed (30+ fps)?
Some code samples would do good
If I got this all wrong, then maybe some more info on the oryginal use of the protocol could clear things up.
Maybe. What the buffer protocol allows is low-level buffer modification from Python; basically, it is a more low-level and more efficient alternative to GeomVertexReader/Writer/Rewriter.
So yes, you can efficiently index an arbitrary vertex and continuously update it. But you still access the vertex buffer that’s on the CPU; ie. Panda still needs to send the buffer to the GPU again every time you modify it. That’s expensive.
Keep in mind that you can simply use GLSL if you want to use vertex texture fetch and add the elevation on the GPU side. This is probably the best approach in the end, since it’s far cheaper to update textures than it is to update the whole geometry buffer.
(Of course, the buffer protocol can also be used to update the low-level texture data more efficiently without having to use a PNMImage!)
You should do collisions against the original heightmap image anyway, rather than actual geometry. This is more efficient since texture lookups are relatively cheap.
Recently, OpenGL added persistently-mapped buffers, which in combination with the buffer protocol would allow one to update the vertex buffer data from Python and have the updates sent quickly and efficiently to the GPU automatically. However, Panda3D currently has no support for these.
So really, there’s nothing wrong with all-GPU terrain based on a heightmap texture; it’s probably the best way to go.
There are some things that I know how to do in Cg but not in GLSL (like texture projection), maybe if Panda had a GLSL shader generator I wouldn’t be so scared of it, but that’s for another topic…
I have no idea how to do collisions on a height image - getting the Z from any XY is simple, but how to check if that arrow can fly over that hill (and where it hit)? But then again Bullet has a heigtmap shape, so maybe there’s no need to panic.
I think that until I have a minimal working case (or two -one on the gpu and one on the cpu), I won’t know. The expensive part (sending the buffer) could still be fast enough to make a few changes per second. Can’t say - maybe some crazy hybrid (change the color of the selected verts and move them in a vshader)?
Persistently-mapped buffers look good, but even if Panda did support them - my gpu will probably not.
Anyway thanks for the info, I’ll have more questions when I’ll start
I think that for cards that support it (virtually all modern cards), sending the heightmap to the GPU will be by far better than any other approach in terms of memory efficiency, render performance and sending updates at a fraction of the cost.
