Blueprint nodes generation at runtime

[nxrighthere]

A robust and flexible system should be implemented to generate blueprint nodes and data types weaved with managed code that exposes functionality to the engine.

[nxrighthere]

The first prototype implemented. Current challenges:

• Auto-generated C++ plugin with blueprint functions cannot be hot reloaded with headers that generated by the Unreal's header tool for a blueprint function library
• Unhandled exceptions cannot be transparently handled and redirected in functions that implemented by a user to prevent termination of the process by .NET runtime (see How to pass APPDOMAIN_IGNORE_UNHANDLED_EXCEPTIONS using hostfxr dotnet/runtime#39587)

[nxrighthere]

Seems like it's possible to generate blueprint nodes dynamically at runtime. The current challenge at this point is the invocation of user functions with variable-length parameters. In terms of performance, the invocation of functions with predefined fixed-length parameters are 195% faster than the closest equivalent for variable-length parameters:

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19041.508
AMD Ryzen 5 1400, 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=5.0.100-rc.1.20452.10
  [Host] : .NET Core 5.0.0 (CoreCLR 5.0.20.45114, CoreFX 5.0.20.45114), X64 RyuJIT

Method	Mean	Error	StdDev
'Fixed-length parameters, Function()'	2.878 ns	0.0149 ns	0.0140 ns
'Fixed-length parameters, Delegate.Invoke()'	3.850 ns	0.0264 ns	0.0234 ns
'Fixed-length parameters, Dynamic->Delegate.Invoke()'	18.292 ns	0.3381 ns	0.2997 ns
'Variable-length parameters, Dynamic->Method.Invoke()'	224.541 ns	1.3883 ns	1.2986 ns
'Variable-length parameters, Dynamic->Delegate.DynamicInvoke()'	372.478 ns	1.4545 ns	1.3605 ns

All delegates for user functions should be stored as dynamic types in a single cached collection for fast access from native code once all entry points are cached at startup.

This approach has a significant impact on performance, unlike the code generation where all functions with parameters can be predefined at compilation time.

A performant solution might be a custom blittable representation of function parameters using a single predefined function for the invocation from blueprints, but that means intermediate conversion to appropriate data types in the user function itself. This approach is counterproductive.

[nxrighthere]

Related to dotnet/csharplang#3718

[nxrighthere]

Blocked by dotnet/runtime#42275

[dagillespie]

Looking forward to this feature. Is it in the main branch or is it pending the initial stable release?

[nxrighthere]

This feature is on hold at the moment, but I think I can ship it partially in the following weeks with certain limitations. The main problem is that .NET 5 lacks functionality to implement this feature the right way.

[dagillespie]

Happy to wait if .NET 5 is the blocker here (does 6 help?) but equally very happy to kick the tyres of your implementation.

[nxrighthere]

Happy to wait if .NET 5 is the blocker here (does 6 help?)

Unfortunately, as long as this issue remains unresolved, it wouldn't help.

[darkguy2008]

Happy to wait if .NET 5 is the blocker here (does 6 help?)

Unfortunately, as long as this issue remains unresolved, it wouldn't help.

As of July 12, 2021, it seems they moved the feature to the Future roadmap, which basically means "anytime between tomorrow and the next big bang, if we're still alive" although I agree with the feature, MS is MS... I think it would be a good time to think on alternatives. I'll check what I can come up with.