Pull in custom FBX UserData - Pull-Request Etiquette Question

Questions
,
1

Heyo,

I’ve been making constant changes to the FBXLoader when ever I want to update versions, so I thought I’d ask here about my changes and pull-request etiquette-

Every version I update my FBXLoader to read custom user attributes from models to support Extra Attributes / Custom Parameters from Maya, Blender, Houdini, etc.
These (image from my npm package) -

userDetails
userDetails1600×406 46.1 KB

This allows Meshs, Curves, & Groups to have custom userData from your CGI program of choice. However, I’m yet to figure out where in the code I’d need to check userData on Lights though.

The changes I do every version of Three.js is to the FBXLoader.js in the parseModels() function-

parseModels( skeletons, geometryMap, materialMap ) {
 [...]
  for ( const nodeID in modelNodes ) {}

    // Any attributes not in the list are custom attributes, add those to userData
    let standardAttributes=[
      "Culling","DefaultAttributeIndex","InheritType",
      "Lcl_Translation","Lcl_Rotation","Lcl_Scaling",
      "RotationPivot","ScalingPivot",
      "RotationActive","ScalingMax", "RotationOffset","fbx_node_path",
      "Shading","Version","attrName","attrType",
      "currentUVSet","id","name","propertyList","singleProperty",
    ];

    let nodeAttrs=Object.keys(node);
    nodeAttrs.forEach( (attr)=>{
      if( !standardAttributes.includes(attr) ){
        model.userData[ attr ] = node[ attr ].value;
      }
    });
[...]

I was curious if this is worthy of a pull request, mostly that the array of names to check needs to exist somewhere; and I’m unsure where they should be stored outside of the function.

Thoughts?

Note : The standardAttributes I got are from Maya (the owner of the FBX format) and Houdini exports. I believe I checked Blender as well when I first wrote this some years back.

2

FBX is a pretty bloated format and not really ideal for web delivery. GLTF on the other hand, is optimized for web… and also supports custom userdata.

3

I understand, but I’ve been seeing smaller files for my FBXs opposed to GLB; and the restrictions of the format during development isn’t the greatest. Yes GLTF is better, but seems case by case basis to a degree, that I’ve seen.
Also that they aren’t ‘fully supported’ by all CGI programs is a hinderance too, being missing features.

So I’d still like to support FBX in my package, since it is full feature.

4

GLTF files can be compressed. I routinely encounter GLB files that are over a gigabyte that compress down to <10 megs. Not all GLB files are stored compressed, but usually can be compressed to a fraction of their uncompressed size.
My workflow is often to store original assets in whatever format the art team prefers, whether that be FBX/GLTF/OBJ whatever, and then convert them to GLB as part of the asset pipeline to bring into threejs.

If you’re loading FBX directly in the browser, you’re just wasting bandwidth, and making your user experience worse.

Then blender gltf exporter allows texture compression, mesh quantization, hierarchy flattening, animation keyframe reduction and various other optimizations.

Subsequently applying gltf-transform or meshopt can apply even more kinds of compression/reduction.

end psa :smiley:

If you want to submit an improvement to the FBXLoader in threejs, the usual process is to check out the repo, make your changes to that copy… create a pull request with a description of what you are improving and the motivation behind it… and then submitting the request.

1 Like
5

Sure, I’ll add that support to my package, but I think my point remains.
If FBX is better for an art team, if they want to see it through my package without a build/pre-process, they can.

So I’ll go through an optimize my GLB down then, but it was close to 4 mb vs about 1.1mb FBX, so I’ll investigate an optimization step. Something must have been wrong hah.

1 Like
6

If you have a file you’d like to test for compressibility, dm me, and I can run it through the tools I normally use to get an idea of what/why/how they can be compressed.

7

I’ll give it another poke for myself for now, I appreciate the offer. I haven’t really bothered with investigating it more than a couple minutes to check file sizes.
It’s probably just vertex attributes being exported I didn’t check for.

Course I figured me submitting that pull request with an array of known attributes isn’t the cleanest in the world. But could send in the pull request, just seems unclean to me.

8

If you think it would improve the FBX story for other users of the importer, then I wouldn’t worry too much about how “clean” your approach is. That will likely be resolved as part of the PR review process.

Alternatively… you can just use your modified FBXImporter as part of your personal workflow until a version change breaks it. :slight_smile:
All threejs classes are really just there to be used and modified for whatever you need, and often just serve as a basis for more complex stuff layered on top.

If you think your change is too invasive, perhaps simply adding a callback to the exporter to allow client code to plug in and handle userdata in whatever way it wants, might be a more agnostic solution… like:

loader.handleCustomNodeAttribute = (model, node, attributeValue )=>{
//Do your custom logic here on the client side....
}

just an idea…

1 Like
9

Solid idea, but the node[attributes] dump once the FBX is loaded. I’ll poke around some more after the loader though.

I just checked again and my FBX is 1.4mb and the GLB is 2mb, so there is still something up.

I guess I’ll make the pull request and hope for the best hah.

Thanks for the input!
I’ll still investigate what’s going on with the GLB though, I think Houdini is just adding TangentU bloating the vertex attributes on export. Cause I’m not generating TangentU on my meshes in the FBX, and there is no options in Houdini like Maya has.

10

Send me your 1.4 meg fbx :smiley: You can drag files into a DM on here.

1 Like
11

I could send it over, I’m a little curious how low you could get to see how far I’m off. The scene isn’t done yet, but wouldn’t mind seeing how bad Houdini’s exporter is for GLB/GLTF
I got it down to a 1.35mb GLB, which is fine.
I used an optimizer that got it to 900kb, but it stripped all the custom attributes, so I can’t use that.

But just found out Houdini really doesn’t like Blender’s GLTFs and GLBs with custom attributes, it just crashes Houdini, that’s fun to find out…