Cleanup to simplify code by using common terms like _first_ and _last_ in context
of predicate applying in a range just like we do for spans and range containers.
Pull Request: https://projects.blender.org/blender/blender/pulls/130380
Looks like the initial version of this struct was copied from Alembic.
Remove the fields that were never ultimately used and initialize the
remaining fields inline.
Pull Request: https://projects.blender.org/blender/blender/pulls/130492
GPv3 build modifier in "Nature Drawing Speed" mode didn't finish
building a frame when the time it took to draw those strokes by hand is
greater than the frame duration. Previous fix#129894 is only effective
for "Number of Frames" build mode. This fix moved the timing scaling
into `get_build_factor` and `get_factor_from_draw_speed` for more
granulated control in different modes.
Pull Request: https://projects.blender.org/blender/blender/pulls/130199
Adds a link to our guide on how to manually collect system information
to the bug report form. This is useful for the situation in which Blender
isn't opening.
Pull Request: https://projects.blender.org/blender/blender/pulls/126039
This member was only really used by `transform_convert_object.cc` and
`transform_convert_object_texspace.cc`.
So instead of using a super-specialized member, use `TransData::extra`
instead.
Turns out that with `-fassociative-math`, GCC turns
`(1.0f - cos_NH2) + alpha2 * cos_NH2` into
`cos_NH2 * (alpha2 - 1.0f) + 1.0f`.
Not sure why since the operation count is the same, but if alpha2 is very
small, `alpha2 - 1.0f` will be exactly -1.0f, which then causes issues.
Luckily, having one_minus_cos_NH2 as its own variable appears to be enough to
make GCC keep the original formulation.
Just to be safe, I've also used one_minus_cos_NH2 in the other branch to
hopefully reduce the chance of it being folded in again. Also turns a
division into a reciprocal, which is in theory slightly faster.
Pull Request: https://projects.blender.org/blender/blender/pulls/130469
Adds support for saving some view state persistently and uses this to keep the
height of a tree-view, even as the region containing it is hidden, or the file
re-loaded.
Fixes#129058.
Basically the design is to have state stored in the region, so it can be saved
to files. Views types (tree-view, grid-view, etc) can decide themselves if they
have state to be preserved, and what state that is. If a view wants to preserve
state, it's stored in a list inside the region, identified by the view's idname.
Limitation is that multiple instances of the same view would share these bits of
state, in practice I don't think that's ever an issue.
More state can be added to be preserved as needed. Since different kinds of
views may require different state, I was thinking we could add ID properties to
`uiViewState` even, making it much more dynamic.
Pull Request: https://projects.blender.org/blender/blender/pulls/130292
This is a more invasive change to the timecode indexer because ffmpeg removed the ability to to get the `pkt_pos` (byte location of a frame packet):
27f8c9b27b
As stated there, they don't think that using it too seek is any better than using the dts or the pts position of the packets.
While you can still seek with the byte position, you need to do quite a bit of extra work to get this information from ffmpeg.
As we are only using it for the indexer and only if the fileformat was quite old (mpegts etc) I thought that we could instead simplify this and always seek by the pts timestamp instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/130444
Recently the GLSL code was changed in Blender. For every GLSL file
the #line directive was added. However due to limitations in Blender
we misuse the indexed based line directive to store a hash. This is not
according to the spec where indexes should index the source inside the
array of sources. In vulkan the indexed based approach is not
'supported' as the compiler inputs only accepts a single file.
We tried to support file based approach but that lead to other issues in
renderdoc. Might be related to that the source file doesn't exist on the
file system.
This PR fixes this by scrambling the #line directive so the
step-by-step debugger can be used. The scrabling only happens when
blender is started with the `--debug-gpu-renderdoc` startup argument.
Pull Request: https://projects.blender.org/blender/blender/pulls/130458
The function table symbol declared in the headers was renamed starting
in OptiX 8.1, from `g_optixFunctionTable` to
`g_optixFunctionTable_<ABI version>`. This adds support for that by
using the new macro for the name when available (after OptiX 8.1) and
falling back to the old name when it is not (before OptiX 8.1).
Pull Request: https://projects.blender.org/blender/blender/pulls/130451
Allow passing range of resources inside the draw manager.
This allows to reduce the overhead of the drawing logic
for group of instances sharing the same drawing state.
The only catch is that we do consider them as having the
same handedness, which seems to be a valid assumption for
now.
For now this is not used and just change the API in a transparent
way to allow incremental changes to the engines code.
Pull Request: https://projects.blender.org/blender/blender/pulls/130290
RNA accessors should never (ever?) modify the `owner_id` of their parent
PointerRNA data. This is opening a potential monstruous can of worms.
If such behavior is absolutely needed, there should be a very detailed
comment about why!
In the present case, this does not seem needed at all - and was most
likely fairly harmless in practice.
Filling the background Box of a text strip was a single-threaded
code before. Which was pretty fast for a simple rectangle, but
when roundness is used it becomes a bit slower (super-ellipse
equation has to be evaluated for each pixel in the rounded corners,
which is 3x powf per pixel).
So make the background box use multi-threading. On M1 Max, filling
background box of 2256x1691 pixels:
- No roundness: 25.8ms -> 4.3ms
- Roundness 0.3 (253 pixels): 31.9ms -> 5.8ms
- Roundness 1.0 (845 pixels): 94.6ms -> 15.8ms
Pull Request: https://projects.blender.org/blender/blender/pulls/130403
The issue was that if the evaluated object doesn't have an active
layer, the canvas is offset by twice the objects position.
The reason was that the code scaled the whole transformation
matrix by two to match the code in 4.2, but then had to overwrite
the location of the transformation again to counteract the scaling.
The fix is to not counteract the scaling and just scale the 3x3 part
of the matrix instead. This way we can remove the part afterwards
that writes to the location of the transform.
Pull Request: https://projects.blender.org/blender/blender/pulls/130454
For flat caps, only one point is added in data.positions array for
endpoints of stroke. It results in incomplete outline. To resolve
this, add another point in new curves at the exact opposite position.
Pull Request: https://projects.blender.org/blender/blender/pulls/130437
The "X" button to delete a keymap entry is too close to the scrollbar,
potentially leading to misclicks that would delete data.
Add margin to the right of the buttons to prevent this.
The X button is now aligned when the box is open/closed.
Pull Request: https://projects.blender.org/blender/blender/pulls/130349
