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
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
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
Undefined nodes are currently drawn using a red alert theme color to
make it easier to spot them and replace them. On the other hand, nodes
that are unsupported, that is, nodes whose poll method fail, are not
reported to the user in any way. So this patch also uses the same red
alert color for unsupported nodes.
The node_type_is_undefined function is moved to the draw file since it
seems to be specific to it and not used anywhere else.
Pull Request: https://projects.blender.org/blender/blender/pulls/136451
Blender crashes in older versions when loading files saved from v4.5 and
contain nodes like Mix in the compositor. That's because those nodes do
not exist in older versions, that is, this is a forward compatibility
issue.
The compositor already has protections in place to not crash when
loading files from future versions containing new nodes. However, for
nodes like Mix which existed in other node trees, the node is not new,
it is just new to the compositor, so it goes undetected and the
compositor tries to execute it leading to a crash.
To fix this, we also check the poll method of the node when verifying
compositor node trees. This should be backported to the corrective
release, as well as LTSs. But for v4.5, a change will later follow to
make the compositor execute such undefined/unsupported nodes using a
default operation that initializes the output with default values.
Pull Request: https://projects.blender.org/blender/blender/pulls/136438
The group output node is updated as part of the topology cache.
When there are multiple group output nodes the first one with an "active"
flag is picked. However, if no group output is flagged this will leave
the group output unchanged in the cache, even if that node has been deleted.
Always initialize the group output runtime cache to null to avoid invalid
pointers.
Pull Request: https://projects.blender.org/blender/blender/pulls/136436
Check on the modifier flag were explicitly masking all modifiers
which isn't needed as this flag is ensured to only have the four
expected modifier flags set.
Simplify logic by removing masking for "all" modifiers.
Some of the existing logic checked that modifiers were KM_MOD_HELD,
other logic checked the value wasn't KM_NOTHING or KM_ANY.
Simplify checks by comparing against KM_MOD_HELD in all cases
as this won't be set to other values.
- Document values to use for modifiers in code-comments.
- Only compare modifier values with KM_ANY/NOTHING/MOD_HELD.
- Use smaller integer sizes where possible.
Toolbars and some other regions are aligned to the left sides of their
areas and have an (often hidden) right edge that can be dragged to
resize or hide it. If there isn't enough vertical space to show all of
its contents then you also get a scroll bar along that same edge. These
two things conflict badly and is almost impossible to use with a tablet
pen. The mouse cursor changes to indicate dragging over the scrollbar
but doesn't work. Dragging the scoll bar requires doing so to the right
of it. This PR moves the scroll bars to the left side of these left-
aligned areas. They are correctly changed to the right side if you flip
the region.
Pull Request: https://projects.blender.org/blender/blender/pulls/136218
When regions are closed, like sidebars and toolbars, we show a little
arrow at the edge. This PR does not change that arrow, nor make any
noticable visual change, but almost doubles the hit size area. Much
easier to hit, especially with a tablet pen. It also changes the mouse
cursor when hovering over it to ones that indicate movement in that one
direction, helping to reinforce that you are over the spot. Otherwise
the mouse cursor looks the same as when over the nearby edge.
Pull Request: https://projects.blender.org/blender/blender/pulls/136334
If a panel has a toggle, then it's a best practice that everything inside it is
grayed out of the toggle is off. It's not something we can enforce for node
groups, but should enforce it for built-in nodes. Right now, we don't have
built-in nodes with panels, but that may change e.g. with #135990.
This patch makes it so that the socket usage inferencing takes panel toggles
into account when determining if an input socket in a built-in node in a panel
is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/135993
Snap nodes by first aligning their inital location to the grid and then
offsetting them in grid increments to avoid jiggling when multiple
unsnapped nodes are moved at once.
Pull Request: https://projects.blender.org/blender/blender/pulls/136437
Newer nodes may not have a fixed `legacy_type`. This was not accounted for
correctly when reading nodes. Such newer nodes are exclusively identified by their idname.
Fortunately, Blender 4.4 was released without any new nodes that don't have
a fixed `legacy_type`. So this does not have to be backported.
Pull Request: https://projects.blender.org/blender/blender/pulls/136431
When adding a texture to a brush datablock, currently, the resulting
undo step does not have any effect when undone. This is due to the
texture being added to the linked asset library. As we do not want this
extraneous undo step to be created since it has no effect, this commit
does the following:
* Removes the automatic undo handling with OPTYPE_UNDO
* Manually adds a undo step if the newly created Texture datablock was
not moved to a library.
Pull Request: https://projects.blender.org/blender/blender/pulls/136336
With tint brush active, holdinh ctrl key doesn't erase the color
attribute. Similar to vertex brush (`VertexPaintOperation`) reduce alpha
value from the influence
Pull Request: https://projects.blender.org/blender/blender/pulls/136424
The issue was that using `DEG_get_original_id` returned the same
evaluated ID, because the `GreasePencil` in the geometry set doesn't
have the original ID pointer set.
Instead, use the original ID pointer stored in the
`GreasePencilEditHints` (which is better anyway).
Also resolves#136307.
Pull Request: https://projects.blender.org/blender/blender/pulls/136455
This reintroduce the same behavior as 4.3 with regard to
selection and depth drawing.
This patch also disables facing overlay during depth
drawing to avoid it conflicting with tge auto-depth
feature.
Also fix#136418
Pull Request: https://projects.blender.org/blender/blender/pulls/136427
This will likely reserve a larger vector more than actually needed.
Reserve only the same count of decorators to be added, since they
likely match the number of buttons that needs to be temporally
retrieved.
Decorators buttons are added along animatable property buttons in each
`layout.prop` function call, when a property is a `XYZ` vector property,
drawing this property adds 3 inputs buttons and for each inputs buttons
this need to insert an aligned property decorator, since this decorators
are added just after the buttons are added this likely just takes out
temporally this last 3 elements and inserts them back with each
corresponding decorator.
Pull Request: https://projects.blender.org/blender/blender/pulls/136191
Use aces_interchange role in OpenColorIO to identify the correct colorspace
for each config. Also use acesImageContainerFlag attribute from the ACES
container format to identify the colorspace.
Write ACES2065-1 chromaticities in EXR files when appropriate. This gets us
closer to supporting output of the ACES container format, though we don't
write acesImageContainerFlag. There are various restrictions that must be met
which are not very practical, and even exr2aces doesn't write it.
Pull Request: https://projects.blender.org/blender/blender/pulls/135823
The OpenEXR format has a chromaticities attribute that identifies the scene
referred linear color space. Detect these two cases now, and assign the
corresponding color space from the OpenColorIO configuration.
In general these chromaticities are known to be unreliable and missing support
in most software, with ideas to deprecate them entirely. However the ACES
container format standard requires them, and with this change we'll be able to
read such images with the right color space set by default.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/135823
Interpolating between curves of the same length was shifting the target
points by 1 index position, starting about half-way along the curve.
The reason is that the `num_free_samples` count compared _points_ of the
destination curve to _segments_ of the source curve, and at equal point
count the segment count is 1 less.
This extra point would be consumed about half-way along the spline, and
then the end point of the source curve was not represented. Fixing
the count makes sure that source and target curve match exactly when
they have the same number of points.
Pull Request: https://projects.blender.org/blender/blender/pulls/136448
