Until now the Vulkan backend supported a single pre-configured sampler.
This PR realizes creation, caching and freeing of samplers based on what
is required by the state manager.
The implementation is similar to OpenGL or Metal. This fixes many issues
including:
- Textures in workbench and eevee use the correct extend and filtering
- Custom icons render correctly
- Depth sampling issues
- Removes artifacts using EEVEE world shader, lighting and indirect lighting.
Pull Request: https://projects.blender.org/blender/blender/pulls/114827
It is not clear why shallow copy needs to be created to access
some fields which are copied from the input object. Just use that
object directly.
Shallow copying is a weird and legacy concept, it should not be
used without huge disclaimer why it is unavoidable in the new
code.
Pull Request: https://projects.blender.org/blender/blender/pulls/114791
This caused NOMINMAX not to be defined when `LzmaLib.h` includes
`windows.h` which causes a definition of min which upsets `std::min`
By moving BLI_winstuff.hh up, it will take care of this define for
us in case it was not yet defined regardless of openvdb being on or
off
Pull Request: https://projects.blender.org/blender/blender/pulls/114816
`target_snap_points` could have size 0, but even so
`memset(snap_data->target_snap_points, 0, sizeof(int));` was always
called.
Avoid writing to unallocated memory. And use C++ arrays.
Probably caused by ad01cdd7fc.
Once again, problems resetting values due to `td->val` and `td->loc`
sharing the same pointer.
This needs to be avoided, as when resetting it is always expected that
one will be 1D and the other 3D.
The distinction would start to become meaningless when we use C++
features in the older C header. The naming and lack of a proper
namespace should be enough to clarify the separation for now.
This breaks versioning because it runs beforehand, giving no time for
versioning to change to the new node type.
This reverts commit 2bf46b3189.
Ref #114803
This function shouldn't return invalid index. Instead assertion in used.
While the branchless code path may not be observably faster in current
code, it should work better with instruction level parallelism in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/114682
When loading an unknown node type from a newer Blender version, the node
storage data cannot be properly loaded. Re-saving the file will then
crash if saving with the same node type idname, since new Blender
versions cannot find the expected storage data.
Loading in older versions should replace unknown node types with a dummy
"Undefined" node that will get loaded as `NodeTypeUndefined` in newer
versions as well. Custom node types are exempted from this since they
store all data as generic ID properties and can always be fully
serialized.
Pull Request: https://projects.blender.org/blender/blender/pulls/114803
Some left-over code from old refactoring/improvements of old addresses
remapping in library reading code was causing some wrong remapping
between different IDs.
The code was actually not doing what its comment was describing, since
it would cause a random remapping to a different new address than the
expected one:
Initial state, before removed buggy line:
`old_addr_1 -> new_addr_1`
`old_addr_2 -> new_addr_2`
End state, if `old_addr_2` == `new_addr_1`:
`old_addr_1 -> new_addr_2`
`old_addr_2 -> new_addr_2`
From the description of the removed line, that behavior was actually
already covered by adding the remapping rule in the line above, since
adding a remapping overwrite an existing one if needed, so the line
above would do (in case a placeholder ID existed before the actual ID
got read):
Initial state, before adding new remapping rule:
`old_addr_1 -> new_addr_placeholder_1`
End state, after adding remapping to newly read ID:
`old_addr_1 -> new_addr_1`
NOTE: Noticed thanks to rare failures of the liboverride tests on
buildbots. The issue was less than 1%-reproducible with a debug build
and ASAN, but had about 2-4% repducibility with release builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/114784
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.
Pull Request: https://projects.blender.org/blender/blender/pulls/114726
The initial pipeline state was not set and could lead to undetected
state changes.
This fixes several issues, including:
* Fix incorrect colors in the UI, that would be used everywhere, and
could be fixed by restarting Blender.
* Overlay extra objects where drawn below the grid.
Pull Request: https://projects.blender.org/blender/blender/pulls/114792
This fixes a bug where the rgb UsdUVTexture shader output
attributes were created with incorrect type color3f when
connected to UsdPreviewSurface diffuseColor and emissiveColor
inputs. The UsdPreviewSurface specification requires the
UsdUVTexture rgb output to be of type float3.
This was happening because the UsdUVTexture outputs were created
implicitly by the call to UsdShadeInput::ConnectToSource(). I.e.,
because the diffuseColor and emissiveColor inputs are of type
color3f, this was the type assigned by default to the rgb source
attributes as well.
Now explicitly creating the UsdUVTexture shader output attributes
with the correct types.
Pull Request: https://projects.blender.org/blender/blender/pulls/114728
The compositor executes superfluously on scene changes when adding or
removing objects.
This was due to an explicit handling of a certain notifier, which was
introduced in commit 1e948b251d. The exact reasoning behind the
addition is unknown, so this patch removes it until we have an informed
decision to keep it.
Devices that don't support GPU_DEPTH_COMPONENT24 natively will use
GPU_DEPTH_COMPONENT32F in stead. When done the current code path raised
an error as the conversion type wasn't set.
Issue detected on AMD RX5700 device.
Pull Request: https://projects.blender.org/blender/blender/pulls/114786
It was weird concept which was calculating scene FPS, but from
the depgraph side. It was misleading, especially for the initial
evaluation of FPS of nan.
If we want FPS counters this needs to be done on a higher level
in the code.
Pull Request: https://projects.blender.org/blender/blender/pulls/114782
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.
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
