vvvv Gamma PresentationApril 17, 2019 posted by: u7angel Guest Post
We are very lucky to host the first vvvv gamma workshop at the Muthesius Kunsthochschule in Kiel. Joreg and Tebjan will give a 3 hour introduction into the vvvv future. Since we use vvvv a lot at the university, it makes totally sense to check out, what we can do with the next big thing.
There are still some seats left.
Where ? - Prototyping Lab, Werkstattgebäude When ? - Thursday 18th of april, starting 2pm
In case you don’t want to patch but just listen to what will come, you are invited to the evening presentation. The boys will give us a making-off presentation of Ocean Of Air, the first ever project realized with vvvv gamma and the upcoming Xenko 3d engine integration. (sentence stolen from the other news post ;)
Where ? - mainbuilding,ZFM Medienseminarraum EG When ? Thursday 18th of april, starting 7pm
See you there
Comments are no longer accepted for this post.
@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.
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!