We are thinking about writing a game with following features for a university project:
brief descpition of the game idea (its actually more a research project):
Worms3d clone but you only die if you touch the water (which gets more likely by time as bombs create dents in the landscape that surpass the water level)
We dont want to use a highmap generated landscape for this (obviously because we don't want to restrict the deformations caused by the bombs).
60000-100000 vertices for the landscape mesh (not highmap generated)
are currently used in our own 3d engine prototype.
Do you guys think it is possible to switch to ogre if our algorithm dynamicly modifies (adding and removing triangles) the mesh and also needs to move parts of the static mesh to movable objects that get attached to a physic engine.
And how well does Ogre perform for partial updates of the mesh geometry?
cheers
Timo
partial mesh geometry updates...
-
- OGRE Retired Moderator
- Posts: 4011
- Joined: Fri Sep 19, 2003 6:28 pm
- Location: Burgos, Spain
- x 2
I don't think dynamically modified meshes of that size will give good performance. I've always thought that worms3D would have a better look if they use CSG instead of vertex manipulation, but that's how they do things. In any case, I guess they're using the marching cubes algorithm or something similar. Maybe a vertex program would help you doing that... but not sure though 

-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
OGRE performs as well as the GPU does. Remember that GPUs like static geometry best. You can, however, define vertex buffers as being dynamic and thus they're placed in AGP rather than GPU memory to make they quicker to update (see the HardwareBuffer usage options) - but you will still pay a performance penalty when you update them.
In addition, if you're updating a buffer, the GPU likes you to update all of it so that you can use a 'discard' lock mode. This means the GPU isn't stalled since it can carry on rendering with the old buffer, and let you write into a completely new areas - flipping them over when it needs to. Remember that the GPU is highly parallel, and rendering is queued - you might actually be a frame or two ahead of the GPU at times. Partial updates to a buffer will cause the GPU to stall since you cannot be writing to the buffer when the buffer is being used for rendering - and since you're not recreating the whole buffer it can't assume it can just flip over later. So partial updates are sub-optimal - nothing to do with OGRE, that. Therefore, you'd be better to split up the geometry into smaller sections, and upload completely new versions of each block when it's updated.
In addition, if you're updating a buffer, the GPU likes you to update all of it so that you can use a 'discard' lock mode. This means the GPU isn't stalled since it can carry on rendering with the old buffer, and let you write into a completely new areas - flipping them over when it needs to. Remember that the GPU is highly parallel, and rendering is queued - you might actually be a frame or two ahead of the GPU at times. Partial updates to a buffer will cause the GPU to stall since you cannot be writing to the buffer when the buffer is being used for rendering - and since you're not recreating the whole buffer it can't assume it can just flip over later. So partial updates are sub-optimal - nothing to do with OGRE, that. Therefore, you'd be better to split up the geometry into smaller sections, and upload completely new versions of each block when it's updated.