When inserting new keys, the depsgraph needs to be updated.
Since that was missing with the new keying code, the NLA wasn't
working properly when inserting the first key.
Pull Request: https://projects.blender.org/blender/blender/pulls/123360
When snapping keyframes in the Graph Editor, handles
that were set to free didn't move.
The issue was that the snapping code didn't set the handle position.
Instead it relied on the handle recalculation (`calchandleNurb_intern`) to do the job.
That code doesn't affect free handles though.
The fix is to also offset the handles in the snapping code. The handle recalculation
will still run for all the other handle types so that behavior isn't expected to change.
This does NOT change the behavior of bezier snapping in the 3D viewport.
Pull Request: https://projects.blender.org/blender/blender/pulls/123173
This implement the holdout flag by switching to
the holdout case in the shader. This has a few benefits:
- Doesn't recompile the shaders.
- Makes the object infos mandatory (already the case in
practice)
- Handle transparent materials properly, keeping the
transparency working.
Fix#123284
Pull Request: https://projects.blender.org/blender/blender/pulls/123315
The callables generated by OSL reference other external functions
(defined in the OSL services module), in which case OptiX cannot
calculate the right stack size just based on the callable alone, it needs to
know all functions linked together in the pipeline to get to an accurate
result. `optixProgramGroupGetStackSize` has an optional pipeline
argument for this purpose, so make use of that to ensure the correct
stack size is calculated.
Ref #122779
Pull Request: https://projects.blender.org/blender/blender/pulls/123368
This happened in the following render test:
`render/light/all_light_types_in_volume.blend`
Unfortunately it seems non-deterministic.
To fix this, we change the heuristic to jump
out of the shadow update loop. Also introduce
a upper bound to the number of iteration.
On top of this, add a flush for every loop
to avoid huge command buffer submission.
Thanks @pragma37 for the fix.
This PR modifies the check for visibility when selected in the outliner.
With the change the visibility check only affects the selection state, not the active state.
The check has also been swapped with a function call to `ANIM_bone_is_visible_editbone`,
so now correctly works with collection visibility.
This PR also fixes the same issue for `Bone` and `bPoseChannel`
Co-authored-by: Cedric-Hutchings
Pull Request: https://projects.blender.org/blender/blender/pulls/123237
At high light count, this missing barriers would
produce invalid, non-unique `prefix_sum` indices.
This then resulted in some slots inside `out_light_buf`
never written to, leaving undefined data inside them.
If the buffer was cleared to zero, these undefined light
slots would be interpreted as sun lights and the
shadow setup compute pass would critically fail because
of out of bound memory.
Fix#123195
This makes it more verbose, and a little clearer that devices prior to 8cx Gen3 are not supported in >=v4.0. It makes the error message from #113674 more prominent than just being printed to cout.
Spurred by an email I got from someone trying to run blender on a Surface Pro X, and getting the not very helpful (to old devices) error.
Pull Request: https://projects.blender.org/blender/blender/pulls/122732
EEVEE Film accumulation workaround for Metal/Intel iGPUs.
On Metal the Intel iGPUs do not support image read write
on array textures. However this limitation doesn't show
any artifacts when using the compute shader.
This PR is a work around that uses the film_comp shader
to process the film samples, but uses a separate film_copy_frag
shader to read the result and copy them to the frame buffer.
I deliberately didn't include the fix to the film_frag shader
as that would change the read/write resources and could lead
to performance issues for other platforms. Writable resources
are typically slower compared to read only resources.
Some code needed to be duplicated (and not added to `*_lib.glsl`)
as compilers would still raise compilation errors due to imageStore/Load
on incompatible resource access.
The Metal/Intel iGPU is also marked to have limited support as
raytracing and probes still produces big artifacts.
This workaround can be tested on any platform just by setting
`use_compute_ = true` in `Film::sync`
Related to #122361
Pull Request: https://projects.blender.org/blender/blender/pulls/123330
- Add an option to build a separate package for each platform, this is
useful to produce smaller packages when large wheels are included.
- Add a reserved field: "[build.generated]" to the manifest when
splitting by platform which overrides the root-level platform
when it exists.
The previous code was using matrix multiplication to
get the local thickness to world thickness.
The correct way is to multiply the local thickness
by the scale of the object (length of each columns
of the object_to_world matrix).
When using particle system the generated coordinates where not set.
The reason is that a loose resource handle was created for particle
system that didn't contain enough information to calculate orcos.
This PR will create the object info from its parent object.
Pull Request: https://projects.blender.org/blender/blender/pulls/123307
This bias was added when the pixel radius estimation
computation was still broken. This resulted in a shadow
bias way too big in general.
Also fix shadow pixel size being clampped to the wrong
LOD level.
Fix#123295
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
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.
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
