| Age | Commit message (Collapse) | Author |
|---|
|
Fbx, fbx, fbx... The Fuzzy Format :(
|
|
it to users.
Those ... people? at AD changed the whole format on binary level it'd seem, even low-level,
binary parsing is broken with those files, nothing else to do but go back to
binary hacking/inspection of new files if we want to support them... will let that
to someone else, FBX has successfully exhausted my patience since years already,
even all the backup emergency reserves I had.
|
|
rigged meshes are global, but implicitly local to their armature... so far
was exporting their animation in global space, and trying to correct it back to local
on import, but this cannot work that way - and actually does not make much sense.
So for now, fully disabling tranform animation of rigged meshes. Did quick check with
Unreal engine, and looks like it is totally ignoring any rigged mesh animation anyway.
If a kind miracle gives us some day full specs of that format, we may learn
what exact behavior is expected in that case.
|
|
Yet another case of the infamous 'iterating over something while modifying it' issue.
Here, setting parent of a node actually modifies the children list of its previous parent,
which resulted in missed items in the iteration.
|
|
Differential Revision: https://developer.blender.org/D1934
|
|
First file ever having 'Limb' (in addition to 'LimbNode'!) bones... Looks like we can more or less
use them as 'LimbNode' ones, though.
|
|
from crappy FBX data.
Also print version of FBX file in console messages.
|
|
Get rid of those flags asserts in read code, we do not use them anyway, and our goal is not
to be a FBX format validator, especially since there is no public FBX format...
|
|
import (from Makehuman)
Regression from rBAd7fa659c6f9d4922, looks like here we do not want pre/post corrections...
Man, those matrices transform are a complete nightmare, guess this only breaks for maya-like FBX
(iirc 3dsmax-like ones do not use those pre/post transform stuff).
|
|
custom fps value...
Patch by Julian (joolsa).
Differential Revision: https://developer.blender.org/D1551
|
|
Can be handy sometimes, especialy with files which should not be animated and yet contain animdata...
|
|
This file actually showed several issues:
*Not always using safe 'get_bind_matrix'
*Not protecting against zero-length bones in the force-connect area
|
|
negative indices as 'skip' flags.
|
|
|
|
'remove leaves' option is set.
Also, refined the whole 'force connect' behavior, such that bones having several children also get their
tail position adjusted to the average children head positions.
This shall finalize our support for 'point-only' based armatures.
And to think that original FBX had a real bone-type armature... :'(
|
|
|
|
|
|
there are several ones with different 'head' positions.
Also, fix a minor bug from previous 'multi-armatures for a single mesh' commit.
|
|
There were two issues here:
I) Since an object can only have *one* parent, it it gets created only during its parent's creation,
we could end in situation where we would be creating an armature that would need its 'fake' children
mesh objects, before we have actually created this mesh object (which would only happen during creation
of the only armature that would be its *real* parent).
This was solved by decoupling object creation/instancing and creation of objets' relationships.
II) We were only storing one set of binding data (matrices) per mesh, which obviously failed when
binding several armatures to a single mesh.
Simply fixed by storing one set of binding data per mesh per armature.
FBX can store on set of binding matrices per mesh per bone, but this is not supported by Blender!
|
|
In theory, Blender's animations start at frame 1, while FBX ones start at t0,
but looks like users need tweaking ability here too! ;)
|
|
Somehow our mapping from FBX int 'enum' code to string representation of rotation order
was pure nonsense, only giving correct result for default 'XYZ'.
Note that we fallback to EulerXYZ in case of 'SphericXYZ', not even sure what this is!
|
|
armature case.
Note that, since I do not have any skinned zero-aligned bones FBX file at hands, I do not
know whether this option breaks skinning or not (hard to predict, we are playing with
at least four different matrices/transforms here)... Time will say.
|
|
Man... this scaling issue becomes ridiculous!
Tried to fix it again also regarding (what is supposed to be) FBX scale/units handling.
Since we store Blender's unit system (with 1BU == 1m in case of none) as the UnitScaleFactor
element, we actually *do not* have to also scale objects themselves... In theory.
Since I have to wait hours here to get my UE4 repo updated and rebuild the monster,
comitting this now, we'll see later for FBXSDK behavior.
|
|
Still unsure we are doing the 'right' thing here, but at least let's be consistent
between our importer and exporter!
|
|
mesh on import.
Issue here is that FBX assigns materials by objects, while in Blender it is by default assigned
to meshes (obdata). This becomes critical with tons of objects using the same mesh (as generated
e.g. by exporting from Blender's dupliobjects).
We may add an option later to assign materials to objects too, but meh... We already have tons
of options in FBX. :|
Also, added some timing/steps reporting in console, helps seeing io process going on,
and spotting stupid issues like this one!
|
|
To be backported to final release.
|
|
Pretty stupid, UV/VCols were passed as a copied list instead of direct blend data.
Not sure there was a reason for that, but now it was seriously conflicting with
new advanced behavior of that code (to allow complex per vert/face/loop normal import
into clnors)...
|
|
Caused by rBc755d8fbb520fbcf2a, can understand we want a 'good' (sigh) naming
before release, but please ensure code already using it is updated then...
|
|
Some FBX files store their normals as polygon ones (flat shading...).
Note this code becomes a bit messy, will need some cleanup!
|
|
Patch by juicyfruit (Martijn Berger) with own minor edits, thanks!
|
|
|
|
|
|
FBX... Looks like even using the SDK does not avoid many mistakes (I would suspect the countrary, actually).
|
|
export and import.
On export, we also want to tage as sharp edges from flat faces, and edges shared by more than two faces.
On import, we want to tag all faces as smooth and enable autosmooth, when we only have smooth edge data...
|
|
Mess in filename props ID.
Thanks one more time FBX for your beautiful demonstrations of pure logic insanity...
|
|
|
|
`elem_find_first_string_as_bytes`, and remove exception for AllSame mapping...
|
|
first), add support for embeded images.
|
|
was a bit too aggressive, forgot lamps, cameras & co).
|
|
Always expect FBX to do stupid things, and hence try to armor against it
with deterministic handling of data...
|
|
This report actually showed two different issues.
First, handling of bind poses was basically useless trash. Blender does not
have any real concept of bind pose, it uses parenting instead. So what we really
need to do here is set matrix_parent_inverse according to bind matrices of armature
and mesh.
Second, mighty FBX actually has *two* different transform models (which combine into
a nice monster using 13 matrices...). Added details in (huge) comment, but short story
is FBX uses by default Maya tx model, but can also store Max one, which uses some kind
of local diff additional transform (similar to our dloc & co I think). So had
to add support for that too, which makes our code even more light and beautiful!
Note those 'geometric transformations' might entertain us again, quite not sure I
caught all cases where we have to take them into account. :/
|
|
Shorten some too long lines, factorize some imports on top of file (!!!),
also done a few optimizations in some places where code was rather stupid.
Nothing expected to change in behavior in this commit!
|
|
|
|
As usual with FBX, 'official' doc of SDK says one thing, actual FBX files
produced by 'official' apps say something else.
This time, it’s about mapping types - looks like it is actually 'valid'
to have layer arrays shorter than actual number of relevant geometry elements (verts, edges, etc.).
Don't know how the SDK handles those case, for now we simply stop filling blen's data layers
once we have reached the end of fbx data layer's array.
Since I was messing with this code, I also refactored it a bit to make it more generic.
Also removed some optimization (like when stride is 1), we loose a few percents of speed,
but nothing critical, and code is much cleaner and generic now.
Only had to keep one exception - seems common to have Poly data with 'IndexToDirect'
mapping without any mapping data - ***sigh***!!!
|
|
|
|
|
|
Looks like FBX allows corruption in its 'database', like UIDs
only existing in Connection table, and just ignores it. When in Rome...
|
|
automatically.
This does by no mean handle complex setups, but most common basic situations
should be read correctly, and it's much more user-friendly!
|
|
Looks like FBX's 'Root' bone is same as our armature object?
|
|
Just use 'new' inverted_safe() everywhere we are not 100% sure the matrix is invertible...
|
