Not many will remember the times when vvvv's 3d rendering was based on Direct3D 8. Not important really, because at the same time we released vvvv 33beta1 in December 2002, Microsoft released Direct3D 9 with a lot of new features, so we knew what we had to do..
Luckily vvvv's DX9 implementation proved powerful enough to be quite useful for many years. Then it took Microsoft 5 years to release its successor DX10 which was only available on Windows Vista, which nobody wanted. Also graphic-card adoption took quite a while so we didn't really feel an urge to start working on it right away.
A year later in 2008 Microsoft released Windows 7 and with it DX11, which altogether looked more promising. But still a lack of adoption of supported hardware and Windows 7 didn't put too much pressure on us to implement it. Instead we thought it would be smarter to improve the plugin-interface for vvvv to make it easier for users to contribute to the library of nodes.
In parallel we had already secretly started work on our next big thing that would become VL, which we first announced at the keynode during NODE13. Since with VL we've mentioned from the beginning that we wanted it to eventually run across platforms, for us, implementing a new renderer based on the windows-only Direct3D api became less and less appealing.
What happened next couldn't have been more fortunate: besides many other major contributions, using the possibilities of vvvv's plugin-interface, power-user vux took it in his own hands to create a set of nodes for rendering with the features of DX11, which he released on vvvv's 10th birthday in December 2012. And the vvvvorld was a better place.
DX11 for vvvv is amazing, but innovation in the world of computer graphics started moving faster and faster. Despite the magic that DX11 brought, users demanded more and more bling, but all we were talking about was how VL would revolutionize visual-programming, which brought us all together in the first place.
With the cross-platform goal in mind, for years it seemed the only option was going for OpenGL instead of Direct3D as rendering API for VL. But all those years, following OpenGLs development and stories about bad support by Microsoft and Apple never got us excited enough to just go for it. Meanwhile a new player has appeared as a modern cross-platform graphics API, called Vulkan, but since it is still in its early stages and support for MacOS seems not official yet, again we were reluctant to jump on it.
All the years we knew there would be another option: Instead of using Direct3D, OpenGL or Vulkan directly, we could base a rendering library for VL on a game-engine API that would deal with different graphics APIs under the hood and would possibly have all 3 as back-ends that can be used on different platforms without us needing to worry about it.
While this sounds brilliant, it obviously has other potential drawbacks (out of scope for this post). But also the range of options for game-engines we could have used wasn't too overwhelming. Until recently. Enter Xenko.
We've had an eye on this engine for a while already but it being targeted at commercial game-studios would mean that every user of vl would also need to buy a license for it, so again we were hesitating and looked for alternatives.
But what just happened could again not have been more fortunate: The company behind Xenko, Silicon Studio, removed its commercial licensing and released it to the community under the MIT license, which is a very permissive open source license. This would allow us to base a renderer for VL on it without any licensing restrictions.
Initial tests look very promising. Within just a few days we were able to patch a little interactive scene and export the project as an executable so it could be distributed via the Steam store and run on a VR device.
Hence our plan is to investigate further in this direction and at the moment we see two interesting workflows between VL and Xenko:
For both scenarios what will be important, is a proper library design wrapping the original Xenko functionality into a comfortable set of nodes, similar to what we just did for Skia.
We'd usually not water your mouths before we are more sure about things. But with Xenko just having gone full open-source and looking to build a community of developers and users, we thought it would be a good idea to talk about this now and try to involve you from the beginning.
So if you're curious about Xenko's universe, just head over to its website and see what it has to offer. You can even download and play around with the editor and if you're familiar with C# create a little game with fancy graphics and assets in no time.
Next we'll demo what we've got so far to participants at LINK and start a discussion there. If you're not at LINK please still join the discussion with your thoughts using this thread. If all goes well we should also be able to share our proof of concept sometime after LINK.
So we hope you understand that at this stage it is too early to promise anything but at the moment we are confident to having found the right library for implementing a 3d rendering system for VL. Just as we were happy when we finally found Skia as the perfect library for VLs 2d rendering system.
We'll update you about developments as we progress...
big up guys
Not that I have a lot of experience with game engines, but I have friends that do and one thing that is not so good there is support for multiple renderers. I assume that you as super cool devvvvs already know that that will not be a problem. but is it?
@sunep, the whole engine is available and hackable, so while probably not trivial to figure out it may be something the original dev team or a member of the community could contribute. Indeed the whole render engine can be forked off and reassembled for VL specific uses. Hmm...
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.
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 )
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?
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 )
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.
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.
@gegenlicht @microdee answers to the discussion in more detail are in the forums now:
had a quick look at xenko, this whole thing sounds really promising :)
big up devvvvs !
Did you just say you exported the project as an executable?
It's the start of a new era.
After some convincing by the devs at LINK, I came to the conclusion that Xenko really can be the thing that VL needs, shortcutting the work on a render pipeline by months (if not years). There seem to be a lot of symbiotic potential between the two.
Also, from todays standpoint, Xenko does seem quite complete for a rendering engine (few things are missing, ofc, such as advanced gpu buffers or animation timelines), and accessibility of the xenko properties (such as scene graph, or materials) is very clean.
Its worthwile to say there are still a few things that are not perfect (i.e. it uses its very own xksl, which seems mighty, but then again, unity shader did seem mighty at one point too). Also, the community seems quite small as of now, so progress within xenko is likely, but far from certain.
But again, devs made a reasonable risk assessment, that I can follow without stomach ache.
anonymous user login