facebookincubator / fbx2gltf Goto Github PK

The tool still invariably creates 16-bit indices, and thus also often splits large FBX meshes into smaller glTF meshes. I'm currently thinking:

• FBX2glTF --use-short-indices
  • force 16-bit indices
• FBX2glTF --use-long-indices # force 32-bit indices
  • force 32-bit indices

Without either option, the tool should choose 16-bit or 32-bit on a mesh-by-mesh basis, depending on which would be most economical.

mutant_walking.zip

Hey Zellski,

My fbx converter (open sourced on github soon) is having the same above issue as yours with this file. But the windows "FBX Review" program shows the model correctly. I'm curious your thoughts on why.

Chip

Surfaces with negative scale end up with backwards normals after conversion.

When downloading the Darwin (macOS) binary i get a 'Segmentation fault' when trying to convert an FBX file.

Defaulting to --pbr-metallic-roughness material support.
Loading FBX File: /my-fbx.fbx
node 0: /RootNode
node 1: /RootNode/scene
node 2: /RootNode/scene/xxxx
node 3: /RootNode/scene/xxxx
node 4: /RootNode/scene/xxxx
node 5: /RootNode/scene/xxxx
node 6: /RootNode/scene/xxxx
node 7: /RootNode/scene/xxxx
node 8: /RootNode/scene/xxxx
node 9: /RootNode/scene/xxxx
node 10: /RootNode/scene/xxxx
mesh 0: xxxx (skinned: NO)
mesh 1: xxxx (skinned: NO)
mesh 2: xxxx (skinned: NO)
mesh 3: xxxx (skinned: NO)
mesh 4: xxxx (skinned: NO)
[1]    962 segmentation fault  ./FBX2glTF /my-fbx.fbx

Note, I obscured my layer names to xxxx.

Also, before I could run the command: ./FBX2glTF /my-fbx.fbx -v I had to modify the Darwin executable like so: chmod u+x ./FBX2glTF

The NPM README lacks any instructions at all on how to use the code. Let's at least add a simple API usage example (which probably suffices for a module that exports a single function as the sum total of its API).

Docs (just put 'em in the README):

/**
 * Converts an FBX to a GLTF or GLB file.
 * @param srcPath path to the source FBX file.
 * @param destPath path to which to write the converted GLTF or GLB file.
 * @param [args] optional array of arguments to pass to the converter tool.
 * @param [cwd] optional current working directory from which to run the tool.
 * @return Promise<string> a promise that resolves to `destPath` when conversion
 * completes, or an error if conversion fails.
 */
convert(srcPath, destPath, args, cwd)

Example:

const convert = require('fbx2gltf');
convert('path/to/some.fbx', 'path/to/target.glb', ['--binary', '--flip-v']).then(
  destPath => {
    // yay, do what we will with our shiny new GLTF or GLB file!
  },
  error => {
    // ack, conversion failed: inspect 'error' for details
  }
);

I am trying to export a rigged character model with no animations (the bone positions will be driven directly). The skins and bone weights are exported properly from Maya to FBX, but the FBX file also includes a default animation which seems impossible to disable. This default animation results in the following output:

"animations": [
  {
    "channels": [],
    "name": "Take 001",
    "samplers": []
  }
]

In the event that an animation has zero channels or zero samplers, I believe we should skip that animation and output a warning Ex. Warning: animation "Take 001" has zero channels. Skipping.

The glTF spec specifies that there must be a minimum of 1 channel and 1 sampler per animation, so I think skipping the animation and outputting a warning is a good solution.

I'll start work on this. Let me know if you have any concerns.

glTF allows to have several Nodes sharing the same Mesh.

It would be great if FBX2glTF supports that feature :)
Several FbxNode instances can share the same FbxMesh (obtained by the getMesh() method), but right now the code allways creates a new mesh, instead of using the mesh created before in that cases (File: Fbx2Raw.cpp, line 895)

Best regards,
David Ávila Membrives
Wave Engine team member

