This changes the `Node.type` and `Node.bl_static_type` properties to be string
instead of enum properties. This allows us to remove another usage of
`NOD_static_types.h`.
Both of these properties were marked as deprecated for a long time already, but
without any way to inform users in a practical way. The result of that is that
especially the `type` property is widely to check if a node has a specific type.
It's used so much that it is impractical to remove it even if it was deprecated.
Instead this patch rephrases these properties as "legacy" (instead of
"deprecated"). This means that they will stay around and won't change in
behavior for existing nodes. For future nodes, we can just return the idname
instead of yet another name specific to these properties so that we can stop
worrying about them.
Pull Request: https://projects.blender.org/blender/blender/pulls/131972
The type check there should not be necessary anymore nowadays. It looks like it
might have been necessary when it was introduced in
eed45d2a23. Back then the object was still passed
into `BKE_mesh_wrapper_ensure_subdivision`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131857
How the new navigation pivot is determined depends a bit on the kind of brush:
* Brushes that deform or remove curves use the 3d-brush position at the start of
the brush.
* Brushes that add new curves set the pivot to the bounding box center of the
new curves.
Finding a good pivot point is not super trivial for curves, but the existing 3d
brush functionality seems to work well. This also has the benefit that almost no
additional computation is needed when the user is using the spherical brush
mode. However, if the projected mode is used, and orbit-around-selection is on,
then we have to compute the spherical brush center now anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/131907
The issue here was sometimes an output socket of a `Group Input` node has a
reference to a data-block. The value stored on these output sockets are never
used, and thus is not exposed in the UI which made it impossible for the user to
find that there still is a data-block reference.
The root cause for this seems to have been fixed a few releases ago. I can
reproduce that the pointer was set in 3.3, but not in 3.6.
This patch only adds some versioning to remove the unnecessary data-block
references to fix old files that might have this issue (e.g. the file from the
report).
Pull Request: https://projects.blender.org/blender/blender/pulls/131900
The autokeying code for cameras used the keyingset code to insert keys.
In the case of "Only Insert Available" turned on this would use the "Available" keyingset.
However, in the case of looking through the camera and moving the viewport
when the camera is not active, the poll function of that keyingset would return false.
Instead of modifying the poll function, the fix is to use the more direct keying code
using `RNAPath`.
This can be backported to 4.2 but not 3.6 due to the changes to the keying code done in 4.0
Pull Request: https://projects.blender.org/blender/blender/pulls/131796
Previously, calling `clear()` on `Map`, `Set` or `VectorSet` would remove all
elements but did not free the already allocated capacity. This is fine in most
cases, but has very bad and non-obvious worst-case behavior as can be seen in
#131793. The issue is that having a huge hash table with only very few elements
is inefficient when having to iterate over it (e.g. when clearing).
There used to be a `clear_and_shrink()` method to avoid this worst-case
behavior. However, it's not obvious that this should be used to improve
performance.
This patch changes the behavior of `clear` to what `clear_and_shrink` did before
to avoid accidentally running in worst-case behavior. The old behavior is still
available with the name `clear_and_keep_capacity`. This is more efficient if
it's known that the hash-table is filled with approximately the same number of
elements or more again.
The main annoying aspect from an API perspective is that for `Vector`, the
default behavior of `clear` is and should stay to not free the memory. `Vector`
does not have the same worst-case behavior when there is a lot of unused
capacity (besides taking up memory), because the extra memory is never looked
at. `std::vector::clear` also does not free the memory, so that's the expected
behavior. While this patch introduces an inconsistency between `Vector` and
`Map/Set/VectorSet` with regards to freeing memory, it makes them more
consistent in that `clear` is the better default when reusing the data-structure
repeatedly.
I went over existing uses of `clear` to see if any of them should be changed to
`clear_and_keep_capacity`. None of them seemed to really benefit from that or
showed that it was impossible to get into the worst-case scenario. Therefore,
this patch slightly changes the behavior of these calls (only performance wise,
semantics are exactly the same).
Pull Request: https://projects.blender.org/blender/blender/pulls/131852
Both the draw manager and gpu backend used the same compilation
directive for enablement. This PR seperates them into
`WITH_GPU_DRAW_TESTS` for draw manager related tests and
`WITH_GPU_BACKEND_TESTS` for gpu backend related tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/132018
Blender stores all pipelines in a pool. Using a hash it checks if a
the pipeline was already created and the previous could be reused. Due
to performance issues when working with graphics pipelines some equal
operations only used a hash check. For scissors and viewports this isn't
enough and could lead to issues.
This PR fixes this to still perform an exact check if the hash are
equal. Note that the performance drops a bit. And should be countered
with other performance improvements in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/132005
These should have a default size/pos, just like stencil itself.
This came up in #131836 (and probably led to asset essential brushes all
having this wrong -- which in turn will not draw stencil masks for them
in the viewport).
NOTE: without those defaults, resetting the brush would also have this
issue.
For further steps to actually fix fully, please refer to #131836.
Pull Request: https://projects.blender.org/blender/blender/pulls/131848
By now it is just a "compositor", so move the files one folder up.
Things that were under realtime_compositor/intern move into
already existing intern folder.
Pull Request: https://projects.blender.org/blender/blender/pulls/132004
This patch optimizes the Step mode of the Dilate node to use the van
Herk/Gil-Werman algorithm which runs in constant time compared to the
current linear time algorithm currently in use. This is an order of
magnitude faster for reasonably large structuring elements.
Only CPU is implemented in this patch, while GPU will be implemented in
a separate patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/131798
This patch adds compile-time optimizations where the operation inputs
are guaranteed to be non-single values. Pixel load methods now take an
optional template parameter CouldBeSingle, which is false by default. If
the input is not guaranteed to be single, it needs to be set to true.
Gives up to 3x improvement in some nodes.
Area "close" operation is actually an area merge of some area into the
one being closed. This means that screen->active_region will be
pointing at deallocated RAM. Normally not noticed because active_region
is set very quickly to the new area, but error nonetheless and noticed
by ASAN. This PR sets the screen->active_region to null when merges
change the active area.
Pull Request: https://projects.blender.org/blender/blender/pulls/131994
While adding tests I found that metaball export has been broken since
Blender 3.4. It would export each metaball geometry twice.
This looks to have been a side effect of a change to `object_dupli.cc`
which no longer sets the `no_draw` flag for metaballs[1]. With the flag
unset we would end up visiting this particular object twice.
Use a direct check for Metaballs now and add test coverage for the
scenario in general.
[1] eaa87101cd
Pull Request: https://projects.blender.org/blender/blender/pulls/131984
The new `--disable-depsgraph-on-file-load` commandline option, when used
together with the `--background` or `--command` ones, will prevent
building a depsgraph immediately after loading a blendfile.
The goal is to improve performances of batch-processing of blendfiles by
python scripts. It is intended to become the default behavior in Blender
5.0.
Scripts requiring evaluated data then need to explicitly ensure that
an evaluated depsgraph is available (e.g. by calling
`depsgraph = context.evaluated_depsgraph_get()`).
------
This disables the call to `wm_event_do_depsgraph` in `wm_file_read_post`.
Some quick performances tests:
* The whole `blendfile_versioning` tests gain about 2% speedup. These are
almost always small and simple blendfiles.
* Loading a Gold production file however goes from 26.5s to 3.5s (almost
90% faster) when this new option is specified.
Pull Request: https://projects.blender.org/blender/blender/pulls/131978
Previously, the number of material slots on the geometry (e.g. mesh) was the
ground truth. However, this had limitations in the case when the object had more
material slots than the evaluated geometry. All extra slots on the object were
ignored.
This patch changes the definition so that the number of materials used for
rendering is the maximum of the number of material slots on the geometry and on
the object. This also implies that one always needs a reference to an object
when determining that number, but that was fairly straight forward to achieve in
current code.
This patch also cleans up the material count handling a fair amount by using the
`BKE_object_material_*_eval` API more consistently instead of manually accessing
`totcol`. Cycles uses the the same API indirectly through RNA.
Pull Request: https://projects.blender.org/blender/blender/pulls/131869
As mentioned in fb6ac24514 and 9a6beb915d, `file_draw_preview()` is a
rather overloaded and confusing function. I'm trying to make it more
readable.
Split out file indicator icon drawing from the preview drawing function,
there's not much reason for it to be there as well. I rather keep
functions a bit simpler and more manageable.
Also added some comments and tried to make logic a bit more clear.
As mentioned in 9a6beb915d, `file_draw_preview()` is a rather
overloaded and confusing function. I'm trying to make it more readable.
Move image scale calculations to a separate function, reducing perceived
complexity of the function and the number of local variables. Also
rename or remove some variables to be more clear, add comments and move
variables closer to where they are used.
The GCC version on the buildbot does not support attribute on
a class member, resulting in the following warning:
NOD_node_declaration.hh:577:42: warning: ‘maybe_unused’ attribute ignored [-Wattributes]
Use the `UNUSED_VARS` macro instead to solve the original warning
about member being unused in release builds without introducing
a warning when using older compiler.
Pull Request: https://projects.blender.org/blender/blender/pulls/131974
The type info table for VSE modifiers was initialized to point
to global variables on first use. But really there's no reason to do
that, we can just declare the actual table instead. This is both
shorter, and avoids dances with preprocessor (INIT_TYPE macro).
Pull Request: https://projects.blender.org/blender/blender/pulls/131958
`file_draw_preview()` does multiple things and is quite hard to follow
already, it needs some improvents. One issue is naming that I always
found made the function unnecessarily confusing. For example `is_icon`
had nothing to do with the `icon` parameter, you'd have to search around
the code a bit to understand what it was actually representing.
Attempt to make variable and function names more clear.
Also reduce variable scope and add a comment.
When baking line art strokes, the object matrix that are used for back
transformation was inverted. Should be `world_to_object` instead of
`object_to_world`. Probably a typo during GPv3 rewrite.
The compositor leaks memory when the node tree contains unavailable
links. That's because the compositor doesn't ignore those links when
computing the reference counts for outputs. To fix this, check if the
output is logically linked and return 0 in case it isn't.
This adds initial support for ReBAR capable platforms.
It ensures that when allocating buffers that should not be host visible, still
tries to allocate in host visible memory. When there is space in this memory
heap the buffer will be automatically mapped to host memory.
When mapped staging buffers can be skipped when the buffer was newly
created. In order to make better usage of ReBAR the `VKBuffer::create`
function will need to be revisit. It currently hides to much options to allocate
in the correct memory heap. This change isn't part of this PR.
Using shader_balls.blend rendering the first 50 frames in main takes 1516ms.
When using ReBAR it takes 1416ms.
```
Operating system: Linux-6.8.0-49-generic-x86_64-with-glibc2.39 64 Bits, X11 UI
Graphics card: AMD Radeon Pro W7700 (RADV NAVI32) Advanced Micro Devices radv Mesa 24.3.1 - kisak-mesa PPA Vulkan Backend
```
Pull Request: https://projects.blender.org/blender/blender/pulls/131856
Change from ababc2e01b did not actually behave in a way that the
caller can force-disable overlays [which seems like the intention from
the commit message and also desired behavior for e.g. grease pencil
drawing/reprojecion].
Pull Request: https://projects.blender.org/blender/blender/pulls/131861
When running tests `WITH_GTESTS` and `WITH_GPU_DRAW_TESTS` the
GPUShaderCreateInfo's specfically created for the tests could not be
found. This failed running tests on any backend.
This PR fixes this. The root cause what that the name of the compile
directive was incorrect. It should have been `WITH_GTESTS` but was
`WITH_GTEST`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131956
Originally intended to be a code cleanup that makes the code shorter
(part of VSE quality project #130975), but as a side effect many
modifiers are now faster since they no longer do many branches in
the innermost pixel loop.
Main part is having apply_modifier_op that given the "modifier op"
functor object, instantiates the correct processing function based
on type of image (byte vs float) and mask (none, byte, float), for
a total of 6 possible cases. And then a helper like
apply_and_advance_mask that applies mask based on input and result
in a consistent and not "literal copy paste of code" way across the
modifiers.
Brightness/Contrast, Color Balance, Tonemap modifiers were already
optimized to move branches out of inner loops previously; their
performance remains unchanged. Mask modifier performance remains
unchanged; it is very simple and memory bandwidth limited on my
machine.
Other modifiers, tested on 4K resolution, Win10 / Ryzen 5950X, time
in milliseconds taken to apply the modifier calculation, on a byte
image with no mask:
- Curves: 12.1 -> 7.7ms
- Hue Correct: 24.5 -> 15.8ms
- White Balance: 20.5 -> 13.8ms
Same as above, but on a float image with a byte mask:
- Curves: 13.5 -> 12.3ms
- Hue Correct: 19.7 -> 16.4ms
- White Balance: 19.3 -> 15.9ms
Pull Request: https://projects.blender.org/blender/blender/pulls/131736
UNICODE code points were named "ascii" or "cha",
use the term "charcode" as used elsewhere in BLF and FreeType.
Also use char32_t internally and add a utility function to apply the
small-caps flag.
Resolve by welding overaps between adjacent underline glyphs.
Besides avoiding overlap, this makes underlines work better when the
text follows a curve.
Also remove increased underline width which was originally added in [0].
This may have been done to avoid gaps - which is no longer needed.
Further, underlines typically don't extend beyond the glyphs bounds
so the increased width isn't expected behavior.
[0]: a07394ef2c
This adds a new `bl_use_group_interface` property that can be set on custom node
group types. By default it is `true` to avoid this being a breaking change. If
it's set to `false` some UI elements related to the built-in node group
interface are hidden.
Pull Request: https://projects.blender.org/blender/blender/pulls/131877
