@domj for xenko, assets are just assets. so the question left is how to tell the system whats available, and this is very well possible at runtime (xenko’s game studio is a game where assets get added while it’s running). so no worries about that.

but let’s compare referencing files by path to using an asset manager/compiler in a general way. we already though a lot about that and it’s not an easy topic because there are many things to consider that are not clear at first.

of course we all want that easy drag’n’drop behavior for textures, models and so on for sketches and beginner workshops. that’s clear and we will implement it.

however, for bigger projects with tons of assets that’s a tedious workflow, especially when things need to change during development. we all know the struggle from vvvv beta.

referencing random files from your hard drive will make an application (at first) only run on your machine. so you need to be quite organized in the first place to have everything set up with relative paths. you also need to take care of copying the assets over to another machine and there is no system that helps you to identify missing assets. if you move files, exchange files or you rename files you need to go to every place in your patch and fix the file references, this can become a major pain (unless you develop your own content management system).

an asset manager/compiler solves this in an elegant way, it kind of makes the files part of your code/patch. this is a huge advantage because now the system is aware of the assets and error reporting becomes possible. not only that, the asset compiler also takes care of making the files correctly available in the output folder of the executable you will export later. and instead of referencing assets by path on disc, the asset manager gives you an internal URL for each asset that will not change during development. so you can do whatever changes you want to the files and you only need to tell the changes to the asset manager at a central place.

another thing where xenko’s asset manager helps a lot is importing complex assets. think of models that contain skeletons, animations and materials. they need to be prepared so that they are easy to use in the patch. the asset manager let’s you for example assign skeletons and animations, let’s you rename the elements and set properties like color space, compression and other ‘static’ things that are otherwise tedious to do in a patch.

so the optimal way is to have xenko’s asset manager working at runtime and then also use it when exporting an executable. that’s what we are aiming for, but it still needs some development from our side. on the other hand, i think the import asset by file path will be there quite soon.

that leaves the dynamic assets you mentioned. i assume that you mean files that change after you exported an executable. for them you can only go the relative file path way or have a file dialog built into your application to select them. there is no restriction that allows only one way of working.

@tonfilm Wow, thanks for the detailed reply. Glad to hear it’s this flexible and there’s definitely a way.

I’m thinking of using the VL.Xenko integration for implementing a visualisation tool for my VL light control software. Ideally I would be loading models on the fly based on the actual used fixtures. There is the GDTF format for describing light fixtures, which is basically a zip of XML definition, 3d models in .3ds format and other stuff. So I’m imagining a system basically working as the Half-Life/Source/CS downloading asset loader. Load the fixture layout (level) and all missing assets (fixtures, animations, etc.) are downloaded from a server, unzipped and loaded into Xenko at realtime. By the sound of it, this all should be fairly possible.

It would be pretty amazing if you managed to release a preview version of VL.Xenko as well. I think everyone understands it’s absolutely bleeding and edge and in many cases experimental and there might be regressions during updates. But it already looks like it could be put to great use and this way many of the approaches you guys are taking could be tested by the wider community.

very nice

yes, big thanks to @u7angel for the invitation and organization!

video entry points are:

vvvv gamma workshop: https://youtu.be/2TGMjryZPPc

making-of “We Live In An Ocean Of Air”: https://youtu.be/0laS6O0ET0w

VL.Xenko demo: https://youtu.be/KgkdLZg7BZw

Just finished watching the Ocean of Air and Xenko demos.

The amount of detail in the Ocean of Air is absolutely mindblowing! Great job!

General Xenko demo was also very impressive but these questions came to my mind: What’s the imagined workflow for dealing with assets and other items only editable from the editor? Right now it seems that you have to open the editor, edit scene, recompile and then start the integration from VS?

Have you also considered some way to deal with dynamic assets - eg. loading models not packaged with the game? While this is super easy with vvvv beta, here it seems somewhat of a challenge. According to the Xenko docs an asset has to be included in the build to be able to load it from code (https://doc.xenko.com/latest/en/manual/game-studio/manage-assets.html). For many projects I can imagine the models to display will not be known at compile time (eg. generic stage previs). Will this require implementing a separate asset management pipeline with new shaders and entities that loads geometry data from files into memory and displays it or is there ways to still leverage Xenko’s rendering pipeline by somehow registering new assets at runtime?

Also +1 for the GPU integration of Skia.

Big thanks for streaming these!