How feasible will be using ReInterop for another C# Engine?

[Krixtalx]

Is Reinterop created ad-hoc for the Unity use case, or is it sufficiently general to be used as a C# binding / wrapper generator?

At first glance it seems like the latter, but seeing this issue in the Cesium-Native repo makes me wonder whether there’s a harder underlying problem or limitation I’m missing:
CesiumGS/cesium-native#979

[azrogers]

So, the interesting thing about Reinterop is that it doesn't generate a binding to use C++ from C#; it generates a binding to use C# from C++. The reason this decision was made is that the C++ side doesn't really need to be all that concerned with what the C# side is doing, as the C# side is managed and can handle its own memory, but if the C# side was dealing directly with the C++ side it would need to be very concerned about what the C++ side is doing.

Therefore, Reinterop doesn't actually touch cesium-native at all. It actually works with a C++ "glue" layer in between Native and Unity. Reinterop generates the C++ headers from the C# source code, and generates partial classes with P/Invoke calls for the functions from the C++ side. That "glue" layer then takes the function calls from the managed side and translates them into calls to the native side, and translates the response back to the managed side.

I don't think anyone's tested it but there shouldn't be any reason you can't use Reinterop for another C# project. However, that C++ "glue" layer would have to be almost entirely rewritten for the new codebase (and that is where a lot of the complexity in Cesium for Unity lies). It wouldn't be the kind of wrapper like that created by SWIG that would expose all the Cesium Native datatypes and function calls to the C# side.

That kind of wrapper would be useful to have, not just for C# but for all sorts of other languages. Cesium Native can do more than just integrate with game engines, and there's tasks like manipulating glTFs and 3D Tiles that people might want to use it for. I doubt just running Cesium Native through SWIG would get you a wrapper without any issues, but as we found out with our work to get Cesium Native compatible with Emscripten, it might require fewer changes than it seems. Worth a try!

[Krixtalx]

Oh, I had seen that C++ can call into C#, but I didn’t realize the integration was essentially driven from the C++ side. If I’m understanding correctly, integrating this into another C# based engine would (very very roughly) look like:

1. Define a C# interface/layer that exposes the engine-specific pieces (like camera state) and receives/consumes the resulting glTF.
2. Run Reinterop to generate the C++/C# interop glue.
3. Implement the needed logic to pass data between C++ and C# using the generated Reinterop code.

Regarding the wrapper, it would be fantastic. In our case, a C API on top of cesium-native would already be enough to build a C# binding relatively easy. But binding directly from C++ is significantly more complex.

[azrogers]

That's right! With Unity, Reinterop runs automatically as Unity has support for Roslyn analyzers and source generators. I'd recommend trying to find a way to set that up to work automatically from whatever engine you're looking to integrate Cesium Native with. Also, Reinterop has so far been something solely used by this project, so if you run into any issues with it please let us know via GitHub issue or PR.

Out of curiosity, what engine are you looking to integrate Cesium Native with?

[Krixtalx]

Of course, if we end up using it, we’ll let you know! For now, we’re trying the binding route with CppSharp since we’re more familiar with that style of bindings. The integration target is Evergine, our own C# engine.

[j9liu]

Hi @Krixtalx, are we good to close this issue? It seems like @azrogers was able to sufficiently help, but let us know if there's something else you wanted to discuss.

[Krixtalx]

Yeah, everything's good. I'm gonna close it!