I'm attempting to convert an FBX to glTF where I have a head and hands mesh skinned to a simple skeleton. The FBX has both the mesh and the skeleton at a scale of 1,1,1. For clarity, I've made sure that the transforms are frozen before skinning. However, when it gets converted to glTF, a root node gets created and the first children under that parent get automatically scaled down to 0.01-- in this case, both the first bone in my skeleton as well as the mesh itself. I'm not sure if this is expected behavior, but it seems like a bug. That, or perhaps the converter is expecting a special kind of hierarchy that I'm not setting up properly. Here is one of the questionable snippets of the glTF:

            "children": [
                2,
                3
            ],
            "name": "Neck",
            "rotation": [
                0.0,
                0.0,
                0.0,
                1.0
            ],
            "scale": [
                0.00999999977648258,
                0.00999999977648258,
                0.00999999977648258
            ],
            "translation": [
                -2.09076537947193e-18,
                0.0147347003221512,
                0.0
            ]
        },

In Modo, if you have an object with a 0% scale, the FBX generates an invalid rotation matrix full of NaN. I'm not sure if this is an FBX issue, or with the code that parses FBX into the internal format of FBX2glTF, but in any case. we should throw an error, or at least a warning instead of outputting invalid gltf
LookDownOnLiftedCube.fbx.zip

--compute-mormals
should be : --compute-normals

Attempting to execute

FBX2glTF-windows-x64.exe "C:\Users\VoidFletcher\Documents\EterniumBottle\eterniumbottles.fbx" -b

results in a crash as seen below. This issue is not present in version 0.9.3

I am trying to use gltf to store several meshes as the key frame for a animated model. The model is single mesh but each of its pose's mesh are also stored in the file.

So first I get all these meshes aligned and to fbx. And use fbx to gltf converter. However I notice that the accessor of gltf shows more vertices number than the original. For instance' a 8 vertices cube now in gltf has 24 vertices. So seems there is some extra vertices generation.

What is the reason for that?

And the big issue is that the index accessor, although have the same length among the key frames, do not have extract same index value. So the one to one map of index is not maintained.

What should I do to keep index map same among key frames?

Thank you.

The Node API is currently admirably simple, but with a tiny bit of effort it could achieve greater flexibility while retaining its simplicity. Let's:

• Modify the scripts to pass their own command line args through to the tool.
• Modify the scripts to not assume the target file suffix is .glb.
• Name the exported function convert instead of fbx2glb, since we're not going to assume a GLB is being generated.
• Allow args to be supplied to the tool via the exported convert function.

Hey, I think it doesn't export light and camera yet ?

The automatic separation we already do for transparent textures (as well as many other material differences) of one source RawModel (based on an original FBX mesh) into multiple (ready for glTF output), we should considering extending to vertex colour.

Hi! I have a problem now using FBX2glTF.
First time I tried to make .fbx to .glb in dos it worked but it told me this:

C:\PATH>FBX2glTF-windows-x64.exe \3d_NAME.fbx -b
Warning: node /RootNode/Active Camera uses unsupported transform inheritance type 'eInheritRrSs'.
         (Further warnings of this type squelched.)
Wrote 804613 bytes of binary glTF to ./3d_NAME.glb.

and then even I'm Admin, I everytime have access denied

C:\PATH>FBX2glTF-windows-x64.exe \3d_NAME.fbx -b
Access denied.

I added the softwear autorization in the firewall but it still doesn't work...
Have you encounter this problem?

Thanks a lot,
Grebert

I'm having issues converting an FBX with textures. Given this model: https://free3d.com/3d-model/batman70-68300.html

FBX2glTF --input ./BAC_Batman70s_rocksteady/batman70.fbx  --output /tmp/Batman

The output is

Warning: could not find a local image file for texture: file4.
Original filename: /Users/jvanderdoes/Downloads/BAC_Batman70s_rocksteady/Batman_V3_Cape_DS_1-4_D.tga
Warning: could not find a local image file for texture: file3.
Original filename: /Users/jvanderdoes/Downloads/BAC_Batman70s_rocksteady/Batman_V3_Cape_DS_1-4_D.tga
Warning: could not find a local image file for texture: file1.
Original filename: /Users/jvanderdoes/Downloads/BAC_Batman70s_rocksteady/DLC3_Batman1970_head_D.tga
Warning: could not find a local image file for texture: file2.
Original filename: /Users/jvanderdoes/Downloads/BAC_Batman70s_rocksteady/DLC3_Batman1970_leg_D.tga
Warning: could not find a local image file for texture: file5.
Original filename: /Users/jvanderdoes/Downloads/BAC_Batman70s_rocksteady/DLC3_Batman1970_torso_D.tga
Warning: Mat [Cape2]: Can't handle texture for TransparentColor; discarding.
Warning: Mat [Cape1]: Can't handle texture for TransparentColor; discarding.
Warning: animation 'Take 001' has zero channels. Skipping.
Wrote 12853 bytes of glTF to /tmp/Batman_out/Batman.gltf.
Wrote 395644 bytes of binary data to /tmp/Batman_out/buffer.bin.

