| Age | Commit message (Collapse) | Author |
|---|
|
Own mistake in some recent refactor...
|
|
Customprop handling helper was called with wrong data for objects and
bones. Many thanks to Nik S (@proteamer) for spotting the issue,
investigating it and finding the solution!
|
|
Now we offer choices to apply everything in transform, store everyting
in FBX scale, or mix both solutions (taking custom export scale and unit
scale into account here).
This change a bit default behavior, and hopefully will allow to find at
least one options working correctly with a given 'other tool' importer.
This may address T51704 and T50159.
|
|
|
|
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.
|
|
This is the 'proxy case', only fixable one for now (linked object have un-editable animdata.action,
so we cannot export animations for them for now).
Issue was simply that armature modifier of linked mesh object still 'points' to linked armature
object, and not to its local proxy. Fix is luckily easy (for once)!
|
|
Differential Revision: https://developer.blender.org/D1934
|
|
(some NLA usages).
Skip 'all actions' options for those objects...
|
|
By default, Blender uses a 'Null' one (rouglhly equivalent to our Empty),
but now user can also choose a 'Root' or even plain "LimbNode".
This seems to be necessary to hack around some Unity bug (see T47325).
WARNING: the 'LimbNode' option *does not* import back correctly in Blender.
Use it in pure export-only cases.
|
|
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...
|
|
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...
|
|
More a TODO than a bug actually, handling of skeys based on other skey was simply not implemented so far.
|
|
This was due to the fact that we generate temp meshes when applying modifiers -
but in dupliobject instances cases, this can be avoided.
Also cleaned up a bit mesh data area, and fixed wrong template user number in this case.
|
|
Grrrr, could have sweared I had done that since ages...
|
|
This file actually showed several issues:
*Not always using safe 'get_bind_matrix'
*Not protecting against zero-length bones in the force-connect area
|
|
not directly supported by FBX format.
This allows some thrid party app to have someting to parse if needed.
Quite obviously, this only applies to exporter.
|
|
supported currently.
Doubt to implement this any time soon, armatures and duplis are both complex area,
if you combine them together you get a Gordian knot (and have no right to cut it!).
Also, this commit fixes a stupid mistake - dupli objects types were not checked at all before...
|
|
Previous 'simplifying' code was not handling correctly micro-fluctuations around zero
(caused by ugly float precision issues). Rewrote it more or less completely,
new code is simpler and only based on relative difference (by default, it
keys each time the diff is above 1e-4, and above 1e-4 * magnitude_of_values).
Might produce more keys in some cases, but at least 'noise' shall never be
exported again.
|
|
|
|
UI of exporter (and, to some extent, importer) was wildly rampaging available space with all its options.
Now we switch to some tab-like drawing, helps keeping things reasonable, and that categorization should
also help user to understand a bit better all those settings.
Also added some more 'UI-compacting' tweaks.
Let's hope 'muscle memory' bawling won't be too loud...
|
|
User request (see T45438).
|
|
error.
Looks like our absolute max diff in animation simplification process was a bit too low,
raised it from 1e-6 to 1e-5, fixes the issue in reported file at least.
|
|
|
|
|
|
'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.
|
|
So, it appears some importers (at least UE4) do not use UnitScaleFactor defined by FBX,
which is assumed to be a way to say 'this FBX file uses units n times default FBX unit'
(default FBX unit being centimeter - afaik, at least I saw some FBX from Max with a
UnitScaleFactor of 2.54 - inches).
Hence, we have to add yet another stupid option to apply that 'unit scaling' to objects
instead (as part of global scaling)... Hurra.
|
|
|
|
Still unsure we are doing the 'right' thing here, but at least let's be consistent
between our importer and exporter!
|
|
Now, we consider default BU as 1 meter (100 FBX units), instead of 1 FBX unit (1cm)...
|
|
Yes... 10h of work, for a oneliner fixing a simple stupid dummy missing connection
between the empty used as armature 'object', and its (void, useless) 'NodeAttribute' data...
Why such basic harmless error breaks something (aparently) completly unrelated
- and why is it breaking anything, btw - is to be added on the Olympus Mons of FBXSDK madness.
Not to mention the usual total lack of parsing warnings/errors from that 'thing'.
|
|
still failing.
|
|
too much in this addon.
|
|
Trying to fix the ugly scaling issue with FBX and animated armatures. No luck so far,
all those changes make our generated file closer to those generated by 'official' FBX apps,
but does not seem to fix or solve anything...
|
|
It would export animations from all compatible actions - even for objects that were
actually not animated at all! This would lead to undesired behavior esp. for
simple objects scenes with only one or two animated.
Now we only export all compatible actions for a given object if it is actually
animated.
|
|
People do not read tooltips it seems...
Would not mind a big red flashing message even, but fear UI mafia would not be happy.
|
|
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!
|
