Realtime mesh fracturing

Has anyone used voronoi to do realtime mesh deformation and fracturing in Urho3D? How would you guys do it?

https://www.assetstore.unity3d.com/en/#!/content/9411

Right now, i’m doing everything by hand: i create a normal mesh, then a fractured one in Blender, and then when the damage is higher than X, i swap the meshes and play a baked animation.

I think the way you do it is the most practical one.
How do you bake animation for fracturing for Urho?

It is practical, but it sucks for the player: everything he blows up a box or something, the same pieces go to the same places. Also, the pieces are not affected by physics, so they go through walls and everything. I have to carefully place everything.


Bullet physics seems to have something similar but you’ll have to port it to Urho3D in order to use it. Probably not much but it’s a start.

Isn’t Urho already integrated with Bullet?

Yes but Urho only wraps the collision and rigidbody systems.

Is there a tutorial on how to integrate other parts?

I’m not aware of any tutorials on that, but my best advice is to just read the source code and try. The community helps you a lot if you have specific questions.

Well, some people implement fracturing using particles. Also you can add variation using separate animations, and use some raycasts to prevent wall passing (but this might use some CPU).

I have used the Exploder Unity plugin, seems it use https://github.com/jhasse/poly2tri library to cut polygons.
So, If U can obtain the mesh data, and do something on it, which is beyond my knowledge :no_mouth:

Games like Half-Life 2 just spawn few pre-defined “piece” models, usually with some explosion to hide the switching from the intact model to its pieces.

Why don’t you simply creates five other more “destroyable” animations and mix between them? Consider that, unless yours a game for happy destructors, most player probably won’t even notice…

The license on the Carve library was changed to MIT by the original author, his github repo for CarveCSG is easy to miss since the top google result is an old fork by someone else. It’s pretty weird to work with, so getting the results you want can be a bit of trial and error.

There’s Alembic for baking simulation results - it’s practically made for the cooked demolition scenario, though it’s almost as nasty to compile as OpenVDB (which can do fracture as well if voxelizing is okay) is.

The talk on Rainbox Six: siege’s destruction is also on youtube - it’s pretty simple.

@Sinoid any idea whats the performance of Carve lib? Is it useable realtime?

@rku anywhere between 200ms - 500ms for Carve, on a potato Surface Pro 1st gen. Fast enough to appear real-time when threaded (which is the case where I got all of these measurements).

  • 4500 triangles minus 12 triangle cube
    • That’s actually 3 ops (A-B, B-A, A u -B)
  • Ran in C++/CLI in actual CLI code for most of the intermediary … so not exactly a rocket
  • Measured via System::Diagnostics::Stopwatch
    • Not the most accurate thing
  • Includes the time to build the vertex data and then translate the results back into something renderable
    • Carve uses a table based storage for attributes of vertices/edges/faces, so that’s quite a bit of workload
    • Preparing the mesh takes: ~145ms
      • Canonicalize
      • Fill buffers
      • Difficult for me to actually measure as I do cache the half-edge mesh used for canonicals
    • Extracting the mesh takes: ~16ms

So, as a threaded work item yes. Keeping all of the intermediate Carve specific data should be enough to make the difference between usable and not usable.

2 Likes

Thank you very much for taking time to do the test! While not the rocket it isnt too slow either. With some trickery like mentioned in R6:S talk you posted it can be totally realtime.

No problem, I kept all the Carve code around even though I ended up rolling my own CSG.


It certainly makes sense as part of a solution. I wouldn’t use it for something simple like subway-columns or a heightfield/planar slice.

The planar blocks from the R6:S edge talk have the huge advantage that it’s trivial to generate a decal skirt for those, with vanilla CSG that’s an additional intersection and the output is triangle-soup so it means looking at edge connectivity to figure out UVs - which doesn’t sound like fun.

UV data is stored per vertex, it has nothing to do with edges.

Godot recently added their own realtime CSG component. Code looks fairly easily portable. https://github.com/godotengine/godot/tree/master/modules/csg

1 Like

6 posts were split to a new topic: [Split - toxic] Realtime mesh fracturing