Page MenuHome

Fracture Modifier design feedback from artists and devs
Open, NormalPublic


This design task is for Fracture Modifier design feedback from artists and devs on which features to keep or remove during the review process.

Some coding challenges are presently being reviewed for the Fracture Modifier. If they cannot be solved easily enough they will be removed from this proposed first version so the Fracture Modifier can pass code review.

Some of them though may be able to be completed with some help from the core devs or devs experienced in the areas they affect. Most of the work for the features has been done already. They just may have a bug associated with them or have undesirable coding implementations.

Patch page(for reference only): D817
Please post your comments on the design of the Fracture Modifier here and not in the actual patch task.

Some basic design documentation can be found here: User:Scorpion81/Fracture_Design

User Documentation can be found here: User:Scorpion81/Fracture_Documentation

Thanks : )



Event Timeline

JT Nelson (jta) added a project: Modifiers.
JT Nelson (jta) set Type to Design.
JT Nelson (jta) added a subscriber: JT Nelson (jta).
JT Nelson (jta) created this task.
JT Nelson (jta) raised the priority of this task from to Normal.

Maybe you could leave the physics simulation out for now and leave it up to the user to add this if necessary. There is actually a pretty good use for this modifier without any simulation as in the case of jade-like stone that is translucent and has fissures.

For now, taking the automatic Rigid Body simulation setup out of the equation will no doubt make the code more straight forward and this will also save time for some uses of the modifier.

Perhaps you can also start by using only one fracture option. The current default seems to work well, Voronoi+Boolean is what's coming up for me.

Maybe the 'Experimental' stuff should go since it's giving you problems and it's all going to complicate the code-review process.

I would like to introduce my design here first and the thoughts which made me make the current design decisions.

Why a modifier ?

It has really some excellent benefits:

Nondestructivity, Ease of use

  • good for nondestructive workflow, stackable and flexible as other modifiers
  • keep all under 1 object, mesh island simulation (nondestructive, fast)
  • do not clutter outliner out of the box (because it's 1 object only and no huge amount of shard objects)
  • easier handling for artists ( because they have to deal with 1 object only)
  • clean workflow: no removal of old shards, no backup, no permanently destroyed mesh in error case, because it's 1 object and keeps 1 object
  • no repetetive refracture and deletion of huge object amounts in error case because it's 1 object and won't be destroyed permanently


  • high fracture performance, much faster than cell fracture, fracture as it should be
  • also improved rigidbody simulation performance , not many objects or even constraint empties / objects, because all remains 1 object, no object overhead

Rigidbody integration, Ease of use

  • tight integration with rigidbody simulation, physical fracture simulation as it should be
  • there are other simulation modifiers as well, and they are ok....though not being perfect
  • one click setup of fracture
  • good handling of many rigidbodies at once, being shards of 1 object, again, logically grouped together...

Why that design / code in general ?

  • current solution, holding it all under the modifier, was the most feasible and least invasive method of storing / caching fracture geometry, while still using the current blender design.
  • self contained, as all changes affect the modifier only, necessary because it is a specialized solution
  • fits into current(!) blender design nicely, it keeps new stuff related to modifier only
  • leaves many other areas of blender untouched and does not affect them negatively
  • most modifications concentrated in modifier and rigidbody system
  • doesn't harm other blender code, only most necessary stuff like modifier registration, storage, customdata improvements and even a motionblur fix(!) are included, also rna / dna structs for storage, yes it can even be properly stored and loaded in blends !
  • can be easily reverted if a better solution has been found, but best approach with current blender design "as is"
  • can be improved together with blender easily, or be exchanged later by another solution, like an alembic pointcache or an improved "base system", but that should take fracture into account as well
  • may affect blender design in general (in a good way), ways for multiple rigidbodies and subgeometry objects have been shown
  • ways to improve performance with own "split to loose" object implementation have been showed
  • long development and integration effort, over 2 years, cooperation with users, already complex objects have been realized with it, usage count raising....
  • if code isn't battle-ready, it can still be replaced, removed, improved but it needs a chance to reach a wider audience, attract more users and even interested developers
  • fracture modifier can be adapted to another design and other design to fracture modifier if in master, they can have positive effect on each other-> the base system can be tailored to include it and the modifier can be adapted to the new base system better then, (no "guessing" of each others design, leading to misaligned /parallel development)
  • and regarding concern about alembic, currently the modifier works right now, with its own system, independent of alembic. When alembic support will be implemented, the modifier can be adapted, that's better than delaying the modifier until it will be implemented, because the modifier can be battle tested and improved in the mean time by more users.

Design Issues Which Should Be Fixed

Here i list some design issues which should be fixed instead of removing the according features. Leaving them out lowers the value of the modifier drastically.

  • general "updating" system -> have an autoexec flag right now, needs to be disabled by the simulation and reactivated by the user afterwards manually, here you can get live feedback of the fracture changes you make
  • fracture modifier geometry storage and simulation caching system -> groups verts to meshislands, with direct references to visual mesh -> not ideal, fracturing itself has shards, simulation has meshislands -> better a single storage system, more general -> how to distinguish properly between user changes and simulation triggered changes (movement) to the mesh ? now i have manual refracture operator and partial autoexecute system, to "commit" changes to mesh
  • storage -> currently storing contents of the cache system in Blender file, additionally to bakes or pointcache -> probably pointcache, alembic (?) could handle this ?

Maybe you could do what Campbell said needs to be done. You could start laying the groundwork for changes to Blenders underpinnings instead of working around them and cloning code.

Ideally, nobody should even notice that you are re-tooling Blender's infrastructure, so you'd have to do it cautiously and take your time. Help redesign Blender in baby-steps so that it becomes what you need to make things work for cool simulation tools.

Once Blender does what you need it to do then you will be free to do more of the simulation stuff without the current technological constraints.

You know the Python, you know some C-code and you also work hard for long periods of time. I'm, sure you can figure the dependency graph stuff well enough to discuss this with the others so you are in the loop with how it's being rebuilt.

Unless I'm mistaken you either have to help retool Blender or wait for others to do it and I think you are currently one of only a few people right now taking serious interest in the B-simulation stuff.

You could look at what Lukas T. is doing since he's working with sub-geometry/simulation type stuff.

Maybe you could adapt your way to sync with what he is currently doing since his work with hair is likely going to be part of the upcoming Blender changes which will affect your design choices for simulation work.

Nobody braids hair in one big motion, it's lots of little changes so why not start with a tiny patch that makes Blender src become more like your branch but makes no functional changes to current Blender use. Just a little different under the hood but still works exactly the same to users and other coders.

Take it slow so potential bug reports have a chance to come in before pushing anything else and no one will complain.

You just have to prove that you aren't breaking anything I guess.

Fracture Modifier Redesign Proposal

This proposal aims to make the design of the fracture modifier system usable for general inclusion in blender.
In the last review there were some major design issues raised, which should be taken into account by this proposal now.

Especially with the beginning of 2.8 redesign plannings I thought it is the right time to bring my suggestions back onto the table.

1) De-duplication of parallel rigidbody systems

