Before rBa8a454287a27, edge creases were copied to the result mesh as
part of `MEdge`. Now they are stored in a separate `CD_CREASE` layer,
which I mistakenly disabled for interpolation. However, to maintain
the geometry node uses a field input, remove the interpolated attribute
there.
**Empty Slot Fix**
Currently the boolean modifier transfers the default material from
meshes with no materials and empty material slots to the faces on the
base mesh. I added this in a2d59b2dac9e for the sake of consistency,
but the behavior is actually not useful at all. The default empty
material isn't chosen by users, it just signifies "nothing," so when
it replaces a material chosen by users, it feels like a bug.
This commit corrects that behavior by only transferring materials from
non-empty material slots. The implementation is now consistent between
exact mode of the boolean modifier and the geometry node.
**Index-Based Option**
"Index-based" is the new default material method for the boolean
modifier, to access the old behavior from before the breaking commit.
a2d59b2dac9e actually broke some Boolean workflows fundamentally, since
it was important to set up matching slot indices on each operand. That
isn't the cleanest workflow, and it breaks when materials change
procedurally, but historically that hasn't been a problem. The
"transfer" behavior transfers all materials except for empty slots,
but the fundamental problem is that there isn't a good way to specify
the result materials besides using the slot indices.
Even then, the transfer option is a bit more intuitive and useful for
some simpler situations, and it allows accessing the behavior that has
been in 3.2 and 3.3 for a long time, so it's also left in as an option.
The geometry node doesn't get this new option, in the hope that we'll
find a better solution in the future.
Differential Revision: https://developer.blender.org/D16187
**Empty Slot Fix**
Currently the boolean modifier transfers the default material from
meshes with no materials and empty material slots to the faces on the
base mesh. I added this in a2d59b2dac9e for the sake of consistency,
but the behavior is actually not useful at all. The default empty
material isn't chosen by users, it just signifies "nothing," so when
it replaces a material chosen by users, it feels like a bug.
This commit corrects that behavior by only transferring materials from
non-empty material slots. The implementation is now consistent between
exact mode of the boolean modifier and the geometry node.
**Index-Based Option**
"Index-based" is the new default material method for the boolean
modifier, to access the old behavior from before the breaking commit.
a2d59b2dac9e actually broke some Boolean workflows fundamentally, since
it was important to set up matching slot indices on each operand. That
isn't the cleanest workflow, and it breaks when materials change
procedurally, but historically that hasn't been a problem. The
"transfer" behavior transfers all materials except for empty slots,
but the fundamental problem is that there isn't a good way to specify
the result materials besides using the slot indices.
Even then, the transfer option is a bit more intuitive and useful for
some simpler situations, and it allows accessing the behavior that has
been in 3.2 and 3.3 for a long time, so it's also left in as an option.
The geometry node doesn't get this new option, in the hope that we'll
find a better solution in the future.
Differential Revision: https://developer.blender.org/D16187
Makes code safer, easier to understand, and less verbose. I detected
negligible performance differences, only a slight improvement for the
normalize step where the function call overhead was probably more
of a bottleneck.
I kept `memset` instead of `.fill(float3(0))` because that gave
better performance in my tests. In the future that stage could be
parallelized, or we could make sure new arrays are allocated with
`calloc`.
It's helpful to have these topology maps standardized and organized
a bit better so they can be optimized and considered for future caching
together. Also use a more standard name for the map for that purpose.
Fix a performance regression from 05952aa94d by storing pointers
to mesh arrays locally in the subdiv foreach context. In a simple test
of a 1 million face grid, this improved performance by 5% (from 0.31
to 0.295 seconds).
A utility function retrieved mesh arrays for every element after
05952aa94d which can be easily avoided. This was used when
building the GPU indices for sculpt mode drawing. In my tests this
saves 0.1ms per PBVH node. There may be very slight improvements
in line art and shrinkwrap as well.
The issue was that geometry nodes was not reevaluated after changing the
content of the collection. That resulted in the other object still having a
reference to the deleted object, which resulted in a crash when it tried to
access it.
Adding the `ID_RECALC_GEOMETRY` tag indicates that the content of the
collection has changed and will trigger geometry nodes setups that depend
on the collection to update.
{F13294314}
# Process
In the pixel extraction process a larger domain will be extracted then the input mesh.
The borders of uv islands are extended with connected geometry of the input mesh.
The extended mesh is then fed into the pixel extraction process.
A mask is used to limit the extraction so UV islands will not overlap.
Input UV islands.
{F13206401}
Extended UV Island (only one showing).
{F13288764}
This patch doesn't include fixing uv seams at non-manifold edges (like suzannes eyes) as that
would require a different approach (edge extending or pixel copy-ing). The later has already been
implemented in D14702, but should be revisited to only use do the non-manifold edge fixing.
This patch supports fixing UV seams across UDIM textures.
There might be an issue when using a single texture on multiple uv maps.
Reviewed By: brecht, joeedh, JulienKaspar
Maniphest Tasks: T97352
Differential Revision: https://developer.blender.org/D14970
Instead of creating a new mesh from scratch, modify an existing mesh.
This allows us to keep derived caches for triangulation and bounds
alive more easily, and allows keeping materials and non-generic
attributes like vertex groups alive on the mesh.
It also has other performance benefits, since face and face corner
attributes aren't affected at all, and because of reduced overhead
from not allocating a new mesh.
Updating edge attributes is a bit more complicated now, since we
have to completely replace the arrays but keep the existing attribute
IDs around. The new mesh update tag is also slightly too specific IMO.
But I think both of those things will improve in the future because
of existing plans for further refactoring these areas:
- New attribute storage that gives pointer stability
- Further use and granularity of mesh update tagging that will
make the correct API more clear
Fixes T102711
Differential Revision: https://developer.blender.org/D16615
The main goal here is to move towards more self contained node
definitions. Previously, one would have to change `blenkernel` to
add a new node which is not necessary anymore. There is no need
for all these register functions to "leak out" of the nodes module.
Differential Revision: https://developer.blender.org/D16612
Basically copy the information from the commit message of the
03e2f11d48 directly to the code.
This makes the information easier to find when working on the
code.
Swapping some ID lists between Mains must invalidate the name_map cache.
Note that in theory, at least WM type could be ignored by name_map
cache, since it is a singleton. However, don't think it's worth adding
extra complication here, for really marginal benefits. The overhead of
rebuilding the name cache here is extremly small.
For some reason, this issue did not show so far in master, only appeared
in some branch work on improving (in)direct status of linked IDs... Go
figure.
a5e7657cee didn't account for slices of zero sizes, and the asserts
were slightly incorrect otherwise. Also, the change didn't apply to
`Span`, only `MutableSpan`, which was a mistake. This also adds "safe"
methods to `IndexMask`, and switches function calls where necessary.
This is not used for anything in practice currently. The original intention
was probably to generate different socket subtypes, but that is solved
differently now (e.g. using `NodeSocketFloatDistance`). It's possible
that an addon tried to use this but it's rather unlikely.
Differential Revision: https://developer.blender.org/D13188
Before this, if there were no missing files, the operator would run
successfully but there would be no user feedback at all, making the
user wonder if the operator was even run.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D16585
`GeometrySet::has()` can return an empty component. It's more convenient
if it doesn't, since other code rarely wants to access an empty component.
The alternative would be adding an `is_empty()` check in the lazy function
for the viewer node, that would work fine too, for this case.
Differential Revision: https://developer.blender.org/D16584
When combining the internal geometry component instancing (used when
the original object type doesn't match the evaluated data type) with
the "vertex dupli" instancing could cause the fix from e508de0417
to fail, because the subsequent fix from 864af51d6a popped from the
"instance generator type" stack even when there was nothing added to it
(for geometry instancing).
Currently the face set of every single face is saved for every sculpt undo step.
When only changing the face sets of a small section of the mesh, this can be quite
wasteful. It also makes face sets a special case compare to all other sculpt undo step
types, which makes the whole system more complex and harder to improve.
Fixes T101203.
Reviewed By: Hans Goudey
Differential Revision: https://developer.blender.org/D16224
Ref D16224
Currently the face set of every single face is saved for every sculpt undo step.
When only changing the face sets of a small section of the mesh, this can be quite
wasteful. It also makes face sets a special case compare to all other sculpt undo step
types, which makes the whole system more complex and harder to improve.
Fixes T101203.
Reviewed By: Hans Goudey
Differential Revision: https://developer.blender.org/D16224
Ref D16224
We currently check multiple dynamic attribute providers for the
attribute ID, even after it has been removed (which can free the name).
This was used as a simple way to remove multiple attributes with the
same name (dealing with name collisions). However, that doesn't happen
in practice at this point, since so much code has moved to the
attribute API which checks for it.
Wrote a new API method, BKE_pbvh_sync_visibility_from_verts
that flushes vertex hidden flags to edges & faces.
Fixes not being able to sculpt outside a face set after
undoing the fkey hide-all-but-this operator.
Wrote a new API method, BKE_pbvh_sync_visibility_from_verts
that flushes vertex hidden flags to edges & faces.
Fixes not being able to sculpt outside a face set after
undoing the fkey hide-all-but-this operator.
This avoids need to do special trickery detecting whether the principal
point is to be changed when reloading movie clip. This also allows to
transfer the optical center from high-res footage to possibly its lower
resolution proxy without manual adjustment.
On a user level the difference is that the principal point is exposed in
the normalized coordinates: frame center has coordinate of (0, 0), left
bottom corner of a frame has coordinate of (-1, -1) and the right top
corner has coordinate of (1, 1).
Another user-visible change is that there is no more operator for setting
the principal point to center: use backspace on the center sliders will
reset values to 0 which corresponds to the center.
The code implements versioning in both directions, so it should be
possible to open file in older Blender versions without loosing
configuration.
For the Python API there are two ways to access the property:
- `tracking.camera.principal_point` which is measured in the normalized
space.
- `tracking.camera.principal_point_pixels` to access the pixel-space
principal point.
Both properties are not animatable, so there will by no conflict coming.
Differential Revision: https://developer.blender.org/D16573
