nicopap / bevy_mod_fbx Goto Github PK

Hey @nicopap
Are you interested in incorporating this work into SpaceEditor?
You have done quite a lot and we could help you maintain this up to date and develop there

FBX is extensible, and it seems each vendor provide their own material extension.

For example, maya's PBR is implemented as an extension, it uses custom properties and texture fields unique to their materials.

I expect this is not only true of maya, and I expect that users of this library will want to load any arbitrary materials.

This is why a custom extensible material loader would be useful.

My current take is define a struct with a few function pointer fields:

/// Load materials from an FBX file.
///
/// Define your own to extend `bevy_fbx`'s material loading capabilities.
#[derive(Clone, Copy)]
pub struct MaterialLoader {
    /// The FBX texture field name used by the material you are loading.
    ///
    /// They are loaded by the [`FbxLoader`] and provided to the other functions
    /// defined in the rest of this struct, associated with their names in a `HashMap`.
    // TODO: probably replace this with a fn(MaterialHandle) -> Vec<TextureHandle>
    // and provide a fn that replaces &[&str]
    pub to_load: &'static [&'static str],
    /// Run some math on the loaded textures, handy if you have to convert between texture
    /// formats or swap color channels.
    ///
    /// Set this to None if you don't intend to pre-process textures
    /// referenced in the FBX file.
    /// This allows caching and re-using of textures, avoiding costly
    /// read from disk of the entire texture.
    // TODO: consider delegating to this the transform from {str->Image} to {str->Handle<Image>}
    #[allow(clippy::type_complexity)]
    pub preprocess_textures: Option<fn(MaterialHandle, &mut HashMap<&'static str, Image>)>,
    /// Create and return the bevy [`StandardMaterial`] based on the [`Handle<Image>`] loaded
    /// from the return value of `preprocess_textures`.
    pub with_textures:
        fn(MaterialHandle, HashMap<&'static str, Handle<Image>>) -> Option<StandardMaterial>,
}

and provide default implementations for Lambert/Phong and an ultimate white clay fallback. This seems to work quite nicely.

This is tracking issue for myself or anyone with access to closed source software which uses FBX SDK for exporting, such as:

• Cinema4D S26
• Rhinoceros 7
• Autodesk Maya 2022
• Autodesk 3ds Max 2022

(Blender uses reverse engieered exporter which may cause issues)

I don't really want to vendor different scenes from the internet which may cause issues with licensing which are usually unclear or scenes on various websites are vendored from different ones without any licensing info.

NOTE: Each scene must be <100mb and exported as FBX 7.4 (bin, not ASCII).

Example scenes:

• Isometric room
• Old vehicle (like multicar/fiat 125p)
• Simple biome (textured/low poly)
• Simple viking village (low poly, entities)
• Post-apo village/city (like Jackson or part of Boston/Seattle but low poly/voxel)

Currently, the fbx scale is hard-coded to 100. It's fine as is, since it's the default, but a file where the scale is different will load incorrectly and appear tinny or giant when it shouldn't.

See:

• lo48576/fbxcel-dom#7

fbx_validate should log to console information if given version of given fbx file is supported and exit if not.

Prevent future naming problems on crates.io.

• repository name
• crate name

Bevy uses tracing spans for easier debugging of runtimes.

We use the trace! macro to check which function we enter/leave. There is absolutely no reason to not use tracing spans instead.

FBX has configurable coordinate space, the file itself specify which axis is up, forward etc. Most things that export to FBX currently uses the same coordinate space as bevy, so no further action is required for most models. But when bevy_mod_fbx encounters a file that doesn't use the same coordinate space as bevy, the model will not look properly forward.

Solutions

Models in bevy_mod_fbx are already spawned with a parent transform, to accommodate scale declared with UnitScale. So we should probably rotate this transform to properly align the model into the bevy coordinate space.

Issue with that solution is situations where the model is mirrored, in which case we'll probably create a shear, which will prevent using the transform_scale_rotation methods on GlobalTransform

Currently our dependency fbxcel_dom doesn't support all kind of normals indexing. Can get sometimes get the following error:

Unsupported reference mode for normals: IndexToDirect

Implementation leads:

• https://banexdevblog.wordpress.com/2014/06/23/a-quick-tutorial-about-the-fbx-ascii-format/

FBX has a scene tree similar to bevy's hierarchy. Currently we do not use it in any way.

The scene tree describes transforms applied to objects. The bistro scene relies on it for example to properly rotate the scene.

Bone transforms are (probably) also described in terms of parent/child relationships, so a solid support of the scene tree is a necessary condition to start supporting animations.

fbxcel_dom currently exposes the scene tree as the Tree data structure accessible through Document::tree. An issue I think this has is that it doesn't expose the tree nodes as ObjectHandle (there is good reasons for this), making it impossible to use the "fallback" values defined at the global level.

• Prerequisite of #13
• Could be helped by lo48576/fbxcel-dom#2

Ideal integration requires rewrite of all math related code in data, utils and triangulator to use bevy_math instead of cgmath.