make more information available from loaded GLTF model#1020
make more information available from loaded GLTF model#1020cart merged 7 commits intobevyengine:masterfrom
Conversation
|
CI failures are due to formatting error in bevy_render, seems like macro |
ambeeeeee
left a comment
There was a problem hiding this comment.
The code changes look good, but I'm not familiar enough with GLTF to comment on much more.
|
I like the idea of exposing more information, but I think we could make this a bit cleaner by addressing an issue with how I implemented the loader: right now it assumes that the scene is the top-level asset. This is problematic for two reasons:
I propose something like the following: #[derive(Debug, TypeUuid)]
#[uuid = "5c7d5f8a-f7b0-4e45-a09e-406c0372fea2"]
struct Gltf {
scenes: Vec<Handle<Scene>>
meshes: Vec<Handle<Mesh>>
materials: Vec<Handle<Material>>
nodes: Vec<GltfNode>,
}This would be the "default" asset returned, instead of a single Scene. It would have a number of benefits:
The downside is that we could no longer do this: commands.spawn_scene(server.load("my.gltf"))But this is almost as good, and is more "correct": commands.spawn_scene(server.load("my.gltf#Scene0"))Thoughts? |
|
The Then we could add the |
|
didn't want to break everything as I was discovering GLTF, but that look's better to me! |
|
I changed the object to be returned when loading a gltf to: in a separate commit I also added the on a gltf file I have, this gives me extra information which looks useful: I have sometimes a crash when I launch example on a crash: also there is a conflict with #1016 that I'll fix tomorrow but I would appreciate some feedback as the PR is getting bigger |
|
Yup so far these changes are looking great! |
|
fixed the conflict. for I would have liked The other way around this would be to have a |
|
should not be merged before #1142 due to |
|
Cool these changes look good to me. I suspect that all of this sorting / hierarchy navigation / allocation might be a bit expensive when loading large gltf files, but this is such a clear usability improvement that I'm down to have that conversation if/when it becomes an issue. |
|
I just merged #1109. Feel free to follow up with Name changes if you feel so inclined 😄 |
| } | ||
|
|
||
| pub fn set_labeled_asset(&mut self, label: &str, asset: LoadedAsset) { | ||
| pub fn set_labeled_asset<T: Asset>(&mut self, label: &str, asset: LoadedAsset) -> Handle<T> { |
There was a problem hiding this comment.
This change makes this kind of code fail compilation:
load_context.set_labeled_asset("cube", LoadedAsset::new(mesh));Is there a way to not be bothered with specifying the T parameter?
There was a problem hiding this comment.
Hmm yeah that is suboptimal. Its both less ergonomic and creates a class of bug where the user specifies the wrong asset type.
We could make it LoadedAsset<T>, then created a BoxedLoadedAsset that we coerce it into within set_labeled_asset
makes node information available as
"path/to/file.gltf#Node0"this helps the user select correct meshes and their transform between each other when picking nodes out of a gltf file
makes list of primitives per mesh and their material available as
"path/to/file.gltf#Mesh0"this lets the user get all the primitives for a mesh with the correct material
I am not sure about the asset type names,
Gltf*, but didn't want confusion with the existingNodeandMeshtypes