Record History

Hello everyone,
I was wondering about the evolution of “record history”, how did it start etc…
and what is the link between “record history” and grasshopper?
I have read somewhere that record history was the initial parametric programming of Rhino until it got shaped in GH.
Any thoughts \ documents ?
Thanks :slight_smile: !

Hi Leyla - none, really - they approach the thing from opposite directions - Rhino records the history from the geometry and GH builds geometry (or whatever) from pre-made history, as it were. History in Rhino did come first, I guess, but honestly, I do not recall - things were developed in more or less at the same time period but independently.


“History” goes back to at least V4.

History has elements of parametric behavior, but I would not consider it as parametric programing. From Rhino Help for History History | Rhino 3-D modeling

The History command stores the connection between a command’s input geometry and the result so that when the input geometry changes, the result updates accordingly.

For example, with History recording and Update turned on, a lofted surface can be changed by editing the input curves.

History only works with “History enabled” commands. Scroll down in the Help section linked above to see the list of History enabled commands.

History in Rhino has some characteristics of parametric CAD but also some significant differences. Objects can be linked other objects with the dependent objects changing when the original input geometry is changed. This can result in multiple levels of linkage. For example object B is created or modified using a History enabled command with object A as input, and then object C is created or modified using a History enabled command with object A as input. If subsequently object A is modified then both objects B and C will update, assuming History has not been broken.

Rhino History does not allow any explicit linking of objects after they are created.

Rhino History does not use any parameters, such as diameter of a circle or length of a box.

Thank you for your prompt reply Pascal,
Yes , I am aware about the difference between both in terms of how they build the geometry, I was wondering about how record history can work based on a set of objects and work out the relation in between… which can be kind of “parametricised”
I wish I can find some documentation on the detailed process of Record History, and why they introduced it… etc.
Thanks again :slight_smile: !

See the Help file I linked to above. My impression was History Rhino originated because it was possible to add the History feature for a few commands without major modifications to the structure of Rhino. With each subsequent release of Rhino additional commands have been History enabled.

I initially always had History enabled with Updates turned on. Then I discovered that objects would be unintentionally changed when other objects were modified. I now rarely use History.

Thank you David !
I checked that link already, was looking for something more detailed and technical! but your reply is very helpful!
thanks again :slight_smile:

Videos about History:

Thanks tons!

Lelya, if you are looking for information about how History is coded, internal data structures, etc I doubt you will find anything. McNeel is careful to protect the internals of Rhino beyond what they provide for developers of plug-ins and similar. My very limited knowledge of how Rhino works is based on observation, experiments, very occasional comments by McNeel developers on this forum, and general knowledge of NURBS and related.

Yes David, I noticed…
I needed this information for an academic research …
But well, it is what it is !

The original developers of Rhino are retiring fast around now, but @dale could probably supply some interesting details about the history of the history feature, the motivation behind it’s development and some general, non-proprietary info on how it works. If he’s not too busy. :slightly_smiling_face:

I see that @dalelear, though retired, is still on this forum. Maybe if he’s getting bored just sitting around the house reading Facebook and Twitter all day he will chime in. :grinning:

1 Like

Thank you for mentioning him!

I added the original Rhino history in something like V4.

The original scope was to automatically “rerun” commands when input changed. Like many things, as time progressed, the feature was used to perform some tasks it wasn’t designed for - sometimes working well and sometimes failing miserably.

The concept was simple.
When any command runs it can optionally choose to be “rerun” if an input object changes and to store the object ids of the input objects, any additional information it chooses to save, and the ids of the output objects. There are SDK tools to handle the mundane tasks of saving this information and the core automatically handles calling the “rerun” code at an appropriate time.

If an input object in the model is replaced (modified by an editing command is a common case), the original command is informed and the command’s “rerun” code can do whatever it wants. Typically the “rerun” code uses the stored information and attempts to recalculate the outputs. If that recalculation is successful, it replaces the original output objects with new output objects.

Expert developers can use this feature in a variety of ways and they have done so in the decades since the original feature was added.

Typically, the most challenging tasks for a developer who is not trying to do something too fancy are:
1.) Structure the additional information so that the recalculation code can determine if is is reasonable to attempt to recalculate the output objects. Challenges include dealing with missing input objects or input objects that have dramatically changed forms or geometry types.
2.) Determine what parameter values should be used during the recalculation.
3.) Gracefully handle complex cases when the recalculation changes the number of output objects.

The history “graph” is a directed acyclic graph. (No “A changes B changes C changes A” kind of stuff is permitted.) History and Undo were designed to automatically work together so that if a history update makes a mess of things, the user can simply run undo, turn of updates, manually update, and everybody can get on with their lives.


Hello Dale,
Thank you you very much for your clarification.