Since there seem to be plans to integrate some kind of mesh fracture code into blender, I decided to write a little text about what I integrated in the 'fractureme' script which I used to do these animations: http://plant.ffa.vutbr.cz/~novak/crackme.htm while the script itself is to be found here: http://plant.ffa.vutbr.cz/~novak/dwnflz/crackme/
I am not planning to port this code soon, since I have a combination of hardware+os where blender 2.5 doesn't work at all, that's why I decided to write up this little documentation to help understand what I used and how it could possibly be used to simulate fractures in an artist-friendly but not physics based way.
I tried to bring in some of the features seen in commercial destruction tools I found, like rayfire or blastcode, and to some extent I succeeded in that. The script has several parts included in the blend file.
The workflow is usually
- generating the shards, and possibly their hierarchy
- setting their physics and game engine properties.
- setting up scenario - using various objects as bombs or projectiles with timing
- running and baking the simulation in game engine
- possible animation cleanup e.t.c.
The shard generation has a 2d and a 3d version:
is actually more advanced in terms of possibilities. It generates box-shaped(usually to be flat in one dimension) groups of shards. These can be used for anything flat in the possible scenario, and complex objects like houses or machine parts can be built out of these. there are 2 options for shard generation. both of them build a graph, which is then used for generation of new meshes.
Generated cracks - shards
This uses a crack-propagation algorithm, where hitpositions and crack characteristics can be defined or random, the look of cracks depends on tuning various properties, and the algorithm isn't finetuned, sometimes hangs.Advantage can be achieving good looking cracks relatively fast, and a 'crackmesh', which is actually just a mesh of all cracks with ordered faces, and thus can be easily animated with the build modifier to get cracks spreading around before things actually fall apart.
Crackmesh was used for these simple vids:
likely to be most used, since it takes a black/white image, builds & optimises graph from it. Doesn't build a crackmesh, but that could be done quite easily if a hitpoint would be somehow specified. example here: http://plant.ffa.vutbr.cz/~novak/crackme_crush01.htm
3D version is much simpler, but also powerfull. It uses heavily booleans, and would take advantage if the carve library mentioned here in list some time ago would make it into blender(I made some tests where it performed better). Also bmesh would be probably good for more stable booleans behaviour.The fact that various objects can be used for crack/shard shapes makes it very artist-controllable, while saving time compared to doing things manually.It also enables to set up hierarchy, and supports building up hierarchy to get sequential splitting of moving objects(so far without baking, so only in engine).
Methods of splitting
Methods of splitting are:
Hierarchical random & random continuous
uses one of four (and possibly much more) crack shapes - flat,flat rough,spheroid,spheroid rough to generate shards, hierarchical option splits each shard in 2 and then splits these subshards again, while continuous leads cracks always all the way through original mesh.
this option is very flexible, since it enables the user to split object with a group of other objects. So the user first creates the inner structure, like bricks with glue, wood e.t.c. and then the object gets split with the whole group.I also wrote a separate script(also in the file), which is called 'owndelaunay', and actually meshes a random voronoi graph :), voronoi cells are used in many fracture plugins for various softwares, although I think they actually don't look that pretty as the other options.
Split with active
this uses the active object to split all selected objects by it, it can be used to define a custom shape, and perform splitting with same way as random splitting.
Setting physics properties phase
is rather simple. The shards get "shard" property and in case of generated cracks also timing. In case of hierarchy(experimental) there must be some logicbricks linked to the shards manually(no logicbrick api).
To set up simulation, you place some of the pre-made objects in the layer together with the shards. objects are:
- 'freezeme' - this freezes all shards physics on the beginning of simulation, should be kept always
- 'bomb' - can be timed, has power/speed
- 'projectile' - can have any shape/animation, can be bullet/hammer/pendulum, whatever.
The scripts for these objects are very very simple, and usually just switch on physics for the shards on 'impact'
is running game engine, with having the ipo recording on. bang!
- UI - not done yet in 2.4x because of 2.5 project
- Proper sequential splitting - could be done relatively easily, but much higher count of meshes would have to be made(after each shard splitting there should stay the rest-mesh).
- Impact based splitting - splitting would have to happen on impact time, not possible during engine simulation.
- Some animation features(also 2.5 reasons):
- Recording of animation for hierarchy splitting, moving objects falling apart...
- Animating hiding of original mesh and unhiding of shards.
- Impact strength influence - wasn't working in ge api, so breaking depends only on speed of the hitting object, not weight.
- Constraints - bullet constraints could be set up between objects/shards
- Deformation of parts pre/post splitting (bullet softbodies with recording?)
- UV's for random splitting objects for 3d version, trivial task