So I decided to try messing around with Worksessions from Grasshopper, and I was looking for a way to switch Active model, adding models, removing models etc, but RhinoCommon doesn’t seem to provide much help on this:
https://developer.rhino3d.com/api/RhinoCommon/html/T_Rhino_DocObjects_Worksession.htm
Is Worksessions something that isn’t really covered or am I just not searching hard enough?
// Rolf
I’ve never used WorkSessions actually, not quite sure how they would extend to gh files. Also not sure to what extent they are covered by the SDK. @stevebaer is that your department?
OK, we’ll see what Steve says about this (he’s probably ducking and quickly adding some methods to RhinoCommon as we speak, and…)
Anyway, since I have not used Worksessions very much manually I might not really understand its potential (and limitations), but what I was thinking was that Worksessions could be a way to split jobs also for Grasshopper definitions, both for “gradual refinement” (step-for-step refinements of a specific geometry/data) and for “sharding” jobs (a kind of map/reduce strategy) for scaling up the processing of lots of geometry/data.
To me it seems meaningful to split up any data in ways that provides granular access to each data chunk with the full power of a full-fledged “Rhino/GH node” (or Rhino.Compute). Think of the potential for presentation (rendering), for data conversion (save/import all available different formats) and so on, and so on, which is the kind of "full richness"of features which each Rhino node instance would be capable of. (this would be overkill in many situations, but that you could say also about the human cells in the body - the smartest and most scalable and flexible distribution strategy ever).
In addition to the extreme “technical freedom” with such rich “worker nodes” and flexible data format, the Worksession/Model would be “human readable” as well.
The human readable aspect would mean that you could start out a project manually, but let a scalable network of processing Rhino-nodes take over, either to refine parts or just share the load (different parts to different nodes) based on the compartment strategy in which the user split his/her model in the first place. Aso.
A few smart properties added to Worksessions and its Models (if not already there) would be to fire events when Models are added/opened, removed/closed, activated (= “locked” as seen from other Rhino instances/nodes), events for when models are saved (= a way to propagate this info to all dependent nodes via the Worksession), and so on.
On modern NVMe SSDs, sharing data via file format is not a bad idea at all (performance is very much a matter of the size of the geometry chunks).
One could even think of “brother” concept inside Grasshopper where a ComputeGroup is assigned a dedicated Worksession Model and…
OK, now I got carried away perhaps, but this is what I had in mind to try experimenting with, but without any SDK support the strategy would only get buried in code somewhere and also the human readable aspect (based on the existing Worksession concept) wouldn’t be there, which is half my point with the basic idea.
Any thoughts on this?
// Rolf
Not sure it is useful for you but it was for me.
Macau Hotel Exoskeleton was made by Front Inc and they use Grasshopper/Elefront and Rhino/Workessession .
A good video is here
I’m constrained by restrictions regarding third party components, and a whole bunch of other requirements which I would implement using my own code. But to be able to do all that, I also need full access control of Worksessions via RhinoCommon API.
I remember looking into Elefront and the Morpheus project a year or so ago, and it is a really interesting project.
However, I think Rhino would benefit immensely from taking a few extra steps in a direction in which it would be scalable out of the box, by supporting a basic sharding scheme which goes hand in hand with the “manual strategy” of std worksessions, because a big value would come from the potential to automate an initially manual workflow and model structure. Anyone could then make potentially scalable solutions from start, without having to explicitly design, tweak and mess around trying to come up with their own scalability solutions.
It is also worth a note that when I say “sharding” I really mean that it’s more or less meaningless with more advanced “distributed” solutions for scalability, because with more advanced distribution concepts follows so many other problems that only very few people, if anyone, would bother mess with it. Paxos and Raft stuff comes with their own set of problems which in most cases, especially for one-off projects, simply isn’t an option. Sharding is exactly at the sweet spot which most people can grasp and many can also implement.
// Rolf
This functionality isn’t available in our SDK yet. I added a feature request for this at
https://mcneel.myjetbrains.com/youtrack/issue/RH-49088
You can get around the missing SDK worksession functionality using the command line. Here is a snippet form a Grasshopper python component i use to automate creating worksessions:
"""attaches a list of files to the current worksession
Inputs:
P: file paths to attach to worksession
Output:
R: True if no errors"""
__author__ = "Dharman.Gersch"
__version__ = "2018.08.22"
ghenv.Component.Name = "Worksession.Attach"
ghenv.Component.NickName = 'WS.Attach'
ghenv.Component.Message = "" #'VER ALPHA 0.0.1\n 2018_07_11'
ghenv.Component.Category = "worksession"
ghenv.Component.SubCategory = "1"
import rhinoscriptsyntax as rs
import Rhino
#P is a list of filepaths to attach to worksession
for p in P:
#command must be surrounded with '' so that file path can e surrounded with ""
#this ensures that paths with spaces still work
rs.Command('-Worksession Attach "{}" _Enter'.format(p))
#useful stuff here: Rhino.DocObjects.Worksession
doc = Rhino.RhinoDoc.ActiveDoc
WS = doc.Worksession
paths = WS.ModelPaths
#R is used downstream. only continue if all worksessions are attached
R = all([p in paths])
And you can save the worksession like this:
"""Saves the current worksession, creates one if it doesn't already exist
Inputs:
P: paths to asave the worksession in
N: name of the worksession file
S: set to true to save WARNING: grasshopper canvas may freeze if you use a button
OUtputs:
R: result boolean
"""
__author__ = "Dharman.Gersch"
__version__ AUR_= "2018.08.22"
ghenv.Component.Name = "Worksession.Save"
ghenv.Component.NickName = 'WS.Save'
ghenv.Component.Message = "" #'VER ALPHA 0.0.1\n 2018_07_11'
ghenv.Component.Category = "worksession"
ghenv.Component.SubCategory = "1"
import rhinoscriptsyntax as rs
import os
EXT = "rws"
results = []
#command must be surrounded with '' so that file path can e surrounded with ""
#this ensures that paths with spaces still work
path = os.path.join(P, N+".rws")
if S:
if os.path.exists(path):
R = rs.Command('-Worksession Save "{}" _Enter'.format(path))
else:
R = rs.Command('-Worksession SaveAs "{}" _Enter'.format(path))
R = os.path.exists(path)
or refresh:
import rhinoscriptsyntax as rs
R = rs.Command('-Worksession Refresh _Enter')
It’s hard to really make any promises about this getting into V7. The issue is on Dale Fugier’s list and is marked as V7, but this can change depending on how hard this ends up being to implement. For these initial service releases we are also a bit more focused on fixing bugs that people users are running into now we have transitioned to a commercial shipping product.
Hi @dharman
I am using your python code to attach worksession files from grasshopper.
Strangely I get the file path letters attached as worksessions in rhino. I tried to fiddle around with the ’ and " but could not make it work. Using R7.
Thanks!
The P input should be a list. Right click on the input and set access from item to list.
Line 20 of the code expects a list of strings.
If you provide a single string as you have, then python will iterate through the characters in the string. Later versions of this also check if the path is an actual file before trying to add the worksession. I can track it down if that would be useful for you.
Thank you very much for the speedy reply @dharman
Changing to list access solved the problem. However, upon running the script, rhino got stuck on the worksession command. I had to click in rhino and press escape or enter key to come out of it in order to do any further work.
I added an additional _Enter in line 23 and that resolved the problem.
Thanks again for the help! Much appreciated.
No problem!, Yep I’ve also had the same problem. The extra enter is to accept the dwg import options. it is not necessary for 3dm files however
I have noticed a strange behavior when it comes to updating / refreshing attached dwg/dxf worksession files.
If I make a change in the dwg and save it, the rhino ws is able to detect the first file update and is able to show the refresh button active. However, any subsequent updates to the dwg files are not detected by rhino ws. I have tried it with various autocad files and it doesn’t work.
Update function works flawlessly with any attached rhino worksession files but not with dwg/dxf files.
Not sure if its something I am doing wrong or other users are able to replicate this issue as well. At the moment my only solution is to detach and reattach the file.
I’m getting a Runtime Error when trying to Save/SaveAs a Worksession file.
Runtime error (TypeErrorException): unsupported operand type(s) for +: 'list' and 'str'
Traceback:
line 28, in script
line 28
path = os.path.join(P, N+".rws")
I’m also attaching a Gh file.
Worksession_Save.gh (6.7 KB)
I don’t understand what I am doing wrong. Could someone help me troubleshoot?
I’ve managed to make a working definition using RhinoCommand from LunchBox, following @dharman 's formating guidelines.
Worksession_Save_RhinoCommand.gh (7.2 KB)
Your variable ‘P’ is a list. Either you need to loop over each item in that list, or change the input from list access to item access
