Part of #118145.
The proxy system was used to store the accumulated translation from
the deformation of multiple symmetry passes. After a brush/tool update
step, all PBVH nodes with proxies were gathered, the proxies from
each symmetry passes were accumulated, and the deformation was applied
to the evaluated mesh, then the base mesh and shape keys.
In the recently refactored brushes, the translations are immediately
applied to the base mesh and shape keys instead. That avoids the need
for storing a float vector for every affected vertex during the
deformation. Reducing memory usage and affecting the memory that is
already hot in the cache has significant performance benefits too.
Also, brushes are now more conceptually independent-- they don't
rely on a separate pass to actually apply deformations.
Finally removing the proxy system reduces the size of PBVH nodes from
728 to 416 bytes. That's helpful as part of the effort to reduce per-
node overhead in order to make nodes smaller, and helps to reduce the
responsibilities of the PBVH, to focus it on being a BVH tree instead
of "bag for storing arbitrary user-interaction data."
Move the node update tagging and normal recalculation outside of the
generic filter initialization to the callers. This avoids unnecessarily
recalculating all normals when the filter/transform starts. That's
especially unnecessary for the color filter which doesn't affect positions.
Part of #118145.
There is more cleanup possible here, particularly doing some loop
fission and making the brush use our common utilities will help
remove some code and make better use of auto-vectorization.
But with this commit the code we want to remove is no longer
used, so we can stop here for now.
Size icons to subpixel precision to give slightly better results when used
with fractional resolution scales.
---
This change is very subtle. So you might have to trust me or get your reading glasses on...
Our icons are designed for small sizes. When the Blender resolution scale is set to exactly 1.0 then the icons are aligned perfectly to a 14x14 grid and features like lines are exactly one pixel wide. So these one-pixel wide lines are perfectly aligned to the pixel grid. Change the scale to 2.0x and they also align perfectly, just with lines that are two pixels wide.
But what happens at 1.25x scale? Now the icon is 17.5 pixels and lines in it are a pixel and a quarter wide . The best that can be is a solid pixel and one next to it that is quarter-opacity. But it can get worse than that as it could potentially touch three adjacent pixels.
Our old icon code took an icon bitmap that was rendered larger and scaled it into the desired size. Because this was done by the opengl shader, this scaling was done to subpixel size. So at 1.25 scale you got an icon that was 17.5 pixels.
The new icon code is truncating the sizes to integer before rendering. I thought this was best, but I was wrong.
The following image has three rows. The top is the old icon code, with UI scale from 1.0, 1.25, 1.5, 1.75, and 2.0. The second row is current code. The third is with this PR:
The first and last columns are identical, obviously because the design perfectly fits the pixel grid.
The left green area, at 1.25 scale, current code is forcing the design into an integer size, while (bottom) gives a more pleasing result as it is properly spread over 17.5 pixels.
The right green area is more interesting. With both the old code and new code, the 1.75 pixel wide line is spread over three pixels. The PR nicely spreads it over two pixels.
Hard to tell; Just squint. This is just very slightly more pleasing rendering of icons.
Pull Request: https://projects.blender.org/blender/blender/pulls/124436
Moving a strip retiming key at the end of a strip, so that a strip
overlaps another one would leave them overlapped. The expected
behavior is that it acts according to the Overlap Mode, like it does
when moving a strip.
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/124424
Lowering the speed of a strip that doesn't have user-created retiming
keys using the "Set Speed" operator would cause the strip to overlap
neighboring strips. The fix shuffles the retimed strip to avoid
overlap. This now matches the behavior of the same operator, when
using it on a user created retiming key.
Pull Request: https://projects.blender.org/blender/blender/pulls/124414
- Access positions from a thread-local array
- Replace use of the proxy system with immediately applied translations
- Access data from stroke cache directly
This addresses #124016. The report provides a scene to test the changes.
Currently, the Blender and MaterialX color spaces are not fully aligned,
but the linear/srgb heuristic should cover most cases however.
Pull Request: https://projects.blender.org/blender/blender/pulls/124315
This adds a new `name` member to the `GeometrySet` class. This name can be set
with the new `Set Geometry Name` node. Currently, the name is only used in the
spreadsheet when displaying instances.
The main purpose of this name is to help debugging in instance trees. However, in the
future it may also be used when exporting instance trees or when creating separate
objects from them.
Note, the name is not expected to be unique, it is fully in user control.
Naming geometries is necessary to make the spreadsheet more useful for instances,
because currently the user has no information for which geometry is used by each instance.
We also want to use this name to improve the integration with grease pencil where
sometimes layers become instances with the same name.
Pull Request: https://projects.blender.org/blender/blender/pulls/114910
Having both custom vertex normals and the "is the face sharp?"
attribute on a mesh leads to some non-intuitive behaviours. Instead,
make the behaviour more aligned with OBJ format description wording,
which says "When vertex normals are present, they supersede
smoothing groups" (https://paulbourke.net/dataformats/obj/).
Pull Request: https://projects.blender.org/blender/blender/pulls/124366
Even if Cycles is not the active render engine, this
versioning code could affect Cycles if a material was
used with Cylces in another file (using linking).
Fix this by spliting the output node into another one
that only affects EEVEE.
Increase fail threshold for tests with platform
dependent noise.
Blacklist `principled_thinfilm_transmission` as
the IOR is very small and isn't packed to the GBuffer
with the same precision on every platform.
Also see 06be295946.
These aren't all cases, but a few that I found by addding a static
assert in `MEM_new` so that it fails for trivially constructible types.
The viewport compositor crashes when the scene is changed in some
situations. That's because the viewport compositor tries to use node
tree data that was freed in the last depsgraph update, while it should
have invalidate those references based on the same depsgraph update.
The source of this issue is in the depsgraph itself. In particular, when
the depsgraph evaluation happens in two passes, the ID recalculate flags
are backed up for every pass then restored at the end of all passes,
however, this doesn't happen for the ID Type Update table. So whenever
evaluations happen in two passes, changes will not be propagated to
engines that require those information, like the viewport compositor
engine in that particular case.
To fix this, we backup and restore the ID Type Update table in a similar
manner to the ID recalculate flags.
Fixes#107235, #124335, #116142.
Pull Request: https://projects.blender.org/blender/blender/pulls/124409
The `trim_end_points` in the draw tool was only supposed to be able to remove
end points of the stroke.
Make sure to clamp the value so that at least one point remains in the curve.
Move some methods on `Slot` in the source file so that they sit next to
their siblings. Some unrelated functions squeezed in between them.
No functional changes.
BPY `library.write` has been moved to new PartialWriteContext code a few
weeks ago, removing this call to `BKE_blendfile_write_partial_end` was
somehow missed then.
