We added a new plugin to Rhino called Snapshots. It is similar to the Named Views or Named Positions. Currently a snapshot contains a Named View, Named Position and Layer State. We can extend this in the future to include other properties like an environment, clipping planes etc.
To get started run the Snapshots command which will bring up a dockable panel.
Often I have scenes where I need to show different material setups. I use object copies at different layers. Could be great if materials would be snapshoted. I use per object assigned materials, but other users prefer layer assigned mats. Could be nice to get both.
Unglaublich! This is going a wonderful add-on!
My first idea would be to pair it with the batch-renderer of some plugins. With that we could produce images for many different alternatives without forcing the batch render to open and close files of several hundred MB (my case in the last months).
My two cents idea: why not let the user decide what he wants to store in the snapshot in the same way it can decide what properties to match with matchproperties?
The âstorageâ procedure should remain âmostly the sameâ, only changes the command that the user runs when he wants to store a snapshot. In that way every user can personalize how to use it using macros.
hi @lars, this is exciting! Iâm glad you guys are tackling this one.
in case you havenât seen it I talked about whatâs needed here:
What I had listed at the time was:
Views
Material assignments
Layer visibility
Object visibility
Curve Shutlining on/off (important for design variations)
Named position
Active clipping planes/Section views
Active foreground/background images
Grasshopper configuration states
âŠI would also add:
displaymode
and more importantly two challenges about displaymode:
_SetObjectDisplayMode state of objects
overrides of visibility in the display panel (like curves of/off, show wires, transparency, etc)
In terms of management I want to be able to reorder them manually and duplicate them. If I rename âsnapshot 01â to âcoolview1â shouldnât the named views/named position/layer state generated at saving âsnapshot 01â be also renamed to âcoolview1â ?
Also a playback button to go from previews to next would be nice. Especially for presentations. even an autoplay with a timer. Can you make smooth transitions between them?
Can you load a snapshot in Layout view and maintain it persistent in a layout viewport.
Last thing: can you export snapshots as screenshots or files (like Step/STLs)
OK, I better stop this should be enough work for a few days
My main question to you guys about this feature is this:
Should we completely ditch named views/positions/layer-states and replace all of that functionality with Snapshots?
There are some disadvantages to doing this - at the moment, you can have multiple snapshots which refer to a single named position/state/view - and if you update that view/position/state, all of the snapshots also update. I guess it will also mean that users who are used to using NamedViews will have to learn something a little bit more complicated.
But the advantage, of course, is that the whole snapshots thing is less cumbersome.
Snapshots feel a bit strange at the moment - itâs a state manager managing state managers. I can think of a few scenarios where what you take as an advantage of the current workflow is actually an advantage indeed but can also think of scenarios where changing a named view also changes it in all snapshots.
In my mind, a snapshot takes a picture of the current situation (with the option to uncheck certain state-types if one needs) and doesnât need one to dig into linking different layer states with different named view and different named positions.
I vote for getting rid of named views, positions, layer-states and see how that goes. (Donât throw the code too far awayâŠ).
What Iâm missing is the functionality to save custom Object Display Modes.
Often I use SetObjectDisplayMode to make things more clear in illustrationsâŠ
Yup - Iâm not suggesting getting rid of Named Views per-se. Itâs just that a named view would become a snapshot where only the view information is saved.
I think for basic use having snapshots as only-main interface makes sense. But I see cases (my most common use) where I want to have snapshots capture design changes (based on layer visibility), motion (based on named positions) and colorways (color/material/finish variation) based on material assignment. âŠin all those cases I will want to see it from a common named view like (persp-front), then also see it again on a different view (persp-rear) and maybe a front view. Ideally I would even set my workspace to 2 or 3 viewports filling full screen and playback my variations of snapshots. Makes sense?
I think we should keep NamedViews as-is unless Snapshots clearly can get to the development level that we can smoothly get rid of it. Apart from one of typical scenarios Gustavo mentioned (many design options from the same viewpoint) it also will add unnecessary complexity if you just want to work with views (which we do a lot, without touching the layer states, positions etc.). Yes, perhaps it is OK to just save named view, but there is a potential to âby accidentâ save or restore other features and mess things up. The UI for universal âSnapshots onlyâ mode would need to be darn good to get rid of LayerStates, NamedViews and NamedPositions. We also have tons of scripted tools utilizing them and using scripting methods related to them that our workflow heavily depends on, so this would cause major disruption there.
I vote âNoâ for getting rid of of the individual modes. Snapshots could be a great addition, but not a replacement.
Maybe it would be helpful to get a table UI and the user can click per right mouse button on a set and update this only. Attache a raw description screenshot.
For example at Snapshot 3 I could update the materials only.
Yes, I think thatâs a good idea, and will avoid duplication.
I donât see why you would need to have different views and layer states setup independently, when there could just be a series of snapshots. Assuming setup and saving snapshots is as easy a NamedViews.
Feels similar to how Bongo works. If there could be integration with this for Bongo, it could help simplify setting up animations massively.
The current Snapshots implementation allows users to combine various pre-existing âstate-saversâ. It however may also get used in the traditional way â to store just a single property. If one kept that approach I would find consequent to get rid of child editors. Snapshots makes them redundant while being equally straightforward to use.
If one however preferred to to keep Layer States, Named Positions separate panels one might also think of alternative ways to allow users to work with (multi) property variations within a single file.
A very powerful option was implementing something similar to what Blender calls Scenes (similar concepts do exist elsewhere). Scenes allow users to create any number of alternative file versions within just a single file. One may chose to start a new variation with independent copies of pre-existing scene members (geometry and /or parameters) or can reference all or some of them. The system offers nice control about further developing scene members as unique objects and sharing objects and any number of properties across Scenes. @nathanletwory sure can give you all specifics on this.
Hereâs the Blender Manual chapter on Scenes.
I didnât find a good youtube-clip explaining the feature, but this one shows the basics.
My gut feeling is that it was easier with Scenes to manage Setup-variation which also involve node based editing with Grasshopper / Cycles Render Nodes etc.
Something else which I believe deserved the name Snapshots was somewhat more focused on geometry development. Rhino isnât parametric and also itâs History implementation has tight limits. We all know that some operations, such filleting and shelling are destructive.Unless the user was smart enough to create copies of input geometry one might end up with painful reconstruction of the unfilleted object state.
If Rhino learned to keep a list of all operation which contribute to the present appearance of objects (> undo selected on steroids) and learned to save this list with the file one might be able to scrub through this per object Undo list and create named Snaphots â a kind of keyframe in the part generation process â and develop object variations from here.
I played a little bit with the current version of Snapshots, so here is some more thoughts on it and @andyâs poll on getting rid of the NamedView,LayerStates and NamedPositions.
The way it is currently implemented it seems like the Snapshots are just a nice UI that ties together the NamedViews, LayerStates and NamedPositions - actually either adding new ones to the respective lists or letting user assign selected ones from each list under specific snapshot name. In this case, to get rid of them would mean a complete change of how it is now implemented, right ?
I thought Snapshots (Scenes?) would store all of the info (current 3 categories + potential many more - Sun, ClippingPlane States etc.) in its own database, independent of existing NamedViews, LayerStates and NamedPositions. In my opinion it would be the best solution, keeping the current workflows intact and adding a powerful and more complex tool.
Currently in many cases we would have say 5 views and 5 design options represented by LayerStates. Does it mean if we get rid of the current setup we would need 25 Snapshots? Yeah, we can create 5 Snapshots with View only and 5 Snapshots with LayerState only, but that kind of defeats the purpose - then we need to start paying attention to name all of them accordingly not to get confused-- I can see how on complex files this will get overwhelming and complicated. In that case you may right away start considering adding âFolderâ structure to keep things better organized and not end up with a list of 100s of items that are a mix of views only, layer states only and snapshots that store a mixed input. This complexity would not be necessary if you keep the current NamedViews etc intact, and just ADD Snapshots.
Scripting: would you make all the methods currently dealing with NamedViews, LayerStates etc. obsolete then? And introduce new robust methods to get/set/edit and dissect the Snapshots to compensate for it? Seems like a lot of work and redoing a lot of current scripted tools. Another reason why I would not get rid of the current categories. Obviously we will ask for scripting access to Snapshots but as an addition, not a replacement.
I donât think so. I would assume it would just hide the functionality of the individual commands - making them accessible only through the new SnapShots.
If it were truly independent, than I would agree that would be a viable (maybe even best) solution. In that case, a SnapShot wouldnât give you access to picking from existing NamedViews or allow you to make new ones. A SnapShot would just take the current status of the (selected) categories and save that as one SnapShot.
Iâm not following this example.
Do you have 5 different views that shall be used for each and every design option or is there one view per option? If it is 5 x 5 and you want to access each of those in the current system (no SnapShots), you will have to manually set the 25 solutions (pairing 5 views and 5 layer states) - this would be quicker if selecting each of 25 SnapShots.