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.
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.
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.
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:
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:
Thanks for all the feedback. We felt we needed to change the core before adding new features. The changes in the latest WIP are:
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.
Restoring a snapshot will allow to select which properties to restore.
The editing of a snapshot got removed.
We are at an early development stage and the file format might change between releases.
If an object is copied out of a file containing saved snapshots and pasted into another (or export selected), the new file contains the saved snapshots in the table, although they don’t actually work in the new file.
testing the new version of Snapshots and have a suggestion - currently seeing the checkboxes dialog on every restore seems to be getting in the way of quickly working with them. At the same time Righ-click Edit Snapshot option does nothing (a left over from the old version?).
It may be useful to have the checkboxes and their states remembered per-snapshot under Edit menu, and Restore (or double-click) would simply restore the Snapshot based on its remembered checkbox states…
Even better if the panel could also have a visual indication (columns with checkboxes) indicating the current ‘properties’ checked per-snapshot.
Looks like you have addressed the suggestions already before seeing them - works nice!
I like the fact that the Snapshots remember the visibility of the objects as well (hidden vs.visible). With that:
a) not sure which parameter controls that - I would think that “object state” could be its own parameter, and include “locked” on top of hidden and normal/visible
b) currently once an object is locked, it fails to get ‘hidden’ in a Snapshot that was saved with it hidden.
Sun position settings would definitely be a welcome addition to the properties list.
I am yet to test how the Snapshots functionality behaves with really large and complex scenes, with tons of materials and objects. Curious to see if there is any lag with save / retrieve all of the settings. I will report once I get a chance to test.
And to nit-pick, maybe the RestorePartial Icon next to restore instead of “Delete” makes more sense?
Really like the direction this going towards. Soon enough will be asking for scripting access to its functionality : )
[quote=“Jarek, post:34, topic:41560”]
I am yet to test how the Snapshots functionality behaves with really large and complex scenes, with tons of materials and objects. Curious to see if there is any lag with save / retrieve all of the settings [/quote]
In terms of large and complex scenes I am actually pretty sure that Scenes were easier to handle. Has anyone at all asked @nathanletwory how this works in Blender? Most technological foundations should already be there – one could also think of this as a more modern and integrated version of worksessions.
What I see as as a possible bottleneck in the Snapshots concept is the Layer Manager, which remains unchanged. If you in later versions even give us an Editor which lists Scene members on Item level (which should be on the wishlist for > a decade) handling vast scenes might get more cumbersome and likely also more computationally intense than necessary (> generating lists of properties of thousands of parts).
Scenes would give us files within files and various instances of Layer Editors, pretty much in the way they already exist in worksessions. My impression is that Snapshots are more suitable as a visualization feature in the way that one can quickly swap object/environment properties visibility and arrangement of a given set of scene objects.
In case a user needs all aspects of this, but in addition wants to introduce a lot of geometric variation between shots this also leads to a growing Layer stack, a longer list of Layouts and possibly at some future point also Node based content which only lives within the file and which is only relevant for one Shot/Setup.
At that point I’m sure Scenes were a more effective filtering means than Snapshots.
I also wonder what’s supposed to happen to Geometry which is newly added to the Scene after quite a bunch of Snapshots were defined. It in the present version all new elements on any particular Layer automatically populate any other Snapshots with the same Layer visible, surely this is as often undesirable as desirable.
One then has to create new Layers and update/resave those Snapshots where we want the new geometry to appear. Possibly needlessly complex housekeeping.
Yes, this is definitely something to consider. Having to update all snapshots each time you create a new layer is a pain.
This is the same limitation SketchUp’s Scenes have. There is an add-on for SketchUp that solves this problem by asking each time you create a new layer if you want this layer to be “on” in all scenes or current scene or no scene. Something like this would be essential to be able to manage snapshots easily.
It is not a question of superiority or appropriateness.
This is pretty much what Snapshots look like, considering you can update snapshots. It isn’t perhaps (yet?) as fluent as working in scenes, but other than that from where I’m standing snapshots are like scenes in Blender. Snapshots are just called something different than scenes.
edit: perhaps you are looking for something that resembles the Outliner in Blender?
I suppose I kinda like that idea but then… by the same logic, when a shapshot exists, every time you translate (move, scale), show, hide, freeze, thaw, change layer color, change material, … you would have to be asked if you want the change to influence a specified snapshot. or?
