Rhino.Inside.UE - Getting Started

Thanks for the “hello world” equivalent in Unreal using USharp to access Rhino.Inside C# libraries from Unreal.

I’d like to build on this and extend the functionality by creating some functions either as a UFunctionLibrary or an AActor to call Rhino.Inside functionality at runtime rather than at initialisation which appears to be when the level first opens in the editor - as your code is based on a GameModel.

Transplanting the code into an AActor or UFunctionLibrary, I’m getting errors in the editor with the try/catch statement calling Rhino.Inside in the object initialisation function when I transplant this into another class. Any suggestions on how to best incorporate this would be amazing.

There are some limitations in the sample due to my understanding of the UE C++ / Blueprint API and some limitations due to the use of the (excellent) USharp library.
Today I did get further and created a Blueprintable AActor class, which I could use to hook into other interesting functionality.

I’ll try to clean up the code and commit (maybe not until Friday due to travel) so you can see how I got it to work. Still, there is a bunch to learn to come up with the best strategy for doing these things cleanly.


p.s. @dagillespie, any knowledge you have and can share about UE, the editor, the api, etc. would be very helpful and welcome! If you have any specific use cases, we can try to get a sample going…

Awesome implementation in an AActor @fraguada. Very happy to discuss in more detail as we definitely have some specific use cases for this in mind (a series of blueprint nodes would be a great one for instance). I’ll be at an Epic event on Thursday that I believe you’re also attending so could be good to discuss then.

PS - glad USharp is working well for this.

1 Like

Great, see you there!

Hey guys, great work.

I tried to run this, I managed to get usharp installed and i’m running the sample project through visual studio but I got stuck.

I don’t know which executable I should be targeting. if I don’t target the UE4Editor.exe I get this error:

What are you guys doing here? Rhino Inside UE4? Give me that! :wink:
Although I’m not a programmist I have some experience with UE4 and “wasted” some time and nerves on experiments with Rhino & Revit together in UE4 workflow. I would be more than happy if I can test something and share my thoughts!
Unfortunately, there is no UE4 section on GitHub https://github.com/mcneel/rhino.inside
How can I follow your steps?


It’s there, just not in the master branch yet.


2 posts were merged into an existing topic: Rhino.Inside.Wpf/WinForms

3 posts were split to a new topic: Rhino.Inside.Wpf

Have you selected ‘Start external program’? Also, double check where Unreal Engine is installed on your machine.
Also, in the command line arguments text box, you should put the path to the .uproject file in quotes so the Unreal Engine Editor opens that file. If you don’t do this, debugging will stop when you reopen the file from the editor.

I had similar dificulties as @Nick_Cassab but thanks to your tips I succesfully opened the project.
Another thing is that I don’t know what to expect at the current stage. I was expecting that it will open UE4 and Rhino at the same time and there will be some geometry both in the UE4 and Rhino (as on your screenshot). Is it only for coders at the current stage of development?
Please consider sharing some short videos showing your work. I’m very curious about this project. Best luck!

@Czaja the sample posted opens Rhino in the background, creates a sphere, and ‘prints’ some text about the geometry to the Unreal Engine Editor console ( Window > Developer Tools > Output Log).

The development we do in the next weeks related to getting Rhino and Grasshopper working inside Unreal Engine will be pretty rough as we’re still learning about Unreal Engine (Blueprints are awesome!). This being said, @kike and I will be giving a ‘masterclass’ on Rhino.Inside at the AEC Tech Symposium NYC on Thursday, October 17th. In addition to giving an overview of the necessary elements needed to get Rhino running inside a host application, we’ll be using Unreal Engine as a case study. When the class is over, we will push the samples and other class material to the public repo.

So far, I’ve been able to open Rhino files and get their geometry into Unreal Engine as you saw above. Today I’ve got Grasshopper running in Unreal Engine:

To be able to do that, I had to do some a tiny edit to USharp. This means we have to find an easy way to make sure anyone who is trying this with Unreal also gets that tiny change I needed to make. Anyways, early days, but definitely fun!

@dagillespie @Czaja we’ve released the contents of the Rhino.Inside Workshop we did yesterday at the AEC Tech 2019 Symposium. https://github.com/mcneel/Rhino.Inside-Workshop
The repository has 4 samples and the wiki goes through each. Check out the Setup section for a custom version of USharp that can be dropped into the Unreal Engine plugins folder. We only changed one variable in the USharp src that disables “hot reloading”. This is a compromise in order to get Grasshopper working. I’ll document what we changed later.
Sample-3 and Sample-4 use an AActor class and have all of the functionality to pass geometry from Rhino / GH. These samples are pretty rough, are not meant to be “best practices”, they are just a basic “hello Rhino”.


Awesome work you’ve done implementing this! Am walking through this right now. Currently wrestling with the assembly resolver nuget package as it claims to not be compatible with my version of Grasshopper as a dependency. I’ve just updated Rhino WIP so wouldn’t have thought this an issue?

Strangely, I’m getting errors even on the console example where it’s failing to resolve the Rhino namespace too.

[Edit - overlooked manually adding the reference to the project in reference manager]

Am curious what you’ve had to do to disable hot-reload as that’s a super useful feature and a massive time saver when developing with Unreal.

@fraguada - Have you also considered implementing this functionality wrapped in a Blueprint library that would be available to other actors and elements in a scene in Unreal? That might start to get towards a toolkit that could be implemented broadly and begin to form the basis of a UE4 plugin.

1 Like

Did you encounter the following error with anyone at the workshop?

USharp: Error: Unhandled exception (vtable func): System.DllNotFoundException: Unable to load DLL ‘RhinoLibrary’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)

This may be linked to the bug above with installing Rhino.Inside from nuget?

@will can you help with this? This is in regards to the different ways VS can reference nuget projects.

The Rhino.Inside nuget package isn’t compatible with projects that use the old packages.config configuration format due to a bug/feature where “stable” packages can’t depend on pre-release ones. The Unreal samples use PackageReference and should compile OOTB.

Were you trying to build the Rhino.Inside Unreal workshop samples that @fraguada posted? Or were you trying to use the Rhino.Inside package in your own project?

This sounds like a CopyLocal issue. Is RhinoCommon.dll showing up in the build output folder?

The variable in question is here: https://github.com/pixeltris/USharp/blob/master/Managed/UnrealEngine.Runtime/Loader/EntryPoint.cs#L40 I changed this to true.

@dagillespie You can check the gitter chat here: https://gitter.im/USharp/Lobby?at=5d91beb77fe6a605d15689a3

Essentially for Hot Reloading to work, USharp loads assemblies into a specific AppDomain (not the default AppDomain). This means that the Grasshopper.dll assembly is loaded in a way that it cannot reference any dependencies, because those are not in the same AppDomain. Here is the main developer’s response: https://gitter.im/USharp/Lobby?at=5d924321fcb47b627ff24d1c

Maybe between some of us we can figure out how to ameliorate this?

Sounds like a good idea. Do you think this is possible via USharp? We are also talking with the Unreal Engine dev team to see what options we have going forward.