bevy_gltf no longer depends or bevy_pbr or bevy_render
#5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
MaterialPropertiesfrombevy_pbrtobevy_materialbevyengine/bevy#21543bevy_gltfshouldn't require knowledge of HOW its renderedSolution
ShortStandardMaterialtobevy_material, this is a subset of fields inbevy_pbr::StandardMaterialMarkerMeshMaterial3dtobevy_material, this has aHandleto theShortStandardMaterialswap_marker_mesh_material_3dtobevy_pbrthat:MarkerMeshMaterial3dStandardMaterialfrom theShortStandardMaterialMarkerMeshMaterial3dMeshMaterial3dwith the newStandardMaterialPlease bikeshed
ShortStandardMaterialandMarkerMeshMaterial3dAbove removes the direct dependency, but adds an indirect one.
Alternative
I could move
ShortStandardMaterialtobevy_gltf(rename itGltfMaterial) , and then have a new cratebevy_gltf_renderthat depends onbevy_pbr, and somehow splitload_nodeto add theMeshMaterial3d, but that would be a much larger change. I think this is simplerSee #6
Testing
cargo run --example load_gltf