| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
To use function style cast '(unsigned char)x' can't be replaced by
'unsigned char(x)'.
|
|
|
|
Sculpt attribute API was incorrectly allocating duplicate
attribute layers.
|
|
Caused by 060a5341419412fd7996cf99.
|
|
When adapting the domain of a single value virtual array, skip
allocating an array for the result and just return another single
value. Among other cases, this can help when everything is selected
in sculpt mode, moving domain interpolation from 5% of perf samples
to 0% when sculpting.
|
|
|
|
Correction of U.dpi to hold actual monitor DPI. Simplify font sizing by
omitting DPI as API argument, always using 72 internally.
See D15961 for more details.
Differential Revision: https://developer.blender.org/D15961
Reviewed by Campbell Barton
|
|
|
|
|
|
This patch replaces the existing transfer attribute node with three
nodes, "Sample Nearest Surface", "Sample Index", and "Sample Nearest".
This follows the design in T100010, allowing for new nodes like UV
sampling in the future. There is versioning so the new nodes replace
the old ones and are relinked as necessary.
The "Sample Nearest Surface" node is meant for the more complex
sampling algorithms that only work on meshes and interpolate
values inside of faces.
The new "Sample Index" just retrieves attributes from a geometry at
specific indices. It doesn't have implicit behavior like the old
transfer mode, which should make it more predictable. In order to not
change the behavior from existing files, the node has a has a "Clamp",
which is off by default for consistency with the "Field at Index" node.
The "Sample Nearest" node returns the index of the nearest element
on a geometry. It can be combined with the "Sample Index" node for
the same functionality as the old transfer node. This node can support
curves in the future.
Backwards compatibility is handled by versioning, but old versions can
not understand these nodes. The warning from 680fa8a523e0 should make
this explicit in 3.3 and earlier.
Differential Revision: https://developer.blender.org/D15909
|
|
The C++ vertex group data accessor returned a span with null data that
wasn't empty. Instead of adding a null check as well as the size check,
just return an empty span when there is no vertex group data.
|
|
The condition from 0d7d8c73cf5c5c5f05c was reversed.
|
|
Using the attribute name semantics from T97452, this patch moves the
selection status of mesh elements from the `SELECT` of vertices, and
edges, and the `ME_FACE_SEL` of faces to generic boolean attribute
Storing this data as generic attributes can significantly simplify and
improve code, as described in T95965.
The attributes are called `.select_vert`, `.select_edge`, and
`.select_poly`. The `.` prefix means they are "UI attributes",so they
still contain original data edited by users, but they aren't meant to
be accessed procedurally by the user in arbitrary situations. They are
also be hidden in the spreadsheet and the attribute list.
Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when selection is used. When the flags are removed
completely, requirements will decrease.
Further notes:
* The `MVert` flag is empty at runtime now, so it can be ignored.
* `BMesh` is unchanged, otherwise the change would be much larger.
* Many tests have slightly different results, since the selection
attribute uses more generic propagation. Previously you couldn't
really rely on edit mode selections being propagated procedurally.
Now it mostly works as expected.
Similar to 2480b55f216c
Ref T95965
Differential Revision: https://developer.blender.org/D15795
|
|
This is very similar to D14077. There are two differences though.
First is that vertex creases are already stored in a separate layer,
and second is that we can now completely remove use of `Mesh.cd_flag`,
since that information is now inherent to whether the layers exist.
There are two functional differences here:
* Operators are used to add and remove layers instead of a property.
* The "crease" attribute can be created and removed by geometry nodes.
The second change should make various geometry nodes slightly faster,
since the "crease" attribute was always processed before. Creases are
now interpolated generically in the CustomData API too, which should
help maintain the values across edits better.
Meshes get an `edge_creases` RNA property like the existing vertex
property, to provide more efficient access to the data in Cycles.
One test failure is expected, where different rounding between float
the old char storage means that 5 additional points are scattered in
a geometry nodes test.
Differential Revision: https://developer.blender.org/D15927
|
|
The mesh's triangulation cache is often created for other operations
besides the drawing code, but during the mesh draw cache extraction
it is recalculated on every single time. It is simpler and faster to use
the existing MLoopTri array. It can also save memory if the cache
already exists by avoiding allocating a duplicate array. For a 4 million
face quad mesh, that is already 128 MB.
Also use face normals for mesh triangulation if they aren't dirty,
which should provide a general speedup when they're both necessary.
Recently 54182e4925de made this more reliable, since the triangulation
cache is invalidated properly when the mesh is deformed.
Fixes T98073
Differential Revision: https://developer.blender.org/D15550
|
|
Similar to the other refactors from T95965, this commit moves sculpt
face sets to use a generic integer attribute named `".sculpt_face_set"`.
This makes face sets accessible in the Python API.
The attribute is not visible in the attributes list or the spreadsheet
because it is meant for internal use, though that could be an option
in the future along with other similar attributes. Currently the change
is small, but in the future this could simplify code by allowing use
of more generic attribute APIs.
Differential Revision: https://developer.blender.org/D16045
|
|
|
|
This makes it easier to pass more parameters to the iterator in the future.
Differential Revision: https://developer.blender.org/D16047
|
|
Whenever animation on nodes was transfered to/from nodegroups (grouping/
ungrouping/separating) via BKE_animdata_transfer_by_basepath, it was
possible to create new nodes with the same name (in the formerly same
path -- see report for an example of this) and animation from the
original node was still performed on them. Issue went away after save/
reload.
In order to fully update the action, a depsgraph is now performed on the
action (similar to what is done when renaming for example).
Maniphest Tasks: T101109
Differential Revision: https://developer.blender.org/D15987
|
|
|
|
Also reported in blender.chat.
Corrupted files were reported after opening files with the new Mix node (rBbfa0ee13d539).
Files saved in 3.4 will not be compatible with older versions of Blender.
Opening these files in previous versions will exhibit a red undefined node.
Reviewed By: HooglyBoogly, brecht
Differential Revision: https://developer.blender.org/D16025
|
|
From the nodes' description: "Retrieve the object that contains
the geometry nodes modifier currently being executed". This was
discussed in the most recent geometry nodes module meeting.
Because the node allows you to retrieve the position of the modifier
object, it has to add a depsgraph relation to object transform.
Expect that modifiers will be reevaluated when moving the object.
In the future, better static analysis of node trees could make this
check smarter.
Differential Revision: https://developer.blender.org/D16037
|
|
Also make the disabled hint argument optional.
|
|
This removes some boilerplate when creating many optional attributes.
|
|
The typed "lookup_or_add_for_write_only" function is meant to do the
same thing as the non-typed version of the function. Instead, it still
initialized values of new attribute arrays, which isn't meant to happen.
Missed in 4c91c24bc7cbe2c4f97be373.
I also had to correct one place that used the "write_only"
function but didn't intialize all values.
|
|
I didn't observe this issue in practice, but since the write_only
version of the attribute API isn't meant to initialize trivial types,
theoretically this could be a problem if the attribute is created
halfway through converting the BMesh to a Mesh.
|
|
|
|
05952aa94d33eeb504fa modified this area incorrectly, transforming
vertices outside of the mesh. That would have been fine, but the mesh
is used to retrieve the bounding box. Instead just avoid duplicating the
positions and normals completely, and avoid using referenced layers
just to be extra safe.
|
|
|
|
Face sets were not being initialized. I had also
forgotten to remove a dead struct member from
SculptBoundary which was being accessed.
|
|
Differential Revision: https://developer.blender.org/D16020
|
|
Links that are linked to unavailable sockets should be ignored.
|
|
Currently the rake rotation is calculated when the angle mode is set. Even when the texture isn't valid.
This change will only calculate the rake rotation when the texture is valid and the angle mode is set.
|
|
|
|
Currently node group assets are supported, but using them by dragging
from the asset browser is cumbersome. This patch adds all node group
assets from user asset libraries and the current file libraries to the
add node search menu and the link drag search menu.
Node groups added through the search will have their "options" hidden,
meaning the data-block selector is displayed. This helps keep the UI
clean, and the selector shouldn't be necessary anyway.
To make that possible, metadata like the node tree type and its inputs
and outputs has to be saved in the file. This requires re-saving the
files that contain the assets with the patch applied.
The node add search operator is moved from Python to C++ to ease
development and allow more flexibility. It supports a tooltip that
gives the description of assets.
Currently the node groups are added with the asset system's existing
"Append & Reuse" behavior. It's likely that linking should be possible
in the future too, but for now the idea is to use the more foolproof
option that doesn't create dependencies between files.
Because loading assets can potentially take a long time, the search
menu refreshes its items as new assets are loaded. However, changing
the search field is necessary to see the update.
Differential Revision: https://developer.blender.org/D15568
|
|
This commit adds a node to distribute points inside of volume grids.
The "Random" mode usese OpenVDB's "point scatter" implementation, and
there is also a "Grid" mode for uniform distributions. Both methods
operate on all of the float grids in the volume, using every voxel with
a value higher than the threshold. The random method is not stable as
the input volume deforms.
Based on a patch by Angus Stanton (@abstanton), which was based on a
patch by Kenzie (@kenziemac130).
Differential Revision: https://developer.blender.org/D15375
|
|
|
|
|
|
In `BKE_mesh_tag_coords_changed_uniformly` the checks for dirty vertex
and dirty poly normals were swapped around, causing an assert to be
triggered.
Differential Revision: https://developer.blender.org/D16002
|
|
`CurveEval` was added for the first iteration of geometry nodes curve
support. Since then, it has been replaced by the new `Curves` type
which is designed to be much faster for many curves and better
integrated with the rest of Blender. Now that all curve nodes have
been moved to use `Curves` (T95443), the type can be removed,
along with the corresponding geometry component.
|
|
This is the last node to use the `CurveEval` type. Since the curve to
points node is basically the same as the resample node, now it just
reuses the resample code and moves the curve point `CustomData` to a
new point cloud at the end. I had to add support for sampling tangents
and normals to the resampling.
There is one behavior change: If the radius attribute doesn't exist,
the node won't set the radius to 1 for the output point cloud anymore.
Instead, the default radius for point clouds will be used.
That issue was similar to T99814.
Differential Revision: https://developer.blender.org/D16008
|
|
The issue was that not all Group Input nodes were updated when
the node group interface changed.
|
|
With the recent addition of the UV unwrapping node, there is a need to
be able to create seams easily. This node does that by outputting a
selection of the boundaries between different input face sets. In the
context of UV mapping, one inputs the "patches" you want, and the node
gives you the seams needed to make those patches.
Differential Revision: https://developer.blender.org/D15423
|
|
Correct interpolation of integer POD types for Catmull Rom
interpolation as implemented in eaf416693dcb.
**Problem description**
`attribute_math::DefaultMixer<T>::mix_in()` assumes/asserts positive
weights but the basis function for Catmull-Rom splines generates
negative weights (see image in revision). Passing negative weights will
yield correct result as sum(weights) = 1 (after multiplication by 0.5)
but the assert is still triggered in debug builds. This patch adjusts
the behavior by extending the mix functions with mix4(). The benefit
of using mix#() over a DefaultMixer is that the result no longer needs
to be divided by the weight sum, instead utilizing that the basis weight
sum is constant (see plot).
**Changes**
* Added mix4() and updated catmull_rom::interpolate() to use it.
* Removed TODOs from catmull_rom functions.
* Moved mix definitions to be ordered as 2, 3, 4 in the header.
**Implementation specifics**
`catmull_rom::interpolate()` uses a constexpr to differentiate between
POD types which multiplies the result with 0.5 after weighting the
values, this reduces the number of multiplications for 1D, 2D, 3D
vectors (https://godbolt.org/z/8M1z9Pxx6). While this could be
considered unnecessary, I didn't want to change the original behavior
as it could influence performance (did not measure performance here
as this should ensure the logic is ~identical for FP types).
Differential Revision: https://developer.blender.org/D15997
|
|
While this worked, the result for curves with a resolution of zero was
just a single evaluated point, which isn't useful or intuitive. Using
the attribute validation from 8934f00ac5701ea34, make sure users
can't set values 0 or less.
|
|
Fixes test failures from 8934f00ac5701ea349f2b.
|
|
We expect some builtin attributes to have positive values or values
within a certain range, but currently there some cases where users
can set attributes to arbitrary values: the store named attribute node,
and the output attributes of the geometry nodes modifier. The set
material index node also needs validation.
This patch adds an `AttributeValidator` to the attribute API, which
can be used to correct values from these untrusted inputs if necessary.
As an alternative to D15548, this approach makes it much easier to
understand when validation is being applied, without the need to add
arguments to every attribute API method or complicate the virtual
array system.
Currently validation is provided with a multi-function. That integrates
well with the field evaluations that set these values now, but it could
be wrapped to be friendlier to other areas of Blender in the future.
The Python API is not handled here either. Currently I would prefer to
wait until we can integrate the C++ and C attribute APIs better before
addressing that.
Fixes T100952
Differential Revision: https://developer.blender.org/D15990
|
|
This bug was caused by the weird ownership logic for render results.
Basically, the most recent render result is owned by the Render, while
all others are owned by the RenderSlots.
When a new render is started, the previous Render is handed over to its
slot, and the new slot is cleared. So far, so good.
However, when a slot is removed and happens to be the one with the most
recent render, this causes a complication.
The code handles this by making another slot the most recent one, along
with moving its result back to the Render, as if that had always been
the most recent one.
That works, unless there is no most recent render because you haven't
rendered anything yet. Unfortunately, there is no way to store "there
hasn't been a render yet", so the code still tries to perform this
handover but can't.
Previously, the code handled that case by just refusing to delete the
slot. However, this blocks users from deleting this slot.
But of course, if there hasn't been a render yet, the slots will not
contain anything yet, so this entire maneuver is pointless.
Therefore, the fix for the bug is to just skip it altogether if there
is no Render instead of failing the operation.
Technically, there is a weird corner case remaining, because Renders
are per-scene. Therefore, if a user renders images in one scene,
switches to a different scene, deletes a slot there and then switches
back, in some situations the result in the deleted slot might end up
in the next slot.
Unfortunately this is just a limitation of the weird split ownership
logic and can't just be worked around. The proper fix for this
probably would be to hand over ownership of the result from the Render
to the RenderSlot once the render is done, but this is quite complex.
Also fixes a crash when iuser->scene is NULL.
|