What's confusing is that those are valid file paths, so I'm not sure why it is having issues finding the textures.

The exported .glb files don't seem to work in anything that uses ThreeJS GLTFLoader. Babylon.JS seems to work fine. Trying to hunt down the root cause, but could use some help.

Here's a test model with the .glb as well as source assets (don't mind the weird UV mapping).

Head.zip

It looks like FBX2glTF can quite easily export zero-length normals, which is not allowed by glTF spec. We should replace those with computed normals.

We currently step through each clip's duration at a constant rate, ask the FBX SDK to calculate the transform of every node, and slam any non-trivial values into a buffer. This leads to enormous files for complex figures. There are many cases now where we can probably represent the animations much more like they're structured in the FBX world.

The main complexity (apart from just writing lots of new code) is probably the bewildering array of features FBX offers for cubic interpolation mode, most of them having to do with the behavior of tangents around keyframes. Figuring out which of them can be represented in glTF (and with how much work) might be non-trivial.

I get the following errors when trying to validate the GLB created using the converter:

"Your GLB File has the following errors: The 3D model could not be posted: This model file is invalid."

For each of 3 images I get this error:

"Unsupported image type 'gif'"

I exported an FBX through Maya 2016 using JPEG textures and cannot figure where the GIF errors are coming from.

Hello again!

In a FbxMesh with multiple DiffuseTexture UV maps (layers), have you figured out how to know which FbxTexture goes with each UV map?

Build successfully with Visual Studio 2017, but when use Debug->Start new instance，(with fbx file path and options presented in debug params) the Visual studio pop up a message box sayng "HEAP CORRUPTION DETECTED after normal block (#41458) at 0x00002149846C820...". And this message box cannot be closed by push close, retry or ignore button as normal.
I have updated the Visual Studio to 2017 v 15.5.7, but still cannot fix this. And my system is Windows 10.
I got same error while using the debug version .exe file generated by my Visual Studio, but with release version, the error may not appear.

FBX2glTF support skin animation, why do I turn over 3ds max2017 fang binxing, after converted into GLTF didn't see the model on the cesium, but no skin animation model can show, but some became transparent like model. Why is that? Is it something to pay attention to when saving FBX?

Compiler cannot determine the type of vertices.size(). It compiles if I cast it to a float... Not sure what is the correct fix.

averagePos += (vertex.position / vertices.size());

https://github.com/facebookincubator/FBX2glTF/blob/master/src/RawModel.cpp#L597

