thanks for your input @gegenlicht
This is really impressive! It looks alot like unity and from my experience with unity the core advantage to me are having Scene, Material, Animation and Sound Editors that can be used the import and Edit assets.
yes, asset and scene management is a big part and xenko seems to do that pretty well. the astroboy walk animation in the teaser video was imported and setup in about 1 minute. xenko also has an FBX importer.
Both options for implementations sound valid. In the Video it appears you create a Scene in the Engines Editor -> Define References for VL within the editor for VL ( Sphere ) -> Have an Application (exe) with separate VL Editor that can still be edited.
In this Demo you can create and Edit all the Scene Objects within the Editor ( Import, Position, Animation, Sound, Shader selection, Material editing )
you guessed that right, in the video the VL editor was started by the game executable, loads a defined VL document and then has full access to all game objects, assets, prefabs, materials and so on by having the game instance as an input. then by referencing the xenko binaries all raw xenko functionality is available as nodes. so it was possible to work on the game while it’s running with the power of VLs runtime compilation.
Does this mean that all Shaders, Html-Texture other Plugins would need to be developed for Xenko? Could VL also be the Source for Textures etc?
everything that’s available in VL works. no need to re-develop anything specific for xenko, only one bridge node is needed that converts to xenko world. we have something like that already for CPU pixel data with the IImage interface. GPU resources like textures and buffers can be shared by handle.
This sounds like VL would become something like Bolt Visual-Scripting for Unity but with a lot more features it can access outside of the engines features. ( https://assetstore.unity.com/packages/tools/visual-scripting/bolt-87491 )
i don’t know that visual scripting editor. but as VL is an actual OOP language with data types, loops, if’s, interfaces, delegates and .NET library import my guess is that its some orders of magnitude more powerful.
Would an implementation like Skia ( VL Including Xenko the Rendering Engine ) make it harder to deploy Multiplatform applications from it? Could this still allow opening “Scenefiles” from the Xenko Editor? Then both Options have the same benefit of Asset Management.
that’s true, in the case of hosting VL in xenko we have the advantage that their cross platform build system works for us. that means as soon as we can export .NET Standard assemblies you can compile win, mac, linux, android and iOs apps. editor would still be on windows tho.
the second workflow of referencing xenko as a package has the drawback that we need to implement the build system into VL, but it is the more ‘lightweight’ and follows the rapid prototyping idea better in the sense that you just download VL, add the xenko package and patch away.
good thing is, the two workflows don’t exclude each other and both can basically use the same set of nodes/patches. developing a proper and easy to use node set is one of the major challenges in any case. how asset management works in the second workflow has to be checked in detail, but we hope that you can also prepare them in the editor and load them with a specific set of node. but we didn’t dive into the xenko asset compiler code yet.
I really like the idea of having something like an editor for Asset management.
The only thing i find really important is that VL + Xenko would still allow the experimental workflows VVVV allows its users. Full Editors tend to influence the work created and less “happy mistakes” happen.
we are totally with you on that part. in both workflows you can just patch around as you like. that’s what VL brings to the table and why most of us are here.
