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.
Set the w component to 1 in Float to Vector implicit conversion for the
Realtime Compositor. That's because the Vector Output node expects a
vector for the velocity input, but the CPU compositor fakes it as a
color input, while assumes a fourth component of 1.
The property name can contain `"` which would cause keyframing to
fail. By escaping it those properties can now be keyframed.
E.g. property names like `"test"` now properly receive keys.
Pull Request: https://projects.blender.org/blender/blender/pulls/119922
Creating the batch cache for rendering crashes when
there is a stroke with one point that is set to cyclic.
There was a missing check for the number of points
because we're accessing the curve lengths, which
needs at least 2 points to be populated.
In `process_stroke_end`, an end point that has a thickness of 0 will be
removed, but the `IndexRange` for points isn't updated, leading to wrong
slicing downstream.
Pull Request: https://projects.blender.org/blender/blender/pulls/120165
ffmpeg AVFrame objects should use correct alignment between image
rows, or otherwise bad things might happen. In this particular
case, multi-threaded libswscale RGB->YUV conversion was trampling
over 4 bytes of V plane, for each thread boundary.
Pull Request: https://projects.blender.org/blender/blender/pulls/120168
Retain the alpha channel in Color to Vector implicit conversion for the
Realtime Compositor. That's because speed passes are exposed as color
sockets, so connecting them to a node like Vector Blur will lose the
y component of the next vectors.
The CPU compositor handles that by faking vector sockets as color
sockets internally, while the realtime compositor does not do that.
As in the Linux case, it seems like the atomic rename doesn't work on all file systems on Mac either.
We did test on Windows and it seems like there is a built in fallback, so we don't need to do this there.
Pull Request: https://projects.blender.org/blender/blender/pulls/120037
For some reason, the custom data type was set as `float[4][4]`
for tangents, but they are written as `float[4]`. The overallocation
might not have been a problem, since it looks like the extra memory
was never written to. But it's still confusing and potentially bad for
performance.