math & physics
Okay, so here is the situation - in my (e.g. my company's) current game project we decided to add another one thing - breakable stuff (okay, I and other developers just wanted the main hero to smash every visible wooden box and lots of other things in a similar way Half Life 2 does it (we all love the way things are smashed in Half Life 2 )).
Though we can't afford DMM or such solution, neither in performance and in cash - it's very expensive (meaning like pre-created models of breakable stuff by our graphics guys is far less expensive than DMM) and not so well suited for open world games (in my opinion) - note that DMM looks good, I don't think it looks that much better than precomputed breakable models like in Source engine games.
Note: In next part I'll refer to NON-broken model as to object and to it's broken parts as to object fragments.
So, to the question - I know that there are more ways to achieve breakable body:
Solution 1: 1.) Create for each object fragment a separate geom and body. Connect them with fixed joints.
2.) Upon recieving enough damage, destroy fixed joints so the object fragments will be broken to parts.
Though this seems good, it's very bad (IMO). You have to render object fragments from the very beginning (so much geometry, not mentioning the seams where AA goes crazy). Also if we have object composed of 20 fragments it means we simulate 20-times more bodies than the single one (before it's broken) - a lot of contact points between them can also occur (slow, slow and horribly slow).
Although this one gives me ability to tear object to pieces one by one (e.g. where needed = where it was hit).
So I came up with better solution.
Solution 2: 1.) Create just single object. (And render as single object)
2.) Upon getting enough damage, destroy this object and spawn object fragments (of course I know I have to set their positions correctly here!)
This looks a lot better from the perspective of speed (and seams). But I don't have ability to tear object to pieces bit after bit (e.g. for larger objects where I'd like to drop off single fragment and keep the rest together...)
So in the end I think the best would be a mix of these two - but only for larger object (that I want to destroy piece by piece). I'd be glad to hear any opinons/advices here.
Note. I know this is unrelated, but Havok and PhysX have some examples to this (and I've used these two in projects some time ago), though this project needs to be cross-platform (and it's primarily developed on Linux) - and so we switched to Open Dynamics Engine.
I think you can try tree-like hierarchy for object fragments. For rendering you have model for each tree node (index buffer per node and global vertex buffer) then if root node is unbroken render its model or else go to the child nodes and repeat recursive.
For physics use modified solution 1: subdivide object based on some criteria and connect parts with fixed joints. Example of criteria: for each contact point with relative speed more than some threshold split fragment tree based on leaf position of contact point (small fragments near contact and large far from it). That way you increase number of physics bodies only at moments of hard blows.
For destroying things piece by piece, you could have a single object and then replace it by fragments as soon as it takes enough damage for even one fragment to be detached (rather than waiting for enough damage to break the whole thing).
Have a think about a voxel solution.
Describing your breakable objects as a single 3D array, with the usual range based simplifications makes destroying objects very simple.
The only real issue is can your existing engine handle droping in voxel objects
Thanks for the reactions!
#Stainless - I have considered voxels and I definitely agree that they're very useful in case of destruction (note that I have implemented destructivity of terrain through voxel solution - though not used in this project), although this project has to use triangles for these destructive objects (there are several cases - 1st one is rendering speed (although with Sparse Voxel Octrees it's possible to render high quality objects at high speed - so this case could be changed) but the 2nd one are graphics (the guys already created lots of stuff with standard trimeshes and also there aren't any good tools for creating voxel objects - but feel free to give me hint on tools if you know of any, i'll definitely use more voxel objects in future)).
Note that our engine isn't exactly voxel-less in the end (clouds (there is actual weather simulation! - of course a bit "hacky", but still dynamic and working (with planned in game weather forecast in daily newspaper in the game), I'll definitely make an article about it after we finish demo world), smoke (dynamic, simulated in grid - a bit "hacky" solution again of couse), etc.).
#Reedbeta - yeah, I had to think about it twice or more times and it's definitely better to break it piece-by-piece (more realistic), breaking it all at once could work for glass or such material, but for wood, or such, it's definitely better to keep it piece-by-piece.
#}:+()___ (Smile) - Tree like hierarchy is surely a good idea! The modified solution 1 you described sounds good and as there probably won't be hard blows in the game either (or maybe in cut-scenes,and that can be pre-computed if it'll be too slow), it just sounds even better...
Okay time to code.... :ph34r: