| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Do not store export scaling, this is internal runtime data specific to
exporter, it’s applied already in objetcs' matrices, and has nothing to
do with actual FBX global scaling.
|
|
Note that FBX still links materials to geometry, so we have to export
own version of mesh in that case (i.e. Object-materials break instancing
if any).
|
|
Kinda odd nobody noticed this so far :/
Also, cleanup: do not loop over key/value of a dict when you only need the keys...
|
|
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.
|
|
unique animations to each take.
Active action of object's animdata would override actual NLA's strip animation...
|
|
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)!
|
|
(some NLA usages).
Skip 'all actions' options for those objects...
|
|
Note that it will export all sampled values - even for actually non-animated channels,
not really possible to avoid that without a hell lot more of code, and this rea is
convoluted enough right now.
|
|
This can fail in some cases (batch converting for example).
|
|
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.
|
|
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...
|
|
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...
|
|
'Force Start/End Keying' correctly.
|
|
User request (see T45438).
|
|
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.
|
|
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.
|
|
|
|
'Content' elements.
This sounds suspicious to me, but it’s FBX, so could be the solution, we'll see...
|
|
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.
|
|
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.
|
|
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!
|
|
readonly properties.
|
|
Well, not exactly a fix, since the buggy behavior from FBXSDK side makes no sense to me.
So it's rather a hack to make that stupid piece of junk happy - now you can (optionally,
but ON by default) force exporting anim keys for all bones of an armature.
Should be safe for 2.74, just adds a new option, cannot see how it could break existing stuff.
|
|
invalid file.
Stupid libfbx crashes when there is no normals in 'main' mesh data, and some shape keys linked to that mesh.
Now, issue is, I removed always writing normals because iirc this was giving bugs
with some importers... Re-enabled it for now, let's hope everything works OK.
*do not backport this* to 2.74!
|
|
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...
|
|
was a bit too aggressive, forgot lamps, cameras & co).
|
|
I’m quite not sure whether such a situation is supposed to happen, but does not hurt
protecting against it anyway.
|
|
|
|
|
|
Thanks to Squashwell (Harrison Nordby) for org report and patch.
|
|
|
|
FBX nodes.
|
|
Just use 'new' inverted_safe() everywhere we are not 100% sure the matrix is invertible...
|
|
leaf-bones.
|
|
* Only export global animation if neither NLAStrips nor AllActions options are set.
* Do not prepend '_' to groups' filenames in case of batchexport with no prefix given.
Requested by Mango Jambo through mail.
|
|
|
|
work).
Will remove experimental one soon. Keeping old 6.1 exporter active for now, though.
Notes:
* Not 100% happy with how complex code is now... Rather sure though refactor would
take a huge amount of time, not worth it for now.
* New code handles things like armature & animation import much much better than previous one,
so definitively worth it.
* New code also fixes some real bugs (like Blender-side of T42135).
* Did a few cosmetic changes on the run, nothing serious.
This should make FBX work complete, aside from a few nice TODOs that I'll tackle in comming weeks,
in addition to ongoing bugbusting.
Many thanks to Jens for his work on armature mess! :D
|
|
groups are active.
Do not say we have a normal layer when we do not!
Also, warn users about the fact that applying modifiers implies loosing all shape keys.
That later point may be addressed ultimately, but not easily. :/
|
|
Now, find the scene most 'used' by exported group elements, and use its unit settings!
|
|
not exported correctly.
Now also check modifiers stack.
|
