A collection of small Xenko usage samples

So as the amount of usage samples of various things you might want to do in your Xenko projects was a bit anemic at the moment, I decided to put together a small repository of my own intended to collect self contained examples of using Xenko to do various things (like procedurally generate a mesh, or use the procedural mesh generation to create a sort of pseudo-instancing to avoid gratuitous amounts of drawcalls by just sticking it all in a big vertex buffer and the like)

Currently there’s just an example of how to use only a vertex buffer and an array of vertices to draw a tetrahedron with a ModelComponent. It’s not using an index buffer since I figured i might as well make the first sample as simple as possible, while still not being just a triangle.

It is for version 3.1 beta of Xenko at present.

If anyone has any specific requests that you want turned into a self contained example, I’m open to any suggestions as it’ll be of benefit to us all, and I’ve come to understand people new to Xenko find it quite obtuse to get started (especially if without much previous experience with other engines).

Some of this might be interesting to incorporate into the docs later if distilled a bit, but for now I figured this was a faster way to do it.


Now also added a small terrain modification sample, generating the plane mesh for the terrain as a subdivided plane (with configurable size and number of subdivisions)

(and collision, assuming I can make the heightfield collider shape to stop fighting me)

With some basic functionality like:

  • Raise/Lower terrain
  • Smooth terrain
  • Level terrain

A small example of something drawn up with it!

Poking some terrain into shape

… and here now with smoothing too


Thank you for this samples @profan!

Thank you for the sample, but is it possible to make it based on version that can be found on NuGet? I can see only here


Yes, I’m sorry, I’d compiled master locally and since that automatically then shows up in the launcher somehow, I’d figured beta02 was also now the latest one, but that’s clearly not the case :smile:

I’ll make it based on beta01-0441 as it was previously! (if I can, I’m not 100% downgrading is all that easy, but I’ll find out shortly, hopefully it’s easy for beta versions)

1 Like

And I have changed to beta01-0441, after compiling, an error raise

InvalidOperationException: Could not load native library libcore.dll from path [D:\XenkoByteSized-master\XenkoByteSized\Bin\Windows\Debug\x64\libcore.dll] using CPU architecture x64.

Right, I just basically recreated the project, but now it’s certainly working on beta01-0441, have a go now :smiley:

1 Like

Works fine, thank you!

1 Like

This terrain modeling and UV can be done in Maya before import to Xenko.

1 Like

I do not agree!
Of course, the terrain can be done in a 3D editor, no one argues. Be it “Maya”, “Blender3D”, “3D-Max”, “SketchUp” … But what if this terrain assumes 100km. - how to be?
I imagine little such “creativity”.
Therefore, the editor of the terrain here appears as the only salvation.
In Russia, there is such a saying … - “Bath - across changing room road” - I see it that way. )

Videos above are not 100km terrain.
You need terrain tiling , object and textures streaming to stream 100km terrain.


The video above is an example that shows the opportunity itself.
For larger terranes, can (and should) use sections. In this case, many problems are solved. For example, LOD, which eventually removes a sectio from processing.

I apologize for my English :slight_smile:

1 Like

Unexpected argument started in here, what is posted here is not intended as anything final, it is merely personal experimentation I am posting so that others may have use of it, if someone wants to be inspired and devise something like an in-editor terrain editor of course I wouldn’t stop you :wink:

(but really this is intended mostly as inspiration and aid more than anything else)

People like @Tom are already working on more “serious” attempts at a terrain system anyways, expect in here mostly interesting toys :smiley:

1 Like

The dispute - leads to the true! )

1 Like

I’m back again, this time I’ve drawn up a small split-screen sample (part of the same repo still) which uses the GraphicsCompositor and Render Targets and 2 cameras (each rendering left and right respectively) and the main camera rendering only then the sprites that are used to display the left/right textures.

Currently uses the same BasicCameraController as the rest to fly around with, you can switch between left and right view camera enabled with TAB, some overview/explanation of the setup is included in the README once again.

The compositor at a glance

So putting it briefly, thanks to the words of @tonfilm in discord, the setup is as follows currently:

There is one orthographic Camera and an associated CameraRenderer which renders only the sprites that hold the render textures, it renders these with the basic forward renderer without any post-fx.

The render textures themselves are rendered with the normal render path with post-fx and it renders everything except the sprites (which are masked out using a render group for them specifically) with RenderTextureSceneRenderer, one for left and one for the right side.

This one is harder to just link to a single script for, so if you want to explore it, read the README and look at the assembled scene and the graphics compositor too, the xenko docs page previously mentioned on render targets was my personal starting point and is also quite helpful.

Feel free to post if you have any questions!


I’m back again, with two small samples this time!

Trigger Scene

The first one being a small example of using a static collider as a trigger to enable/disable a door:

To see this one and how it’s put together, it’s easiest to open the project and look at the scene, it also includes a simple setup of Xenko’s own PlayerController with a capsule collider for the player so you can actually walk around in the scene.

For the actual door collider it uses two separate static colliders, one for the trigger volume, one for the actual blocking collider of the door.

Vehicle Scene

The second one being a scene with a (small) example of using physics constraints, in this case to create a vehicle (basically a solid block) that rolls on 4 cylinders:

The constraint stuff especially can be a bit confusing to work out how the reference frames work and some previous posts like: Constraint limit... In world space? helped me work it out personally, I encourage experimenting with the constraints (changing angular limits and such) to see how things behave!


Note that currently if you switch to the VehicleScene and back to any other scene, then back to VehicleScene again, it may crash (pending figuring out why this occurs).

Fixed it, just had to properly get rid of the constraints from the simulation.


Nice work and keep em coming.

1 Like

Haven’t yet looked into new examples, but I am also following the tutorial code from here https://doc.xenko.com/latest/en/manual/scripts/create-a-model-from-code.html . I see various way to put a mesh into a scene, but it seems they are not compatible with each other, such as using GeometricMeshData or by a Mesh, my concern is about index, since I don’t find a way in Mesh class use a proper vertex index with the vertex buffer, while with GeometricMeshData it’s easy, but they don’t work with each other…

The main thing to see here is that all of these end up with a MeshDraw in the bottom before anything ends up in a Model (where MeshDraw holds the associated vertex + potential index buffer objects).

I can put up a corresponding example of something like drawing a cube with a vertex + index buffer that matches the tetrahedron example if that helps? :eyes: (similar in all ways except now also employing an index buffer).

Yes, that will be helpful. Thank you.

1 Like