generative modeling for Rhino
RHP Import as Referenced Assemblies
I wonder if this is a planned feature, or if it is possible at all, but I see the bridging of a vast gap if it were possible to use RHP files as References assemblies into GH scripting nodes.
There is a VERY VAST base of Rhino plugins that mostly ship as RHPs, which would open to Grasshopper through code (instead of needing to re-code things like PtSetReconstruction or Electric Fields or Circle Packing from scratch in GH). I have pondered several times if it were possible to use Rhinoscripts inside GH without having to rewrite the code from scratch, and I wonder if we could use monkey to compile them into RHPs and then reference those into GH?
What say thy experts & gods?
There is a VERY VAST base of Rhino plugins that mostly ship as RHPs, which would open to Grasshopper through code (instead of needing to re-code things like PtSetReconstruction or Electric Fields or Circle Packing from scratch in GH). I have pondered several times if it were possible to use Rhinoscripts inside GH without having to rewrite the code from scratch, and I wonder if we could use monkey to compile them into RHPs and then reference those into GH?
What say thy experts & gods?
Views: 74
Replies to This Discussion
-
Permalink Reply by Damien Alomar on -
In terms of it being possible, as I understand it the answer is yes, but its not as cut and dry as that. RHPs are just renamed DLLs, so its certainly possible for GH to reference those assemblies, its a matter of whethere there is anything too reference.
The problem is that unless you were writing a plugin specifically for being accessed from GH, then it would not be likely that the access you're looking for would be there. Plugin writers tend to keep the access to the functions that they write as limited as possible, generally only their plugin can access those functions safely. On top of that, most plugins are designed to interact with the Rhino environment, so their may be extra hoops to jump through in order to get the information you need and clean up after, if you can even get what you're looking for.
As to Rhinoscripts, there really isn't any way to access their functions from GH, but since you would presumably have access to the code, you could write it in a way for some sort of remote access. Rhinoscripts couldn't be referenced in the same way as a dll, but you certainly could call it as a command. A script would have to be designed to limit the interaction though, so no prompts or picking. Any geometry that it wanted to reference would have to be added to the document, and any geometry that would need to be referenced back into GH that was created by the script would have to be within the Rhino document first. I doubt there could be any direct communication between the script and GH, so information (ie variable values, geometry UUIDs, etc) would probably have to be written out to a text file or something so that it could be somehow accessed.
Ultimately, unless the script is incredibly complex (in which its probably not going to be a good realtime solution) its just better to translate the code. If its an issue of not knowing the SDK, I think translating code from RS would be a good way to gain that understanding.
Coming back to plugins, its possible that as things progress with GH that developers would consider exposure to GH just as they do exposure to Rhinoscript. I think its a matter of whether it makes sense for the plugin and for the GH approach. Not every plugin is really meant for realtime interaction, and not every developer is okay with open access to certain parts of their plugin. All that being said, I think the possibility of having a plugin for general use in Rhino, exposure to Rhinoscript, and access from GH would be really cool and add tremendous value to that plugin.
-
Permalink Reply by Suryansh Chandra on -
I was kind of sceptical about what amount of functionality do plugins expose for external access.. and yes, getting around the the object selection bits and interaction with the Rhino environment and in some cases custom display pipelines can be really hard to get around (and then there are those with custom forms with their own set of sliders and inputs). So I guess its something that needs to be approached from both sides.. plugin writers need to consider exposing functions to GH, and there needs to be work done on the GH end of things as well to make this work. RHPs perhaps need to be used as 'libraries' (as the DLLs are being used at the moment) that expose custom classes & functions like the SDK does, which could make sense to GH.
About using scripts from RS, doesn't the compiler that comes with Monkey already convert the RS code to its equivalent .NET or C++ code to make an RHP? If it does, then the problem can only be limited to interacting with RHPs and there wouldn't be much need for a 'remote access' for RS.
At this time, translating the code indeed is the best way out and perhaps always will remain, but its also the most laborious and not always within reach to everyone.
If it ever indeed were to be within reach, it really would make GH tremendously more capable and get wider acceptance as well as one of the primary reasons so many people shy away from it is that the entire body of work that is developed in Rhinoscript or plugins over the decade of Rhino's existence is nearly entirely unusable from within GH.
-
Permalink Reply by David Rutten on -
Hi Suryansh,
"doesn't the compiler that comes with Monkey already convert the RS code to its equivalent .NET or C++ code to make an RHP?"
No, the compiler merely compiles the Script code as Strings into the rhp file, then runs them again as RhinoScripts. There isn't a complete overlap between the public SDK and RhinoScript methods so a reliable translation cannot be guaranteed, not to mention it would be a gargantuan task.
"I was kind of sceptical about what amount of functionality do plugins expose". This is
definitely true for some plugins, but most DotNET plugins will have classes that can be used directly.
(dinner, to be continued) >>>
-
Permalink Reply by David Rutten on
-
...can be used directly. This is certainly the case for PointSetReconstructivism, but note that the components in Grasshopper that do delaunay and voronoi etc. have far better algorithms build in. And *.gha files are also merely renamed *.dll files.
"that the entire body of work that is developed in Rhinoscript or plugins over the decade of Rhino's existence is nearly entirely unusable from within GH."
Yes, regrettably. But the same is true for RhinoScript, it often cannot tap into functionality inside plugins. And the same is true for Plugins, they won't be able to tap into functionality in other plugins, unless a lot of care was taken to make sure this is possible.
One of the more esoteric things we've been discussing ("we" being Steve and me) is to have a grasshopper-aware section in the Rhino SDK, which essentially allows plugin developers to expose the functions they've already written as Grasshopper components, without the need for any additional dlls or rhps or ghas. All you have to do is expose your stuff as MGrasshopperComponent classes as well as MRhinoCommand classes. This is still little more than a silly idea though, and it doesn't directly solve the issue you brought up here...
--
David Rutten
david@mcneel.com
Poprad, Slovakia
-
Permalink Reply by Damien Alomar on
-
That's not silly...That's a very VERY good idea. Right now if I wanted to write a plugin that exposed rhino, GH, and RS functionality, there's quite a bit of extra work that goes into each of those. I think RS is an example of the extra work that's needed for a plugin developer to add extra functionality. If there's the potential to get away from that and make it much simpler, then by all means.
-
Permalink Reply by David Rutten on
-
Yes, well, the major problem with this is that Grasshopper is not part of the Rhino core product, and thus anyone writing a Grasshopper implementation from within the Rhino SDK, has to do so without being able to use any of the Grasshopper classes.
This dichotomy makes it very hard to do proper OOP. Anyway, there are solutions to all of this, but it involves a lot more Steve than David in the beginning so I'm just going to sit back and see what comes down the chute.
In the meantime, my plan is to make it much easier for people to develop directly for Grasshopper.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
-
Permalink Reply by Suryansh Chandra on
-
Grasshopper-aware sections of the Rhino SDK would certainly make life a lot easier, but is it practical considering the speed at which GH is changing/growing?
GH at this time maybe branded as only a plugin, but considering how complex+capable it is rapidly getting (its a plugin with its own SDK!), perhaps in sometime it might be worthwhile considering making it a part of the core Rhino product, thereby enabling tighter integration with the core SDK as well.
"..most DotNET plugins will have classes that can be used directly."
Can we have the ability to reference RHPs in the next release?
-
Permalink Reply by David Rutten on
-
I'll allow those extensions in the Reference editor, and we'll see where it goes from there.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
-
Permalink Reply by Suryansh Chandra on
-
Thanks! That should be good starting point. One more question: how does one figure out what classes does an RHP/DLL expose for external use? Will it show up on the intellisense?
-
Permalink Reply by David Rutten on
-
yup, that's pretty much it. If you can see it in intellisense you can use it.
You can also get Reflector.exe (it's free), which decompiles DotNET assemblies into the language of your choice. Do note that you'll often break the law when you decompile someone elses code. A lot of license agreements have clauses that specifically forbid this.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Translate
Search Grasshopper
&width=104&height=139)
© 2012 Created by Scott Davidson.
Powered by