bazel build //:com_chibifire_fbx_importer.dll
INFO: Analysed target //:com_chibifire_fbx_importer.dll (0 packages loaded).
INFO: Found 1 target...
ERROR: D:/godot/com-chibifire-godot/addons/com-chibifire-fbx-plugin/BUILD:68:1: C++ compilation of rule '//:libFBX2glTF' failed (Exit 2)
c:\users\fire\appdata\local\temp\_bazel_fire\amzgrobr\execroot\__main__\thirdparty\fbx2gltf\src\FBX2glTF.h(17): warning C4005: 'NOMINMAX': macro redefinition
c:\users\fire\appdata\local\temp\_bazel_fire\amzgrobr\execroot\__main__\thirdparty\fbx2gltf\src\FBX2glTF.h(17): note: command-line arguments:  see previous definition of 'NOMINMAX'
thirdparty/FBX2glTF/src/RawModel.cpp(597): error C2782: 'mathfu::Vector<T,d> mathfu::operator /(const mathfu::Vector<T,d> &,const T &)': template parameter 'T' is ambiguous
C:\users\fire\appdata\local\temp\_bazel_fire\amzgrobr\execroot\__main__\thirdparty\mathfu\include\mathfu/vector.h(556): note: see declaration of 'mathfu::operator /'
thirdparty/FBX2glTF/src/RawModel.cpp(597): note: could be 'unsigned __int64'
thirdparty/FBX2glTF/src/RawModel.cpp(597): note: or       'float'
thirdparty/FBX2glTF/src/RawModel.cpp(597): error C2784: 'mathfu::Vector<T,d> mathfu::operator /(const mathfu::Vector<T,d> &,const T &)': could not deduce template argument for 'const T &' from 'unsigned __int64'
C:\users\fire\appdata\local\temp\_bazel_fire\amzgrobr\execroot\__main__\thirdparty\mathfu\include\mathfu/vector.h(556): note: see declaration of 'mathfu::operator /'
thirdparty/FBX2glTF/src/RawModel.cpp(597): error C2784: 'mathfu::Vector<T,d> mathfu::operator /(const mathfu::Vector<T,d> &,const mathfu::Vector<T,d> &)': could not deduce template argument for 'const mathfu::Vector<T,d> &' from 'unsigned __int64'
C:\users\fire\appdata\local\temp\_bazel_fire\amzgrobr\execroot\__main__\thirdparty\mathfu\include\mathfu/vector.h(601): note: see declaration of 'mathfu::operator /'
thirdparty/FBX2glTF/src/RawModel.cpp(597): error C2676: binary '/': 'Vec3f' does not define this operator or a conversion to a type acceptable to the predefined operator
cl : Command line warning D9025 : overriding '/Od' with '/O2'
Target //:com_chibifire_fbx_importer.dll failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 2.644s, Critical Path: 2.14s
FAILED: Build did NOT complete successfully

It would be immensely useful for artist workflows to be able to drag an FBX into a browser window and have it immediately available as a glTF file & a live preview. The NPM package already has a little API for executing the binaries in a cross-platform way. Adding the rest of the functionality should be relatively simple. We may be able to usefully harness the power of https://github.com/donmccurdy/three-gltf-viewer for effort-saving purposes.,

I exported an FBX from Maya LT with "embedded media". When I convert the FBX to gltf it appears to see the textures, unlike #54, but when it copies the textures it converts them to pure white pngs.

The FBX is here: https://storage.googleapis.com/blocker-gltf-test/GenericCameraFBX/GenericCameraEmbedded.fbx

And inside of a GenericCameraEmbedded.fbm director is this texture https://storage.googleapis.com/blocker-gltf-test/GenericCameraFBX/GenericCameraEmbedded.fbm/CameraTexture.jpg

• Running on a mac
• Latest release of FBX2glTF

The PNGs we write now are quite bloated; STB's image_write.h, which we use now, is a small header-only library that does not go to great lengths to minimise output file size.

An obvious candidate for maps that represent colours (albedo, emissive, etc) is this quantisation library, which underlies pngquant, one of the better CLI applications for smashing pre-existing PNGs where you're okay with an 8-bit palette.

For the general lossless case there's a huge survey here.

The way animations are handle in Fbx2Raw goes something like this:

• For all the FbxAnimStacks in the scene,
  • Use SetCurrentAnimationStack to prepare the evaluater
  • Use the associated FbxTakeInfo struct to get time/frame data
  • Create a channel for and iterate through all the FbxNodes in the scene
    • Evaluate the "default" transform of the FbxNode and save it
    • For each of the frames in the animation,
      • Fill the channel with data from the evaluated transform of the node at the given time/frame
      • Compare this result to the "default".
      • If they are different, add this node's transform data to the Raw animation channel

This algorithm is not working for me. I have an FBX model (exported from Maya using its GameExporter) of a humanoid with left and right hand animations on separate FbxAnimStacks. Each animation (open_L, open_R, fist_L, fist_R, point_L, point_R, etc.) was created to only affect the rotation of certain bones in my skeleton. The "default" transform for each of the FbxNodes in the algorithm above is whatever the transform of that bone happens to be when I export from Maya. (All of the animations are on a single timeline in Maya, so if I slide along the timeline I see all of the animations play one after another.) All of my animations have only a single frame, because I intend to transition between them as "poses".
However, I have two problems:

