This adds a "Legacy Behavior" option to the Limit Rotation constraint that makes
it behave how Limit Rotation constraints did prior to
ed2408400d. Newly created constraints have this
option disabled, but versioning code enables the option on constraints from
older files to ensure that the behavior of e.g. existing rigs is not altered.
This is one part of a two-part fix for #123105. The other part is in PR
extensions/rigify#4.
Pull Request: https://projects.blender.org/blender/blender/pulls/123361
Cycles runs a check to see if the camera is possibly inside a
volumetric object by seeing if the bounding box of the camera
and volumetric object intersect.
If the calculation is wrong (Cycles says the camera is outside the
volume when it's inside it), then the volume will not render properly.
This commit resolves most of these issues by making the camera
bounding box larger than before, taking into consideration
features like:
1. The impact DOF could have on the camera ray start position and how
that should impact the bounding box size.
2. Taking into consideration near clipping, which was missed from the
orthographic camera due to a oversight in a previous commit
(08cc73a9bb).
Pull Request: https://projects.blender.org/blender/blender/pulls/123341
`GpencilIOParams.ob` is set to `CTX_data_active_object` at the beginning
of the export [which is not ensured to be a valid `OB_GPENCIL_LEGACY`
object, non-valid objects are filtered out later in
`create_object_list`]. From this (potential non-greasepencil) object's
data, a "global `bGPdata` is stored in `GpencilIOParams`.
From here, it can only go downwards as `stroke_point_radius_get`,
`export_stroke_to_polyline`, `BKE_gpencil_stroke_perimeter_from_view`
all use this "global" `bGPdata`.
Two possible solutions might exist:
- [1] just cancel the operator if the active object is not a
`OB_GPENCIL_LEGACY` object
- [2] make sure we use corresponding `bGPdata` when iterating over
valid objects to export
This PR chooses [2] since it also seems wrong to always use the
`bGPdata` from the active object for certain calculations when iterating
many objects. For example, the export ignores different values for
`Thickness Scale` on different objects and always takes the value from
the active object, which does not seem to be by design.
NOTE: this changes behavior (see above) but for the better
Pull Request: https://projects.blender.org/blender/blender/pulls/123224
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
