Is it feasible that at some point we will be able to run vl as a plugin inside one of these engines, with engine variables accessible within vl, and the plugin updating in something close to real time?
Probably I’m looking at it the wrong way, but a quick search returned some results showing that unity tcp\udp communication already exists.
Could this be a point to start from?
as we’re trying to communicate in our updates on VL anything that is a .net library will have a high chance of being consumable by vl.
unreal has a dead project for .net interoperability: http://mono-ue.github.io (which i guess at some point will be revived)
unity (as far as i understand) are still using their own blend of .net, which may make it harder (but i also guess they will fix that rather sooner than later).
and cryengine recently announced c# support… so at the moment it is mostly us who need to get our bits together so we can start experimenting on such interoperability.
C# in unreal is still not a production ready thing. epic has no interest in it at all, there’s other one cslled krawl if i remember well which is maintained but that also has quite some limitations. let’s hope now microsoft and unity has closer relationship unity will start support full fledged .net libraries on windows.
how about VL in visual Studio?
I was thinking of creating a new topic on this, but seeing that the discussion has already been started, it might make sense to continue here, 3 years later.
So since gamma 2019.2 now allows for exporting I was curious whether any VL-Unity integration has become possible - through importing a VL generated DLL .NET managed library. Eg. code your logic in VL and then render in Unity and make use of Unity’s ecosystem and deployment possibilities.
In principle, this should work, according to https://docs.unity3d.com/Manual/UsingDLL.html
I tried recreating the example with a simple VL app that has no drawing and has a class with some methods: AddValues, uses basic C# + and GenerateRandom which uses RandomCentered from the VL.CoreLib.
Exporting the VL project yields a VS solution that can be easily adjusted to export a DLL class library. So far so good, but the issue comes with all the references.
I managed to reduce the number of Unity’s compiler errors significantly by pruning out the exported lib folder - removing all duplicate (locales & x86) dll and other extraneous stuff. Also removed Skia references from the generated app code and exchanged the VL.App.WindowsForms nuget ref only with VL.Core and VL.Lang in hopes of getting rid of UI dependencies to avoid having to get Skia and WinForms working in Unity (which I assume is far from easy if not impossible).
Unfortunately the dependencies are as follows
So using any VL.CoreLib node will inevitably lead to UI dependencies in the current state.
And then as you can see there’s also some issues with .NET assemblies.
In general if it’s possible depends on how much can the interdependencies be reduced and the incompatible things removed if unneeded by the finished compiled VL libraries or somehow fixed.
If the devvvvs deem it feasible without a complete rework of the internals I think it’s definitely worth pursuing. Even without the editor ever being available. Unity has a very wide ecosystem with easy deployment to all meaningful platforms desktops, mobile devices, all VR, game consoles, WebGL (dunno how much that can be compatible), … The efforts on the Xenko front are amazing but not sure if it’ll ever reach such wide acceptance.
PS. this is what was left in the lib folder https://pastebin.com/1jzigze9
PPS. no issues referencing UnityEngine.dll in VL
Indeed, except for VL.Core, all our libraries are still on net472. Moving the main libraries to netstandard20 (which implies certain cuts as well as moving away from windows forms for renderers and input notifications) and the UI as well as the runtime to netcore3 will be looked at after this release.