Blender Git Commits

Compositor: silence clang/clang-tidy override warnings

`-Winconsistent-missing-override` and `modernize-use-override`.

Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D10654

Fix T86417: Crash deleting Shader AOV from an empty list

Missing NULL check in {rB2bae11d5c08a}.

Candidate for corrective release I guess.

Maniphest Tasks: T86417

Differential Revision: https://developer.blender.org/D10666

Cleanup: Correct area writing function name

This function writes areas, not regions. The old name read as if it was
regions.

Sculpt: 'Unifiy' Dyntopo Detail Size operators

Prior to rB99a7c917eab7, Shift + D was used to set detail size for both
constant and relative detail (using radial control). The commit added an
improved operator for doing this for constant detail (showing the
triangle grid representation), but left the user without a shortcut to
do this for relative detail.

Interestingly rB99a7c917eab7 only changed this for the Blender keymap,
the Industy Compatible keymap still has the "old" entry.

This patch changes both keymaps to have both entries.

For user experience, the real change here is to have both available on
one 'primary' shortcut (Shift+D), the improved
'dyntopo_detail_size_edit' operator will now act on all possible cases.
If it deals with constant detail, it acts as before, if it deals with
relative detail etc, it will fallback to the "old" way of doing it via
radial control instead. I assume this adresses what was stated in
rB99a7c917eab7: "Deciding if both detail sizes can be unified needs a
separate discussion"

Also, move dyntopo_detail_size_edit to sculpt_detail.c

Fixes T83828

Maniphest Tasks: T83828

Differential Revision: https://developer.blender.org/D9871

Fix the session UUID being set for temporary blend file data

Triggered by temporarily appending library linked data from Python.

Fix: unconnected multi socket input crashes

The crash would only happen when the output of the Join Geometry node is used.

Cleanup: fix warnings

UI: Clean up sub-panel for new boolean modifier options

A few changes to make this consistent with other modifier panels:
- Title case for UI labels
- Use property split (and therefore decorators)
- Declare sublayout variables after getting modifier info

Cleanup: Complete earlier geometry component refactor

This was meant to be part of rB9ce950daabbf, but the change dropped from
the set at some point in the process of updating and committing.
Sorry for the noise.

"Show Texture in texture tab" button: full support for Sculpt / Paint

In {rBb279fef85d1a} the button that displays a texture in a Properties
Editor texture tab was added for geometry nodes.
Same commit will actually show them for Brush textures as well (but
disabled -- because the Texture users dont match).
This task is for finanlizing proper support for Brush textures as well.
There was originally a separate patch for this (see {D9813}) but most of
it was already implemented by above commit.

**what this solves**
from the default startup file:
- go to any sculpt or paint mode and add a texture to your brush
- observe the button to edit this texture in the Properties editor is
greyed out

{F9860470}

There are two possible solutions:
- [1] call the texture template for the brush `texture_slot` texture
(instead of the brush 'texture') from the python UI code, this is then
working in harmony how ButsTextureUser works for brushes
- [2] tweak the way `ButsTextureUser` works (dont rely on
`RNA_BrushTextureSlot` there)

This patch implements the first solution.
Since `brush.texture_slot` is `br->mtex` RNA wrapped and `brush.texture`
is `br->mtex.tex` RNA wrapped, this really comes down to doing the same
thing. I checked that creating a new texture and unlinking/deleting will
have the same results even though they take slightly different code
paths: assignment and NULLing the pointers are working on the same (see
above) and RNA update callbacks also do the same [even though in
different functions]:
- brush.texture will do rna_Brush_main_tex_update
- brush.texture_slot.texture will do rna_TextureSlotTexture_update /
rna_TextureSlot_update
(only difference here is an additional DEG relations update in the case
of texture_slot which should not do harm)

Differential Revision: https://developer.blender.org/D10626

Geometry Nodes: Rename subdivision nodes

This makes the following changes to the name of the two
geometry nodes subvision nodes:
- `Subdivision Surface` -> `Subdivide Smooth`
- `Subdivision Surface Simple` -> `Subdivide`
Most of the benefit is that the names are shorter, but it also better
mirrors the naming of operations in edit mode, and phrases the names
more like actions. This was discussed with the geometry nodes team.

Fix T86357: EEVEE: Shadows: Casters have exponential performance degradation with many objects

When you have many distinct objects, in an Eevee render then the shadow caster gets exponentially slower as the number of (distinct) objects increase.

This is because of the way that frontbuffer->bbox (EEVEE_BoundBox array) and the associated frontbuffer->update bitmap are resized.
Currently the resizing is done by reserving space for SH_CASTER_ALLOC_CHUNK (32) objects at a time.
When the number of objects is large, then the MEM_reallocN() gets progressively slower because it must memcpy the entire bbox/bitmap data to the new memory chunk.
And there will be a lot of *memcpy* operations for a large scene.
(Obviously there are a significant number of memory allocations/deallocations too - though this would be linear performance.)

I've switched to doubling the frontbuffer->alloc_count (buffer capacity) instead of adding SH_CASTER_ALLOC_CHUNK (32). As I understand this is the only way to eliminate exponential slowdown. Just increasing the size of SH_CASTER_ALLOC_CHUNK would still result in exponential slowdown eventually.

In other changes, the "+ 1" in this expression is not necessary.
if (id + 1 >= frontbuffer->alloc_count)
The buffer is 0-based. So when the buffer is initially allocated then id values from bbox[0] to bbox[31] are valid. Hence when frontbuffer->count == frontbuffer->alloc_count, is when the resizing should be triggered.
As it stands the "+ 1" results in resizing the buffer, when there is still capacity for one more object in the buffer.

