The code before this change was relying on the ShadowPayload have
the same "header" as RayPayload for some of the primitive types
(curve, motion triangle, point): intersection functions were shared
between "regular" and shadow rays (shadow in this case is shadow_all),
but extra filter function was used for shadow rays.
This is fragile if someone changes one of these structures. What is
worse is that compiler might actually decide to shuffle things in
some structs, or remove unused fields.
This change also solves confusion about ShadowPayload::prim_type
seemingly only being assigned to PRIMITIVE_NONE. With time it is
not impossible that compiler will also see this, and constant-fold
some checks, or even remove the field. If that happens then the
render result will be wrong. Maybe it is already happening as there
are some GPU and driver and optimization flag specific bugs in the
area.
It is unclear whether it was causing any actual problem: W7800
seems to render all hair correctly on Linux.
Also make some style decisions more consistent: for example,
the way how stop/continue search return value is commented.
Prefer lower vertical space for those.
Mainly readability purposes:
- Having variables called local_payload is ambiguous: does it refer to
LocalPayload type or to a variable be local in a function?
- Some of the functions are used for different ray types, so having the
type case in intersectFunc and filterFunc makes it easier to scan.
For the latter: now it is more obvious that Curve_Intersect_Shadow
expects RayPayload, but Curve_Filter_Shadow expects ShadowPayload.
It might not be a problem currently as ShadowPayload has the same
"header" RayPayload, but it might change in the future. Also, compiler
might optimize fields out from one but not from the other.
Add support for a 5th modifier key called "hyper",
this is a modifier supported on Wayland & X11 although
other platforms could support an additional modifier too.
Both GNOME and KDE can map CapsLock to Hyper.
Other compositors can use the XKB_DEFAULT_OPTIONS environment variable.
This allows users to have an additional modifier for their own use
that doesn't conflict with other keys.
Ref !136340
Some regions, like toolbars and sidebars, can be dragged open and
closed. But this often doesn't work correctly a second time because
we don't update our saved widths once the area is hidden. This results
in an incorrect offset. This PR just resets the saved widths to zero
when the region is hidden so this doesn't occur. Note that this does
not affect the ability to just click and release on the widget, only
dragging from it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136527
Rename to be more consistent with other Blender keymaps, as well as the
naming convention used in "View Type."
- "SequencerCommon" -> "Video Sequence Editor"
- "SequencerPreview" -> "Preview"
- "Sequencer Timeline Tool" -> "Sequencer Tool"
- "Sequencer Preview Tool" -> "Preview Tool"
There is versioning in place to make sure custom keyconfigs keep working.
Once #131102 goes through, if we would like to rename the "Sequencer"
view type to "Timeline" or "Sequencer Timeline," then we can make the
necessary changes here too.
Pull Request: https://projects.blender.org/blender/blender/pulls/136217
Strip locking was meant to be used with strip transformation only. So
the check, whether strip is locked is removed from hide/unhide operator.
Further it was requested to lock sound strip subframe offset. Since this
is time related property, it was moved to time panel. This also
addresses request to make it more obvious, why the value can't be
changed.
The name of the property was clarified from "Offset" to
"Sound offset", because there are another 2 offsets in the panel.
Finally, when channel is locked, properties in side panel now reflects
this state. This is done by adding RNA get function for `Strip.lock`
property. Function `seq::transform_is_locked` is used instead of
checking `SEQ_LOCK` flag, because it also checks channel state. With
this setup, the lock property can't be disabled while channel is locked.
However strip lock flag will be unset, which can be prevented. (I am not sure which is better. Both are fine in my eyes.)
Pull Request: https://projects.blender.org/blender/blender/pulls/135831
The "slip strip contents" operator in the VSE now can move the strip
keyframes. There is a property to enable keyframe slipping.
The property is disabled by default, mainly because animation is
often used for fade in/out, which would be annoying if it moved with
content.
Pull Request: https://projects.blender.org/blender/blender/pulls/136386
There is a known precision bug in the current HIP compiler version (RDNA2 family/Windows) that has already been fixed and will be available in
a future HIP SDK release. Enabling more precise math prevents the artifacts.
This may cause a 5-10% performance drop in some scenes.
Fix#136138: Microfacet BSDF
Fix#136449: Hair BSDF
Pull Request: https://projects.blender.org/blender/blender/pulls/136341
The initial goal of this PR is to avoid creating vertex and index
buffers as part of the "request" phase of the drawing loop. Conflating
requesting and creating index buffers might not sound so bad, but it
ends up significantly complicating the whole process. It is also
incompatible with a future buffer cache that would allow avoiding
re-uploading mesh buffers.
Specifically, this means removing the use of `DRW_vbo_request` and
`DRW_ibo_request` from the mesh batch extraction process. Instead, a
list of buffer types is gathered based on the requested batches. Then
that list is filtered to find the batches that haven't been requested
yet. Overall I find the new process much easier to understand.
A few examples of simplifications this allows are avoiding allocating
`MeshRenderData` on the heap, and the removal of its `use_final_mesh`
member. That's just replaced by passing the necessary information
through the call stack.
Another notable difference is that for meshes, EEVEE's velocity module
now requests a batch that contains the buffer rather than just requesting
the buffer itself. This is just simpler to get working since it doesn't require
a separate code path.
The task graph argument for extraction is unused after this change. It wasn't
used effectively anyway; a simpler method of multithreading extractions is
used in this PR. I didn't remove it completely because it will probably be
repurposed in the next step of this project.
The next step in this project is to replace `MeshBufferList` with a
global cache that's keyed based on the mesh data that compromises each
batch, when possible (i.e. for non edit-mode meshes). This changes above
should be applied to other object types too.
Pull Request: https://projects.blender.org/blender/blender/pulls/135699
Rather than transforming the nodes inside shrinking frames together with
their parent, they are now transformed individually. That way the nodes
are aligned with the grid when snapping and the frame is adjusted by
the automatic resizing.
This makes the grid alignment of nodes is consistent, no matter whether
the node or its parent frame is transformed.
The behavior for manually resized frames is unchanged.
Pull Request: https://projects.blender.org/blender/blender/pulls/136381
The new correction avoids washed out areas near the shadow terminator,
preserving more detail from normal and bump maps.
It implements the method from the paper "A Microfacet-Based Shadowing
Function to Solve the Bump Terminator Problem" by Alejandro Conty Estevez,
Pascal Lecocq, and Clifford Stein.
Pull Request: https://projects.blender.org/blender/blender/pulls/135380
This makes it possible to restore previous Blender 4.3 behavior of bump
mapping, where the large filter width was sometimes (ab)used to get a bevel
like effect on stepwise textures.
For bump from the displacement socket, filter width remains fixed at 0.1.
Ref #133991, #135841
Pull Request: https://projects.blender.org/blender/blender/pulls/136465
Resolves#136183
To avoid quadratic worst case runtime when gathering values from
the modifier properties, build a temporary VectorSet of the modifier's
IDProperties. In the file from #136183, this change improves playback
performance by 1.4x for me, from 50 to 70ms.
Ideally IDProperty groups would have constant time lookup on their
own, but that's a much larger change, and this smaller change for just
Geometry Nodes is not so invasive.
Pull Request: https://projects.blender.org/blender/blender/pulls/136463
The crash regression comes from 583e2b7240.
Pass the s_sharedHGLRC directly to wglCreateContextAttribsARB instead
of using wglShareLists.
Context: https://github.com/baldurk/renderdoc/issues/1224
This doesn't only fix the recent regression, but solves all the long
standing issues with Renderdoc on Windows (F12 rendering support,
multiple windows, deferred compilation...).
(Fix suggested by @LazyDodo)
Pull Request: https://projects.blender.org/blender/blender/pulls/136140
The output of the mentioned test was slightly off from what main
currently produces, so update the reference image to resolve test
failures.
Ref: blender/blender-test-data!78
Usually we prefer to propogate attributes based on name, even for
conversion between geometry types. Builtin attributes are a common
exception though. The Curve to Points node and the Curve to Mesh node
didn't correctly handle the "custom_normal" attribute, which shouldn't
be propagated. This has only been a problem since custom normals were
converted to a generic attribute on meshes in f9b627d29c.
Pull Request: https://projects.blender.org/blender/blender/pulls/136452
... when in multiobject editmode
We had a similar issue in #95752, so the fix here is similar to
cc0c4c17f0
The reason here is that `edbm_region_to_loop_exec` switches to edge
select mode but was only doing this on objects that actually had faces
selected, all other participating meshes would keep their selectmode
which would now be out of sync with both the objects that had faces
selected and scene settings for these.
This causes problems later in 'Select Linked'. Here, a mixture of
objects are used. First the viewcontext is set up with the active
object, then all participating objects are iterated (changing the
viewcontext to another object), then `unified_findnearest` would use
that changed viewcontext which would now contain the last object
iterated. To repeat: this could now have a different selectmode than the
active object which is later **again** used to get the nearest `BMElem`
from in `EDBM_elem_from_selectmode`. So in the failing case, we could
get an edge (but no face because of edge selectmode) from
`unified_findnearest`, `EDBM_elem_from_selectmode` would return NULL
though (edge provided, but in face selectmode), leading to the crash.
To solve this it is best to change selectmode on all
participating meshes in multi-object editmode if necessary so
these are always in sync for following operations.
Pull Request: https://projects.blender.org/blender/blender/pulls/136497
The Cryptomatte node fails for image sequences in some cases. This is
due to a use after free error which might even crash in some cases. This
is because the loop that computes the image Cryptomatte layers calls the
cached images container to get the passes, which might free the render
layers structure that is used while looping.
To fix this, gather the render pass names first then retrieve all the
images at once.
When moving slots (with all their associated animation data) from one
Action to another, tag the data-blocks that are affected by the slot
move, so that they get re-evaluated. Without this, their (out of date)
evaluated copy would still point to the original Action, which no longer
has animation data for the moved slot.
Pull Request: https://projects.blender.org/blender/blender/pulls/136454
F-Curve interpolation uses the `FCURVE_INT_VALUES` and
`FCURVE_DISCRETE_VALUES` flags, which were not set in the keyframe
insertion function for slotted Actions. This is now resolved by making
the RNA property type part of the `FCurveDescriptor`.
Existing code has been refactored a bit, mostly to allow calling
`update_autoflags_fcurve_direct()` with just the RNA property type,
instead of passing the property itself. This avoided the need to include
pointers to RNA properties in `FCurveDescriptor`, which I think is a
slightly nicer design. It also makes it more explicit which aspect of
the property is used.
Because there's now another `std::optional<>` in the `FCurveDescriptor`,
I've also changed some `std::nullopt` to `{}` for brevity of the code,
as repeating that another time would have caused longer lines with more
rewrapping.
Pull Request: https://projects.blender.org/blender/blender/pulls/136446
In the animation & armature editors, replace calls to
`WM_global_report()` with `BKE_report`, to ensure that the reports go to
the appropriate report list (and giving callers control over this).
There's one `WM_global_report()` call left, in
`ED_armature_bone_rename()`. That doesn't have a `ReportList` available,
so I left it as-is for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/136261
