For a 16 million vertex mesh, when there are no loose vertices or edges,
copying that information to new original mesh saves 100ms after applying
a modifier on a Ryzen 7950X.
This was only used in one place. Adding the name lookup to
`SCULPT_vertex_mask_get` is not good long term, but the use
of that function can be removed too.
Store paint masks as generic float attributes, with the name
`".sculpt_mask"`. This is similar to 060a534141, which made
the same change for face sets. The benefits are general
consistency, nicer code, and more support in newer areas
that deal with attributes like geometry nodes.
The RNA API is replaced with one created in Python. The new
API only presents a single layer as an attribute class, so it
should be simpler to use in general:
- Before: `object.data.vertex_paint_masks[0].data[0].value`
- After: `object.data.vertex_paint_mask.data[0].value`
Pull Request: https://projects.blender.org/blender/blender/pulls/115119
Caused by e5ec04d73c
Since above commit, the edge crease is a named attribute and considered
a "fake" customdata layer (similar to bevel weights or UV seams --
`CD_FAKE`). Thus, a special case in
`data_transfer_layersmapping_generate` has to be added for
`CD_FAKE_CREASE`.
Pull Request: https://projects.blender.org/blender/blender/pulls/115180
Avoid the need to call the separate `BKE_mesh_wrapper_minmax` function
that dealt with the edit mesh wrapper. This makes the API inconsistent,
since other mesh functions don't implicitly deal with the wrapper.
But the bounds are a bit of a special case anyway in regard
to the GPU subdivision wrapper already, and this is much more
convenient in the rest of the refactors for #96968.
Use functions to retrieve the next and previous corners
in a face. The complexity of tracking them manually isn't
worth it here. Also standardize naming a bit and use a
C++ BitVector instead of the C equivalent.
Pull Request: https://projects.blender.org/blender/blender/pulls/115146
This struct is currently defined in the `functions` module but not actually used there. It's only used by the geometry nodes module, with an indirect dependency from blenkernel via simulation zone baking. This scope is problematic when adding grids as socket data, which should not be part of the functions module.
The `ValueOrField` struct is now moved to blenkernel, so it can be more easily extended to other kinds of data that might be passed around by geometry nodes sockets in future. No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115087
This path merges the Musgrave and Noise Texture nodes into a single
combined Noise Texture node. The reasoning is that both nodes
intrinsically do the same thing, which is the layering of Perlin noise
derivatives to produce fractal noise. So the patch de-duplicates code
and unifies the use of fractal noise for the end use.
Since the Noise node had a Distortion input and a Color output, while
the Musgrave node did not, those are now available to the Musgrave types
as new functionalities.
The Dimension input of the Musgrave node is analogous to the Roughness
input of the Noise node, so both inputs were unified to follow the same
behavior of the Roughness input, which is arguable more intuitive to
control. Similarly, the Detail input was slightly different across both
nodes, since the Noise node evaluated one extra layer of noise. This was
also unified to follow the behavior of the Noise node.
The patch, coincidentally fixes an unreported bug causing repeated
output for certain noise types and another floating precision bug
#112180.
The versioning code implemented with this patch ensures backward
compatibility for both the Musgrave and Noise Texture nodes. When
opening older Blender files in Blender 4.1 the output of both nodes are
guaranteed to always be exactly identical to that of Blender files
created before the nodes were merged in all cases.
Forward compatibility with Blender 4.0 is implemented by #114236.
Forward compatibility with Blender 3.6 LTS is implemented by #115015.
Pull Request: #111187
This changes a bunch of nodes that have a data type drop-down to using a dynamic
node declaration that changes based on the selected data type instead of always having
all sockets. This greatly simplifies the code and is less weird than having suffixes on
socket identifiers.
Backward compatibility and forward compatibility remain due to #113497 and #113984.
One user-visible change is that changing the data type in these nodes does not break
the link anymore.
It may be necessary to bring back some functionality from link-drag-search afterwards.
Pull Request: https://projects.blender.org/blender/blender/pulls/113553
There was two problems because these operators were not supported in GPv3:
* If you remove the slot, the material was not reassigned and the material index attribute could get a wrong index. This also affected the unused slots.
* The Unused Materials operator was executed, but it was doing nothing because there was not support for new GPv3 object.
This PR adds support for new Grease Pencil object.
Pull Request: https://projects.blender.org/blender/blender/pulls/114850
Use float3, float3x3, and Array for data used for mesh crazyspace
calculation. Propagate the change wherever necessary to not add
more casting to the old C types.
Because `ObjectRuntime` (and therefore `DEGObjectIterData`) became
non-trivial structs, the code that swaps iterators for RNA depsgraph
object iteration had to be changed a bit to be more friendly to C++
memory semantics.
Pull Request: https://projects.blender.org/blender/blender/pulls/114998
In 89e3ba4e25, the preprocess step was removed because the
normals are lazily calculated. But now we need to fetch the source normals
from the correct placed-- they still were looked for in `CD_NORMAL`.
Convert the vector socket from four nodes to a rotation socket, adding
versioning to insert the conversion nodes and change the default values
where necessary.
- Distribute Points on Faces
- Instance on Points
- Rotate Instances
- Transform Geometry
Implicit conversions from vectors and floats, and to vectors have been
added, though using rotation sockets directly can be faster, since converting
to and from Euler rotations is slow. Conversion nodes are not inserted
by versioning if the implicit conversions can be used.
This change is not forward compatible with 3.6, and socket values
are lost when opening 4.1 files in 4.0. The correct socket types are
added back in old versions, though newly added conversion nodes
may have to be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/111482
Move object runtime data to a separate header and allocate it separately
as `blender::bke::ObjectRuntime`. This is how node, mesh, curves, and
point cloud runtime data is stored.
Benefits:
- Allow using C++ types in object runtime data
- Reduce space required for Object struct in files
- Increase conceptual separation between DNA and runtime data
- Remove the need to add manual padding in runtime data
- Include runtime struct definition only in files that require it
Pull Request: https://projects.blender.org/blender/blender/pulls/113957
For improving performance in the triangulate node (#112264), it's
helpful to know whether the mesh has edges or faces that overlap
each other. If that is known to be false, the node can skip edge de-
duplication.This might apply to the future "Replace Faces" node too.
This information is stored as a flag on the mesh and set in various
places that create "clean" new meshes. It isn't calculated lazily unlike
other other areas, because the point is to improve performance, and
the calculation probably isn't faster than the duplication check it's
meant to replace.
Pull Request: https://projects.blender.org/blender/blender/pulls/113205
Refactoring of object bounds to make evaluated to original syncing
more explicit wasn't accounted for yet. This was a mistake in the most
recent refactor 1cbd0f5a85.
To fix this, add separate functions to account for `runtime.bb` which
is the data synced from the evalauted object to the original. In future
refactors, `runtime.bb` will be changed more, including a more helpful
name that reflects this purpose.
Pull Request: https://projects.blender.org/blender/blender/pulls/114897
The motion tracking always operates with horizontal sensor mapping, but
conversion code form tracking camera to Blender camera was not setting
the sensor fitting to Horizontal (Python code was leaving sensor fitting
unchanged, C code was setting it to Auto).
Additionally, the Python code was not handling camera shift, making it
so non-centered optical center was not handled correctly.
The reason why the code is written in two places is because C code is
used when conversion from tracking camera to Blender happens after solving
the motion, and the Python code is used for the "Setup Tracking Scene".
It is possible to unify some code, but it is not that much of an importance
at this time.
Pull Request: https://projects.blender.org/blender/blender/pulls/114253
This caused NOMINMAX not to be defined when `LzmaLib.h` includes
`windows.h` which causes a definition of min which upsets `std::min`
By moving BLI_winstuff.hh up, it will take care of this define for
us in case it was not yet defined regardless of openvdb being on or
off
Pull Request: https://projects.blender.org/blender/blender/pulls/114816
The distinction would start to become meaningless when we use C++
features in the older C header. The naming and lack of a proper
namespace should be enough to clarify the separation for now.
This breaks versioning because it runs beforehand, giving no time for
versioning to change to the new node type.
This reverts commit 2bf46b3189.
Ref #114803
This function shouldn't return invalid index. Instead assertion in used.
While the branchless code path may not be observably faster in current
code, it should work better with instruction level parallelism in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/114682
When loading an unknown node type from a newer Blender version, the node
storage data cannot be properly loaded. Re-saving the file will then
crash if saving with the same node type idname, since new Blender
versions cannot find the expected storage data.
Loading in older versions should replace unknown node types with a dummy
"Undefined" node that will get loaded as `NodeTypeUndefined` in newer
versions as well. Custom node types are exempted from this since they
store all data as generic ID properties and can always be fully
serialized.
Pull Request: https://projects.blender.org/blender/blender/pulls/114803
Currently, atomic additions in vertex normal calculation introduce
non-determinism that can influence the result of other operations,
sometimes causing non-reproduceable renders (in cases like #100250
and #101726). This is because the order used during threading when
accumulating face normals changes.
This commit fixes that non-determinism, using a vertex to face topology
map to calculate vertex normals without atomics. When the map is already
available, this can be faster too.
In the longer term future, this method of vertex normal calculation
means it will be easier to do partial recalculations when only part
of a mesh changes. That might be essential for cases like transforming
small selections in a non-BMesh edit mode.
As an experiment I tried a "fast" code path that avoids weighting face
normals by the corresponding corner angle when averaging them to
create vertex normals. This significantly reduces the necessary
computation and memory bandwidth for vertex normal calculation.
The results are shown below too, but it's not part of this PR.
I measured the FPS with two smooth shaded 16 million face grids:
| | Before | After | After (fast) |
| -------------------------------- | ------ | ----- | ------------ |
| Created from scratch every frame | 0.96 | 0.91 | 0.92 |
| Deformed by geometry nodes | 0.99 | 1.32 | 1.40 |
Though many other things besides normals are being tested here,
it's clear that the performance difference isn't that large either way,
though there is an observable regression with meshes created from
scratch, and there is a noticeable improvement when the topology
stays the same and is persistent.
Pull Request: https://projects.blender.org/blender/blender/pulls/111718
Discussed in #114646.
This commit transforms the "alt_navigation" option of the transform
operators into a new modal key item. "PASSTHROUGH_NAVIGATE"
In addition to cleaning up a lot of the code, it allows you to
customize the key chosen to navigate while transforming.
