Snapshots plugin prototype in the latest WIP

v6-presentation
v6

(Miguel Villegas Ballesta) #4

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


#5

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

thanks!

–jarek


#6

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.


#7

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


#8

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


(Gustavo Fontana) #9

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


(Andrew le Bihan) #10

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

(Wim Dekeyser) #11

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


#12

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


(Andrew le Bihan) #13

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

(Gustavo Fontana) #14

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


#16

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


#17

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.


#18

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.


#19

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


#21

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


(Wim Dekeyser) #23

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.


#24

In that case, what is the benefit of hiding them? I only see less flexibility of how we choose to use Rhino

Yes, in this example each design option needs to be shown from several exactly same views. In current system the ‘speed’ of setting them manually may be comparable to picking each of 25 snapshots, but: a) I have only 10 items to deal with b) I can easily change adjust single view of design option without a need to update 5 snapshots. c) easy to script with no need to set manually and much less clutter and combinations to manually create.
Also, keep in mind these numbers grow quickly with more options… The Snapshots list for all what may be needed and is currently well taken care of by the separate combos may grow very long and confusing quickly.

I am all for well working snapshots, but against getting rid of the current flexibility.

Yes, that’s what I am hoping for.


(Gustavo Fontana) #25

Hi @lars , I used snapshots in a real project/deadline last night, it’s very helpful already and I have some things to report.

  1. When you create a new Snapshot the tool is not defaulting to the saved view of the active viewport, but rather to an older saved view on the file.

  2. When I’m in the modal dialog to choose my NamedView, NamedPosition and LayerState (also like the screenshot above) I should be able to see (and edit) the name of the new snapshop name I just entered. After you have a few of these you can get lost really easily otherwise.

  3. When loading saved snapshots I notices that the saved view or saved layer state assigned to that snapshop is not loading ( I can’t confirm that saved position was not loading). After trying a few times loading more snapshots (double-clicking on the Snapshot panel) the eventually started loading.

  4. Somewhere along the way all these new ‘copy’ versions where created automatically. I think it happened after I modeled a new part, but I can’t confirm:

  5. I have a workflow issue that I think needs a bit more transparency of what’s going on. I’m using a combination of layers and named position for each of 4 concepts. Then using two saved views to show these 4 concepts. The logic is as follows:

I would like to be able to see/control/edit the following:

5A. Be able to see which view is associated in each snapshot. That’s my current use-case, but for others might be layerstate/namedview.

5B. If I delete a snapshot (like I did to those ‘copy’ ones that created themselves), I’d expect to delete any other items that snapshot had created, so these named positions seen here should go away:

5C. I want to be able to edit the name of a saved snapshot (as you can see I have a few typos). I can do that today, however I would expect it also renames the associated named views/positions/layerstates. For example look at how that did not happen when I renamed my snapshot 02:

That’s all for now, thanks! Let me know if you have any questions,

G


#26

Thanks for all the feedback. We felt we needed to change the core before adding new features. The changes in the latest WIP are:

  1. Saving a snapshot will not create a named view, named position and layer state anymore. The snapshot itself contains the information of the current states. It will also not ask anymore which properties to save.
  2. Restoring a snapshot will allow to select which properties to restore.
  3. The editing of a snapshot got removed.

We are at an early development stage and the file format might change between releases.