This simplifies the usage of the API and is preparation for #104478.
The `CustomData_add_layer` and `CustomData_add_layer_named` now have corresponding
`*_with_data` functions that should be used when creating the layer from existing data.
Pull Request: blender/blender#105708
This renames the `BKE_gpencil_*` as well as the `DNA_gpencil_types.h`
files to indicate that it's the legacy grease pencil.
Pull Request: blender/blender#105597
Refactoring mesh code, it has become clear that local cleanups and
simplifications are limited by the need to keep a C public API for
mesh functions. This change makes code more obvious and makes further
refactoring much easier.
- Add a new `BKE_mesh.hh` header for a C++ only mesh API
- Introduce a new `blender::bke::mesh` namespace, documented here:
https://wiki.blender.org/wiki/Source/Objects/Mesh#Namespaces
- Move some functions to the new namespace, cleaning up their arguments
- Move code to `Array` and `float3` where necessary to use the new API
- Define existing inline mesh data access functions to the new header
- Keep some C API functions where necessary because of RNA
- Move all C++ files to use the new header, which includes the old one
In the future it may make sense to split up `BKE_mesh.hh` more, but for
now keeping the same name as the existing header keeps things simple.
Pull Request: blender/blender#105416
The C4100 warning is related to unused formal parameters in functions.
Enabling it better aligns with "-Wunused-parameter" option in other
compilers.
While suppressing it with `__pragma(warning(suppress:4100))` is not the
same as using `__attribute__((__unused__))` in GCC or Clang, it is
still preferable to use it over completely hiding the warning.
This ensures consistent warning behavior across compilers and improves
code quality by addressing unused function parameters.
(Note that some warnings in Windows-specific code have already been
silenced in 7fcb262dfd)
Pull Request: blender/blender#105534
Currently the shade smooth status for mesh faces is stored as part of
`MPoly::flag`. As described in #95967, this moves that information
to a separate boolean attribute. It also flips its status, so the
attribute is now called `sharp_face`, which mirrors the existing
`sharp_edge` attribute. The attribute doesn't need to be allocated
when all faces are smooth. Forward compatibility is kept until
4.0 like the other mesh refactors.
This will reduce memory bandwidth requirements for some operations,
since the array of booleans uses 12 times less memory than `MPoly`.
It also allows faces to be stored more efficiently in the future, since
the flag is now unused. It's also possible to use generic functions to
process the values. For example, finding whether there is a sharp face
is just `sharp_faces.contains(true)`.
The `shade_smooth` attribute is no longer accessible with geometry nodes.
Since there were dedicated accessor nodes for that data, that shouldn't
be a problem. That's difficult to version automatically since the named
attribute nodes could be used in arbitrary combinations.
**Implementation notes:**
- The attribute and array variables in the code use the `sharp_faces`
term, to be consistent with the user-facing "sharp faces" wording,
and to avoid requiring many renames when #101689 is implemented.
- Cycles now accesses smooth face status with the generic attribute,
to avoid overhead.
- Changing the zero-value from "smooth" to "flat" takes some care to
make sure defaults are the same.
- Versioning for the edge mode extrude node is particularly complex.
New nodes are added by versioning to propagate the attribute in its
old inverted state.
- A lot of access is still done through the `CustomData` API rather
than the attribute API because of a few functions. That can be
cleaned up easily in the future.
- In the future we would benefit from a way to store attributes as a
single value for when all faces are sharp.
Pull Request: blender/blender#104422
This renames the `OB_GPENCIL` object type and the `ID_GD` to `OB_GPENCIL_LEGACY` and `ID_GD_LEGACY` respectively.
There is no change for the user.
Pull Request: blender/blender#105541
At a random the bf_io_ply_tests would fail in one of the fixtures.
The root of the issue was that the exporter parameters were used
uninitialized, causing the mesh to be triangulated in some of the
runs and not be triangulated in other runs.
This change makes it so PLYExportParams is always zero-initialized,
so that this solves this issue, and that adding fields to it in the
future will not re-introduce the issue.
Pull Request: blender/blender#105537
Doing such writes leaves dangling file in the installation directory which
then is packaged as well. Not only this makes it so a random file gets
packaged for installation, it also makes notarization process to fail because
of not-so-clear reason.
The `ply_exporter_ply_data_test.SuzanneLoadPLYDataUV` fixture seems to be
unreliable and fails at random, even before this change. This makes it
hard to reliably get green light on all tests.
Pull Request #105504
The up_axis_update/forward_axis_update was the same logic between
the two, so factor that out.
Also use the same time reporting logic in PLY as in OBJ/USD/Alembic.
If the texture image path in the MTL is a "quoted" absolute path, the importer will fail to find the
file. It was only attempting to un-quote the path for the relative case. Now we attempt to un-quote
in all cases.
Pull Request #105478
- Add missing braces for if statements
- Tweak variable naming to use snake case
- Use more common name for `MLoop`s of a face
- Use `std::move` when appending an array
- Use const for a few variable declarations
Address some issues discussed in PR #104404:
- Vertex color options changed to None/sRGB/Linear, default is sRGB
to match the existing Python addon.
- Change name to "Stanford PLY" from "PLY" in the menu item.
- Default "Export UVs" to on.
- After importing vertex colors, they are set as enabled for render.
New (experimental) Stanford PLY importer and exporter written in C++.
Handles: vertices, faces, edges, vertex colors, normals, UVs. Both
binary and ASCII formats are supported.
Usually 10-20x faster than the existing Python based PLY
importer/exporter.
Additional notes compared to the previous Python addon:
- Importing point clouds with vertex colors now works
- Importing PLY files with non standard line endings
- Exporting multiple objects (previous exporter didn't take the vertex
indices into account)
- The importer has the option to merge vertices
- The exporter supports exporting loose edges and vertices along with
UV map data
This is squashed commit of PR #104404
Reviewed By: Hans Goudey, Aras Pranckevicius
Co-authored-by: Arjan van Diest
Co-authored-by: Lilith Houtjes
Co-authored-by: Bas Hendriks
Co-authored-by: Thomas Feijen
Co-authored-by: Yoran Huzen
Similar to the previous commit, this simplifies future refactoring
to change the way edges are stored, and further differentiates
single poly variables from array pointers.
With the goal of clearly differentiating between arrays and single
elements, improving consistency across Blender, and using wording
that's easier to read and say, change variable names for Mesh edges
and polygons/faces.
Common renames are the following, with some extra prefixes, etc.
- `mpoly` -> `polys`
- `mpoly`/`mp`/`p` -> `poly`
- `medge` -> `edges`
- `med`/`ed`/`e` -> `edge`
`MLoop` variables aren't affected because they will be replaced
when they're split up into to arrays in #104424.
Consistent with naming from 1af62cb3bf. Keep the "coord"
naming in the "vert_coords_alloc" set of functions since they should be
removed (see #103789).
This commit adds the default .usdz export capability.
The importer already supports usdz so no change is required other than updating the text in menu to match the updated exporter text.
On export, a .usd/a/c file has to be created first, and then converted to .usdz. A weird change of directory is required because of a quirk with the USD conversion to usdz. If an absolute filepath is passed into the `UsdUtilsCreateNewUsdzPackage` function, the usd files inside the usdz archive will have the same directory structure, i.e. if one tries to create a file at `C:\code\BlenderProjects\file.usdz`, when the usdz file is created, inside it will have the structure `\code\BlenderProjects\file.usdc`.
This is counteracted by setting the current working directory to the temporary session directory where both the usdc and usdz files are created, and just passing the file name to `UsdUtilsCreateNewUsdzPackage` without any filepath. Once the usdz file is created it is moved to the intended directory.
There is a separate `UsdUtilsCreateNewARKitUsdzPackage` capability for exporting usdz for iOS devices that will be implemented in a follow up patch as it will require some more small UI changes.
Co-authored-by: Charles Wardlaw (@CharlesWardlaw)
Co-authored-by: Sonny Campbell (@SonnyCampbell_Unity)
Co-authored-by: Bastien Montagne (@mont29)
Pull Request #105185, based on #104556.
Originally caused by 6514bb05ea
More cases where the active/default color attributes were not set
correctly:
[1] Using the old Python vertex_colors API (vertex_colors.new)
[2] OBJ importer
[3] Collada importer
[4] Data Transfer layout (both standalone operator and "Generate Data
Layers" from the modifier)
Similar to 101d04f41f.
Brought over from https://archive.blender.org/developer/D16977, see
discussion there why some of the code for data transfer is not for the
genereal attribute API.
Pull Request #105020
Fixes the `-Winconsistent-missing-override` warning.
In theory the `virtual` is redundant in such case, but this is how
it is done in may other areas of USD code.
Pull Request #104977
The logic for looping over imported OBJ faces and checking whether any
of them are "invalid" (duplicate vertices) was wrongly skipping
validation of the next face right after some invalid face. It
was the previously invalid face, moving the last into its place,
but then the loop was incrementing the face index and that just-moved
face was not properly validated.
Fixes#104593 - importing attached obj file (which contains some faces
that have duplicate indices). Added test coverage with a much smaller
obj file.
The OBJ spec (page B1-17) allows "l" entries to specify
polylines with more than 2 vertices, optionally with texture
coordinates.
Previously, only the first 2 vertices of each polyline
were read and added as loose edges, failing when texture
coordinates were present.
This adds support for proper polylines, reading but ignoring
texture coordinates.
Pull Request #104503
A properly authored USD file will have the extent attribute authored on all prims conforming to UsdGeomBoundable.
This cached extent information is useful because it allows the 3D range of prims to be quickly understood without reading potentially large arrays of data. Note that because the shape of prims may change over time, extent attributes are always evaluated for a given timecode.
This patch introduces support for authoring extents on meshes and volumes during export to USD.
Because extents are common to multiple kinds of geometries, the main support for authoring extents has been placed in USDAbstractWriter, whose new author_extent method can operate on any prim conforming to pxr::UsdGeomBoundable. The USD library already provides us the code necessary to compute the bounds for a given prim, in pxr::UsdGeomBBoxCache::ComputeLocalBound.
Note that not all prims that are imageable are boundable, such as transforms and cameras.
For more details on extents, see https://graphics.pixar.com/usd/release/api/class_usd_geom_boundable.html#details.
Note that when new types of geometries are introduced, such as curves in https://developer.blender.org/D16545, we will need to update the USD writer for that geometry such that it calls this->author_extent.
Update on Feb 2: This patch has been updated to include a unit test to ensure authored extents are valid. This test requires new test assets that will need to be submitted via svn. The test assets are attached in the d16837_usd_test_assets.zip file. To use, unzip and merge the contents of this zip into the lib/tests/usd folder.
This unit test also addresses #104269 by validating compliance of exported USD via UsdUtils.ComplianceChecker.
Pull Request #104676
This commit adds the ability to import USD Shape primitives (Gprims).
They are imported as Blender Meshes using the USD API to convert, so
that they appear the same as they would in other applications. USD
Shapes are important in many workflows, particularly in gaming, where
they are used for stand-in geometry or for collision primitives.
Pull Request #104707
Since USD is no longer statically linked these linker tricks
are no longer needed.
Co-authored-by: Ray Molenkamp <github@lazydodo.com>
Pull Request #104627
CustomData layer names should not be written except via the CusomData
api. Therefore use const char * instead of char * when referencing the
layer name.
Pull Request #104585
Using callback functions didn't scale well as more arguments are added.
It got very confusing when to pass tehmarguments weren't always used.
Instead use a `FunctionRef` with indices for arguments. Also remove
unused edge arguments to topology mapping functions.
As described in #95966, replace the `ME_EDGEDRAW` flag with a bit
vector in mesh runtime data. Currently the the flag is only ever set
to false for the "optimal display" feature of the subdivision surface
modifier. When creating an "original" mesh in the main data-base,
the flag is always supposed to be true.
The bit vector is now created by the modifier only as necessary, and
is cleared for topology-changing operations. This fixes incorrect
interpolation of the flag as noted in #104376. Generally it isn't
possible to interpolate it through topology-changing operations.
After this, only the seam status needs to be removed from edges before
we can replace them with the generic `int2` type (or something similar)
and reduce memory usage by 1/3.
Related:
- 10131a6f62
- 145839aa42
In the future `BM_ELEM_DRAW` could be removed as well. Currently it is
used and aliased by other defines in some non-obvious ways though.
Pull Request #104417
Straightforward port. I took the oportunity to remove some C vector
functions (ex: copy_v2_v2).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
