lo48576 / fbxcel-dom

FBX DOM library for Rust. // See https://github.com/lo48576/fbx-viewer for working example application // rework (total rewrite) is planned

fbxcel-dom

fbxcel-dom is an FBX DOM library for Rust programming language.

For low-level features, use fbxcel crate.

Note that this crate is highly experimental and updated frequently with breaking changes (especially for objects-related APIs).

Features

• Only read-only operations are supported.
• Low-level tree traversal.
• Objects and connections traversal.
• Easy property access for some fundamental object types.
  • Geometry, material, texture, etc.

FBX versions

• FBX 6 or below is not supported.
• FBX 7.0 to 7.3 is not explicitly supported, but you can try FBX 7.4 feature to load them.
• FBX 7.4 and 7.5 is supported.

FBX format

Only FBX binary format is supported.

Currently there is no plan to support FBX ASCII format.

Rust version

Rust 1.56 or later is supported.

License

Licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE.txt or https://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT.txt or https://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

fbxcel-dom's Issues

Avoid Deref polymorphism

std::ops::Deref should be only used for smart pointer types, and it is considered as an anti pattern to use it to "derive" parent type.

• Deref Polymorphism - Rust Design Patterns
• std::ops::Deref - Rust

Deref should only be implemented for smart pointers to avoid confusion.

--- https://doc.rust-lang.org/stable/std/ops/trait.Deref.html

Currently, some object types abuse Deref trait, and this use of Deref should be removed in future.

• v7400::object::**::*Handle (including ObjectHandle)
  • So many types!
• v7400::data::mesh::layer::*Handle (including tree::v7400::NodeHandle)

Getting transformation data of an node

In FBX-SDK we can get the transformation data of an node like this:

const FbxVector4 lT = pNode->GetGeometricTranslation(FbxNode::eSourcePivot);
const FbxVector4 lR = pNode->GetGeometricRotation(FbxNode::eSourcePivot);
const FbxVector4 lS = pNode->GetGeometricScaling(FbxNode::eSourcePivot);

Is there any way to access the same using fbxcel-dom? I searched the documentation and examples, but could not find an equivalent.
Without being able to access the transformation of an MeshHandle, the pivot of all objects in the scene becomes the same (0, 0, 0) and hence submeshes can not be translated/rotated to their global position correctly.

Add more examples

Specifically, an example of how to load a mesh made of n-gons and different indices for normal/uv data. How would I get to the data of such a mesh?

I.e. I do not want a triangulated mesh, I want the original n-gon data.

On that note: does fbxcel have options to fix meshes with disconnected faces on import? I.e. if a mesh has faces referring to different vertices in the index but the positions of these vertices are equal, in 3D?

Easy Traversal of Scene Graph?

It looks like there's no functionality to traverse a scene graph (ie. parent/child connections). Is that correct? Just checking in case I'm blind, before I implement it myself.

I see the connections iterator on objects, just not an easy way to, for instance, get the root objects of the scene or get the parent of an existing object.

Negative index not allowed

Hello, I'm co-author of bevy_fbx plugin for loading FBX in Bevy Engine, which is heavly based on your fbx-viewer code.

While trying to load Bistro Scene from Amazon's Lumberyard demo, I'm getting following error

2022-07-12T13:01:02.864866Z ERROR bevy_fbx::loader: failed to load "BistroInterior_Wine.fbx"

Caused by:
    0: Failed to load geometry mesh
    1: Failed to reconstruct UV vertices
    2: Negative index is not allowed: direct=-1

For us, it looks like UB caused by FBX file (v7.5) from Amazon and I would like to know if you have any info of how we could fix this problem, either in fbxcel(-dom) or our loader.

According to Autodesk forums, FBX uses negative values in PolygonVertexIndex which then have to be turned into possitive ones by reader.

the negative values in PolygonVertexIndex are just used to indicate the end of a polygon.
It will be converted to a positive value by fbxreader according to certain rules.
So you do not need to worry about them, as long as you import the FBX file, the reader will take care.

Already tried exporting it as v7.4 and changing settings in Cinema4D and that didn't helped.

Does this crate support `Animations`?

Compile error

When I use this crate, this compile error shows

error: 1 positional argument in format string, but no arguments were given
   --> src\v7400\data\mesh\layer\common.rs:248:89
    |
248 |             MappingMode::None | MappingMode::ByEdge => bail!("Unsupported mapping mode: {:?}"),
    |                                                                                         ^^^^

error: could not compile `fbxcel-dom` due to previous error

This error exists for 0.0.6, 0.0.5 and the develop branch.

Remove dependency to `failure`

failure depends on backtrace crate when std feature is enabled, but it prevents me from testing dependencies with minimal versions (by cargo +nightly update -Z minimal-versions && cargo test --all-features).
(See rust-lang-deprecated/failure#310 for detail.)

Additionally, std Error trait are being improved and it would be useful enough (see rust-lang/rust#53487).
So it would be better to use simpler error types, rather than error types with many features and extra APIs, to avoid providing unnecessary functionalities and keeping their compatibilities.

I'll use anyhow or thiserror, but it is not yet decided.

Hi, how to get fbx models skeleton and what's more even modify the skeleton names?

Hi, how to get fbx models skeleton and what's more even modify the skeleton names?

Total rewrite

Yeah I know this is generally bad thing to do, but I'm seriously considering rewriting this crate.
3+ years of Rust experience since the first release of this crate (and more years since the release of the predecessor) told me I can (and should) provide better API...

I'll track the progress in this issue.