This adds support for exporting attributes from a Blender Curves object to Cycles.
The implementation follows that of the Mesh object. This also creates motion blur
data if the "velocity" attribute is present on the Curves.
Ref T94193
Reviewed By: brecht
Maniphest Tasks: T94193
Differential Revision: https://developer.blender.org/D14088
Due to the freeing and re-creation of textures performed when binding
offscreen viewports, VR viewport textures would be needlessly
re-created every drawing iteration, leading to a negative impact on VR
frame rate.
This was brought to light by 6738ecb64e, which introduced an
additional texture clear operation on initialization and was
prohibitively costly on some systems when performed every frame.
Now, the textures for VR viewports will not be always re-created
during offscreen binding, but only when necessary using a pre-drawing
step (`wm_xr_session_surface_offscreen_ensure()`).
Reviewed By: jbakker, fclem
Differential Revision: https://developer.blender.org/D14059
When using a RGBA16 (`GL_RGBA16`, `DXGI_FORMAT_R16G16B16A16_UNORM`)
swapchain format with Quest 2, no image is presented to the headset.
This can occur when using the SteamVR runtime with an AMD graphics card
(ex. T95374).
Workaround is to move this format after the Quest 2-compatible RGBA16F
formats in the candidates list so that the RGBA16F formats are chosen
instead.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14024
Crash was caused since the function pointers
`s_xrGetOpenGLGraphicsRequirementsKHR_fn`/
`s_xrGetD3D11GraphicsRequirementsKHR_fn` were static and were not
updated with the correct proc address after being set the first time.
As stated in the OpenXR spec: "function pointers returned by
xrGetInstanceProcAddr using one XrInstance may not be valid when used
with objects related to a different XrInstance".
Although it would seem reasonable that the proc address would not
change if the instance was the same (hence the `static XrInstance s_instance;`),
in testing, repeated calls to `xrGetInstanceProcAddress()`
with the same instance still can result in changes (at least for the
SteamVR runtime) so the workaround is to simply set the function pointers
every time, essentially trivializing their `static` designations.
Reviewed By: Severin
Maniphest Tasks: T94268
Differential Revision: https://developer.blender.org/D14023
For the majority of node groups created in Blender 3.0 the behavior does not change.
So far we only found a single file where this setting has an effect.
Differential Revision: https://developer.blender.org/D14078
For an upcoming project we would want to match multiple id types in a
single go. To not replicate the implementation using other types we
introduce `BKE_library_id_can_use_filter_id` that returns all supported
types as a filter.
Not all ID types have a filter_id (ID_LI, ID_KE, ID_SCR) These
exceptions are not available in the filter_id function.
Reviewed By: mont29
Maniphest Tasks: T95279
Differential Revision: https://developer.blender.org/D14061
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Complex Solidify creates edge bevel weights on the rim if the
according vertex has some vertex bevel weight. If there are no
edge bevel weights, they were left disabled even if vertex bevel
weights are used.
Some curve objects don't have an evaluated mesh at all, but line art
currently assumes that all curve objects have one before converting
it to a mesh internally. Fix this by checking if the curve object has an
evaluated mesh before skipping it.
The remaining problem is that evalauted from non-mesh objects or
evaluated curves from non-curve objects, etc. will be ignored if
"Allow Duplicates" is off. That's a different problem though.
Differential Revision: https://developer.blender.org/D14036
For curve-heavy scenes, memory consumption regressed when we switched from MetalRT to bvh2. Allow users to opt in to MetalRT to workaround this.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14071
Disable binary archives on Apple Silicon (issue stems from instancing multiple PSOs from the same binary archive). Pipeline creation still filters through the OS shader cache, mitigating any impact on setup times after the initial render.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D14072
This is part of the project of converting `MVert` into `float3`.
(more details in T93602), The pbvh update flag is removed and
replaced with a bitmap stored in the PBVH structure. This
patch is similar to D13878. This is mainly setup for an eventual
performance improvement by removing the extra data from
mesh vertices, but if it's consistent with testing in the other patch
doing the same thing for another "temp tag", then it may actually
increase the speed of sculpt code slightly, since less memory needs
to be loaded when checking/changing the flags.
Differential Revision: https://developer.blender.org/D14000
The main issue is that the image and image user is not updated correctly
in `rna_ImageUser_update`. `BKE_image_user_frame_calc` does not set the
correct frame, because the image is null. Also `IMA_GPU_REFRESH` is not
set for the same reason.
When gpu materials are first created, it is expected that the frame is set
correctly, and the flag is set if necessary. Therefore, somewhere during
depsgraph evaluation, those have to be updated. The depsgraph node
to do the update existed already. Now there is a new relation so that it is
executed when the node tree changed, not only when the frame changed.
This is partially caused by a stupid mistake in cfa53e0fbe
where I missed initializing the `vert_normals` pointer in
`MResolvePixelData`. It's also caused by questionable assumptions
from DerivedMesh code that vertex normals would be valid.
The fix used here is to create a temporary mesh with the data necessary
to compute vertex normals, and ensure them here. This is used because
normal calculation is only implemented for `Mesh` and edit mesh, not
`DerivedMesh`. While this might not be great for performance, it's
potentially aligned with future refactoring of this code to remove
`DerivedMesh` completely. Since this is one of the last places the data
structure is used, that would be a great improvement.
Differential Revision: https://developer.blender.org/D13960
