When moving importers from Python to C++ validation was removed
(from PLY) & disabled by default (STL & OBJ) which re-introduces
crashes reported by users such as #31835.
Enable validation by default because crashes caused by imported data
should be avoided, especially since the crashes may happen later when
users enter edit-mode or run certain editing operations.
This does slow down importing, from testing a 236MB .OBJ it takes around
twice as long to import (~1.5 to ~3 seconds). Although validation can
be optimized to reduce the overhead ad well as run in parallel for
importers that load multiple objects.
The defaults for USD and Alembic remain unchanged since this was never
enabled by default, although we could consider enabling these as well.
This should get all of the tests to pass on Windows ARM64 platforms.
Sadly it needs disabling for hydra/USD stuff as currently it doesn't play nicely with the new preprocessor. @LazyDodo suggested a USD version update may fix this, which is something I can investigate in due course - right now, let's get daily builds up and working :)
Pull Request: https://projects.blender.org/blender/blender/pulls/121361
Remove the one-definition-rule violation due to two `Triangle` types
being used inside the same `blender::io::stl` namespace. Make a small
set of non-functional changes in the surrounding code along the way to
use `const` in more places.
STL had 4(!!) triangle types:
- A `class Triangle` : Used for import, contains indices
- A `struct Triangle` : Used for export, contains verts/normals, the ODR
violation
- A `struct ExportBinaryTriangle` : Used for export but is really the
same as the above type
- A `struct STLBinaryTriangle` : Used for import but was a duplicate
of the above type
Now STL has just 2. The `class Triangle` containing indices during
import and a `struct PackedTriangle` containing the verts/normals for
everything else. The duplicated `BINARY_HEADER_SIZE` constant is now
common as well.
Performance remains the same for both import/export and ascii/binary.
Pull Request: https://projects.blender.org/blender/blender/pulls/121179
Added mesh validation on import as an option.
If bad mesh data is imported, there may be a crash on a switch to edit
mode or similar. This adds an option to validate if a user determines
the file is corrupted, allowing the possibility for data recovery.
This is especially useful for importing files exported from certain CAD
applications.
The option here matches the option that OBJ and Alembic both provide.
Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121054
Blender USD import already supports the displayColor primvar, when it is
specified on Mesh prims. These colors are visible in the viewport when
the viewport shading color type is set to Attribute.
This PR extends this displayColor primvar support to also work with the
various shape prims, such as Box, Sphere, etc.
The original displayColor support was implemented in USDMeshReader.
Because USDShapeReader is a sibling to to USDMeshReader, and
USDShapeReader first converts shapes to a Mesh, we have factored out the
mutually beneficial code from usd_reader_mesh.cc into a new usd_mesh_utils.cc.
For now only the displayColor primvar is supported on shapes, but this
could be easily extended in a future PR.
Authored by Apple: Matt McLin
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/120236
Cleans up the following issues:
- USD arrays were passed by value instead of references
- UsdGeomBasisCurves and UsdGeomNurbsCurves were potentially sliced when
assigning to their parent UsdGeomCurves object in a non-polymorphic way
- Make more parameters and functions const
- Align with how Alembic validates the curve_types and cyclic values
- Standarize CurvesGeometry naming like what was done in 5ed9c8c9dd
(Curves data-block is called "curve_id", CurvesGeometry is called
"curves")
Pull Request: https://projects.blender.org/blender/blender/pulls/120760
During Export, we were accidentally duplicating the `velocity` attribute
data. Once inside the `write_surface_velocity` function (which was
correct) and again while writing out all "custom" attributes inside
`write_custom_data` (which was incorrect). Fixed by excluding the
"velocity" attribute inside `write_custom_data`.
During Import, we were only loading back in those "custom" primvars so
things happened to work, by accident, but only for USD files produced by
Blender. Now we import just the Velocities attribute which should work
with all files.
This should fully address #96182
Pull Request: https://projects.blender.org/blender/blender/pulls/120771
Adding support for converting between Blender custom properties and
USD user-defined custom attributes. Custom attributes on Xforms, many
data types, and materials are all supported for round-tripping.
Please see the USD attributes documentation for more information on
custom attributes.
Properties are exported with a userProperties: namespace for simple
filtering in external apps. This namespace is stripped on import,
but other namespace are allowed to persist.
An "Import Attributes" parameter has been added with options "None" (do
not import attributes), "User" (import attributes in the 'userProperties'
namespace only), "All custom" (import all USD custom attributes, the
default).
An "Export Custom Properties" export option has been added.
The property conversion code handles float, double, string and bool
types, as well as tuples of size 2, 3 and 4. Note that USD quaternions
and arrays of arbitrary length are not yet supported.
There is currently no attempt to set the Blender property subtype based
on the USD type "role" (e.g., specifying Color or XYZ vector subtypes).
This can be addressed in future work.
In addition to exporting custom properties, the original Blender object
and data names are now saved as USD custom string attributes
"userProperties:blender:object_name" and "userProperties:blender:data_name",
respectively, on the corresponding USD prims. This feature is enabled
with the "Author Blender Name" export option.
If a Blender custom string property is named "displayName", it's handled
in a special way on export in that its value is used to set the USD
prim's "displayName" metadata.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118938
Enables the STL and PLY formats for Collection export.
Changes
- Set the export operator on the File handlers
- Plumb through the `collection` property and make use of it while
building the depsgraph
- Skip drawing the "Selection only" and "Batch" mode options when used
with collections
Pull Request: https://projects.blender.org/blender/blender/pulls/120944
Importing `COLLADAFW::MeshPrimitive::LINES` would assert trying to get
the `material_indices` (these are on the Face Domain -- which does not
exist here).
To resolve, early out if we know we handle LINES.
Probably didnt happen before 45cff837bc
Stumbled over this looking into !120737
Pull Request: https://projects.blender.org/blender/blender/pulls/120738
Exposed by 1ea169d90e
Colladas `MeshImporter::mesh_add_edges` is a copy from `mesh_add_edges`
in `source/blender/editors/mesh/mesh_data.cc` (done in 2c05190374 --
there is a comment to deduplicate this into BKE, but this wont be done
in this patch).
However, as time passed there have been additions to the later, namely:
- 353fe610ed (clearing the mesh runtime caches)
- 12becbf0df (altering selection handling, guess this can be ignored
here since collada generally does not seem to select geometry)
So in order to resolve, now also clear the caches for collada as in
353fe610ed (even though just the subset of just `mesh->runtime-
>loose_edges_cache.tag_dirty()` would also be enough).
Pull Request: https://projects.blender.org/blender/blender/pulls/120737
- "Log Encoding with Chroma inset and rotation": add "of primaries" in
the description of the AgX Log color space to better explain the
operation, based on wording in !106355.
- Remove a few double spaces.
- Make Line Art title case everywhere, to convey it's the system /
brand / product name and not the generic concept.
- "Copy Absolute coordinates or Normal vector" -> "of Normal Vector":
typo.
- "Makes a link between selected output in input sockets" ->
"Make...", "output and input": typo.
- "Purge Unused Data From This File" -> "from this": title case as per
HIGs.
- GPencil -> Grease Pencil: no reason to use an abbreviation here.
- "Around Current Frame" -> "Around Frame": actual name of the
onion-skinning method.
- "... (layer height for layer tool, i.e.)" -> "(i.e. the layer height
for the layer tool)": put "i.e." at the start of the sentence.
- Expand description of toe-in stereo camera option.
- "Children collections their parent-collection-specific settings" ->
"Children collections with their...": typo.
- "Generate vertex weights base on..." -> "based on" : typo, lower
case.
- Expand description of GP modifier properties, based on their mesh
counterparts.
- "AEnvelope" -> "Envelope": typo.
- "Falloff type the feather" -> "of the feather": typo.
- "usually make transition as long as effect strip": rephrase.
- "When disabled a users extensions directory is created" -> "a
user's": typo.
- "successfull" -> "successful": typo.
- "Remove all attributes... a single wildcard (*).": remove trailing
".".
- "..., use "Save Preferences."": remove trailing ".".
Some issues reported by Marina Veselkova and Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/120649
Support the new Curves object type in Alembic when exporting curve data.
Make corresponding fixes to importing at the same time.
Summary of changes
- Exporter now supports the `Curves` object type during Export
including when using the convert to mesh option
- Exporter will now enforce that only 1 combination of curve type and
periodicity are in a given object [0].
- Catmul-rom basis curves are now supported and will be used for Hair
data [1].
- Bezier curves are exported with their left/right handle data [2].
- Cyclic bezier and nurbs curves should be handled correctly now.
Along the way this required changes on the Import side as well in order
to be complete
- Importer will now load bezier curve handle data correctly
- Importer could fail to set the correct cyclic data on the last spline
of a multi-curve object
See PR for screenshots
[0] See https://github.com/alembic/alembic/blob/master/lib/Alembic/AbcGeom/OCurves.h#L55
Prior to this change the Alembic exporter could write invalid data to
the file in these cases.
[1] Alembics created with the new Curves Hair object with this patch
will not be loadable in prior versions of Blender. The importer does not
handle the curve data correctly and will crash.
[2] There was a long-standing TODO about how to handle bezier curve data
since nothing is documented on Alembic's side. Bezier data wouldn't even
round-trip properly inside Blender itself. On a hunch, because USD was
influenced by certain aspects of Alembic which came before it, I decided
to try writing out the data the same way as USD. That turned out to work
quite well in at least 1 external software so that's what this patch
will use for both import and export.
Pull Request: https://projects.blender.org/blender/blender/pulls/119894
Object names can contain "/" & "\" and aren't safe to use in paths,
use BLI_path_make_safe_filename to ensure the name can be used in a
path.
Ref !120515
Make it match behavior of the previous Python importer: it was
accepting such faces, and then always calling mesh validation function
that got rid of them. Instead of doing the whole validation cost,
just do not add such faces in the first place.
It was mostly correct, except for the case where a user sets an
empty string as the export filename. What was happening is:
- STL exporter invocation adds ".stl" extension, so the path becomes
foo/.stl
- Code tries to replace extension with "ObjectName.stl", but
BLI_path_extension_replace sees that the filename part starts with
a dot and thinks the ".stl" part is the whole filename, not the
extension
- Resulting path thus becomes "foo/.stlObjectName.stl"
When using Collection export skip drawing certain operator properties
which shouldn't apply for this style of export.
These suppressed properties were mentioned a few times while gathering
feedback for the feature and they are ignored internally when using
collection export anyhow.
This implements the ability to have file exporters added and configured on Collections.
Exporting is reachable from several locations:
- Individually on each exporter configuration: The `Export` button in each panel header
- For all exporters on the collection: The `Export All` button in the main panel interface
- For all exporters on all collections in the scene: The `File`->`Export All Collections` button
Visibility of which collections currently have exporters configured is done by ways of an icon added to the Collection row in the Outliner.
Adding multiple exporters for the same file type is permitted. The user is free to setup several exports of the same format but with different file locations or settings etc.
Notes:
Only USD and Wavefront OBJ are enabled for the initial commit. Additional formats, including those implemented in Python will be added as separate commits after this.
Ref #115690
Pull Request: https://projects.blender.org/blender/blender/pulls/116646
The MTLWriter was using a BLI_assert to check user-provided data, which
is incorrect and would only work in Debug builds. Release builds would
end up using too small of a buffer and would needlessly fail to append
the `.mtl` extension in some cases.
Instead, we now allow the path manipulation code to just use the full
max size available to it.
Pull Request: https://projects.blender.org/blender/blender/pulls/120275
Move the public functions from the editors/object (`ED_object.hh`)
header to the `blender::ed::object` namespace, and move all of the
implementation files to the namespace too. This provides better code
completion, makes it easier to use other C++ code, removes unnecessary
redundancy and verbosity from local uses of public functions, and more
cleanly separates different modules.
See the diff in `ED_object.hh` for the main renaming changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119947
These functions were declared in the editors/mesh module but
defined in the editors/object module. This commit moves them to
a separate header associated with the object editors module.
There are still a few places that are more complicated where the replacement
to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly
`IDPropertyTemplate` usage.
