as you might have read in the VL: ThreeDee blog post, we see two major workflows with vl/xenko. To get familiar with xenko we jumped on a project where the second mentioned workflow, "Xenko game as a host for VL" makes sense.
First contact was better than expected and we were quickly able to patch with the original xenko entities. The nodes we created so far allow to setup the scene graph and also combine it with scenes or prefabs made in xenko's game studio.
We also tested custom 3d drawing á la vvvv dx11 and the performance is crazy good so far! We implemented some pretty complex shader pipelines like a 3d fluid simulation and particle systems and we see insane frame rates, even on laptops.
The scene graph is a high level system that has concepts like light, shadow, materials, physics, audio etc. Patching with the scene graph feels quite easy since there is no need to work with shaders directly. Let's see how this looks like:
The entry point into the rendering is the RootScene:
Much like a vvvv Renderer you connect the content to its input. Each object in the scene is a so called Entity. Or in other words, entities are the building blocks of the scene graph. They can be as simple as a Quad or as complex as a complete level of a game. For example the Box or the AxisAndGrid node are entities. Entities can also have children, so we modeled the almighty Group node as an entity with two or more inputs for child entities:
For a basic setup we can connect an AxisAndGrid and a DirectionalLight to the Group:
It might feel odd to vvvveterans to connect AxisAndGrid and DirectionalLight to the same Group. But this is what the engine manages for you, it picks up all entities in the scene graph and builds the correct shaders, render calls, physics setup and so on from it. That is how most modern game engines work, the concept is called entity/component/system (short ECS) and xenko has a nice documentation about it here if you want to know more.
Of course you can still work with custom shaders when needed. More on that in an upcoming blog post.
Now let's finish our little scene by adding a floor plane and a box:
There you have it, doesn't it look nice?
If you want to see more vl/xenko in action, join us at the next vvvv meetup where we will give a bit more insight into the current state of the library: vvvv meetup #5
See you there,
thanks for the update - looks exciting!
it might be too early for this question: do you have plans already how to intermingle xenkos editor and the scenegraph built up programmatically from within VL? the posted example shows the scenegraph entities created completely in the patch. if i'd like to design the scene using the xenko editor - would i automatically get this scene as a patch like above? (would this even make sense?)
i'm asking because having this capable editor from xenko would be one of the big advantages for many projects and i wonder which direction will be pursued first...
so you can build any scene with game studio and add dynamic content in vl, its the same scene graph. you can also "prepare" any content in game studio and load it dynamically as a Prefab when you need it. since you can access the whole scene graph, you can modify it as you like in vl. but there is no xenko 3d editor to vl patch conversion.
the tree doesnt look too unfamiliar.
This looks pretty promising, can't to see where this goes with VL's OOP ..
One question : how would the patch look like if I want my cube to have some fancy PBR material ? Does this BoxEntity have some kind of Material pin ?
@sebescudie yes, for now there is a fixed white material loaded for all basic primitives. that's what the color input is for.
for different materials you would use a more advanced version of the box with a material input pin. but you rarely need basic primitives with fancy materials. i think you would rather want prepare more advanced models and materials in xenkos game studio and load that as a whole package, for example as a prefab.
so, as an advanced user you would build your own custom entities and add the components that you need for that specific entity (model, material, physics, audio etc.). the predefined entities are rather for quick drafts and act as a kind of template for more complex custom entities.
Okay, thanks for clarifying, I realy like this approach :)
Awesome, glad to see progress on this!
What is this dark them I'm seeing? :D
anonymous user login