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.
Only converted value types in the structures.
The pointer values are left unchanged as it requires more careful look
to avoid possible alignment mismatch.
Function arguments are left unchanged as well.
Only float[3] is converted as the float[4] will likely need to be
converted to some C++ rotation class. And float[4][4] often did not
compile when change is only done in the header.
Pull Request: https://projects.blender.org/blender/blender/pulls/114636
Cleanup talked about in the previous semi-related PR, #114501
- saacos, saasin, sasqrt have been 100% identical to saacosf,
saasinf, sasqrtf since 2012.
- For all the above, there exist more intuitively named safe_acosf,
safe_asinf, safe_sqrtf that do the same thing, so switch all code to those.
Pull Request: https://projects.blender.org/blender/blender/pulls/114593
Function Module Inclusive Time Exclusive Time
--------------------------------------------------------------------------
mesh_render_data_update_normals blender 297.51 0.00
315 -> 297
acos() usage in all places related to normal calculations shows up in the
profiler. Given that "angle between faces" is only additional heuristic
weight in there (the effect of it at all is very subtle), approximate but
faster version of acos() might be just fine. Especially since some other
parts of Blender (e.g. mikktspace) use approximate acos in a conceptually
the same part.
- Adds safe_acos_approx() to BLI_math_base.hh. Implementation the same
as already exists in Cycles; max error 0.00258 degrees. Between 2x and 4x
faster in my tests.
- Changes all normals related calculations to use the function above instead
of saacos.
Computing normals on a Stanford Lucy (14m verts) mesh:
- Mac (arm64, M1 Max): 247ms -> 229ms
- Win (x64, Ryzen 5950X): 276ms -> 250ms
All places that are about "normal calculation" were changed, including e.g.
Corrective Smooth modifier. Applying that one to the same 14m vertices mesh,
Mac M1 Max: 9.96s -> 9.76s
Tiny changes in several test output expectations w.r.t. normals are
observed, these were reviewed and updated expectations checked in svn.
Pull Request: https://projects.blender.org/blender/blender/pulls/114501
Extract:
- "Attribute", when creating a new attribute with
`GEOMETRY_OT_attribute_add()`: make the default name in the operator
a null string, and set it to "Attribute" translated inside an invoke
method instead.
- Also for new attributes, from `BKE_id_attribute_calc_unique_name()`,
for instance to create a default vertex color layer when going into
Vertex Paint mode: use `DATA_()` instead of `IFACE_()`, since it
represents user data.
Disambiguate:
- "Weight" can be the thickness of font glyphs.
- "Mark as Asset" and "Clear Asset" are operator names already
extracted using the Operator context. They were recently added to a
manual translation in the UI, but the existing one can be reused.
- "Second" as a time unit in the context of frame snapping.
Some messages reported by Satoshi Yamasaki in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/114159