1. If my "default" pose has open hands, then the "open_L" and "open_R" animations don't differ from the default pose and thus don't end up in my glTF model. Likewise, if one of my hand poses leaves some fingers in the default pose, the glTF model will end up with only the changed fingers in the resulting animation.
2. In the Maya timeline, the left hand is animated through a series of poses, then left it at its last pose. Then the right hand is animated through its poses. None of the right hand's poses explicitly include information or keyframes about the left hand, but because of the parsing algorithm, all of the right hand poses end up with information about the left hand.

I compared FBX2glTF to blender's FBX import step and the biggest difference I can tell is that blender reads from the FbxAnimCurveNodes while FBX2glTF doesn't. Is this on purpose? I think the animation data we actually want does not require a comparison from an evaluated value to a "default" value, but can be obtained accurately and without the problems I mentioned by reading the curve data in the FBX more "directly". I tried to come up with a fix but I am stuck and looking for help finishing / understanding. I am new to FBX, glTF, and animation and any corrections / advice is welcome.

Here is my fork of Fbx2Raw.cpp where I tried to come up with a fix.
master...johnshaughnessy:bug/animations
I am stuck at the point where I am reading FbxCurves but do not know how to evaluate them at a given time and then associate their values with the correct nodes. What I am printing out is all the information I figured out how to extract from a given FbxAnimStack. I noticed that pNode->GetUniqueID() is different than the unique ID's given by the FbxObjects associated with the FbxProperties animated by the curves. I am lost as to how one connects to the other.

Below is example output from my fork with an FBX model as I described:

...

FbxAnimCurveNode T has dstProperty Lcl Translation
FbxAnimCurveNode T has 3 channels.
  Channel X has 0 curves.
  Channel Y has 0 curves.
  Channel Z has 0 curves.

FbxAnimCurveNode S has dstProperty Lcl Scaling
FbxAnimCurveNode S has 3 channels.
  Channel X has 0 curves.
  Channel Y has 0 curves.
  Channel Z has 0 curves.

FbxAnimCurveNode R has dstProperty Lcl Rotation
FbxAnimCurveNode R has 3 channels.
  Channel X has 1 curves.
    Curve 0 has 1 dstProperties
      R has ID 2271
  Channel Y has 0 curves.
  Channel Z has 0 curves.

...
Node RightHandThumb1 has ID 95
Node RightHandThumb2 has ID 96
Node RightHandThumb3 has ID 97
Node RightHandThumb4 has ID 98
Node RightHandIndex1 has ID 99
...

