It’s a kind of difficult situation for us. We have designed the Fracture Modifier in a way to achieve certain targets of functionality and performance that we had in mind. To realize those targets it required some unorthodox coding which wasn’t accepted by the core developers of Blender.
There were expressions of intention from their side that the limited rigid body / pointcache system of Blender would be overhauled and improved for version 2.8 to serve our purpose better. We have had a few discussions with core devs but nothing has changed so far.
The point is: if the Blender Institute doesn’t think it’s worth to invest time into the problem, and we believe there is currently no better way to implement the FM, then we are stuck. We cannot magically fit the FM into the current Blender design and meet all conventions at the same time.
However, in practice it doesn’t matter much for us anyway. It’s open source, so how could it? Everybody can download our builds and use it. We are maintaining our own branch, we have all control - that’s pretty cool, too.
Having said that, it’s not carved in stone that the FM won’t find its way into the official Blender version one day - miracles happen -, but you better don’t wait for it. If you want to use the FM then just use it now.
There were expressions of intention from their side that the limited rigid body / pointcache system of Blender would be overhauled and improved for version 2.8 to serve our purpose better. We have had a few discussions with core devs but nothing has changed so far.
That sad, FM as an official module in Blender would be something big and exceptional, like Mantaflow. And if it would be node-based - damn!
If it is not possible right now to make FM in official release of Blender, why you’re not making unofficial port to 2.9+, as it is now done with Blender 2.79? Someone merged FM into 2.80, I’ve tested it and it is somehow working - so it is not possible to make it to work properly, or it is not performance wise or maybe it’s time wasting?
Aaargh, there was no such question yesterday and I didn’t catch the moment to ask :(( Hope for the next episode, but Pablo announced the end of bcon1, so I guess blender 3.0 it is
I need to export an FBX with 3 sets of shards (3 fractured objects), with red, green & blue vertex paint respectively. Red on all of one object/set, blue on all of the next object/set, etc.
It looks like, unless you disable the FM on an object, vertex paint is broken.
And when you re-enable FM, everything goes green whatever you’ve painted it in vertex-paint mode…
I need FBX to get the sim into Embergen properly (it’s completely broken for alembics WRT vertex colours at the moment), and be able to separate the shards into different smoke emitters (using vertex colours)…
At the moment I’m converting the FM objects into keyframed objects then exporting as FBX (from 2.9x), but Blender can’t vertex-paint multiple objects (bastard!), so you have to select the shards one by one and paint them one by one…
HI @Mark_Spink , I remember talking with Scorp about vertex paint and the FM and I think he did some experiments but that was a while back and I don’t remember what the results of his findings were.
Vertex paint has some of its own considerations that may not be handled in the FM’s code loop so it may not be a valid part of the workflow. I’ll poke Scorp and Kai and when they have time maybe they have some thoughts.
Frequently the FM compensates for blender short comings successfully and other times not so well and this may be one of them. You can always try grouping and empty hacks because sometimes they surprisingly work and are undocumented.
Keep us posted if you find a usable workflow. Until then…
Fracture ON!
Hello @JTA I’m sort of nailed down as Embergen only supports a single animated object import and only Vertex Paint with FBX objects at the moment (can’t read Alembic properly). So whatever I do it comes down to Vertex Paint being necessary to differentiate ‘bits that emit’ from ‘bits that don’t emit’, and as you can appreciate- manually painting a load of shards (as Blender refuses to vertex paint multiple objects) is somewhat tedious / would take a month!
I hope you can find something that works!
Or point me at a script / addon that can v-paint multiple objects once a fractured object has been converted to ‘multiple keyframed objects’…
Cheers!
I can confirm that vertex colors are not correctly supported by the FM. As a workaround you could try to convert the individual vertex color channels into vertex weights and convert them back after fracturing and simulation, as vertex groups are well supported. This requires some Python scripting though, so it’s not an option for everybody. We’ll check if adding support for vertex colors would still be feasible.
I want to paint after fracturing I’m afraid, so some shards can emit smoke/fire, and some only act as colliders…
Looks like I’m stuffed unless there’s a script to allow vertex painting multiple objects at once, or copying vertex colours to multiple objects after painting one.
Vertex painting on a mesh changing modifier isn’t possible in general, you can only paint on the source mesh. However, you could fracture your object and make an applied copy of it for painting. To make it work with animation you can export your original object’s simulation as pointcache file (.mdd / .pc2) and add the animation via Mesh Cache modifier to the painted object. Keep in mind that the pointcache format requires unmodified topology, so if you change your fracture settings in the future you’ll have to make a new copy of the fracture mesh as well.
Won’t work I’m afraid: I need an FBX to import into Embergen so I need to export from FM as ‘separate keyframed objects’ then convert to FBX: which seems only to support a bunch of separate objects, as in I can’t make a working FBX from an Alembic using a mesh-cache, so I’m guessing same story from a single MDD object.
Embergen can import Alembic but can’t read v-paint data yet, it can only import a v-painted FBX which can then use R, G & B to generate ‘masks’ for emission, as in you get a Geo out put (whole object), and 3 mask outputs. Then you can use the masks as discrete emitters.
Here’s an example of one I painted manually-
So- FM sim, exported as ‘separate keyframed objects’, manually/individually painted some of the larger shards (red) in 2.9x and exported everything as an FBX, then imported to Embrgen and used just the red bits to emit, and everything to act as a collider (geo output), then rendered with Embergen’s VDB in blender.
So I need to be able to select multiple separate objects in Blender and v-paint them all at once, or copy one objects vertex colours to multiple objects I have selected. That’s what I’m after.
Someone had the idea of duplicating the lot, painting it as one, then transferring the vertex colours back to the original separate objects, but I can only work out how to do that individually- so might as well just paint them one at a time!
I also found a script on stackexchange - https://blender.stackexchange.com/questions/192388/vertex-paint-for-multiple-objects-in-blender-2-8
But is seems to do nothing when I try it in 2.9x…
In fact I just tried the script again; it seems to be failing when trying to create a vertex colour attribute on the objects which have none. Any chance you can fix it?!? (I am just a humble Broadcast Engineer: no clue about Python!)
In fact: I found one (script for vertex painting multiple objects) that works!
@Kai_Kostack I know this is a tired old question, but - FM in 2.9x Blender, anywhere on the horizon ever?
I only ask as I now find out that the Alembic export from 2.79 has a somewhat fatal flaw, after a couple of days wasted rendering- https://developer.blender.org/T87587
Needless to say, the ‘ShatteredMoon05a.abc’ mentioned in this bug report was exported from 2.79b Fracture Modifier branch.
So I/we could really do with FM in something that can export uncorrupted Alembics as well as ‘separate keyframed objects’.
I think I may be getting somewhere with ‘separate keyframed objects’ exported then converted to FBX in 2.9x, but it is a bit of a tortuous workflow however you cut it!..
And the ‘Blender 2.79 still works’ argument is getting a bit lame now, with geometry nodes and a wealth of other things in 2.9x you can really use to good effect (mantaflow, adaptive sampling, CPU+GPU rendering, an arguably several 100 times better UI/UX, updated/fixed import/export modules, etc.).
Here’s a script that should work for you. Paste it into the text editor and uncomment the desired color before running.
Note: make sure only one color is uncommented at a time and use the correct one for your blender version.
import bpy
import random
import time
# the color to set the selected objects - uncomment the desired color or set your own,
# numbers range between 0-1 for each color channel
# 2.79 colors
#color = (1, 0, 0) # RED
#color = (0, 1, 0) # GREEN
#color = (0, 0, 1) # BLUE
# 2.9x colors
#color = (1, 0, 0, 1) # RED
#color = (0, 1, 0, 1) # GREEN
#color = (0, 0, 1, 1) # BLUE
# start in object mode
objects = bpy.context.selected_objects
for obj in objects:
mesh = obj.data
if not mesh.vertex_colors:
mesh.vertex_colors.new()
color_layer = mesh.vertex_colors.active
i = 0
for poly in mesh.polygons:
for idx in poly.loop_indices:
color_layer.data[i].color = color
i += 1
You Beauty! (Not an Aussi quite yet, just living there!)
I actually found one that works fine on here, but I shall definitely keep yours in a back pocket!
In fact I’ve just saved both to a couple of machines & a NAS!
Thanks for taking the time for a dumb non-python type…
