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
Change BrightRings exr file to not contain nan/inf pixels. Testing for
nan/inf in input just gives too many headaches across different
platforms, and is arguably a very corner case.
Pull Request: https://projects.blender.org/blender/blender/pulls/131926
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
Refactoring functions out of the 3D text layout funciton was
becoming difficult because vfont.cc mixed API's that use VFont
for different purposes (clipboard, text layout, ID management.. etc).
Split VFont to character & text layout into its own file.
Resolve multiple inconsistencies when 3D text could not load fonts.
- When the font wasn't found:
The default font was used.
- When the font existed but could not be loaded:
The 3D text would fail to display anything.
- When only the VFont assosiated with a style failed to load:
The 3D text would fail to display only when the stype existed.
So toggling bold for example could cause all 3D text to vanish.
Instead of falling back to defaults, display a placeholder glyph
(a hollow rectangle) displayed when the font can't be used.
For the UI fallbacks are fine, for user content, it indicates something
is wrong as needs to be corrected - similar to a bright magenta in
renders when images fail to load. This means it's clear to users when
they have broken paths which need to be corrected.
This also simplifies vfont_to_curve, removing a "goto" to go to the
end of the function to cancel 3D text rendering entirely.
Introduced in 750e3a6fba
The commit above incorrectly passes the `grids` `Span` into the
`calc_front_face` function, causing the calculation to miss vertices in
certain cases, as the function attempts to index instead of reading the
`normals` `Span` directly.
This has the potential to cause crashes too, as the indices of the grid
are not guaranteed to be bounded by the size of the `factors` array.
Pull Request: https://projects.blender.org/blender/blender/pulls/131886
Cursor snapping operators does not support undo/is not designed to be
undo-able, and currently you can't undo moving of the cursor anyway, so
remove the `OPTYPE_UNDO` flag to make it not show in the undo history.
Pull Request: https://projects.blender.org/blender/blender/pulls/131427
This adds material propagation in two places to fix the bug:
* Conversion from legacy to new curves.
* From the main curve input to the output mesh in the Curve to Mesh node.
Pull Request: https://projects.blender.org/blender/blender/pulls/131862
Give the `IDWALK_CB_…` enum an explicit name:
`LibraryForeachIDCallbackFlag`. This way the flags are type-safe, and
it's known where values come from. This is much preferred (at least by
me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_CB_NOP` as that has the same
value and is of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int` though.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Give the `IDWALK_…` enum an explicit name: `LibraryForeachIDFlag`. This way
the flags are type-safe, and it's known where values come from. This is
much preferred (at least by me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_NOP` as that has the same value
and is of the right type.
One invalid use of `IDWALK_CB_NOP` was detected by this change, and is
replaced by `IDWALK_NOP`.
This change might be incomplete; I gave the enum a name, and then fixed
the compiler errors.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Supporting a new on_material_import() USDHook callback.
Also added support for import_texture() and export_texture()
utility functions which can be called from on_material_import() and
on_material_export() Python implementations, respectively.
Pull Request: https://projects.blender.org/blender/blender/pulls/131559
Previous method of doing the projection from the spot of the camera
was not reliable (depending on where the view/camera was located).
Instead, use the same ray origin for all methods and define the plane at
the placement location (with the view direction).
This is also easier to read I think.
Pull Request: https://projects.blender.org/blender/blender/pulls/131790
