Blender Git Commits

Code cleanup: fix incorrect socket names in hair and particle info nodes.

GWN: Fix compilation on windows

BKE: Changing ID freeing order.

Screen can contains manipulators that contains batches to be freed before the opengl contexts (in WM) are destroyed.

Also fix other GPU related free.

Fix incorrect OSL raytype bits and add some comments.

Fix T54105: random walk SSS missing in branched indirect paths.

Unify the path and branched path indirect SSS code. No performance impact
found on CUDA, for AMD split kernel the extra code was already there.

Fix T54107: bevel shader + normal map gives wrong result.

Gawain: VertexFormat: Cleanup

Reorganize struct elements by size, rename a constant.

Gawain: Refactor: VAOs caching AND use new VAOs manager.

A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls.
This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing).

Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself.

--- Batch changes ---
For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime.
The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs.
This mean a VAO can be generated and cached for this instancing case.

A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true.

--- Draw manager changes ---
The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free.
This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches.

--- VAO cache ---
Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives.
If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings.
The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static.
Using this hybrid approach is a bit more performant than the dynamic array alone.
The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed.

--- Results ---
Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw!
In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms.

The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).

Gawain: Add new context/vao manager.

This allows allocation of VAOs from different opengl contexts and thread as long as the drawing happens in the same context.

Allocation is thread safe as long as we abide by the "one opengl context per thread" rule.

We can still free from any thread and actual freeing will occur at new vao allocation or next context binding.

Cleanup: Don't perform borderselect on channels that aren't visible

Fix: Return back to conventional way of averaging points for keyframe de-dup

The other approach was causing too much error in some cases (e.g. favouring
the lower-valued keyframes). This fix should make the resulting curves less
bumpy/jagged.

Fix: Forgot to recalculate handles after deleting keyframes

Fix: Don't average keyframe values if FCurve can only have int/discrete values

This is to prevent problems with integer/enum properties getting invalid
values set.

Cleanup: Delete debugging code and the old version of the automerge code

Tweak/Fix for T54106 - Moving multiple selected keyframes on top of an unselected one would not merge the keys

This commit removes an earlier attempt at optimising the lookups
for duplicates of a particular tRetainedKeyframe once we'd already
deleted all the selected copies. The problem was that now, instead
of getting rid of the unselected keys (i.e. the basic function here),
we were only getting rid of the selected duplicates.

With this fix, unselected keyframes will now get removed (as expected)
again. However, we currently don't take their values into account
when merging keyframes, since it is assumed that we don't care so much
about their values when overriding.

Minor Optimisation: Terminate early if we've passed the insertion point for tRetainedKeyframes

Feature Request T54106: When scaling keyframes, merge (by-averaging) selected keys
that end up on the same frame

Currently, when scaling keyframes in the Dopesheet, if multiple
selected keyframes end up on the same frame post-scaling, they
would not get removed by the "Automerge" setting that normally
removes duplicates on the same frame.

This commit changes the behaviour so that when multiple selected
keyframes end up on the same frame, instead of keeping all these
around on the same frame (e.g. resulting in a column of keyframes
on different values), we will instead merge them into a single
keyframe (by averaging the values). This should result in a
smoother F-Curve with fewer "stair-steps" that need to be carefully
cleaned out afterwards.

Requested by @hjalti

bezt_add_to_cfra_elem() - Use same keyframe equality test as in other places

This shouldn't affect anything currently, as this function doesn't appear
to get used anywhere.

Fix T54065: NLA-Strip Control Curves would get disabled when name-based-filtering is enabled

This bug took a while to track down. In the test file with this report,
the Nla-Strip Control Curve for strip time would get disabled if you
changed the NLA Editor to a second Graph Editor instance.

It turns out that because this second Graph Editor would have the
"filter fcurves by name" option enabled, this would trigger a lookup
of the referenced property's name (in order to test whether it matched
the filtering criteria). However, since that filtering code was written
before the introduction of these curves, it still assumed that the names
for these Control Curves should be handled the same as for standard FCurves.
Unfortunately, that doesn't work, as the property lookups fail if the standard
method is used - when the lookups fail, the F-Curves get tagged as being
invalid/disabled (and need to be reset using the "Revive Disabled FCurves"
operator).

Note: The changes in this patch look complicated, as I've had to shuffle
a bit of code around so that the name-filtering check can have access to
the additional info it needs. In the process, I've also removed the earlier
(hacky) approach where the control curves were getting added to a temp
buffer to get changed from normal FCurves to special ANIMTYPE_NLACURVES.

Fix more missing ID remapping in animation editor callbacks

Applying the same fixes as introduced in 98d797b67c07e85889768bf8ecde292e9e6f70e9
this time, for the Graph and NLA editors