bevyengine / bevyengine/bevy

bevy_gltf improvements to decouple it from scene creation

Open
#13,681 5 comments 5 reactions 0 assignees View on GitHub
A-glTF C-Feature
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 16h
Merged PRs (30d)
171

Description

## What problem does this solve or what need does it fill?

Currently lots of logic related to gLTF loading is embedded into scene creation within the loader. This means one can't easily customize how the scene creation happens. My plan is to add addition metadata / information to the gLTF assets so that it's possible to recreate scene creation logic in a loader with customized logic, eg to spawn it differently, to spawn a subset of gLTF scene or to spawn a subtree starting from arbitrary node in gLTF.

This is the first part of this: https://github.com/bevyengine/bevy/pull/13558

## What solution would you like?

### Stage 1 - concrete

Add necessary metadata to gLTF asset types.

0. Add tests to bevy_gltf that loads various gltf files and checks that assets are good.
1. Make children of nodes, meshes etc be handles, not direct objects to avoid copying in scene creation. *breaking change*
2. Add GltfSkinnedMesh type that wraps skinned mesh information.
3. Add a boolean field to indicate if a node is an animation root. Add handles to AnimationClips that this one is root for.
4. Add animation target id field to node if it's an animation target.
5. Add morph weights to GltfMesh.
6. Add bounding box / aabb to GltfMesh.
7. Add camera to Node and GltfCamera type (if needed - maybe just Camera bundle inside asset?).
8. Add light to Node and GtlfLight type (if needed - maybe just corresponding light bundle inside asset?)
9. ??? Whatever other info that is implicitly created in load_node of scene creator, but not stored in Gltf Assets.

Other considerations that might be good

1. Add a handle wrapper / handle component to all entities we spawn from gLTF, so that they have handle back to gLTF node/mesh and can access information for it. Deprecate "Gltf*Extras" components as they wouldn't be needed.

### Stage 2 - decoupling scenes from loader

Don't create scene when loading gLTF (maybe as an option). Add GltfScene asset. Add function to create Bevy scene from a GltfScene (or GltfNode) object and its tree.

Generally each gLTF asset should have a way to spawn it in Bevy - but I assume some of those would make less sense, eg you can't spawn a node with skinned mesh when you don't spawn bones - should be protect against that?

Add examples and documentation of how to better handle gLTF loading without importing the whole scene.

## What alternative(s) have you considered?

There is bevy_scene_hook that hooks into scene creation after it has been created. The problems with this solution is that you can't control which nodes to not spawn and it happens in systems after the initial spawn, possibly missing some frames. In addition, you need to rely on spawned node names to do your logic.

@ricky26 suggested not loading gLTF resources as assets at all, but instead using asset transformation pipeline to convert gLTF to Bevy native types. That is one option to look at, however that won't allow flexible spawning of sub trees without overriding the whole SceneProcessor. This limits the way one could possibly use gLTF as, eg, a mesh library. In addition asset processors don't support subassets right now so there is a lot of new API surface area needed in Bevy.

## Additional context

- Adding names and labels to gltf: https://github.com/bevyengine/bevy/pull/13558

Contributor guide

Open the contributing guide

Research direction

Read the bevy_gltf loader, especially load_node, and compare the requested metadata with PR #13558. Use the listed Stage 1 asset types and tests as the initial scope; completion would require covering the agreed metadata and validating it with glTF loading tests before the Stage 2 decoupling work.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
game-dev
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.