| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Fbx, fbx, fbx... The Fuzzy Format :(
|
|
|
|
|
|
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).
|
|
Looks like only change here was that binary switch from uint32 to uint64
for some core metadata of the format. At leas, could import some 7500
files here with that mere change.
Thanks again @xchip (Raul Aguaviva) for finding the culprit in T49822!
|
|
Based on patch from T49822, thanks a bunch for investigation.
Change is actually pretty limited - 7500 now uses some uint64 instead of
uint32 integers as some root element info (like size etc.), and
accordingly raised the 'stop nested data' marker from 13 to 25 NULL
bytes.
Next step: check if we can make actual importer load FBX2016 files that
simply!
|
|
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.
|
|
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.
|
|
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.
|
|
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)!
|
|
Differential Revision: https://developer.blender.org/D1934
|
|
(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.
|
|
|
|
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...
|
|
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.
|
|
Object.is_duplicator, much cleaner solution).
|
|
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...
|
|
negative indices as 'skip' flags.
|
|
'Force Start/End Keying' correctly.
|
|
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!
|
