A strip was wrongly deemed to be opaque (and thus strips below it
were skipped from rendering), if the strip content was opaque, but
it gained transparency via presence of a Mask modifier.
While at it, I also noticed that a strip could have been wrongly deemed
opaque when it had a Multiplier < 1.0 with "multiply alpha" option
checked under strip Color settings. So fixed that too.
The whole logic of that factored out into is_opaque_alpha_over function
to make the call site clearer.
Pull Request: https://projects.blender.org/blender/blender/pulls/123303
For very low frequency sounds (the ones where waveform drawing goes into
"line mode"), either of min or max can go outside of -1..+1 range.
The code was assuming that only max could be above +1, and only min
could be below -1. Fix that, and also make "line mode" also apply
red "clipped" color when clipping happens.
Pull Request: https://projects.blender.org/blender/blender/pulls/123246
EEVEE has a transparent render pass that renders materials where
the render mode is set to blended. This was introduced when EEVEE-Next
was still in development, but was never fully backported.
This PR adds the missing pieces.
Pull Request: https://projects.blender.org/blender/blender/pulls/123298
In `sound_bake_animation_exec`, the camera needs to be ensured each
frame so that marker camera switch can still give correct stereo/surround
effect during render.
Pull Request: https://projects.blender.org/blender/blender/pulls/123294
In `sound_bake_animation_exec`, the camera needs to be ensured each
frame so that marker camera switch can still give correct stereo/surround
effect during render.
Pull Request: https://projects.blender.org/blender/blender/pulls/123294
While implementing preview snapping, I noticed an oddity with snapping
videos to view bounds, and found that the preview window's total v2d has
half a pixel of extra padded width.
The bug was introduced in fb5e2f5610, which added `roundf` calls to
numerous areas in the blender code to replace instances of adding `0.5`
and then casting to an integer.
One mistake in the patch was fixed shortly after in d122911d10, but the
other mistake has been unfixed until now. This fixes the glitchy
behavior with preview snapping and is also small enough to add to 4.2
LTS.
Pull Request: https://projects.blender.org/blender/blender/pulls/123279
The issue is that timeline snapping code does not set the transform
`values` to a rounded frame delta, instead, it adds the rounded distance
between current source and target points to the unrounded `values`
float, leaving it unrounded.
Since snapping code is only run on some `transform_modal` calls due to
"time base quirky code" in `transform_snap_mixed_apply`, sometimes
frames briefly show mouse input added to `values` causing the strip to
get transformed away from the snap target before the snap code is run
once again.
To fix this, set transform `values` to the exact rounded snap target
frame diff (like in node snapping) instead of expecting it to get
properly rounded for every call. Do this by changing
`tsnap->snap_source[0]` to the original snap source on `transformInit`,
not the updated snap source.
Pull Request: https://projects.blender.org/blender/blender/pulls/123217
The base-4 Owen scrambling hash needs a seed value that's somewhat random-
looking, so the default value of 0 causes problems. Hashing the input seed
avoids this.
To avoid changing the noise pattern in pre-4.2 scenes, this hash is only
applied to blue-noise patterns.
Pull Request: https://projects.blender.org/blender/blender/pulls/123274
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.