(The full output can be found here, but it isn't more informative than this: https://github.com/johnshaughnessy/FBX2glTF/blob/111b75d764befc34ece1b6caeb9e89c9f679979f/sample_output.txt)
How can I associate the FbxAnimCurveNode (whose X channel curve points to a property whose FbxObject has ID 2271) with one of the nodes of the hand (with ID ~90)?

It's unreasonable to expect users to create RGB (rather than RGBA) textures just to send a message: "this texture does not have transparency." In fact, it's seems to be common for baking exports to simply output RGBA PNGs, no matter what.

Let's actually investigate the pixel values of RGBA images. If they're all 255, the texture is opaque.

Pepe_Mocap.zip

Again, an instance where both your and my converters are exhibiting the same issue but the FBX file works correctly in FBX Review...

Chip

@zellski Thank you for your efforts on this project! This is a fantastic tool and was badly needed by the community.

When do you think you will have your next release? Is v1.0 around the corner? I'm waiting for the PBR material fix (#55) when converting from an FBX with common materials. I've been using FBX2GLTF --khr_materials_common flag but three.js just abandoned support for this extension with their latest release (r90). I'm hoping you can properly encode common materials to PBR like Khronos' COLLADA2GLTF converter.

It's difficult for me to compile your source code in my environment so I rely on your precompiled binaries. I look forward to your next release!

Especially when outputting animation data, leaning on sparse accessors could likely save a fair bit of space in the output file.

If we end up Draco-compression animations in the future, the value of sparse accessors goes down; long runs of zeros largely vanish in compressed form. Even in that situation, though, there are time- and memory-saving benefits on the client.

I have a low poly model of a car that doesn't appear to convert correctly. I've used assimp to convert to a gltf with separate binary and I'm able to view it in here. The glb generated by FBX2glTF, however, isn't displayed. I've linked the source, the working bin/gltf and the apparently broken glb.

https://storage.googleapis.com/blocker-debug/YellowCar.fbx
https://storage.googleapis.com/blocker-debug/assimp/YellowCar.bin
https://storage.googleapis.com/blocker-debug/assimp/YellowCar.gltf
https://storage.googleapis.com/blocker-debug/FBX2glTF-darwin-x64/YellowCar.glb

FBX2glTF version 2.0

$ ~/Downloads/FBX2glTF-darwin-x64 -b --input  YellowCar.fbx --output /tmp/YellowCar --verbose
Defaulting to --pbr-metallic-roughness material support.
Loading FBX File: ./Resources/StageAssets/AssetLibrary/Vehicles/Models/YellowCar.fbx
node 0: /RootNode
node 1: /RootNode/Car_med_A_001
mesh 0: Car_med_A_001 (skinned: NO)
animation 0: Take 001 (0 channels, 0.0 MB)
Building render model...
Material 0: Naranaja  [shading: Phong]
Material 1: Gris 01 [shading: Phong]
Material 2: Vidrio [shading: Phong]
Material 3: Light [shading: Phong]
Material 4: Gris_oscuro con rallas [shading: Phong]
Material 5: Naranaja  [shading: Phong]
Material 6: Black_1 [shading: Phong]
Material 7: Rojo_1 [shading: Phong]
Material 8: Grey [shading: Phong]
   9201 vertices
   5151 triangles
      0 textures
      2 nodes
      9 surfaces
      1 animations
Warning: animation 'Take 001' has zero channels. Skipping.
Warning: surface 0_Car_med_A_001 has neither texture nor vertex colors.
Warning: surface 1_Car_med_A_001 has neither texture nor vertex colors.
Warning: surface 2_Car_med_A_001 has neither texture nor vertex colors.
Warning: surface 3_Car_med_A_001 has neither texture nor vertex colors.
Warning: surface 4_Car_med_A_001 has neither texture nor vertex colors.
Warning: surface 5_Car_med_A_001 has neither texture nor vertex colors.
Warning: surface 6_Car_med_A_001 has neither texture nor vertex colors.
Warning: surface 7_Car_med_A_001 has neither texture nor vertex colors.
Warning: surface 8_Car_med_A_001 has neither texture nor vertex colors.
Wrote 338217 bytes of binary glTF to /tmp/YellowCar.glb.

I think the problem is that the model was split to four submeshes(and the names of those submeshes are even not listed in the gltf file). The morph targets are working, but the animation is not playing (the intention is to play through morph targets as a sequence.

Model: https://drive.google.com/drive/folders/1NE8uqjBPg-g0d8A5pUJ_sJW680cC9A5E?usp=sharing

We currently support skinned animations. A more recent sibling to the FbxSkin class is FbxBlendShape, and we should tap its eldritch powers as soon as possible.

In glTF the Morph Target is an extension to mesh geometry (through the introduction of targets) as well as to animations (through the temporal mutation of weights).

FBX2glTF cannot deal with aa FBX file that contains two objects with the same name. The generated glTF file only import one node, instead of 2.

Maybe a solution is to change the name of each node that has the same name that other object:
Box, Box_01, Box_02, etc..

Here you can find a sample FBX model with two animated cubes with the same name ("Box")
https://drive.google.com/open?id=1IEZGHINDZMvR-hHfDQLC5WsbltcB9XIC

Best regards,
David Ávila Membrives
WaveEngine team member

• Improve and validate the tricks we already use to match a texture file as listed in the FBX with what exists in the local filesystem.
• If inferring the local file fails, warn explicitly and don't try to read anything later on.
• Extend RawTexture with another field; it should have name (logical texture name), fbxFilename (the original filename, usually an absolute path on the model author's machine), and localFilename, a path that's guaranteed to exist on the local file system.
• In non-binary mode, we bizarrely just add '.ktx' to the texture name, which is certainly guaranteed to be forever wrong. As @robertlong says in the comments, we should copy source files into the output directory and reference them by basename, i.e. as relative path.

When exporting an FBX that has Tangents/Binormals already calculated/included, the GLTF file does not include the TANGENT attribute on the geometry. Is there a command line switch or something to get that working?

The same texture that feeds metallicRoughness can also feed ambientOcclusion; let's bake it all into the same texture (This is what Substance Painter already does, I believe.)

I've been looking into the transform inheritance types and can't quite figure out what this inheritance type means or how to avoid it. Could you document this?

We have a flag for --khr-materials-common, but it seems to always generate a commonPhong technique. Is there a way to have it output technique="CONSTANT"? Would it be worthwhile to add a --khr-materials-common-constant flag to force it?

Hello,

Could you give me the steps to install this on my Linux Amazon AMI Ec2 instance?

I am getting these errors when i just copied the binaries to /bin

FBX2glTF: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by FBX2glTF) FBX2glTF: /usr/lib64/libstdc++.so.6: version CXXABI_1.3.8' not found (required by FBX2glTF)

提示缺少 draco,这个是在哪里配置的?

A common workflow for animated models involves creating separate FBX models containing the same mesh or skeleton, each with a different animation. Then in Unity, it can all be joined up as a single model with multiple animations that may be played in separately, blended, etc. This doesn't work quite so well for runtime loading of glTF, where duplicate copies of the same mesh are unwanted bloat.

Being able to specify additional FBX files, whose animation data should be loaded and applied to the base FBX as new animation clips in the resulting glTF, would be a very welcome addition to FBX2glTF in my opinion.

Current options for exporting multiple animations are Sketchfab and Kupoman/blendergltf. COLLADA2GLTF and the Khronos Blender exporter can only write single animations.

I've just updated to the latest FBX2gltf version (0.9.2), and now this tools crash while is converting to gltf. With the previous version (0.9.1) it works perfectly.
Here you can find a tested FBX model that causes the crash:
https://drive.google.com/open?id=1VPZfDZMM_aNr3hdYKZV2i3HSenNG71ln

Thanks in advance for this incredible tool :)

Best regards,
David Ávila
WaveEngine Team member
http://www.waveengine.net

We should summarize key stats about different aspects of the model as we convert them from Raw to glTF.

For materials, list at minimum the textures involved, perhaps some constant factor stats. For meshes, list attributes included, primitive counts various interesting geometric statistics.

There's some real low-hanging fruit to start with before we get too fancy.

One of the biggest issues with FBX->glTF conversion is that the former has no canonical support for representing PBR materials, whereas glTF natively targets PBR exclusively.

The closest thing we have to a standard for representing PBR within a FBX is Stingray PBS. It encodes a metal/roughness workflow as follows:

• A 'Maya' compound property, containing
  • TEX_global_diffuse_cube
  • TEX_global_specular_cube
  • TEX_brdf_lut
  • use_color_map: boolean
  • TEX_color_map: Vector3f Texture
  • base_color: Vector3f
  • use_normal_map: boolean
  • TEX_normal_map: Vector3f Texture
  • use_metallic_map: boolean
  • TEX_metallic_map: Vector3f (?) Texture
  • metallic: float
  • use_roughness_map: boolean
  • TEX_roughness_map: Vector3f (?) Texture (?)
  • roughness: float
  • use_emissive_map
  • TEX_emissive_map: Vector3f Texture
  • emissive: Vector3f
  • emissive_intensity: float
  • use_ao_map: boolean
  • TEX_ao_map: Vector3f (?) Texture

Furthermore, such a material's ShadingModel is unset, as opposed to the regular 'Lambert' and 'Phong' strings we see.

All in all, it should not be conceptually hard to detect this type of material, represent it internally as distinct from a Phong or Lambert material, all the way up to the glTF generating layer, where it can be output appropriately. In practice, it does require a non-trivial amount of internal refactoring.

Used the Khronos and ThreeJS GLTF systems/loaders to verify the same behavior in both systems.

Authoring in Max, export to FBX, run the utility, and this started happening (shader set up to show normals direction in world space):

In Max, verified normals (as shown below), "reset xform", collapse all modifiers, re-export, and no change.

This looks like a bug in the converter, but I cannot figure out what the pattern is. Perhaps a winding order problem? Almost looks "axis based" in where it goes wrong.

Hi there, our application needs to preserve all the weights in an FBX file, beyond just 4.

This issue here - KhronosGroup/glTF#878 - describes the standard way to encode more than 4 weights; the solution allows graceful degradation to four in existing applications.

If we could have a switch or option to preserve weights, it would be greatly appreciated!