New rules for object History

It seems to me that the rules for Object History are different in the Rhino 8 WIP than in Rhino 7. Is that true? If so, what are they now?

As far as I know, up through Rhino 6, the rules of history did not change:
· Turn on History
· Make an object
· Create a copy (child)
· Move the parent alone, child updates.
· Move parent and child together. History is broken.
· Move child alone. History is broken.

In Rhino 7, you added the feature that when you move a parent and child together, this no longer breaks history. While this was kind of neat sometimes, it also caused some very unexpected results. Please note that this change only applied to the Move command. Doing any other command (Scale, Rotate, etc.) to the child and parent at the same time will still break history.

Now in the Rhino 8 WIP, this behavior has changed again. As far as I can tell, it depends on what tool is used to create the child, in addition to what tool is used on the child.

If you use Copy to create a child, then moving the child and parent together DOES NOT break History. If you use any other tool (Mirror, Polar Array, etc.) to create the child, then moving the child and parent together DOES break History.

Is this an accurate description of how the rules work now? If not, please elaborate. It seems like you are trying to ameliorate some of the unintended consequences of the change in Rhino 7, but making it unnecessarily complicated.

In my opinion, the rules for History have gotten more and more muddled since Rhino 6. In 6 and before, History was controlled by one factor, not working directly on the child objects. In Rhino 7, it is controlled by a combination of not working on the children and/or only using Move on the children with the parent. Now in Rhino 8, it’s a combination of not working on the children, only making children with Copy, and/or only using Move on the children along with the parent.

All of these exceptions to the rules of History make it difficult to keep track of from one version to another. More importantly, they also make it very difficult to explain History to our new Rhino students. Please bear in mind that many of us (particularly in the jewelry industry) use History all the time on everything. We leave Record History on all the time as a default and use it to great advantage in our workflows.

Can you share with us a clear description of what actions will break history for Rhino 8? Is this a moving target?

Thanks!

  • Mike
1 Like

Hi Mike -

The short answer to that question is “yes”.
As long as users request new features or report “bugs”, things will change.

While, from a user’s point of view, things might simply boil down to some “rules”, this is not how a complex piece of software like Rhino is developed. There is no such thing as rules in the code that commands just point at.

From digging into your description of the current state in the WIP, it looks like an entirely new option was added to the WIP to provide mirror history by using an object. The request for this new feature specifically states:

[…] and propagate the same mirror with History relationship by copying the inputs to a new location.

Notice the “copying the inputs” part.
It doesn’t say “copying either the inputs or inputs and outputs”.
… and that’s what the developer added.

As you report, that new feature unintentionally broke some previous behavior.
I’m afraid there is nothing in place that reliably catches all such occurrences when new features or bug fixes are implemented and we - like it or not - rely on feedback to be able to fix these things when they happen. We have the WIP system in place to be able to minimize the fall-out from changes in a new version. Thanks for using that process!

RH-72646 History: Moving history-mirrored objects breaks history
-wim

Hi Mike -

It appears that this change was by design…
-wim