here a logical bug in boolean intersection with history.
Basically, History works when only the source objects are moved after the operation, but not the created object. This is fine.
The created object inherits the properties of the first selected object while the operation is being performed. If you select the red cube first, the end result is red, otherwise it is blue. OK.
But there is a problem with the inheritance when the initial objects are animated. Actually, this should not be a problem if the animation data were not inherited. But they are inherited and this destroys the history function.
Here is a simple example. Please try selecting the cube first. When the slider is moved between 0 and 20, the history is destroyed. It is even worse if the ball is selected first for the BooleanIntersection, then the resulting object moves with the ball.
Mich,
I managed to make working model [Test BooleanIntersection Animation 001.3dm|attachment]
The trick is to animate de ‘first’ object after the execution of the BoleanIntersection. So:
first animate the ‘second’ object (ie the blue sphere)
then BoleanIntersect - History enabled - with the ‘first’ object ‘ (i.e. the red cube)
finaly animate the ‘first’ object.
Using Rhino’s move-command on the ‘first’ object in Animation mode will break the History, but all other Bongo animation techniques BongoScale, BongoRotate, or BongoAddKeyframe and even BongoMatchAnimationProperties leave the intersection free from animation-data and maintain operational History.
Thank you Luc for taking the time. Interesting workaround. (Only I can’t play the video.)
I have extended your workaround a little. Since my full animation is already quite long before the critical point, I don’t want to repeat this part again. But in the test file I was able to transfer the animation data via _BongoMatchAnimationProperties to another object and delete the data from the red cube. Then I applied the boolean intersection and got the animation data back via _BongoMatchAnimationProperties. It worked.
@Joshua_Kennedy should fix the problem anyway. Animations are often quite complicated as it is and I hope a workaround can be avoided in the future.
Unfortunately at my full animation I loose the history again.
I have now simplified things for the calculation. I leave my animation as before and when the animated clipping comes, I switch to a layer with a copy of the object (without animation data), which I only use for the clipping sequence. So I can be sure that it doesn’t break again.