A collection of small Xenko usage samples


If you have GeometricMeshData then you can turn that into other pieces:

var data = GetYourGeometricMeshData();
var primitive = new GeometricPrimitive(graphicsDevice, data);
var meshDraw = primitive.ToMeshDraw();
var mesh = new Mesh(meshDraw, new ParameterCollection());

The method ToMeshDraw() on the geometric primitive is an extension method available with using Xenko.Extensions;. I really think it should be part of the class or be in the same namespace as the geometric primitives, it’s very hand and provides a place to look on how to build your own MeshDraw if you need to (such as how @profan does in his subdivided mesh example).

1 Like


There’s now a sample with both vertex + index buffer (and I may well convert my terrain sample later to use it also as it would probably save me quite a bit of data) but still :slight_smile:

(also got rid of some superfluous calls to SetData on the buffers created in the samples, as I realised the Buffer.Vertex.New, Buffer.Index.New etc upload the data for the resource in the process of creating the buffers on device as well :slight_smile: … just something you may want to look at so you’re not doing it twice if you’ve looked at the previous samples)

1 Like


Thank you, the suggestion about Xenko.Extensions it very useful!



How about a uni-directional collider?

Or one character can enter this collider or trigger, but others cannot?



You mean like, the action like opening a door should only happen for a specific character/object?



No, I’m thinking spawning. I’ve been thinking about a collider in which only a specific character can enter, it will disallow other characters.

In Xenko I use collision groups for a lot of things, I haven’t tried creating a unique collision group per character, but that would do the trick. In other words, an outer collider would only allow a specific character or physics object to enter.

This is an issue in multiplayer games when spawning units into the world space, you can either check for character proximity to a spawn before spawning, or have a custom spawn-in location per character, this prevents spawning on top of or inside of other characters.

I haven’t looked into with Xenko yet… there may be a better way to do it than collision groups.



You could have a set of possible spawnpoints, each with an associated collider for the “safe” area, so when something spawns there, you just flag the spawn as “occupied” until the given character leaves the trigger?

That way when you cycle through all possible spawn positions available you just check the occupancy flag and pick the first non-occupied one (maybe combining with some other metric if you need that?) , or thats how I would approach it if I’m understanding your problem correctly :eyes:

Alternatively, there’s probably a way to do a shape cast into the physics space before actually spawning something in right?

So you could potentially just try a set of random locations around a spawn point too until one works and doesn’t collide with something in the space



Hmm. I’m thinking a two fold approach would work best for the desired goal:

  1. Do a raycast or shape cast into the physics space, check for collisions and identify if the location is available.

  2. Slide in a spawn capsule or some other physics shape/object that will gently push any other colliders away before spawn. This would be done as secondary measure. Spawning directly into the world space using Character.Teleport() or turning on a character collider can have a drastic effect on other colliders.

On a similar note though, can you create a collider inside of another collider? Can the first collider then exit the second collider?

I have seen similar behavior with projectiles spawning inside of character colliders.

Maybe I give this a try.

1 Like


I will create an entity with a sphere collider on demand, add it to the scene, check for collisions of certain types and then remove and dispose… A poor man’s shape cast. Thanks for tossing ideas around with me.

1 Like


… Instancing? Sorta. Not Quite.

So I’m back now with yet another sample, slightly longer in the oven this time.

For a while there’d been a little misc discussion on (… somewhat) efficiently rendering a ton of little bits of geometry, but not much (or almost nothing) out there on how to actually do that, so I decided to make a sample that covers doing this with the help of streamout/transform feedback and the aid of our good @tonfilm who… kindly kept providing me VL patches and shaders of similar attempts or previous geometry shaders.

So without much further ado, here it is rendering 4096 cubes.
(the only data technically unique to each instance is the transform here)

The README expands on it a little bit more and it probably deserves a slightly more thorough explanation, but I will return and refine this, for now you can have a look if you’re interested! :slight_smile:

Miscellaneous: This demo only really covers simple meshes, no tangents and doesn’t consider materials, but one could absolutely build on this if desired (and likely there will be something semi-official soon that fills a similar usecase).

(and some changes will likely be made as long as this sample is up to improve it as well…)