| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Getting textures to work was a bit tricky, since we basically have no
more texture IDs in modern shaders (they are mere nodes).
Modified specular conversion to be quadratic (between FBX Phong exponent
to Pricipled specular factor).
Also fixed several issues in both importers and exporters.
And cleaned up ugly usage of 'mat' short name for materials in exporter
(mat is reserved for matrix in Blneder code in general, 'ma' is short
for material).
|
|
Using new ShaderWrapper from nodes_shader_utils.
Note that porting is not exact same as in 2.7x (which was using
cycles_shader_compat wrapper). New one does not support as many
features, and not in the same exact way (since it's based on Principled
BSDF), but goal here is to have soon a matching nodal material support
in the exporter...
|
|
That's now useless in 2.8, we always 'use cycles' materials. :p
|
|
That kind of display helpers are now fully overlays settings, no way for
us to set that to meshes anymore.
|
|
|
|
Some typos, and missing named parameters...
|
|
Default cube scene exports and imports ok (besides missing features like
nodal material handling). Anything else is either known broken, or yet
to be tested. :P
Note that I raised main number of addon version, so that we can keep
track of smaller fixes that can be done in both 2.7x and 2.8 versions of
the addon.
|
|
Conflicts:
io_scene_fbx/export_fbx.py
io_scene_fbx/import_fbx.py
|
|
Those asserts were already commented out in quiet a few places, now it's
obvious that having that set of properties defined in actual data nodes
is totally optional, so remove them alltogether.
Also fixed a bug in property fetching, with newer (>= 7.4) FBX files we
would never get templates... Stupid mistake. :/
|
|
|
|
Code would break on empty shapekey names, and was actually broken in
all cases where Blender would have to alter the shapekey name when
creating it.
|
|
Requested in T54050, usually would not add new stuff to FBX but this
looked like totally needed for compo needs...
|
|
This file also has insanely long object names etc. So added a generic
way to handle names for Blender data (IDs, but also non-ID data like
customprops names, UVLayers, etc.), by truncating names and adding seven
digits from their sha1 hash to their end.
Not sure how much an issue name collisions would be here, but in doubt
that should not hurt.
Too complex/risky of a change to add that one to 2.79a, though.
|
|
FBX part at least - note that we are actualy coping with totally invalid
FBX file, strings there should always be in utf-8 encoding as per
offcial FBX doc... But this error-handling does not hurt really.
Based in D3012 by Philipp Oeser (@lichtwerk).
To be backported to 2.79a.
|
|
Do not try to get some string namecode of Enum items if string part of
the custom FBX Enum property is empty! Just stick to basic int value in
this case.
|
|
Based on patch by Gábor Vásárhelyi (@vasarhelyi), just slightly modified
mainly to avoid another extra dict.
|
|
|
|
|
|
Not sure when this has been broken, or whether it ever worked...
To be backported to 2.79a should we do it.
|
|
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!
|
|
That way other addons may use it as well.
|
|
|
|
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.
|
