i saw that this was brought up before quite a while ago so i wanted to refresh the yearnings a bit to see if any thoughts have been given to this issue. Since Grasshopper is a real essential part for many why not making this a little easier to handle. also having to share 2 different files is not convenient.
if this would be anyhow possible to achieve, would there be any further plans integrating grasshopper’s savings into rhino? @DavidRutten
I know that embedding the GH canvas in the 3dm file has been discussed and is on the Wish List, (probably for GH 2), but I don’t know the details or the potential tricky bits because of all the different plug-ins.
Embedding (several) grasshopper files into 3dm files shouldn’t be that big a deal, but since it would require a significant amount of new UI code it will have to wait for GH2. There are also downsides to having files within files, so the ability to save separate *.gh files will continue to exist.
what would you consider a downside?
a gh definition alway uses rhino space and in case somebody wants to load a external gh definition it could just load the “embedded” gh file from the 3dm without opening its hosting rhino space as an option in the opening prompt.
that UI has to be changed to make this happen is understandable which would contextually also simplify it additionally. anyway for me grasshopper always felt like it would not know if it should be a part of rhino, a plugin, or even an extra application. that it needs an “extra” screenfilling workspace is if not comfortable at least acceptable and sure necessary at least in the sense of area needed, still it feels fiddly and complicated and the messy extra files also do not add to keeping ones data trash in clarity.
for many people grasshopper is actually the real reason for coming to rhino at all, one should not forget that. so aiming for making this feel a bit tighter is an important aspect i believe.
another last idea for now is that a grasshopper autorun (autolaunch) for gh files embedded would be handy, to keep it simple but also allowing to feel more settled and compact within the whole process.
Not every Grasshopper file requires Rhino data, or even Rhino itself. By embedding GH data in a 3dm file you now need to deal with two file formats if you want to inspect it. Autosaving will be less efficient since potentially far more data needs to be saved. Exchanging files with people who are running an older version of Rhino will not work, even if the Grasshopper data itself would have worked fine. If you want to be able to reference other GH files (for example user objects, or clusters, or worksession like stuff) then that’s more complicated. Working in teams where some people work on the Rhino data and others on the GH data is complicated if everyone has to change the same file, version control becomes more involved. You might want to develop a gh file on a simplified/reduced 3dm file so it updates quickly and run it on the real 3dm file only when done. I could go on.
There are also benefits of course to embedding gh data in a 3dm file. So I imagine both options would be available and you can choose whichever suits you best at any given time.
That’s a good point actually. What do you think should happen if a 3dm file which contains gh file(s) is opened? Should GH start and load all the files?
I agree that GH exists in a grey area between plug-in, app and native-feature, but is this an actual problem? Does it need to be unambiguously one of those three?
yes but every grasshopper file uses rhino space eventually and this is also the part where i doubt that embedding is the way to go, i was rather thinking about saving gh files natively as 3dm file not seeing it as a file coming from a plugin but from rhino itself. one could think of keeping a gh importer for older versions.
which also leads to this part again :
i dont mind at all having an amorphous idea behind it, that sure can be positive for keeping development open, as long as the workflow is tightly integrated.
when i compare to the xpresso editor of c4d for example which is in a way similar to grasshopper the opening of such is a click away, a window opens which i can also integrate into the regular interface of the main window - its a part of the software. when i open grasshopper it does not take long of course with ssd probably opening in an ok speed still it takes time, interrupts the workflow and feels apart from rhino.
in xpresso all functions are base UI functions of the software it at least feels like it. why cant grasshopper use the same base functions or feel like it would, meaning that it would not have to load them extra. there are sure several functions for which one has no UI and no access in rhino space without using development, rhino common whatever. but this all could be a strong part of grasshopper integrated into rhino and loaded at the beginning.
this is of course a huge change leading to making rhino itself actually parametrically, meaning that probably everything from the UI has to be ripped apart but for me honestly that would be very well worth the effort and dont we all know that sometimes starting from scratch can iron out many unnecessary folds? if any step at all into this direction would be too much of an undertake for GH2 and i am sure it is because rhino 6 is already knocking on the door, but i would at least hope that this can happen anytime later.
meaning that thinking about the below would not be necessary anymore
i am talking about grasshopper getting a proper place for sinking deep into rhino using the same UI functions and enhancing them like a pull down menu.
What do you mean by “Rhino space” exactly? I thought you were referring to viewports before, but now I’m not so sure any more.
Wait, do you mean switch the gh file extension to 3dm but not actually embed the grasshopper data into the Rhino model data? So Grasshopper would still use distinct files, they’d just have the same extension as Rhino?
We do use lots of different file types already beyond 3dm (rmtl, renv, rtex, lay, rvb, rsun, rui, rws, …).
with Rhino Space i actually mean Rhino itself (which of course also includes the working space/viewport) since Grasshopper functions as an external Space (environment may be a better word) which is “only” linked to Rhino.
yes in a way, i mean that the GH data is being saved through rhino and not through GH. it would suggest that this would mean being embedded for the time being, but for future thoughts it would offer itself thinking about making grasshopper more native to rhino. when you save a definition without any geometry that it just opens an empty viewport but the definition is available right away, or you import the data if needed.
well yes… what shall i say if developer tools need many different formats then it shall be so, but getting a bit an order into the mess may not be wrong.
Just wanted to jump in quickly, though my comments won’t help to resolve much.
In VisualARQ 2 with Rhino 5, one can make object styles through Grasshopper Definitions. These definitions ARE embedded into the 3dm and if the 3dm is open on a machine without the original GH Def, it can still solve the embedded definition.
At the moment, there is no UI available to ‘open’ this embedded definition in the Grasshopper Editor, but it is entirely possible and will be considered for a future release.