[Bf-committers] Fracture Modifier - call for hints / advice / help

Martin Felke martin.felke at t-online.de
Sat Oct 11 17:16:04 CEST 2014

Hi, i am the developer of the fracture modifier, which is currently under review.

You can find the review patch here:  https://developer.blender.org/D817
Also, there is a more frequently updated branch: http://git.blender.org/gitweb/gitweb.cgi/blender.git/shortlog/refs/heads/fracture_modifier

With this mail, i wanted to call for some help among current and previous core developers interested in fracturing and rigidbody systems.
I could need some hints / guidance / help to finish some of the features, which i will list later, in time.

First a short introduction to the fracture modifier.
In general, this modifier allows a nondestructive, fast fracturing workflow. 
It is easier and faster to handle a single object with subgeometry objects that a bunch of separate blender objects.
It allows to easily tweak the fracture appearance (shards) or simulation parameters because of relatively fast feedback.

Now i want to give a general modifier state overview, on how it currently looks in the branch. I still commit in regular intervals to fix bugs or memoryleaks.

Basic features are mostly done, except some issues listed later.

- voro++ interface:      * pass pointcloud from modifier and a container (object bounding box) to voro++ 
			 * read back cell data (vertices, faces, centroids) directly, not via file anymore

- core fracture system:  * create shards as storage system for subgeometry from existing derivedmeshes, 
			 * recombine shards to a new derivedmesh
			 * invoke boolean and bisect intersection algorithms

- rigidbody preparations: * allow multiple rigidbodies per object, 
			  * store them in an cache_index_map with a "linear" index

- pointcache preparations: * read, write, access rigidbodies from worlds cache_index_map

- fracture modifier:  * this is the central connection point between fracture and rigidbody system and serves as storage system as well (DNA)
		      * create pointcloud and pass to core system, 
		      * combine and manipulate pointclouds to get varying fracture results, 
		      * using groups of helper objects as well or specifying inner material, also can hide inner geometry if specified
		      * read shards back and convert to simulation meshislands
		      * manipulate simulation parameters and constraints to get varying simulation results, like breaking thresholds, angles, distances
		      * weightpainting threshold and passivity weights to immobilize meshislands or let them break apart earlier, 
                        modifier uses given vertexgroups for this
- rigidbody simulation adaption: * extend simulation functions to deal with modifier storing the meshislands
								 * accessing the rigidbodies stored in meshislands via their linear index, 
								 * moving the meshisland verts according to movement of the rigidbody object centroid, 
								 * meshislands store a physics mesh also serving as shape for the rigidbody object 

Some advanced features are WIP still, but i am kinda stuck with them currently, here i could need some advice / help...

- sub object groups:  * supposed to combine meshes of differently fractured objects into one object without applying each modifier 
                        -> lacks customdata support still and can be used by re-using existing islands only (may crash else)

- non mesh object support: * can directly fracture curves, surfaces and fonts, mesh conversion is done in the modifier and is temporary 
                          -> wont render in cycles, modifier results not taken into account there, BI works

- complete editmode support: * supposed to pick single shards and manipulate them in editmode 
                          -> currently selects all elements at once, possibly the internal drawing mesh is not properly updated

- inner vertex group -> filled by modifier, but contains "too many" verts, meaning even faces from the outer shell will appear with e.g. the mask modifier after it

I also wanted to talk about several design and implementation issues i hit while developing the modifier.
Generally spoken, i often had to be a bit "creative" to find solutions which make this modifier work, 
due to lack of knowledge of mine as i dont know each function of the codebase. But issues arise also due 
to limits of blenders current design.

- weightpainting with active fracture modifier, works only if modifier is invisible and requires a refracture to interpolate vertex data down to the shards

- support for all customdata, currently limited to textures and weights

- proper greasepencil support -> got a crash with sketching session and autoexecute, cant run both at the same time

- 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 ?

Martin Felke

More information about the Bf-committers mailing list