| Age | Commit message (Collapse) | Author |
|---|
|
Still unsure we are doing the 'right' thing here, but at least let's be consistent
between our importer and exporter!
|
|
|
|
'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.
|
|
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!
|
|
|
|
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.
|
|
rBAbfbabc0592b8.
Now using a class factory to allow customization of those defaults axes, still way less
verbose than previous code!
|
|
To be backported to final release.
|
|
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!
|
|
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)...
|
|
180 degree rotation of meshes.
Issue found, investigated and fixed by ib_rod (Rod Boyd), thanks a bunch!
And again, a special mention to the "quality" of FBX doc (even on official API level)...
|
|
|
|
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).
|
|
when working with linked libraries.
Now take libname (lib namespace) into account when generating ID's name or key...
|
|
|
|
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...
|
|
I’m quite not sure whether such a situation is supposed to happen, but does not hurt
protecting against it anyway.
|
|
|
|
|
|
|
|
Helps ensuring common behavior, and saves quite a few lines of code, too...
|
|
|
|
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!
|
|
|