Only use the new, modifier based system from now on, which supports multiple rigidbodies per object.
The former use case of a single rigidbody will be covered here by just not fracturing the rigidbody, thus keeping one island only.

The fracture settings will be stored together with the fracture results and the multiple rigidbodies beneath
the old ob->rigidbody_object (RigidBodyOb) struct under Object, in a new FractureContainer struct.

Constraints are handled in a similar way, a ConstraintContainer holds fracture constraint specific settings and groups per-shard
constraints beneath it.

The container holds all settings as well as fracture results, grouped by fracture states. Optionally there are multiple states for
different frames, to allow dynamic fracturing.

This is a good time to introduce such a potentially backwards compatibility breaking change, because 2.8 is allowed to break
physics backwards compatibility.

2) Sticking to existing data structures for storage of fracture results

To store results of a fracture operation a regular mesh data block per fracture state will be used.

As the fracture system needs to know about which polygons form a mesh island, a new custom data layer should be introduced in Mesh,

This just stores an island membership index for each polygon, which is provided by fracturing with voro++.

When reading the blend, each object with an active Fracture Modifier on it should build its necessary runtime structs for fracture simulation
from this information. Alternatively this can happen prior to first execution of the fracture modifier, to keep blender starting times faster.

3) Conversion to (mostly) runtime only structs, keeping them off the DNA

The former approach to store shards and meshislands directly in the DNA is supposed to be replaced by dynamically rebuilding MeshIsland
and Shard data structures when necessary from custom data information in stored mesh id blocks.

4) Fracture Modifier just for displaying the simulation results

The fracture modifier does not do any fracture operations any more nor stores any fracture data. It just extracts these info from its object's
fracture container and displays them.

One exception though, the modifier still is responsible to perform dynamic deletion of inner geometry during display.
This happens distance based and is called autohide.

The rigidbody system itself takes care of updating the vertex coordinates of the mesh islands.

5) Pointcache Usage

This point reflects the current situation, using blenders old pointcache system, for prefracture and even for dynamic fracture.
It is most likely supposed to be replaced by alembic or a comparable system.
Each object holds a pointcache list in its FractureContainer.

In the prefracture case, we have one FractureState and thus one pointcache per object.

When using dynamic fracture, we want to map each fracture state to a pointcache in the list, so each state with a growing count of
rigidbodies can use its own pointcache with the necessary capacity.

In the event of another fracture, an new state and thus a new pointcache is created to simulate the then current amount of mesh islands.

Current state of implementation

Points 1) and 4) are mostly done, but constraints dont work properly yet because of some cache reset problems.
The cache wont reset properly unless one of the objects is slightly moved, which is a longer known quirk in blender.
Because of this the distributed caches dont synchronize properly and the constraints wont be rebuilt.
This needs to be investigated by me.

Points 2) and 3) are partially done, because still the full lists of mesh islands and shards are being stored in the DNA.
This is subject to change to runtime only structs and customdata-layer based storage together with regular mesh datablocks.

Point 5) is partially done as well, but due to the plans of replacing pointcache by an alembic counterpart, this is likely to change again.
As the plannings for pointcaches in blender are still quite uncertain, this change is not being done quickly as well.

Existing Code Branch

People who are interested to see the existing code so far, can find it here: , "fracture" branch

what about getting bullets fracture system code to work in blender? maybe get blender and bullet more intertwined so you could then work at this from adding to bullet?

just a thought.

Using voro++ for fracturing itself is better than bullet for this purpose, imho.
To be honest, I dont even know HOW bullet does the fracture exactly, imho it just provides convexhull, and like in cellfracture you have to cut your cells yourself with that info.
Voro++ does this for you automatically and as you dont need to code anything more for that purpose, its faster as well.
All you have to do is just to build the mesh from the incoming raw data.
Furthermore bullet fracture wont solve ANY of the mentioned problems, so this aint a good idea in my opinion.

Looks like it comes down to following requirements and thus considerations for Blender redesign:

  • We need support for subobjects or submeshes that can work independently from slow depsgraph or database evaluations (to effectively simulate thousands of shards)
  • We need a new point cache that can manage changing object counts and changes of mesh topology at run time (required for dynamic fracturing)

Is there something else that keeps you from getting it done "the right way" without going into too much detail? We should try to bring it down to an essence, so that it's easier for the coredevs to figure out what's *really* needed to progress.