Feat: Improved GLTF loader, implement typed asset loading

[skairunner]

Two features:

(1) Issue #367 : I updated asset loading and implemented load_typed() to use alongside load_untyped(). I did this by changing the extensions-to-loader hashmap to have a key of (TypeId, String) instead of the previous String. This cleanly supports having multiple AssetLoader with different T but the same file extension.

(2) Implemented texture reading for GLTF.

(2a) Retouched the GLTF loading procedure so that instead of checking just the first node, it reads all nodes, meshes and textures. Then it returns just the first valid mesh/texture, depending on what you're requesting. This opens the door for potentially loading multiple assets from a GLTF file, but that is a much larger scope than this PR, because it is not possible to create and return multiple handles from within an AssetLoader at the moment.

Future work:

• This work was mostly orthogonal to loading GLTFs as scenes.
• A GLTF has to be parsed multiple times in order to get everything needed to load a model. This is highly inefficient -- as you can see in the 3d/load_model example, it takes a moment for the cubes to appear -- but as per (2a) it's not possible to easily solve right now.
• We still only allow returning the first mesh or texture from a GLTF, when it can contain any number of files.

[skairunner]

[andreasterrius]

Would this PR solve #367 ?

[skairunner]

Would this PR solve #367 ?

I think it should. You can't request, say, a Texture from a hypothetical OBJ loader because the list of extensions to loaders is keyed by type as well as extension.

[skairunner]

Merge conflict resolved.

[Lowentwickler]

One of the possible workarounds for scene loading could be a load_scene method in AssetServer that will work similar to load_from_folder, but instead of the recursive directory walk, it can open a GLTF file and walk through assets, adding them.

I have suggested to use URI-like notation to access the assets and @cart liked it. For example, if you load spider.gltf, you can access assets using artificial paths like:

• spider.gltf#model -> mesh
• spider.gltf#skin -> texture
• spider.gltf#walk -> walk animation
• spider.gltf#jump -> jump animation

Alternative to # characters could be ? or :

[skairunner]

I was going to implement the URI-like notation as well, way back when I first wrote this PR, but I ran out of steam, partially because it didn't seem like it would get accepted soon.

[cart]

Yeah sorry for not responding sooner. I intentionally put this off because the asset system is either going to be replaced by atelier-assets or modified to account for cases like this better.

I don't want to merge anything that extends and/or hacks around the current asset system, as it will almost certainly be replaced in short order.

If we go with atelier, aspects of the implementation in this pr will need to change. If we go with extending the current asset system, aspects of this pr will need to change.

Again, I'm really sorry for not keeping you in the loop. I really appreciate the work you put in here and leaving you in the dark on my current thoughts for so long was disrespectful.

[skairunner]

It's just that Ateliers been happening soon:tm: for ages, and in the meanwhile people can't load GLTF files properly. I feel like there's value in merging this PR for the here and now.

…

On Fri, Sep 18, 2020, 00:26 Carter Anderson ***@***.***> wrote: Yeah sorry for not responding sooner. I intentionally put this off because the asset system is either going to be replaced by atelier-assets or modified to account for cases like this better. I don't want to merge anything that extends and/or hacks around the current asset system, as it will almost certainly be replaced in short order. If we go with atelier, aspects of the implementation in this pr will need to change. If we go with extending the current asset system, aspects of this pr will need to change. Again, I'm really sorry for not keeping you in the loop. I really appreciate the work you put in here and leaving you in the dark on my current thoughts for so long was disrespectful. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#378 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA22VOZRQCZTTJNCM7JJ4FTSGKEINANCNFSM4QNPPSIA> .

[Lowentwickler]

I believe current bevy_asset can stay as a part of the engine for longer, even as bevy_asset_legacy or bevy_legacy/bevy_asset, being deprecated, whatever path you choose to go either rewrite or switch to atelier.

Another thought on the topic, is that it could be optional choice to stay with atelier, or native bevy_asset, or even a 3rd party bevy_asset package, because for some projects atelier could be kind of an overkill.