Snapshots plugin prototype in the latest WIP

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.

Please post bugs, questions, and wishes here.

Thanks.

20 Likes

WOW! Thank you. I haven’t tested it yet, but if this is what it seems to be, it’s going to be a very welcome addition to Rhino.

Good idea!!!

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.

1 Like

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).

1 Like

Great idea. I would find it helpful to add Sun position in the saved properties set, ad well as ClippingPlane states.

thanks!

–jarek

4 Likes

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.

Cheers.

4 Likes

Definitely a good idea. + 1 or customizable data stored.

Also, ability to import Snapshots from other file (like NamedViews) would be helpful in a long run.

3 Likes

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:

    1. _SetObjectDisplayMode state of objects
    2. 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 :grin:

G

1 Like

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.

Thoughts?

  • Andy
1 Like

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…).

1 Like

Hi @andy,

I need _NamedViews for certain optical purposes!

What I’m missing is the functionality to save custom Object Display Modes.
Often I use SetObjectDisplayMode to make things more clear in illustrations…

Thanks,
Jess

1 Like

Jess

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.

  • Andy
3 Likes

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?

G

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.

–jarek

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.

1 Like

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.

2 Likes

A good and long awaited development!

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.

Holger

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.

  1. 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 ?

  2. 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.

  3. 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.

  4. 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.

Cheers,

–jarek

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.