Im attempting to fragment a series of objects, to run through pflow and create an explosion sequence. Ive been following charleycs really excellent tutorial on the subject, and had some success as far as breaking up the object goes.
Where I have trouble is in attempting to break things up into chunks of geometry with a volume rather than thin-shell fragments. The algorithm Im using seems to work the first pass through, and generates a single solid fragment; however, it screws up the copy of the geometry Im subtracting from such that it is no longer a nice airtight mesh. All subsequent subtracts behave as if it werent a solid object, and give me thin-wall fragments.
The problem seems to be that the subtract operator functions destructively. The fragment is formed by the intersection of [MeshToSubtract] and [MeshToSubtractFrom] (which is initially a copy of the base object). This volume is then removed from [MeshToSubtractFrom]this way, if my various cutter objects overlap, the overlapping volume will only be generated once (the first time it intersects MeshToSubtractFrom). If I dont do this (and instead take the intersection of the object and the base mesh), I get the chunks Im looking for, but a lot of z-fighting and large overlapping sections.
Trying various workarounds on this has been holding me up for about a week now, and Im about ready to give up. Im hoping someone at CGTalk will be able to suggest something that will help me resolve this problem.
The relevant code is:
MeshToSubtractFrom=(Copy BaseMesh)
Subtractors = $Mesher_Fragment* as Array
for i in Subtractors do(
MeshToSubtract=(Copy i)
Temp = copy MeshToSubtractFrom
MeshToSubtractFrom - MeshtoSubtract
MeshToSubtract * Temp
Delete Temp
)
meshToSubtractFrom = copy basemesh
subtractors = $Mesher_Fragment* as Array
for subtractor in subtractors do
(
--get the intersection of the subtractor with the basemesh
result = (copy subtractor) * meshToSubtractFrom
--now modify the basemesh so we don't get intersections where it has been subtracted already
meshToSubtractFrom - subtractor
)
hide basemesh
hide subtractors
Your biggest problem is the lack of code readability and comments. When you are approaching a problem, write down in comments what you need to do. Then under each comment, put the line or lines of code for how to accomplish that.
So for example, the outline looks like:
–booleans are destructive to the first operand, so we need to operate on a copy
–get all the mesh fragments
–for each fragment, we will…
–get the intersection of the fragment with the basemesh
–modify the basemesh by removing from it the fragment we just took out. This is so later, overlapping fragments don’t take out the same volume.
–hide the original objects
Obviously this is not needed for each line of code when you get better at coding, but it is an important step when learning how to code, or do anything for that matter.
In contrast, the logic of your original script was more superfluous and ultimately wrong.
--booleans are destructive to the first operand, so we need to operate on a copy
MeshToSubtractFrom=(Copy BaseMesh)
--get all the mesh fragments
Subtractors = $Mesher_Fragment* as Array
--for each fragment, we will...
for i in Subtractors do(
--copy the fragment
MeshToSubtract=(Copy i)
--copy the basemesh
Temp = copy MeshToSubtractFrom
--subtract the copy of the fragment from the basemesh
MeshToSubtractFrom - MeshtoSubtract
--get the intersection of the copied fragment and the modified basemesh
MeshToSubtract * Temp
--delete the copied basemesh
Delete Temp
)
If you were to work through that code, you’d see it doesn’t really make sense nor accomplish what you want it to do.
Rob, thanks for the feedback, I appreciate it (I’ve also been reading your stuff at Tech-Artists.org– very neat). You’re definitely right to say that my documentation should be better, particularly where I’m presenting it for someone to look at. I’ll adjust my practice going forward.
However, in this case, I think you may be mistaken about the nature of the problem I’ve been experiencing. The code you suggested, while somewhat more elegant, produces the same results as the script I’d been using: the first iteration works smoothly, producing an intact, airtight chunk, but renders MeshToSubtractFrom a shell with a hole in it, making all the subsequent intersections thin-shell fragments.
With further testing, I think this actually has something to do with the topology. When I attempt to use a simple cube as the base geometry (with either version of the script), it actually loops properly multiple times before ruining the base. I haven’t been able to isolate what’s causing it to break down, unfortunately.
Try doing it by hand and see what results you get. I am inclined to believe this is a boolean issue- you may want to look at ProBooleans instead. But I don’t ever work with Booleans, so I can’t be more help.