Previously, md5 was used which is significantly slower. In almost all cases
this does not have a significant performance impact in practice. However,
it's possible to build geometry nodes setups that become a few percent
faster ( by combining lots of cheap node groups). Using xxhash instead of
md5 should never be slower.
Pull Request: https://projects.blender.org/blender/blender/pulls/120225
4b427e1b57 confused `unode->maxgrid` and `unode->grids.size()`
which is the number of all grids in the mesh. A follow-up commit will
rename `maxgrid` to make that clearer.
This was caused by ab84f9eaf0.
The issue is that setting the flag in the `TreeNode`
constructor means that the root group will always
hide masks when its created. This effectively disables
masks in the entire object.
Instead, leave the default flag to be `0` (masks enabled)
and explicitly set the `HIDE_MASKS` flag when
creating a new layer/layer group.
Pull Request: https://projects.blender.org/blender/blender/pulls/120218
It is not immediately clear why DDS compressed (DXT/S3TC) textures need
to be power of two in size (since nothing in DXT/S3TC intrinsically
requires that). It is only needed due to the "flip the texture upside
down" dance that we do for DDS at load time.
While at it, when logging DXT related messages, tell which texture
was it for, and dimensions. This changes logs like:
```
Unable to load non-power-of-two DXT image resolution, falling back to uncompressed.
Unable to load non-power-of-two DXT image resolution, falling back to uncompressed.
Unable to find a suitable DXT compression, falling back to uncompressed.
```
Into:
```
Unable to load non-power-of-two DXT image resolution, falling back to uncompressed (281splash-dxt1-mips.dds, 890x501).
Unable to load non-power-of-two DXT image resolution, falling back to uncompressed (281splash-dxt5-mips.dds, 890x501).
Unable to find a suitable DXT compression, falling back to uncompressed (281splash-rgba8-mips.dds, 890x501).
```
Pull Request: https://projects.blender.org/blender/blender/pulls/120210
Adds ".selection_handle_left" and ".selection_handle_right" attributes to
`CurvesGeometry` and their support in curve's select all, pick, box, circle
and lasso select tools.
Pull Request: https://projects.blender.org/blender/blender/pulls/119712
Implements the GPv2 onion skinning functionality.
There are no functional changes exept for the `use_ghosts_always`
option, which has been removed. This was used to show onion
skinning in the final render.
Pull Request: https://projects.blender.org/blender/blender/pulls/119792
After some discussions and investigation over the last couple months,
it's not clear what the "wrapper type finalize" logic is necessary for.
For edit meshes and regular meshes, normals are calculated lazily when
building the draw cache.
Apart from the unnecessary complication for mesh GPU draw data
extraction, this code also causes normals to always be calculated
when turning an edit mesh wrapper into a regular mesh. However, those
normals are immediately discarded since the edit deform cache is deleted
in the next line.
Beyond the obvious simplification, the motivation for this change is to
avoid requesting write access on the evaluated mesh and cage mesh. This
works better with implicit sharing, allowing other improvements.
Pull Request: https://projects.blender.org/blender/blender/pulls/120066
Avoid copying the positions array into the evaluated edit hints array
that's used to support editing with deformed positions when there is
a topology-changing procedural operation. In a simple test in sculpt
mode with 706k curve points, memory usage went from 78 to 70 MB.
This adds more duplication would be ideal, mainly because retrieving
the data with write access and making implicit sharing info for arbitrary
arrays aren't abstracted by implicit sharing utilities. It may be possible
to improve both of those aspects, either now or in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/120146
`xxHash` is a fast non-cryptographic hashing library. It significantly outperforms
md5 which we use in some places currently while also having great collision
resistance if not attacked explicitly.
The library is added to `extern` because that was the easiest way to do it and has
the least impact on others. I expect this library to become a required dependency
instead of an optional one. It's licence is `BSD 2-Clause` which seems to be the
first of its kind in Blender (there is `BSD 3-Clause` a couple of times).
For now, I used the library only for data deduplication when baking geometry nodes
where the same geometry is generated for each frame. The bake time in my test
goes down from >6s to <1s (note that this includes more than just the hashing time).
Pull Request: https://projects.blender.org/blender/blender/pulls/120139
after alignment, the rgb_frame's linesize is not equal to the actual
data length, so when copying the data generated from render to the
rgb_frame, they should use different linesize, one after alignment
and one before alignment.
Pull Request: https://projects.blender.org/blender/blender/pulls/120184
Caused by 2df06a05ae
totobj and selected objects are not counted for sculpt mode stats (can
do that but it's unnecessary). Hence the above commit falsely showed 0
objects in statistics. To fix this, skip showing object count in sculpt
mode, otherwise print 0 objects if selobj and totobj are none.
Pull Request: https://projects.blender.org/blender/blender/pulls/120106
Seems to be caused by c53e220aef. I didn't think our PBVH building would
ever create a node with no triangles, but I guess I was wrong, since I
checked and the PBVH is clearly being rebuilt after the trim operation,
so it seems there isn't anything else weird going on here.
Rather than trying to figure that out, I'll just add the empty check
back here. Eventually we should completely replace the algorithm that
creates the PBVH nodes anyway.
The root of the issue seems to be calling `BLI_snprintf` with the
wrong number of arguments in the `MorePointsForBezierRequired`
case. The fix arguably makes things simpler anyway: just use a
separate call in each case of the switch.
This PR completes coverage of the event icons used to represent keymap
entries on the status bar. This adds 0-9, non-alpha keys, tablet, F13-
F24, NDOF buttons, etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/120117
Adjustments to the spacing of keymap items shown in the status bar
while idle and during modal operators. Decreased space between icon
and related text makes each item have better separation.
Pull Request: https://projects.blender.org/blender/blender/pulls/120124
When the cage mesh is the output of a modifier that supports deforming
BMesh directly, it will be a mesh wrapper and `MR_EXTRACT_BMESH` will
be used. Otherwise the cage mesh will be a `Mesh` and its own normals
should be drawn instead of the the original normals. Thought this seems
deceivingly simple, it works with no modifiers, BMesh-deforming modifiers
with cage enabled and disabled, and topology changing modifiers, which
should be all the possible cases here.
