Age | Commit message (Collapse) | Author |
|
Indirectly reported in T59162. We do not have access to render depsgraph
currently, so we need to work on `show_viewport` option of modifiers we
want to hide when generating temp export mesh, instead of `show_render`
one...
|
|
|
|
This follows naming convention agreed on in T56648.
|
|
Also extended a bit the options for batch exporting (collections give
more ways to organize your scene).
And added non-batch option to only export objects from active Collection.
'partial' support because until we can force generate depsgraph for
inactive view layers, we cannot support exporting instances (dupli
objects etc.) for batches.
TODO: move the batch logic to IO helpers, that could be another
decorator, to easily add the same feature to all exporters able to
export several objects...
|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D3746
|
|
|
|
Python dictionaries are now ordered by definition, so no need to add
extra thingy here anymore to keep our well-ordered FBX structure.
|
|
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 happened to work because our FBX object wrappers tend to get
created frist with real data-blocks (and the key of a real and COW
datablock would be the same)... But that definitively wasn't healthy
behavior!
|
|
|
|
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...
|
|
|
|
Now exporting duplis and animation shall work, at least in basic cases
(still have to check more complex ones).
|
|
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
|
|
That old piece of code was deprecated-and-not-maintained-anymore-since-ages.
Plus, increases consistency, since we never implemented import of ASCII
FBX variants anyway... So now we only support binary 7.x versions.
|
|
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. :/
|
|
|
|
|
|
|
|
calculating tangent for some reasons recompute mesh' UV layers, so we
cannot use iterators on those...
|
|
|
|
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...
|
|
D3068 by @cyaoeu
|
|
|
|
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.
|
|
Inverse Coefficients decay method was added later, never made it to FBX
exporter.
Note that this is very limited approxiamtion/simplification here, we
cannot really export this correctly.
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.
|
|
Blender's empty.
Based on https://developer.blender.org/D2279 by Pavel Křupala (@pavelkrupala), thanks.
|
|
Need more scene updates in FBX anim export code to ensure we do get sane
poses...
|
|
node-based materials.
|
|
Based on patch by Gábor Vásárhelyi (@vasarhelyi), just slightly modified
mainly to avoid another extra dict.
|
|
|
|
|
|
These are changes to the ply and fbx export functions, and the ply
import function, to deal with vertex color alphas as implemented in the
GSoC 2017 Vertex Paint project - see T52910 & D2855
|
|
Not sure when this has been broken, or whether it ever worked...
To be backported to 2.79a should we do it.
|
|
Broken logic in selecting 'best' scene to take settings from while
generating temp new scene used to export selected objects only.
Safe enough to be backported to 2.79
|
|
Own mistake in some recent refactor...
|
|
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!
|
|
Now we offer choices to apply everything in transform, store everyting
in FBX scale, or mix both solutions (taking custom export scale and unit
scale into account here).
This change a bit default behavior, and hopefully will allow to find at
least one options working correctly with a given 'other tool' importer.
This may address T51704 and T50159.
|