2) 3d Engine
Direct3d, OpenGL or Vulkan, all possible with VL but what does a library of nodes look like for the things we want to do. What’s the basics, what’s needed, what’s a bonus?
2 Likes
jumping in as a non-coder that found a home here for the last 12 years,
@everyoneishappy has showed the world that realtime gpu patching is possible with InstaceNoodles and FieldTrip. Adopting this concept for both 2d and 3d gpu work should be key
Just the first thing that came to mind while reading about xenko:
Will multi-window / multi-screen setups be possible?
The only thing I’ve found concerning the issue is this (unanswered) post:
http://answers.xenko.com/topics/multidisplay+multiscreen.html
Someone put it on their radar (cyclical reference a-coming)
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…
@sunep our studies did not get that far, but from what i have seen in the xenko repository, the code is very well engineered and since it’s open source we are confident that we can get it to work in way our power users expect it to work. also, as soon as we open source our developments it could indeed be a user from here contributing it.
1 Like
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. ( Bolt for Ludiq | Visual Scripting | Unity Asset Store )
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.
2 Likes
this is great news! finally VL officially appearing outside of vvvv again!
on the other hand though I would still advocate a lower level engine inside VL (as well) like GitHub - bkaradzic/bgfx: Cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library. for multiplatfor bring-your-own-backend thing
@microdee nobody stops you from doing that. there is no rule that there should only be one 3d engine. especially as they can work together by shared GPU resources. regarding bgfx, as a graphics api abstraction, this was the one we were favoring: GitHub - veldrid/veldrid: A low-level, portable graphics library for .NET.
however, compute shader support is not that advanced and it doesn’t come with asset/scene/material/skeleton management.
regarding shaders btw, xenko has an insane extension of HLSL called XKSL which compiles to every platform and supports inheritance, overrides, generics, pipeline streams and more…
2 Likes
yup fair enough,
for people worrying about multiple window outputs, I assume you can just create shared textures from Xenko and use those in other renderers
but if vl has access to everything what xenko also has because they are running in the same appdomain, then it has access to the xenko graphics stuff, including their lower level pipeline too I wildly guess. So you don’t even have to resort to shared resources
yep, its the same app/process. no restrictions, the whole engine is at your disposal.
Great news about Xenko and VL indeed, I would like to know how versatile could be / can be this adoption. To be more clear, one of the vastly missing parts (yet) is a Timeline and a powerful-simplistic renderer. For the second one I can see the potential and the possibilities we may have with Xenko. But what a bout the first ? Would be possible to use such kind of features of Xenko to enrich the way we drive and treat things in VL (such as a proper Timeline would be ? ). Will be a vice-versa communication between Xenko and VL or it is one way thing VL->Xenko ?
1 Like
@guest thanks, I missed completely the first part !
If this option flourishes, this would replace vvvv patching+dx11 development wise ?
I think shared texture is very consuming for higher resolutions, practical but not the same as direct multi screen solution.
xenko currently doesn’t have a timeline/storyboard. but they started a discussion about it here: Storyboards Epic · Issue #18 · stride3d/stride · GitHub
however, a timeline in VL that works in realtime would probably be the better solution since the xenko editor works in design time and not run time.
not many tests have been done in that regard, however in our current proof of concept VL has access to all parts of the application in realtime and xenko game studio can be used for design time jobs like asset management, materials, 3d editor for the scene and so on. that means in the workflow where VL is integrated in xenko like it is now in vvvv you can design something in game studio and then animate it and add logic/interaction in VL.
in the other workflow where we setup the 3d engine of xenko entirely in a VL renderer node (as it is in skia) we still have to investigate how we could make use of all the features xenko game studio has. it should be possible and is more a question of understanding the different systems in xenko separately and of course work hours.
i’d say if it all works out as we think it will, we have something with similar flexibility and power as vvvv+dx11 in VL. and the goal would even be to improve on the vvvv layer concept and patching patterns, as you can already see in VL.Skia.
however, right now vvvv+dx11 is the best choice and is still cutting edge. it could work together with VL/xenko by sharing GPU resources. shared textures for example are only slow if you have to pass them over on the CPU. sharing textures on GPU is super fast regardless of the resolution because you only need to share the texture address. there are always details of course…
3 Likes
Wow, Awesome that VL was so quickly integrated already with the engine!
I was alwasy thinking that for VL its a logical step to integrate with an existing engine.
but was more expecting that it will be bought one day by a big player with the devs finally receiving their well earned millions for their birlliant work.
I, however also fear that it would be the end of vvvv as we know it. Or at least, would be a good moment to give over VVVV as MIT as well?
Regarding the two directions you mentioned, integrating it in VL or integrating VL in vvvv, you would need to take the time window (with Xenko dev working full time for the open source project for a couple of months) to integrate it into Xenk. Because then there would be a good chance that VL gets an influx of realy good programmers that are with the Xenk project and that could leverage the whole thing on a realy interesting level.
I kind of like this idea but on the other hand i think I rather need to stay more in the direction of doing my own low level API / node based programming tool,with my VVVV.js branch beeing a super rewarding coding project in the last couple of years, bringing a lot of DirectX11 typical features into the browser with VVVV style patching.
VVVV.js is completely MIT and that is very nice to work with, I would also like to be able to hack together my own node sets in VL, with OpenGL support in a similliar way.
I also like it plain so it is possible to get the overview and know all your code.
This would get probably harder and harder with VL/xenko
you do understand that MIT gives Silicon Studios the opportunity to take over again at any time, and slap a paying license on it once again? All it needs is a few killer features to get ahead of the open source branch, some offers that the future core-devs of Xenko cannot refuse, and by-gone the good times of open source again.
This whole thing could be only a political play to keep Enlighten an important brick in the Unity universe really. Kudos for the Xenko devs trying it anyway, but it is obvious even they treat it like an experiment, waiting for an influx of more action than Silicon Studio could provide with their financial commitment.
@velcrome Okey thats probably true and an interesting point!
yes, but so can every other company on the planet. only because it’s possible, it doesn’t mean that it’s likely to happen. and even if, the community version would still be available.
it’s rather the case that with unity and unreal as overlords, it doesn’t make sense to sell a commercial game engine anymore. no matter what killer feature you have.
we are rather hoping that companies like xamarin or microsoft jump in and support the project. it’s in their best interest to have a high end game engine that is written in .NET available for everyone.
EDIT, from the SharpDX developer:
https://twitter.com/xoofx/status/1025339481090666497
Day 1:
Getting everyone up to speed with the two integration approaches:
1.) VL in Xenko
- Xenko in the background
- Graphics pipeline patched in VL
2.) Xenko as library in VL
- Shared nodes
- Like Skia
- Mixed Pipeline
Modifying objects should work in the same way in both approaches.
Game objects can be created / instanced on both ends:
- In Xenko (statically in 3d editor)
- Or in VL (dynamic instantiation or process nodes)
Easily possible, design a scene first and then get access to them in VL.
“She Sarp” :)
Would that also be possible in Unity?
- Not really because they are not .Net standard
- But if they were, yes - possible in principle
Xenko is using the same technolgy as VL - so friendly and easy to get / generate nodes
How can special cases like different Renderers etc be done?
- They have to be implemented, but can be with custom renderers.
Probably someone would be interested in use only certain features like material imprt, asstes, etc.
-> The Xenko features should be made availabe as easy to use node set, which is usable in real time.
Shut up and take my money!
Higher level patching would be great - similar to Skia wrapping in VL. But all the low level node should be accessible. -> two node sets:
- low level graphics API nodes (like dx11)
- high level scene graph nodes
How much does VL rely on the development of Xenko?
- We always have to rely on something
- Xenko can be continued by anyone
- It’s open, so the possibility it is continued is great
What if EvilCorp buys Xenko?
- We shoud be protected by MIT license
Does another low level api make sense?
- can easily share GPU resources
Day 2:
Gathering of ideas, workflows and node sets on whiteboard:
Creative projects have more special needs than games. We need to do some tests. Maybe setup a public repo on GitHub with issues and everyone picks one and commits a xenko project that tests a certain technology:
- Max backbuffer resolution
- Multiscreen
- Multiple Scene graphs (scenes) in the same time
- Multi GPU (Quadro cards have it abstracted in driver)
- Max polygons and other limits
- API and GPU vendors (ATI, Nvidia, Intel, Quatro, …)
- Gen lock
- Video playback
- Vulkan vs. DX11/12
- Non realtime rendering
- Control the mainloop by vvvv like node
- Combination with VL Async/Threading nodes
- Change resolution at runtime
- Integrate middle ware (HBAO+, Nvidia game works)
General wishlist:
- Multiscreen
- Multi scene graph
- IGPUImage to share gpu textures with other frameworks/vvvv
- Multi GPU support
- Material workflows + node set
– import + patching materials and textures - Scene graph nodes
- Graphics compositor patching
- Graphics API nodes
- GPU resource binding nodes
- Constant Buffer management
- Texture/geometry FX style nodes
- Mesh/Animation import (Export?)
- Non visual studio shader editor (for lightweight patching/shader coding)
- GPU particle nodes
- Physics nodes
- Special case renderers
– Spherical
– Cubemap
– Offscreen
– Volume - Debug materials
– UV map
– Normals - UI nodes
– Skia?
– Xenko?
– NotUI?
– NoesisGUI? - HTML texture
- Target platforms
– VL export
– Switch render pipeline depending on platform
– Switch input devices depending on platform - VVVV interop
- Asset streaming
Everyone not at LINK is also invited to add items to the list.
2 Likes