This add a way to use a software clip plane in the
prepass shader (surf_depth_frag.glsl).
The benefit of using this instead of gl_ClipDistance
is that the rasterization pattern is given to match.
Which means that only the prepass shader have to use
this.
This is slow and should only be enabled when needed.
Previously, the geometry nodes modifier was converting the
viewer path to a compute context at the same time as it was
setting up side effect nodes for the geometry nodes evaluation.
Now, this is changed to be a two step process. First, the viewer
path is converted to the corresponding compute context.
Afterwards, a separate function sets side effect nodes up so
that the given node in the given compute context will be evaluated.
This has three main benefits:
* More obvious separation of concerns.
* Can reuse the code that maps a viewer path element to a compute
context already.
* With gizmo nodes (#112677), it may become necessary to add side
effect nodes based on a compute context, but without having a
corresponding viewer path.
The position validation when manipulating node group items now includes
outputs..inputs order in addition to sockets..panels order. The method
for finding a valid position has been simplified, it's just a single
iteration of insertion sort.
Versioning has been added to ensure files from 4.0 alpha with
potentially unsorted sockets get re-sorted. This uses `std::stable_sort`
so that sockets keep their relative order apart from the input/output
grouping.
Pull Request: https://projects.blender.org/blender/blender/pulls/113060
If the DAE file was written with something other than Blender 4.0, it
doesn't have the bone collections info. That resulted in a nullptr, which
is now handled properly.
Overlay engine is currently responsible to initialize the framebuffers
depth_in_front texture. This is a hack and hasn't been ported to
Overlay-Next (yet). This PR skips copying the depth_in_front texture
when it isn't initialized yet.
Issue detected when working on Vulkan backend due its more
strictness.
Pull Request: https://projects.blender.org/blender/blender/pulls/113188
It's possible for there to be no outputs under Wayland
(when unplugging monitors for e.g.) so this must be accounted for.
Also avoid calculating the window position when the GHOST backend
doesn't support window positions (which is the case for Wayland).
Add checks for the SDL backend too, where accessing the
screen & desktop size may fail.
The logic to handle word selection from double clicking ran even when
the event wasn't inside the button. This would pass an invalid position
to BLI_str_cursor_step_bounds_utf8 which hung.
Resolve by limiting word-selection to when the event is inside
the text editing field as well as clamping the position to ensure
it's within the allowed range.
Caused by fb556c75df
The ideal would be to increase the version file, but this would make
the versioning code a bit messy, and it was a recent error
(it shouldn't affect many users).
Since different symbols are implemented, there is a distinction between
endpoint and loose point, which was partially missing in the snap code
for Mesh.
This case probably hasn't been triggered before because we rarely move individual
const-components around between geometry sets. This happened in #113083 in the
optimization when all elements are in the same group.
Pull Request: https://projects.blender.org/blender/blender/pulls/113160
`DRW_drawdata_get` reuses the same `DrawData` for all duplis,
so they all end up using the same `ObjectHandle` and `ObjectKey`,
which breaks motion vectors.
* Don't use `DRW_drawdata_get`.
* Simplify `ObjectKey`.
This also solves the issue of objects created "on the fly" always having
the `ID_RECALC_ALL` flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/112544
Since garbage collection of texture pools happens every time
`drw_manager_init` is called, interleaved calls to different
`DRW_draw`/`DRW_render` functions can result in a constant cycle of
creating/releasing textures.
This PR changes texture pools to only release textures that have not
been used for N garbage collection cycles.
I chose 8 as default since I think is high enough to avoid the issue
while it's unlikely to cause any major spike in memory consumption.
Pull Request: https://projects.blender.org/blender/blender/pulls/113024
