When entering sculpt mode on an object without any color attributes and
starting to paint, the newly created color attribute was set active, but
not default (camera icon).
Now set it default as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/108271
Follow up to [0], some material data wasn't accounted for.
- The embedded node-tree's owner_id wasn't set.
- Animation data (both the material & it's embedded node-tree).
- Updating depsgraph relations is needed when animation data is freed
as part of paste too.
Also report when paste fails.
[0]: 5b5a1e3581
Commented [0] (2.5x refactor that disabled many free functions),
for some reason this call was never re-enabled.
Add back the free call along with other clipboard buffers.
---
Cherry picked [1] from main as other fixes material clipboard
are difficult to validate when memory is leaking.
[0]: a1c8543f2a
[1]: cb0c4f04d4
Use a macro to make the ID-free switch more compact & use ID indices
for better readability. Also typedef the enum so missing types in the
switch will report compiler warnings.
When a file passed in from the command line failed to load,
blender would exit & save the quit.blend.
Resolve by adding a `do_user_exit_actions` to WM_exit_ex which is
false in backgrounds mode or when an error has occurred.
---
Back-ported [0] & [1] from main with fix [2] included.
[0]: c803ddab29
[1]: d7d1c524e3
[2]: d3d91b79e0
The "no custom" normal used to be stored inside the custom normal space
struct, now it's stored separately. Before the normal was modified, but
not the one in the normal space struct. Fixed by storing the original
before modification in a temporary variable.
This function replaced the evaluated mesh with a new one with the given
custom data type mask. That doesn't work in general anymore for a few
reasons: the increased dependence on named attributes (a opposed to
custom data types), and the "all or nothing" approach to reevaluating
the depsgraph. Other objects might depend on the object's evaluated
geometry, so it shouldn't just be replaced. Pushed a bit further, this could
give nice simplifications to mesh modifier evaluation.
There are two breaking changes, `bmesh_from_object` and BVH tree
`FromObject` require the source object to have a proper evaluated
mesh now.
If this causes a regression, it's likely that the object is missing
an update tag when a mode is entered that requires extra evaluated data.
Pull Request: https://projects.blender.org/blender/blender/pulls/106186
2a56403cb0 changed the way bevel weights are stored in 4.0.
Add versioning for reading the new files that replaces the new generic
attributes with the old non-generic custom data layers. The code is
paranoid with lots fo checks I expect will typically not be necessary.
For emitter particle systems, these were never rendered anyways, Path is
kept for hair systems of course.
As a consequence, the new default for particle systems is:
- render as None (users have to explicitly set this to object/
collection)
- display as point
When changing to Hair type, this automatically gets set back to
- render as Path
- display as Render
Changing back to emitter, will use points as display again (and render
as None -- same here, users have to explicitly set this to object/
collection)
Not sure if this is still for 3.6, patch is for 4.0 for now.
"Fixes" #80197
Pull Request: https://projects.blender.org/blender/blender/pulls/108231
The code which was preventing this originated to an early days of the
light linking project where bits accumulation was done as part of the
graph evaluation. Since then it was changed to be pre-calculated at
the graph build time.
The updates of the receivers is ensured via the HIERARCHY nodes and
relations between them.
Also made it explicit that the emitter is updated with the tag of
the collection: before it was relying on implicit Copy-on-Write
component tag.
Pull Request: https://projects.blender.org/blender/blender/pulls/108425
Small correction to word selection in Console. Start and end of
selection were in incorrect order so it displayed correctly but
did not copy to clipboard as expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/108434
A missing `CONSTRAINT_OFF` check in `transform_convert.c` causes the
inverse matrix of that constraint to be added on top of the translation,
causing weird translation response in the viewport. Now fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/108217
* Fix image rendering.
* Fix AOV rendering.
* Merge all render passes and AOV textures into 2 arrays (one for colors and one for values).
* Make AOVsInfoData std140 compliant.
* Remove surface color from Diffuse Light and Specular Light passes.
* Add Environment pass support.
* Add Shadow pass support.
Pull Request: https://projects.blender.org/blender/blender/pulls/108239
MakesRNA uses WITH_VULKAN_BACKEND, but it wasn't included in the
CMakeLists.txt. Also added WITH_METAL_BACKEND. Metal is currently
included as a global compilation directive. We might want to sanitize
that according in a different patch.
This PR makes sure that Vulkan backend can be selected via the PythonAPI.
Note that the changes to user preference UI isn't added to this patch as
the Vulkan backend isn't usable to end users.
`bpy.context.preferences.system.gpu_backend = 'VULKAN' should now be
possible. After saving the user preference and restarting Blender it should
initialize the Vulkan backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/108414
When a descriptor pool cannot allocate a descriptor set in stead
of resulting `VK_ERROR_OUT_OF_POOL_MEMORY` it is adviced that
drivers will return `VK_ERROR_FRAGMENTED_POOL`.
Before this PR the Vulkan Backend crashed as it only checked the
out of pool memory. According to the Vulkan specification it is
adviced to driver developers to report fragmented pool.
The crash happened as no new pool was allocated and no descriptor
set could be allocated anymore.
This change improved the reliability of the vulkan backend to be
able draw an animation in the 3d viewport for half an hour without
crashing. Before this change Blender would crash in a few seconds.
Pull Request: https://projects.blender.org/blender/blender/pulls/108416
This PR adds the ability to only read back an area of a framebuffer
texture. It also adds the ability to read back from the depth
attachment.
Also reduces the amount of needed memory and reduces the CPU cycles
by reading back directly into the memory provided by the user. The
previous implementation wasn't able to do so as the `VKTexture::read`
function always returned a new buffer. The introduced
`VKTexture::read_sub` works on a pre-allocated buffer.
Pull Request: https://projects.blender.org/blender/blender/pulls/108418
Current implementation of the Color Blend State worked for framebuffers
with a single attachment. This PR adds support for Color Blend State for
multiple attachments. It is assumed that the Blend State is the same for
all attachments.
NOTE: Integer based attachments aren't yet supported. In OpenGL it is
assumed that Integer based attachments aren't blended. It is currently
to early to tell if this is also the case for Vulkan. If this assumption
is incorrect we should use multi blend state.
Pull Request: https://projects.blender.org/blender/blender/pulls/108419
