TerrainNode problems (editor)

[suliman]

Hi

I found Katsankat code for editing the terrain ( http://irrlicht.sourceforge.net/forum/v ... hp?t=32251 )
The arrow "finds" the right triangle under the mouse. But its extremely slow. I use a 1024x1024 heightmap and when editing the vertices i get a drop from 300 to 5 fps and smooth painting becomes impossible. And i can only fear when i start editing more then one vertice at a time (which is a must).
If i change to 256x256 heightmap i get much less drop but thats to low for me.

If i remove the last line (terrain->setPosition()) i get no drops at all but terrain doesnt change either... Any way to make this work? Ive seen working terrain-editors out there so im hopeful.
Thanks a lot
Erik

Code: Select all

 
void world::RaiseTerrainVertex(ITerrainSceneNode* terrain, s32 index, f32 step, bool up)
{
        IMesh* pMesh = terrain->getMesh(); 
 
        s32 b; 
        for (b=0; b<pMesh->getMeshBufferCount(); ++b) 
        { 
                IMeshBuffer* pMeshBuffer = pMesh->getMeshBuffer(b); 
                // skip mesh buffers that are not the right type 
                if (pMeshBuffer->getVertexType() != video::EVT_2TCOORDS) continue; 
 
                video::S3DVertex2TCoords* pVertices = (video::S3DVertex2TCoords*)pMeshBuffer->getVertices(); 
 
                pVertices[index].Pos.Y += (up) ? step : -step;
        }
 
        // force terrain render buffer to reload 
        terrain->setPosition(terrain->getPosition()); 
}

[NickLH]

The problem is coming from recalculating the entire mesh buffer every time. Not only is that intensive on the CPU side, but you have to upload the data to GPU memory.

My suggestions:
Make a completely flat terrain (you could still use the default terrain node but with a couple of minor changes), and store your terrain height in a heightmap texture. Make a vertex shader that reads the texture and displaces the vertices along the y axis based upon those height values. That way, you don't recalculate the whole mesh every time.

One drawback that I could see with this approach is that the terrain LOD might not work properly. For example, if you had a very high peak (Mount Everest? ) and had the camera at the top of that peak, the geometry would be at a low LOD because the camera would be so far from the actual geometry (which is just a flat plane way below). I'm sure that could be addressed with a bit of clever thinking though.
Also, picking the terrain vertices would have to be tweaked because the visible points will not reflect the underlying mesh.

Another thing to consider is that even though you're not recalculating the whole mesh every time, uploading a new texture every time something changes is also memory intensive. A better approach would be to find which parts of the texture change, and update only those parts in memory (assuming you have enough GPU memory to store the heightmap permanently in GPU memory).