| Age | Commit message (Collapse) | Author |
|---|
|
This was (correctly) asserting before, now handle this more gracefully
and just skip (and warn about this) a custom property that has an
invalid value set.
Seems there are a couple of exporters out there that do this wrong, I
think this tradeoff can be made though.
Fixes T91062, T81657, T83501, T86595
Maniphest Tasks: T91062, T86595, T83501, T81657
Differential Revision: https://developer.blender.org/D12354
|
|
|
|
not invert)."
While it's nice to see attempts to fix cameras (their orientations are know
broken in some case for ages), this commit has several issues:
- It did not get any review.
- It changes default behavior.
- It adds yet another parameter.
- It does not actually fixes anything, nor does it explain anything.
The first two points in particular are red lights.
But the last two are also more and more annoying, unless someone can provide
a good, valid understanding of how camera orientation is supposed to work
in FBX, am fairly not keen on accepting any more hack like that.
This is just adding more parameters that users just don’t understand,
and which generates by themselves even more bug reports.
This reverts commit 9eddf664d68a2ed6be1bf17b0b26d6d66d81c0eb.
|
|
invert).
|
|
While it's an error case, the ascii detection caused
the missing file case to raise a full exception before running
code which handles this case more gracefully.
|
|
that value was not exported, and imported with some weird conversion
without any proper explanation for it.
For now, just export and import the value as-is, we can always come back
and tweak it once we know what BumpFactor is supposed to be exactly in
FBX...
|
|
|
|
Blender maps crease sharpness from internal [0, 1] to OpenSubdiv's
[0, 10] by squaring the value (see `get_edge_sharpness()`).
Other software seems to treat FBX crease as linear times 10 using OpenSubdiv.
This commits attempts to make FBX exported by Blender consistent with the
results from FBX exported from Maya regarding crease intensity.
Differential Revision: https://developer.blender.org/D5930
|
|
Note that such complex rig features remains barely supported anyway,
such complex setup will require some manual editing after import...
|
|
There are still other add-ons to fix.
|
|
Based on investigation and patch by Yannick (@kschoice), many thanks!
|
|
Add option 'Export Subdivision Surface' to the FBX exporter (disabled by default).
When enabled the exporter will write the **last active Catmull-Clark subdivision surface modifier**
as FBX properties instead of applying it.
Edge crease data is also written to the FBX file if 'Use Creases' is enabled in the subsurf modifier.
Reviewers: mont29
Tags: #add-ons
Differential Revision: https://developer.blender.org/D4982
|
|
Relative filepath having a 'absolute look' (starting with a path
separator) can lead to recursively checking for the whole root!
This is nasty, so try to avoid it by making relative paths actually
relative.
Based on D5143 (report and patch) by andreas atteneder (@atti), thanks!
|
|
Classical stupid issues when trying to shorten an utf8 string to match a
given bytes length... ;)
|
|
3DSMax can produce pure white `TransparentColor` with (default, from
template) `TransparencyFactor` of 0.0... Looks like we are supposed to
use `Opacity` then... sigh...
|
|
Much better option than using Principled's Transmission setting.
Related to T64609.
|
|
|
|
This reverts commit 9524a08a60cf570e9b0540a6ae195a269b403817.
|
|
Sequell to rB55d0ff708c617f, grrrrr....
|
|
Although we had no way to reproduce the issue, that fix indeed seems
needed from code logic point of view.
Investigation and patch by Pete Chown (@PeteX), thanks!
|
|
more maps.
Do not do 'smart' init of our UV/VCol data layers, this is lost
computation and can generate issues when not all items are explicitely
defined in FBX file.
|
|
Blender only supports 8 UVMaps per mesh, avoid crashing addon when
trying to import more.
|
|
Usual crap with PoS of FBX... feeling bad though, that report skipped
out of my radar for too long. :|
|
|
Quiet hard to believe, but looks like that critical recursive call has
never been there... This basically broke any real-life case of 'objects
parented to bones' relationships.
Scaling issues remain though, this will be for some other time.
|
|
|
|
Identity checks should never be used with strings, it may fail based on
Python's interning logic.
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D3746
|
|
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.
|
