Keeping history of the changes after saving

So when I save a design and then go back to it another day I cannot undoe changes I made.

In Fusion 360 it keeps all the history so you can go back to a point in the design and change it, is there a way to do this in Rhino.

Hope this is clear :grinning:

1 Like

Nope. Rhino is not parametric/history-based modeling.

:disappointed_relieved: :disappointed_relieved:

i wonder how much it would take to save the undo list in the file, maybe even specific to an object. sounds feasible by the idea at least. is there any scriptable access to the undo redo list? i have a faint memory of this being asked and discussed somewhere, not sure what the outcome was, but rather not good i suspect.

I do not think the undo stack is currently directly exposed to possible scripting in RhinoCommon.

It would be fragile at best - all you could theoretically do is go back to some previous state, but you couldn’t modify anything and go forward again. Plus it would most likely make file sizes immense.

IMO, given how Rhino works, of questionable utility.

yes that takes up some space. which why i disabled the versions. also i never created anything that can not be reversed with a few clicks. still sensitive complex projects should be saved after each iteration till the design process has elapsed, and best before you screw up an important object, duplicating it onto a new layer can be even done with a simple macro.

the question would be, what could possibly be complex enough that is irreversible. things like FilletEdge which could be a pain to change, are now even connected to history.

idk but saving the entire undo list in the file does not sound like a terrible idea.

Well, yeah, but only if you don’t modify the object in any way afterwards. If you do, all history is lost.

1 Like

yup, but changing a filleted object sounds like masochism already :smiley: i would never attempt that.

You can keep the basic model in a separate layer and apply fillets on a new copy. :slight_smile: That way, you don’t need to worry about removing fillets, because you have a back-up copy hidden into another layer. However, that will increase file size.

On top of that, “Snapshots” (accessible via the Properties panel) allows you to save different positions of the selected object(s), including optional camera views. It can be applied to operating doors, windows and anything that moves in different positions and is especially useful for presentations.

1 Like

Saving versions while I work is one of the big reasons I find myself using a Mac OS more all the time. Set up a dedicated storage drive like a Time Capsule and Mac OS will use Time Machine to automatically save versions of your work at user defined intervals.

1 Like

My understanding is “Undo” and “History” work in fundamentally different ways in Rhino.

Undo does not work by Rhino reverse calculating the changes to geometry. After each operation Rhinos stores in an “Undo stack” in memory a version of any geometry which as altered, and keeps that information until the amount of memory available for Undo is filled. Once the Undo memory space is filled the oldest Undo information is deleted as needed to make room for new information, This Undo information is in additon to the current geometry data. When Undo is executed Rhino then uses the appropriate information from the Undo stack to replace the current geometry information. If the Undo stack data was saved during a .3dm file save then when a .3dm file was openned the undo ability would be the same as when the file was save. Again, this is my understanding and could be completely wrong.

Saving the undos is a system that exist in other software.
Zbrush makes extensive use of that functionality [user can choose if to save the undo list, and how many. but since it saves a separate undo list for every object, file size quickly swale [a 5gb project file for 1 ring is normal at some point in design development] So it’s a question of balance between the penalty of file size, and the benefit of keeping the undo list.

One can always choose to purge the undo list from the save and get back to small file size.

I wish this would be added to Rhino, I have requested this in the past, and it may even be on the pile…


It depends on the type of geometry. For example, I do a lot of control point adjustments and some more complex surfaces could require more than 100-200 fine tune adjustments with the “UVN move” tool until they gets perfected. The file size would get extremely high if Rhino has to save every iteration of the surface.

Maybe there can be a way [like a “smart undo save”] that let the user exclude certain types of commands [like CP manipulation] and only save to the file undo bigger steps …?


The user can set the maximum amount of memory t be used for Undo:

Options > Rhino Options > General > Undo > Max memory used (MB)

Rhino for Windows has the IncrementalSave command, though it does not execute automaticaly.

Long ago I adopted the practice of adding a two, three or four digit number to the end of file names. Periodically and after major steps or several major steps I Save, and then immediately SaveAs with the number incremented by 1, or to the next 10 or 100. Occassionally I go throught he directory and discard old file versions I am confident I no longer need. The numbering system also has the advantage that if I share a file with someone it is easy to determine which version they have.

1 Like

I add a simple date format at the end of my files, such like "Left fender - 17_2_2021.3dm, “Left fender - 21_2_2021.3dm” etc. This way, I save a new file for each day I have been working on the project, and it lets me easily go back to a certain older version to see if there is some basic version of a 3d model that I want copy to the newest file when I need it. It’s a good way to have a back-up, because sometimes unwanted mistakes happen and I could accidentally delete or move an object that will be only recoverable if I import it from an older file.

1 Like

For dates on files, etc. I use a year-month-day format so that sorting on name is is sequential with date. For example 2021-02-21. Then if I also have versions 2021-02-17 and 2021-01-31 a name sort will result in:




1 Like

I rely on the date sorting of Windows 10, which is very convenient. This is why I use a day_month_year name format. :slight_smile:

No… When you close the Rhino, the memory and everything in Undo command will be cleared.