Snaps shots are quite useful, but it seems that it doubles the file size even though only things I use are camera location, layer, and hidden objects. Is this a normal behavior? The file was large to begin at around 400mb (imported from Revit). Now that I have about 4 snap shots, it jumed to +700mb.
Hard to imagine why. The same function is easily achieved in SK with scene saving. Granted, Rhino’s snap shot is much more powerful with more functions. But it seems like it’s copying the entire model duplicates inside the model even though I’m only using it for camera, layer, and hidden objects.
Search the forum for snapshot issues like these, there are plenty. The potential is great but it is extremely buggy. IMO it should be _TestSnapshot instead and send a big fat warning pop up to the user:
Backup your model before using snapshot! Use at your own risk! Potentially messes up your entire model in seconds!
That’s a bummer. We currently are trying to transition away from Sketchup, but saving views with hidden objects is so important. This thing along may cause people’s refusal to accept a different software than SK, and I would totally understand.
There is really seriously any other way? It seems like such a simple thing we are all used to too much, using SK.
Just deleted 4 snapshots. It came down to 450mb from 750 mb. How do other people deal with different scenes with hidden objects/layers?
I got the memory problems to. You could try a workaround - save you snapshots and save your project to a temporary file. Than open your previous saved project file and import the snapshot from the temporary file. If you save you project now your file size could be kept. But like Gijs sayed - be careful with snapshots. I hope Snapshot will be enhanced also for Rhino 6.
for this you don’t necessarily need snapshots, could do that with layerstate manager as well. For now that would be a safer bet. The only thing is that it will not save object/material states.
I work with V-Ray and found especially when creating things AFTER making snapshots, is particularly dangerous as it can delete assets when going to a snapshot that you created BEFORE making the changes.
We tend to create a lot of views with different hidden objects. I dont think layer state gets linked to named views? Every time users switch view, they have to select each layer state? Sketchup users, we try to transition away, will revolt. No scripts or grasshopper magic, i wonder?
No, but until McNeel solves the issues with snapshots I think this is the best way, layer sets + named views.
When moving to a different software you lose a few things and gain others, I think that you will gain way more than what you will lose switching to Rhino, just give it a little bit of time and ask here whenever you need. Also, try to adapt yourself to the Rhino way instead of emulating SketchUp’s workflow.
I’ve been one of the earlier proponents of Snapshots. If this tool worked it would be an awesome addition to our workflow.
Currently they are buggy and dangerous. So we only make snapshots to files when there’s no more design/modeling work to do. And when we are ok to completely destroy that file.
We see these main problems:
file size/memory and performance issues (they can get real slow to load)
we cannot add new content to files (new layers, new objects, edit objects in ways that object IDs change (like explode and rejoin with new edits) and have any certain of what will happen.
we cannot make changes and be sure if we are making the change globally or to a particular snapshot (why don’t we have a big red bar in the viewport telling us that we are in Snapshot editing mode?)
snapshots are not supported in layout mode. So we cannot load different snapshots to different details. Snapshots has one job: save and restore various states, and what’s the point of doing that if you cannot document it in layouts? …but layouts is a conversation for a different topic/year/rhino-version.
we have no way to know if materials that are not currently in use (but are used by a snapshot) and materials that should be purged
we have no way to add objects to already saved namedpositions states in snapshots. @pascal worked out a scrip to fix this, but it’s still too confusing and risky to use.
no output of all snapshots as images or animations (@nathanletwory did write a great script for the images export, it should be part of the built-in functionality)
previews don’t work so you save snapshots and have no way to visually know which one you already saved, or choose which one to load again.
…Feel free to add anything else to the list. We are so scared of them that we used them very sparingly so we have not uncovered all its ways of betrayal
This tool has never lived to its potential. It was never designed or coded with the level of attention to execution and follow through it deserves, especially when it comes to Q&A and testing, something that McNeel continually expects us the customers to do. The problem here is that it’s such a work-wrecking tool that no one will want to put any effort into it.
Snapshots needs a lot to work from McNeel to be useful, reliable and stable. And only then, they will be awesome. I’ve been asking for this for about 15 years, since I started using NamedViewManager script (I believe was from @ThomasAn_?), including giving a live demo at a lecture in Colombia in 2014 where I showed live changes of design and configuration variants all running in a live Rhino session using namedviewmanager and the audience loved it, Bob and Don Andres Senior were there, so it was a bit of activism on my part when I told the audience they could all have this if they told Bob and Don Andrés they wanted it. So this shows you how long I’ve been a ‘Snapshots Activist’.
Snapshots will be absolutely great, but right now they aren’t. They are a great idea very poorly and partially executed, and with zero regards to content integrity and safety.
McNeel team, are you aware of this? Where do you see it in terms of importance and priority of effort?
Thx,
Gustavo
PS: The activism will continue until Snapshots improve.
PSS: I edited my poor grammar and poorer iOS auto-correction
Thanks @gustojunk for this extensive write up. I think you covered all I experienced and more before I decided to stop using snapshots. Honestly I think it should be removed from Rhino until the model and material destroying bugs are solved.
I myself don’t enjoy using SK, so I don’t have a problem. Other people in the office, not so much. It’s incredibly hard for people to change something that they are already used to. That’s especially when something simple they kept using is not available anymore. At that point, all other goodies are out of the window.
I have no idea how complicated the fix will ultimately be.
The developer is on annual vacation as the more civilized European countries so, but it is on his list.
My guess is the fix may be too risky for V6, but is targeted to be fixed before V7 is initially released.
A Snapshot in Rhino 6 includes the whole document, meaning everything Snapshots supports like materials, layer states, object positions etc. The idea was that even though you only selected the layer states at creation time of a snapshot you could later go and edit the snapshot and enable lets say the materials too. That has the benefit of not losing data but has the side effect of increased size. We have changed that in Rhino 7. Rhino 7 only saves the information the user has chosen during the creation of a snapshot.
Try Snapshots in V7. The memory will go up some but not as much.
You can release that with ClearUndo.
Thank you. That sounds better. Since Enscape doesn’t support WIP 7, I only use WIP 7 for revit integration (then save down for 6). Hopefully 7 becomes official soon.
I’m attempting to use snapshots to save a series of images with their respective layer states for export. The model is virtually unworkable now – very slow – as opposed to simply using named views. I do not know the reason for this but it is a simple massing model (which I cannot share due to non-disclosure agreements) and this behavior is highly unexpected.
It is an architectural model (using feet at an urban scale).
This is an attempt to export a large series of images that illustrate an iterative process without having to manually adjust layer states or create sheets every time a new view is needed.
If there is a best practice workflow for something like this (which is a very common procedure) please let me know.
