The fix is to support interleaving the drawing of zones and frames.
The draw order is determined by the width of the zones/frames.
Larger areas are drawn before smaller ones. This makes sure that
everything is as visible as possible.
The zone border outlines are still drawn on top of all frames.
Solving that is technically more challenging, because we don't want
to use transparency for zone backgrounds because that results in
many possible mixed colors which we want to avoid. Fortunately,
drawing the outlines on top seems to be quite useful anyway.
Data is not stored per-PBVH node for dyntopo undo logging.
Previously we push an undo node anyway, but to separate things
a bit more, just use the undo type and bm_log directly.
Currently the corner_vert and corner_edge attributes go through the
generic custom data interpolation, only to be overwritten directly
afterwards. In a profile of the execution of the subdivision surface
modifier, 5% of the time was spent in `layerInterp_propInt`. To fix
this, first build a `CustomData` layout to be used just for face corner
attribute interpolation. Then allocate the topology attributes
separately and add them to the result mesh later. This requires a fair
amount of boilerplate right now, but it should be improved with various
changes to mesh attribute storage in the future.
In a file with many object with a subsurf modifier, this change
improved the overall execution time by between 5 and 10% in my tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/123254
The issue was that we used `from_orthonormal_axes` which obviously expects that
the axes are orthonormal. However, with custom curve normals this is not always the
case. Math wise, an additional normalization is necessary because the cross product
is not automatically normalized anymore.
This change also means that `point_matrix` may have a shearing component. But I
think that's fine here because the matrix is only immediately applied on vertex positions.
This shouldn't affect any case where the normal and tangent are orthonormal.
Pull Request: https://projects.blender.org/blender/blender/pulls/123238
Do this by:
- Removing depth and depth test.
- Scale the sphere to the covered pixels size.
- Use infinite orthographic matrix
We can still improve this by scaling the sphere
bigger depending on the accuracy at its position.
Fix#123165
`booleans_mix_calc` was incorrect. While it computed the correct result in
many common cases, under some specific circumstances, at was wrong.
Whether it was wrong also depended on how the range was split up for
multi-threading which is not deterministic.
The function was used in `Mesh::normals_domain` which then also returned
the wrong domain in some cases.
`Copy Material to Selected` now sets the `Link` type of the selected objects to match those of the active object.
Without this, it changes the underlying material slots on the mesh data block, which is probably not what the user intends. With the new behavior, it now changes the selected objects to use object-linked materials.
Pull Request: https://projects.blender.org/blender/blender/pulls/122579
Avoid warning the user that there is a geometry, if it does not have any points/data.
Such geometry components shouldn't just be removed generally. because they
still contain information (such as the set of existing attributes).
The threshold is way too high as the light power gets very small.
It still make sense to include the power here because
some lights might be disabled for some BSDF types, and
skipping the LTC eval code can be beneficial.
So reducing the threshold to very low value near FLT_MIN
to fix the issue.
Fix#123193
This moves move clip related properties to own movie clip panel as it
is done with other strip types that uses other datablocks. The clip
property is added to RNA, so this can be added to the panel.
Requested in #120357
The issue was a floating point precision issue
between the number of the cycle and the time
within the cycle (`cycle` and `cyct`).
Due to that the `cycle` would advance to the
next whole number while the `cycle time`
is still slightly under that.
This is fixed by calculating the `cycle` with double precision.
This has a measurable performance
impact (for `fcm_cycles_time`)
| Before | After |
| - | - |
| 39ns | 44ns |
For fcurves with a cycle modifier,
this code is run at every evaluate call.
The only time when that would be an issue is
in the graph editor, where there is an evaluate
call for roughly every pixel for curves that have a modifier.
However even in that scenario the performance
is the same within run to run variance (for `graph_draw_curves`)
| Before | After |
| - | - |
| 91565ns | 91430ns |
Pull Request: https://projects.blender.org/blender/blender/pulls/123222
When using GPU_SAMPLER_EXTEND_MODE_EXTEND the incorrect sampler
was created, making the OCIO shader fail. This PR selects the
correct wrapping mode (CLAMP_TO_EDGE).
Pull Request: https://projects.blender.org/blender/blender/pulls/123234
