| Age | Commit message (Collapse) | Author |
|---|
|
As suggested by Omar Emara (@OmarSquircleArt), break after first
matching framerate found, instead of searching the whole list everytime,
ending up selecting the last matching value.
NTSC 'drop frame' type are rather unusual, they should never be
auto-selected anyway.
|
|
FBX exporter code was only supporting "Face Corner - Byte Color"
attribute type, using the deprecated Mesh.vertex_colors API. Update
the to use the new attributes API, and to handle all the attribute
combinations.
An option to pick between sRGB (default, matches current behavior),
Linear (requested in T82847) or None (don't export/import any color
attributes) has been added to the exporter and the importer.
Reviewed By: Bastien Montagne
Differential Revision: https://developer.blender.org/D15942
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D15646
|
|
Support for BoundaryRule (how to handle edges/vertices in subdivision
surface) was added in rBA9a285d80167f, but the values between
'CreaseAll' and 'CreaseEdge' were inverted.
Reviewed By: mont29
Differential Revision: D15035
|
|
Highly suspect the source FBX file to be broken, but investigating a 20MB
binary FBX file is not really an option right now, so cannot be 100%
sure. This can only be realistically investigated if we get a much
smaller reproducible case.
In the mean while, add similar check about indices validity for source
FBX data as we already have for destination Blender data arrays. This
allows to keep importing instead of 'crshing' the import process at
least.
|
|
Add missing values to the `FBX_FRAMERATES` data, including those that
Blender does not really support (the NTSC 'drop frames' variants, better
to have them mapped to regular NTSC framerate than completely ignored).
|
|
This is no longer necessary, see: T98554.
|
|
This change adds options to FBX Export intended to mirror existing
options available in GLTF export, namely:
Include > Limit To > Visible Objects.
The GLTF options were discussed and agreed on in this discussion:
https://github.com/KhronosGroup/glTF-Blender-IO/issues/1139
And implemented in this change:
https://github.com/KhronosGroup/glTF-Blender-IO/pull/1361/commits/f39e14c1ba1310576614eed919e08950f68793fb
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D14539
|
|
I noticed the FBX export was missing a triangulation option seen in other software and other Blender exporters such as .obj.
This feature is rather useful for example for ensuring consistent normal map baking in third party software, where tangent space gets easily messed up with tools using mikktspace that depends on triangulation choices.
This patch adds a "Triangulate Faces" option in the export options similarly to what the Wavefront OBJ exporter has. Diff-wise it's rather simple by reusing the temporary mesh creation from "Apply Modifiers".
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D14352
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D14312
|
|
An exponent should never be negative... but FBX files being FBX files,
just add a 0.0 clamping to that value.
|
|
When importing an animation from FBX or BVH the fcurves are currently shown as a very long list in the dope sheet.
When you manually create a keyframe they are grouped by bone name, which is much more user friendly. This patch groups imported animations by bone name too.
The changes are trivial:
* In the FBX case it was falsely using the object name to group all curves rather than the bone name.
* The BVH importer simply wasn't using the grouping feature at all.
Reviewed By: mont29
Maniphest Tasks: T82472
Differential Revision: https://developer.blender.org/D11269
|
|
|
|
This commit aims at fixing the (very) redundant action names when importing animation data from Fbx files.
By default importing actions from an animated Fbx skeleton file leads to this:
**skeleton_name|skeleton_name|action_name|skeleton_name|action_name**
It works this way: **id_data.name|stack_name|layer_name**
These containers are generally made of the exact same strings multiple time.
This is a proposal to avoid such redundancy by stripping the "layer_name" in case it's identical to the "stack_name"
I'm not sure yet if one of them could be always skipped, I haven't experienced cases when they are different.
With this patch actions are named:
**skeleton_name|skeleton_name|action_name**
It could still be improved, since the "id_data.name" is generally the armature name, already contained in the "stack_name". But sometimes it's not (for Shape Keys for example: Key|skeleton_name|action_name)
Maybe more checks could be added to avoid redundancy even more. Just to open the discussion about it...
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D14130
|
|
Follow up to previous commit adding it to import side of things.
|
|
Credits go to a coworker (he wanted to be referred to as "prutser") who was importing some camera animations, just wanted it to work, but not create a Blender account ;(.
After this patch FocusDistance is applied to the Blender camera.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D6666
|
|
See T95597
|
|
|
|
It's handy being able to track where fbx files originate from.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D13788
|
|
As part of Fbx Export, while handling Armature modifiers for Meshes, each
armature's position is backed up, then put into REST position for exporting,
and then restored back to original position. A dependency graph update is
triggered at the end of this.
This commit avoids the whole backing position setting + depsgraph update in
case the armature is already in rest position.
As an example, a model which I am developing for a game used to take
20 minutes for the Fbx Export. After this change, it only takes 20 seconds.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D13712
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D5801
|
|
These were moved to the object level in rBca64bd0aacda.
|
|
Code tried to set the action to None, but in this case, the action is
read-only.
If we find such a case, now set tweakmode to False temporarily and
restore after actions have been processed.
Maniphest Tasks: T93209
Differential Revision: https://developer.blender.org/D13286
|
|
If the file contains a parent chain that interleaves nodes with
is_armature true and false, the parent armature may wrongly pick
up meshes owned by the child, causing an exception later. No idea
if such FBX files are valid or malformed, but this is a simple fix.
Differential Revision: https://developer.blender.org/D13224
|
|
Currently when exporting a subdivision surface (//Geometry / Export Subdivision Surface// enabled) the exporter uses a hard-coded BoundaryRule rule of 2 (CreaseAll, meaning hard corners). The subdivision surface modifier has an option for boundary smoothing mode so this patch propagates that information to the FBX exporter.
Example .fbx file with this feature exported from modified Blender 2.93: https://github.com/bqqbarbhg/ufbx/blob/overhaul/data/blender_293x_subsurf_boundary_7400_binary.fbx
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D12204
|
|
Do not spam stdio with timing messages by default, this is more a
development/investigation tool than an end-user feature.
Reviewed By: campbellbarton, mont29
Differential Revision: https://developer.blender.org/D12477
|
|
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
|
|
This is a followup patch for D9697 which applies the changes to the
addon reporistory. Almost all of the changes are in rigify, but there
is one change in "curve_tools" and two trivial changes in IO addons.
Differential Revision: https://developer.blender.org/D9919
|
|
This mostly affects default names in object collection manager add-on.
|
|
Allow to disable the rotation matrix that is applied to the object transforms
during export.
With this option disabled only the axis system is written to the fbx file,
but the object transforms are left as-is. This leaves it up to the importer
on the other side to apply the space transform during import.
Unity has added an import option to apply space transform on import in its
latest version, but the current version of setting the axis system in the
fbx file and applying the matrix causes unexpected behaviour.
Most users will expect that Blender has a forward direction of -Y and
an up direction of +Z (Suzanne is looking in the -Y direction and the
"front" view is coming from the -Y direction). But if you set the axis
conversion to -Y and +Z the exporter will apply a 180° rotation because it
assumes a forward direction of +Y.
When done this way, using the new Unity import setting, the mesh will be
imported correctly in Unity, but the rotation of the root objects will
contain that 180° rotation. Using the +Y and +Z axes during export will
import everything without any rotations, but what the user expects to be
forward will now be pointing the other direction in Unity.
When we just write the axis system as -Y and +Z to the fbx file and leave
the rotations of the root objects untouched, we can effectively define any
foward axis and have it still be imported correctly, because every conversion
will be done on Unitys side.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D8078
|
|
Blender has a limit for both vertex color layers and UV layers. The
functions `bpy.types.Mesh.vertex_colors.new()` and
`bpy.types.Mesh.uv_layers.new()` will return `None` once the limit
is reached. The FBX importer and glTF importer didn't handle this
case before and attempted to access the `data`, which failed. This
patch adds the missing checks. In case no vertex colors or uv map
can be created, the assignment of colors or uv coordinates is
skipped.
Reviewed By: mont29, julien
Differential Revision: https://developer.blender.org/D9613
|
|
|
|
gracefully
If the 'Include Custom Normals' import option is used, and the FBX looks
like it has LayerElementNormal (but lacks the actual data), dont throw
an error, just print a warning and continue.
(this has a downside, since such stuff can easily go unnoticed then, but
this seems to be done elsewhere as well...)
Maniphest Tasks: T78083
Differential Revision: https://developer.blender.org/D8122
|
|
|
|
Because, why would you stick to a single separator between name and
value, right? Where would be the fun in that?
|
|
Further optimizations on top of rBA8e70aeae091c5b357.
Note that these changes require latest master (2.90.3 at least).
|
|
Note that this patches changes how we insert keyframes, since we cannot
use the `'NEEDED'` option of the slower previous code, we may generate
more keys than needed.
This change gives about 60 times speedup when importing heavy animations
though, so think that trade-of is totally acceptable.
Patch by @Hotox, with some fixes and cleanup by @mont29.
Differential: https://developer.blender.org/D7762
|
|
Please do not commit random things to code maintained by other people,
especially if you are breaking basic 101 things like codestyle. This is
loss of time for everybody. Even worse since not ansewring to comments
on original commit.
Also no need to add extra `text` parameters (and more useless UI
messages) in add-ons, when the only usage of the property's name itself
is in own add-on' UI...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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...
|
|
We shouldn't have removed this, the option only works in specific cases.
|