I've changed the initial buffer allocation to use MEM_mallocN() instead of MEM_callocN(). The difference is that malloc() doesn't memset buffer (with zeros) when allocated. I've checked the code where new bbox records are created, and it does not rely on the buffer being initialised with zeros.
Anyway, isn't calloc() safer than using malloc()? Well no, it's actually the opposite in this case. Every time the buffer size is increased, it is done using realloc(), and this does not zero-out the uniniitialised portion of the buffer. So the code would break if it was modified to assume that the buffer contains zeros. Hence I believe initialising the buffer using calloc() could be misleading to a new developer.

Won't this result in increased memory usage? Yes, if you have millions of objects in your scene, then you are potentially using up-to twice the memory for the shadow caster. (However if you have millions of objects in your scene you're probably finding the Eevee render times a slow.)
Note that once the render gets going the frontbuffer bbox/bitmap will be shrunk to a multiple of SH_CASTER_ALLOC_CHUNK (32), therefore releasing the overallocation of memory.
As observed in Visual Studio - this appears to be prior to peak memory usage anyway.
Note this shrinking is executed in EEVEE_shadows_update() - during the first render sample pass. If necessary you could consider shrinking the buffer immediately after the EEVEE_shadows_caster_register() has done it's work. (Note however it appears you would need to add that function call is multiple places.)
Anyway as per the bug report I raised, I observed a 5% increase in peak-memory. And I'm unclear whether this difference in memory is due to me running the debug build. (It could be that there is no difference because of the shrinking.)

I couldn't figure out how the shadow caster backbuffer works. I see that EEVEE_shadows_init() has an explicit command to swap the front/back buffers. However this is done only when the buffers are first initialised and there is nothing in there yet. In my testing, the backbuffer->count was always zero, EEVEE_shadows_update() never did anything with the backbuffer.

Finally this problem is most evident when using Geometry Nodes or a Particle System to instantiate many objects. Objects created through say the array modifier do not cause any issues because it is considered one object by the shadow caster.

Reviewed By: #eevee_viewport, fclem

Differential Revision: https://developer.blender.org/D10631

Geometry Nodes: Improve performance of point distribute node

This commit refactors the point distribute node to skip realizing
the instances created by the point instance node or the collection
and object info nodes. Realizing instances is not necessary here
because it copies all the mesh data and and interpolates all
attributes from the instances when this operation does not
need to modify the input geometry at all.

In the tree leaves test file this patch improves the performance of
the node by about 14%. That's not very much, the gain is likely larger
for more complicated input instances with more attributes (especially
attributes on different domains, where interpolation would be necessary
to join all of the instances). Another possible performance improvement
would be to parallelize the code in this node where possible.

The point distribution code unfortunately gets quite a bit more
complicated because it has to handle the complexity of having many
inputs instead of just one.

Note that this commit changes the randomness of the distribution
in some cases, as if the seed input had changed.

Differential Revision: https://developer.blender.org/D10596

Outliner: Port scene elements and some related types to new tree-element code design

Continuation of work in 2e221de4ceee, 249e4df110e0 and 3a907e742507.

Adds new tree-element classes for the scene-ID, scene collections, scene
objects, and the view layers base.
There is some more temporary stuff in here, which can be removed once we're
further along with the porting. Noted that in comments.

Cleanup: Rename recently added Outliner files to exclude "_base" suffix

These files can contain more than just the "base" tree element types. E.g. the
class for the view-layer base element can also contain the class for the
view-layer elements. Otherwise we'd end up with like >50 files for the
individual types, most of them very small.
So just give the files a general name and put the related classes in there.

Cleanup: Split up new files for Outliner ID tree-elements

Splits up `tree_element_id.cc`/`tree_element_id.hh`.
If we move all ID types into this one file, it will become rather big. Smaller
files are probably easier to work with. We could still keep small classes like
`TreeElementIDLibrary` in the general file, don't mind really, but this creates
separate files for that too.

Python version of `make_source_archive.sh`

This is a Python version of the existing `make_source_archive.sh`
script. IMO it's easier to read, and it'll also be easier to extend with
the necessary functionality for D10598.

The number of lines of code is larger than `make_source_archive.sh`, but
it has considerably less invocations of `awk` ;-) And also the filtering
is integrated, instead of forking out to Python to prevent certain files
to be included in the tarball.

Reviewed By: dfelinto, campbellbarton

Differential Revision: https://developer.blender.org/D10629

Cleanup: Move geometry component implementations to separate files

Currently the implementations specific to each geometry type are in
the same file. This makes it difficult to tell which code is generic
for all component types and which is specific to a certain type.
The two files, `attribute_access.cc`, and `geometry_set.cc` are
also getting quite long.

This commit splits up the implementation for every geometry component,
and adds an internal header file for the common parts of the attribute
access code. This was discussed with Jacques Lucke.

EEVEE: Occlusion: Use ScreenSpaceRay for iteration

The sampling is now optimum with every samples being at least one pixel
appart. Also use a squared repartition to improve the sampling near the
center.

This also removes the thickness heuristic since it seems to remove
a lot of details and bias the AO too much.

EEVEE: RenderPass: Improve AO pass if screen space radius is small

This just bypass the occlusion computation if there is no occlusion
data. This avoids weird looking occlusion due to the screen space
geometric normal reconstruction.