Jump to content


- - - - -

Breakable objects

3d physics

4 replies to this topic

#1 Vilem Otte

    Valued Member

  • Members
  • PipPipPipPip
  • 345 posts

Posted 05 August 2012 - 01:03 PM

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 :D)).

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.
My blog about game development (and not just game development) - http://gameprogramme...y.blogspot.com/

If you don't know how to speed up application, go "roarrrrrr!", hit the compiler with the club and use -O3 :D

#2 }:+()___ (Smile)

    Member

  • Members
  • PipPipPip
  • 169 posts

Posted 05 August 2012 - 09:24 PM

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.
Sorry my broken english!

#3 Reedbeta

    DevMaster Staff

  • Administrators
  • 5305 posts
  • LocationBellevue, WA

Posted 06 August 2012 - 02:22 AM

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).
reedbeta.com - developer blog, OpenGL demos, and other projects

#4 Stainless

    Member

  • Members
  • PipPipPipPip
  • 578 posts
  • LocationSouthampton

Posted 06 August 2012 - 09:12 AM

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

#5 Vilem Otte

    Valued Member

  • Members
  • PipPipPipPip
  • 345 posts

Posted 06 August 2012 - 06:36 PM

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:
My blog about game development (and not just game development) - http://gameprogramme...y.blogspot.com/

If you don't know how to speed up application, go "roarrrrrr!", hit the compiler with the club and use -O3 :D





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users