Caused by 6faa39edb7
In that commit it was assumed that the view offset does not need to be
updated if the operator is `V3D_OP_MODE_ROTATE` instead of simply
checking `this->use_dyn_ofs`.
Since `use_dyn_ofs` is always `True` when using Auto Depth or Orbit
Arround Select, the offset should always be updated in these cases.
Previously the cmake code would try to run the LIBDIR specific "findX.cmake" files for both vulkan and shaderc.
However these would pick up system headers and libraries when LIBDIR were not present. This would lead to compilation errors as the system library configurations were not taken into account or queried.
This changes it so that if LIBDIR is not present, the proper pkgconfig files will be used instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/114639
Use general util to build mesh topology map instead of array of vectors.
This util can be optimized in future by better multithreading and new
algorithms with better CPU catch heuristics. For now this will provide
better usage of memory without a lot of small allocations.
Pull Request: https://projects.blender.org/blender/blender/pulls/114683
3 component texture formats are often not supported by vulkan devices.
Sometimes the support is less than 5%. The 4 components variants have
more than 90% support.
This PR builds on top of the existing vulkan data conversion to add
the ability to convert between RGB16F<=>RGBA16F and RGB32F<=>RGBA32F
texture formats.
This allows using color management other then Standard/sRGB. Most places
the 3 component texture formats are phased out, but OCIO, external
render engines and real time compositor uses them.
Pull Request: https://projects.blender.org/blender/blender/pulls/114708
Currently, atomic additions in vertex normal calculation introduce
non-determinism that can influence the result of other operations,
sometimes causing non-reproduceable renders (in cases like #100250
and #101726). This is because the order used during threading when
accumulating face normals changes.
This commit fixes that non-determinism, using a vertex to face topology
map to calculate vertex normals without atomics. When the map is already
available, this can be faster too.
In the longer term future, this method of vertex normal calculation
means it will be easier to do partial recalculations when only part
of a mesh changes. That might be essential for cases like transforming
small selections in a non-BMesh edit mode.
As an experiment I tried a "fast" code path that avoids weighting face
normals by the corresponding corner angle when averaging them to
create vertex normals. This significantly reduces the necessary
computation and memory bandwidth for vertex normal calculation.
The results are shown below too, but it's not part of this PR.
I measured the FPS with two smooth shaded 16 million face grids:
| | Before | After | After (fast) |
| -------------------------------- | ------ | ----- | ------------ |
| Created from scratch every frame | 0.96 | 0.91 | 0.92 |
| Deformed by geometry nodes | 0.99 | 1.32 | 1.40 |
Though many other things besides normals are being tested here,
it's clear that the performance difference isn't that large either way,
though there is an observable regression with meshes created from
scratch, and there is a noticeable improvement when the topology
stays the same and is persistent.
Pull Request: https://projects.blender.org/blender/blender/pulls/111718
When VSE cache is invalidated (on most VSE edit operation e.g.), or
Blender quits, in some cases (complex and very long edits), the
prefetch job would block several seconds after being requested to stop.
This was because one codepath would keep looping over all frames without
checking for the `stop` flag.
The problem is in the way of identifying "fast" intersections through bounds.
In the existing code, before testing the intersections (to identify
holes) the polys are sorted according to the bounds
(in the order x1 < x2 || y1 < y2).
Then a for loop is used on the order returned by sort.
Each time the bound of a polygon intersects with another, it is joined
and the bound is added.
The problem with this solution is that some bounds may not intersect
with the first, but could intersect one that is joined to the first,
which, as it is cleared, makes the intersection undetected.
The solution is to remove this code with `qsort` and create a
"target_map" that identifies a source polygon and a dest polygon.
Pull Request: https://projects.blender.org/blender/blender/pulls/114600
This PR solves an issue when using texture pools with textures that are not
natively supported by the device. In the previous implementation the
internal `Texture::format_` was changed. Any check if the texture could
be reused would fail as its format would be different that the requested one.
This PR fixes this by separating the requested format `Texture::format_` and
how it is stored on the GPU `VKTexture::device_format_`.
This solves the next artifacts:
* Workbench flickering artifacts on AMD/Intel GPUs
* Workbench TAA on AMD/Intel GPUs
* Overlays were not always drawn fully solid
Pull Request: https://projects.blender.org/blender/blender/pulls/114697
OpenGL uses a depth range between -1 and 1, which is then normalized.
Metal & Vulkan uses a depth range between 0 and 1, which is already normalized.
The final plan would be to default to a depth range between 0 and 1, but
for now the depth ranges are retargetted so they won't be clipped away.
This solves the next issues for users:
- Navigate control will be rendered correctly
- Ortographic view clipping artifacts
- EEVEE light evaluation
Retargetting happens at the end of the vertex stage or when a geometry
stage is present at the end of the geometry stage. Derivatives using
depth would have a different value compared to OpenGL, but would match
Metal backend. OpenGL performs clipping and generates derivatives based
on the original depth value.
`gl_FragCoord` and clipping would have some precision differences as clipping
and normalizing are done in a different order but would match Metal.
Geometry shaders should use `gpu_EmitVertex` to ensure that the retargetting
is done per vertex.
Pull Request: https://projects.blender.org/blender/blender/pulls/114669
No functional changes.
Extract code from the function `insert_keyframe_value`
to make it easier to use in other places.
I created a new function `remap_driver_frame` that
removes 3 parameters from the function.
And I removed the requirement for a `ReportList`
by just returning false and letting the caller
create a message.
Pull Request: https://projects.blender.org/blender/blender/pulls/114700
Discussed in #114646.
This commit transforms the "alt_navigation" option of the transform
operators into a new modal key item. "PASSTHROUGH_NAVIGATE"
In addition to cleaning up a lot of the code, it allows you to
customize the key chosen to navigate while transforming.
Ensure that the view layer is properly synced before trying to get the
active collection.
Without the sync, imported objects typically get placed in the global
Scene Collection rather than the new collection that was just created
for the import.
Pull Request: https://projects.blender.org/blender/blender/pulls/114650
The first problem was triangles with motion blur were all grouped into
one category without separating the ones with and without triangle
motion steps.
The second problem was HIP RT uses the generic motion triangle
intersection function and this function checks prim_visibility buffer.
HIP RT doesn't provide the buffer per primitive but passes it to HIP RT
core per instance.
The buffer name was changed to prim_visibility from visibility to be
the same as what Cycles uses but when the motion triangle intersection
function is called from HIP RT kernels, the instance id is passed to
the function instead of primitive id.
Pull Request: https://projects.blender.org/blender/blender/pulls/114555
No functional changes.
`ANIM_get_normalization_flags` had the argument type of `bAnimContext *`.
That made it more difficult than it needs to be to reuse that function.
Pass a `SpaceLink *` instead since that is what the function actually uses.
Pull Request: https://projects.blender.org/blender/blender/pulls/114676
There were some issues with workbench shadow drawing. This PR
does some tweaks to fix the shadow drawing on vulkan.
* Framebuffer stencil clearing when write stencil is disabled
* Tweaks to stencil operation and tests
* Disable restart for line adjacency
Pull Request: https://projects.blender.org/blender/blender/pulls/114673