Previous code would consider two different face groups sharing no common
edges as fully isolated from each other, and could assign them the same
bitflag facegroup value.
Following FBX recent option to export these bitflags smoothgroups (!135646),
also consider that two different face groups are connected if they only share
common vertices, and assign them different bitflags values.
NOTE: This seems to be the expected behavior in major DCCs actually
using smoothgroups, only considering boundary edges create groups that
generate broken shading when imported by these tools.
NOTE: The 'unique integer identifers' option is kept for OBJ exporter,
as such OBJ files are also found on internet, depending on which app
generated them.
Pull Request: https://projects.blender.org/blender/blender/pulls/135998
- Use const in more places
- Use more appropriate headers and forward decls elsewhere
- Remove one instance of variable shadowing
- Rename an internal rna enum list and the USD operator property object
to follow surrounding code and naming guidelines
Pull Request: https://projects.blender.org/blender/blender/pulls/136112
WM_report was originally added for special cases however new code
has been using this in operators for example, where reports should be
sent to the operator via BKE_report, so the caller can handle,
and so Python can catch the errors.
Rename the functions to make them less easily confused with BKE_report
and add a code-comment on why their use should be avoided.
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
These were primarily put in place during the library update period of
4.2 to ease the in-between time when not all platforms had updated
libraries. Also, now that we've begun depending on later version of USD
and MaterialX, there's little reason to pretend that using versions
prior to 24.03 is still supported.
Pull Request: https://projects.blender.org/blender/blender/pulls/135202
Now import nodes are automatically created in Geometry Nodes when dropping
`.obj`, `.stl`, `.ply` and `.csv` files. Note that this is still hidden behind an
experimental feature flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/135036
- There's only a few unit conversion options, just test all of them
- Use reference instead of pointer when passing export settings struct
- Organize scaling struct fields to keep similar options together
Pull Request: https://projects.blender.org/blender/blender/pulls/133774
This commit moves the Convert World Material checkbox under Materials to
a World Dome Light option "under" Lights. Based on feedback this is more
intuitive for artists. Previously artists would try unchecking "Lights"
and be confused why a DomeLight would still be in their scene.
This is only a UI layout change, API remains unchanged.
Authored by Apple
Co-authored-by: Dhruv Govil <dgovil2@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/131829
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
This rescales the whole scene by its root transform to match the same
visual size while not forcing the user to wait for scale to be applied to
each object.
This is requested by studios whose main applications / USD scenes are
in CM, because referencing and payloading scenes from disparate scales
can cause issues at resolution time.
If "Apply Unit Scale Conversion" is unchecked on import, the user now
has the ability to bring the objects in with a scale factor of 1.0, so that the
objects may be edited as if Blender's scene units matches the imported
stage's.
At export time, a "Stage Meters Per Unit" value can be chosen from a list
of common measurements, as well as setting a custom value.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/122804
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
- Initialize PLYExportParams/PLYImportParams members
- Use enum class in ePLYVertexColorMode
- Pass import/export params as reference
This kind of fixes#126337: previously in the PLY Import node the
import paramters were all set to zero/false values, instead of sane
defaults. Which meant that it ignored vertex colors.
Tidy up:
- Use blender::Map and blender::Vector for newly created `prim_map`
- Leave bread-crumb comment for moving map creation outside of loop
- Expand UI tooltip for newly added export option
Pull Request: https://projects.blender.org/blender/blender/pulls/131770
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
Adds support of NURBS weights or "rat bspline" in OBJ terms.
Tries to guess Blender knot mode better:
- Detects and closes loops. This decision is based on geometry only. No metadata is provided in OBJ for this, so importer has checkbox to disable this feature.
- Bezier knot mode allows to import circles and circular arcs.
Pull Request: https://projects.blender.org/blender/blender/pulls/131169
The `fmt::format` can process the format string at compile time. Currently, we
don't seem to be using that as we don't use `FMT_STRING`. Starting with C++20,
that will be the default though, and one has to explicitly opt out in places
where the string is not known at compile time using `fmt::runtime(...)`.
Currently, our code does not compile as C++20 because of that. Unfortunately, we
have many places with runtime format strings, because of i18n.
Pull Request: https://projects.blender.org/blender/blender/pulls/130392
Adds the option `merge_parent_xform` to the USD export operator and
panels so the transform and shapes are merged into a single USD Prim.
Without the option (existing default), a top-level mesh would be
exported as a top-level `Xform` that has a `Mesh` child:
```
def Xform "MyBlenderMeshObject"
{
matrix4d xformOp:transform = ...
def Mesh "MyBlenderMeshData"
{
}
}
```
This matches the Blender data model, where a transformable object
contains a geometric shape (like a mesh). This structure is also very
valid in USD, where we don't want to directly instantiate geometric
primitives[1]
However, "since number of prims on a stage is one of the primary factors
that governs how USD scale"[2], to reduce the number of prims in a
stage, geometric primitives *are transformable* themselves (see the
inheritence diagram[3]).
As such, the new export option allows to export geometric primitives
without the parent transform:
```
def Mesh "MyBlenderMeshObject"
{
matrix4d xformOp:transform = ...
}
```
This MR adds a the `is_object_data_context` flag to the
`HierarchyContext` context structure. The point of this change is to
make unambiguous in `USDHierarchyIterator::create_usd_export_context`
the fact that an `object` or a `data` is currently being exported: the
new `merge_parent_xform` option is meaningless for `object`. Only `data`
can be exported with a parent `Xform` or as a child of said `Xform`.
Ideally this flag would not be needed at all: the final USD prim path
*could* be computed in an override of the virtual
`AbstractHierarchyIterator::get_object_data_path` method. However, this
would mean that an `object` and a `data` would have the same export path.
This does not currently play well with
`AbstractHierarchyIterator::ensure_writer`, where `writers` are cached
*by their export path*: it would cache a transform writer, but will skip
the subsequent data writer.
Additionally, another new `is_parent` flag is added to handle the case
where merging the Xform is invalid: objects that are parents to other
objects should remain unmerged as otherwise that would yield invalid USD
files.
[1] https://openusd.org/release/glossary.html#usdglossary-gprim
[2] https://openusd.org/release/glossary.html#usdglossary-instancing
[3] https://openusd.org/release/api/class_usd_geom_xformable.html
Co-authored-by: Odréanne Breton <odreanne.breton@ubisoft.com>
Co-authored-by: Sttevan Carnali Joga <sttevan.carnali-joga@ubisoft.com>
Co-authored-by: Charles Flèche <charles.fleche@ubisoft.com>
This new import option will allow users to chose if we merge USD prims
with their Xform parent.
Given a USD like:
```
def Xform "MyObject"
{
def Mesh "MyObject_LOD0"
{
}
}
```
When the option is set to True (existing default), only the mesh will be
imported and its parent Xform transformation will be baked into the
Mesh.
```
# In blender after import
- MyObject_LOD0 (Mesh)
```
When the option is set to False, the parent Xform will always be
imported as an Empty object:
```
# In blender after import
- MyObject (Empty)
├─ MyObject_LOD0 (Mesh)
```
Co-authored-by: Odréanne Breton <odreanne.breton@ubisoft.com>
Co-authored-by: Sttevan Carnali Joga <sttevan.carnali-joga@ubisoft.com>
- "Export additional animationsThis feature..." -> Add period and
newline to separate sentences.
- "name from laoded image" -> "Name from loaded image": typo.
- "Duplicate Active Keyframe (All Layer)" -> "All Layers": grammar.
- "%s is no directory" -> "%s is not a directory": grammar.
- "Can't ensure directory: %s" -> "Cannot", see HIG.
- "Duplicate active Frame(s)": title case.
- "Delete active keyframes of all layer" -> "... layers": grammar.
- "Grease Pencil group color tag": title case.
- "color tag": title case.
- "Bake all line art modifiers" -> "... Line Art...": title case for
product name
- "... imported USD files.Export remaining..." -> "... imported USD
files.\nExport remaining...": missing newline.
- "Premanently delete brush. This can't be undo." -> "Permanently
delete brush. This cannot be undone.": typos.
- "Samplerate" -> "Sample Rate": use more correct two-word form.
- Decimate Keyframe operator: rename and rephrase a property to better
reflect what it does.
- "Remove" -> "Factor"
- "The ratio of remaining keyframes after the operation" ->
"The ratio of keyframes to remove"
- "Add a repository referencing an remote repository" -> "an": typo.
- "... unique within the Action.This is used..." -> "... unique within
the Action.\nThis is used...": missing newline.
- "Threashold in screen space ... within this threashold " ->
"Threshold in screen space ... within this threshold ": typo
- "... occluded by other faces (Slower performance)" -> ... (slower
performance): no need for the capital here.
- "Indices must be sorted in acending order" -> "ascending": typo.
- "Enable the new Overlay code-base" -> "codebase": typo.
- "dectected by plane tracks" -> "detected": typo.
- "the same index can occure" -> "occur": typo.
- "Single element geometry..." -> "Single-element": spelling.
- "it can be quite inefficient to splitup large geometries" -> "split
up": spelling.
- "If true, true gizmo is displayed..." -> "the gizmo": typo.
Some issues reported by Tamuna Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/129001
During development of Collection Export, it was noticed that our various
IO formats deal with errors in vastly different ways [1]. The crashes
were all fixed but now the motivating scenario is as follows:
If you setup a Collection Exporter for OBJ, STL, or PLY, and if it
runs into an error during processing, the C++ operator will return
"FINISHED" to the caller but the operator will also RPT_ERROR. This
causes the caller, Collection Export, to indicate "success" to the user
but the RPT_ERROR then causes a UI report that indicates failure.
This PR chooses to use the presence of the RPT_ERROR as indication of
"CANCELLED" operator status and should be safe enough to also apply
to 4.2 LTS.
This aligns with what Python does [2] and with what the new GSoC import
nodes have chosen to do [3]. Though doing this on import isn't quite
correct so this PR does not add that in to the base import operators.
Alembic and USD are better behaved in this scenario already. However,
they have their own quirks to follow-up afterwards.
[1] https://projects.blender.org/blender/blender/issues/117881
[2] https://projects.blender.org/blender/blender/src/branch/main/source/blender/python/intern/bpy_capi_utils.cc#L25
[3] https://projects.blender.org/blender/blender/src/branch/main/source/blender/nodes/geometry/nodes/node_geo_import_obj.cc#L49
Pull Request: https://projects.blender.org/blender/blender/pulls/127525
USD has the concept of material "purposes" which allows different
materials to be associated for a prim and gives special meaning to them.
These are somewhat similar to display purposes, which we already allow
to be chosen, but are distinct concepts. This PR adds an option for
Import allowing the user to chose which material purpose to load.
Blender currently attempts to load purposes automatically. It starts
with "allPurpose" and then moves to "preview" and "full" in that order.
This behavior is now changed and the automated search is removed to
instead give the user control which purpose to load. Additionally, USD
already has its own fallback behavior during material resolution[1]:
- When given "full" it will first check "full" and fallback to
"allPurpose" if not found. An additional, Blender-specific fallback
to "preview" is also implemented here upon request.
- When given "preview" it will first check "preview" and fallback to
"allPurpose" if not found
- When given "allPurpose", it will only check "allPurpose"
I have opt'd to keep this behavior directly as-is to not introduce
differences that may surprise those already familiar with USD elsewhere.
Additionally, I've set Blender's default import purpose to "full" to
ensure we're loading in the highest quality assets first. Though this
has the obvious risk that "full" assets tend to be quite heavy. We can
change to "preview" if this proves too problematic later.
This does not change how Blender exports materials. Blender always uses
the "allPurpose" binding when writing its USD files.
--------
[1] USD docs:
https://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#detailshttps://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#UsdShadeMaterialBindingAPI_MaterialResolution
Pull Request: https://projects.blender.org/blender/blender/pulls/128206
Export Blender Point Clouds as `UsdGeomPoints` primitives.
Summary
- Adds the `USDPointsWriter` class
- Adds tests to ensure that animated positions, velocities, radii, and
regular attributes are all written correctly (in a sparse format)
- Adds a new `export_points` operator property, mirroring the existing
`import_points` option
Pull Request: https://projects.blender.org/blender/blender/pulls/126389
These libraries are used for grease pencil import/export. If both of
them are disabled the SVG import operator is still built but needs a
function that was hidden.
Pull Request: https://projects.blender.org/blender/blender/pulls/126555
`paths_from_operator_properties` can return paths for both the explicit
operator `filepath` property as well as the `directory` content.
16129d6a attempted to fix this, but fails because one instance of a path
can be absolute and the other negative.
This patch makes sure to only compare absolute paths. Comparison uses
a separate list so that the final output can still mix absolute and
relative paths, but should only include each path once.
Pull Request: https://projects.blender.org/blender/blender/pulls/125608
Access each parameter by name instead of depending on ordering.
Also reorder the parameters to better indicate their groupings, making
things a bit easier to see at a glance what is possible to be set.
Pull Request: https://projects.blender.org/blender/blender/pulls/125620
This patch uses the USD AssetResolver to deal with texture paths.
Functionally, adding this patch should make no functional differences in
the way textures are written.
If textures are specified as assets instead of file paths, at current
the file will error on load and the textures will not be assigned. These
should now be processed correctly.
See PR for example file and testing scenarios.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com>
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/122747
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
Use the correct property names in the up and forward axis update
callbacks. Otherwise they don't work as intended and the following will
be traced to the console:
```
RNA_enum_get: WM_OT_usd_export.forward_axis not found.
RNA_enum_get: WM_OT_usd_export.up_axis not found.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/124112
Added a new custom_properties_namespace USD export option, to
allow replacing or omitting the current default "userProperties"
namespace prefix.
Note that this option does not apply to names that already have a prefix
(e.g., it would apply to name "bar" but not "foo:bar"). It also does not apply
to the internal Blender "object_name" and "data_name" properties which
always have the prefix "userProperties:blender".
Also added logic to handle ":" namespace delimiters in property names.
Pull Request: https://projects.blender.org/blender/blender/pulls/124067
