Rhino.Inside.UE - Getting Started

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

2 Likes

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!

5 Likes

@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”.

2 Likes

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.

Thanks - I was following the example that @fraguada posted in my own project however will try building the examples in the repo to see what the difference may be.

RhinoCommon.dll, RhinoInside.dll and Grasshopper.dll are all showing up in the Binaries/Managed folder after compiling.

That would be ideal as hot reloading is a great feature of UE4 and reduces the cycle time developing significantly as you go from minutes recompiling and reloading the editor to 10/20 secs (depending on complexity of what you’re doing)

I’ve built one of the samples following the (v well documented) guide from @fraguada to get up and running. The key things seem to be:

  • Changing the NuGet package settings to reference (allowed me to add the package)
  • From this I could test the base functionality with the command line application and then extend this to the UE4 command line application
  • Starting UE4 from debugging works and even afterwards, if you just reopen the UE4 project the code runs as it was compiled from debugging mode.
  • Hot reloading doesn’t work (as you know). UE4 just hangs. (hence your modified USharp to disable hot reload)
  • Basically everything you said in your guide! - Just have to make sure to follow the fine print!

I also find there is a delay when the function is called which I assume is to do with the time it takes to open a head(er)less Rhino? (poor Rhino)

1 Like

Glad the tutorial works!
In the samples, the first time the Play button is pressed is when Rhino and / or GH are started, hence the delay. Subsequent plays in the same session should not suffer from the delay since Rhino/GH should already be running.

They are well written that really helps.

We’ve been looking at ways to get around the hot reload issue which is a pain. Maybe we will need to dive down the rabbit hole of AppDomains (which isn’t something I’m yet familiar with), we were trying to find a way to split a VS project into two projects:

  • 1 Rhino.Inside Project - One project for Rhino.Inside where you have to build with Unreal closed (no hot reload)
  • 2 Other Project - One project for other C# things which we hot reload to our hearts content (for other tools developed in C# using USharp)

Assuming there are no changes made to the Rhino.Inside that needs a more traditional build process for, we were hoping that hot reload would still work for project 2. So far we’ve been struggling to get a second project in the same solution to play with USharp

@dagillespie We might have a way around this, which would be to use a similar strategy as what we are doing in the Unity Sample 2: How can I reference Grasshopper.dll assembly in Unity?
I’ll give this a try today with the unmodified USharp src. btw, can you give me an example of how you use hot reloading? I think I can get this to work with the unmodified source, but not sure I could test it properly without knowing the mechanics of hot reloading.

@dagillespie check the UE/Sample4. I haven’t tested if it works with unmodified USharp, but it doesn’t depend on any Grasshopper dlls (at least from the USharp perspective), which is what made us try to modify the USharp source.