We shouldn't use parallelism internally for each node, but it snuck in
with recent changes to use `array_utils::gather`. That's a nice change,
but we need a better way to turn off parallelism for that sort of
function. Until that's decided on, add a quick fix to fix the deadlock.
The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
Recently this was inlined [0] however the purpose of this define is to
allow for the method of setting the value to be changed.
It also means the hack doesn't have to be explained whenever it's used.
Move the BEZKEYTYPE to DNA, update it's doc-string and restore the
original comment.
[0]: fd3629b80a
In the context of meshes `totface` reads as if its the number of faces
in the mesh. This was infact the number of looptris however as this
is converted into a "bodyface" array, use that as the prefix.
The intent of `ghost_event_proc_timestamp_warning` is to give a console
warning when an event time is outside of an expected 5 second window
around the last time. However if an event happens within the first 5
seconds we get an overflow in a calculation and we get warnings for
normal times within the range.
Pull Request: https://projects.blender.org/blender/blender/pulls/116164
Add "Preserve Current Retiming" option to set speed operator. This
option is enabled by default. When changing speed of retiming segment,
the strip changes length instead of changing next segment speed.
Ref: #112343
This feature improves workflow, where it is necessary to select all
retiming keys after one that is selected in order to change speed of
only 1 segment.
The feature is reusing `sequencer.select` "linked time" feature and
mapped Ctrl key.
Ref: #112343
Caused by 133dde41bb, it is expected behavior now for linked ID in
general, see also #105786 and #106321.
However, Scenes are a special case here, since they are almost never
(and should not be) indirectly linked by other data, and have (almost)
never any real user, unless they are active in one of the open main
windows.
So this commit essentially reverts the new behavior implemented
in #106321, for linked scenes only.
Should be backported to a potential bugfix release of 4.0.
Link/append code sets the scene pointer to `null` when the active
scene is a linked one, to avoid attempt to instantiate linked data
(objects or collections) into a linked scene, which is forbidden.
However, code was still calling some functions expecting a valid scene
pointer, leading to crash.
It is unclear when exactly this issue was introduced code wise. From a
user perspective, it seems to have been revealed between 3.6 and 4.0
release (bisect points at 00a36cbf24, which does not seem to be
directly related...).
In any case, the fix is trivial and safe, so should we do another 4.0
bugfix release, this commit should be backported.
Due to lack of forward compatibility, tool_settings.snap_uv_element
could return empty if a 4.0 file is opened in 3.6.
This causes a Python error when trying to identify the element's icon.
Avoid this python error.
Usually we expect new DNA values do be zeroed when we add them. But the
conversion to the interface format for 4.0 didn't clear the memory, so
behavior was different when updating old files. Fix that by using
`calloc` instead of `malloc`.
These shouldn't be called in hot loops at all, and mostly aren't
anymore anyway. Definining them outside of a header allows removing
the `BKE_customdata.hh` include from `BKE_mesh.hh`.
Doing this in preparation for also supporting volume
grids in the same type (#115270).
At some point we could also actually use an `std::variant` in this
type, but that would change behavior without futher changes.
The previous behavior, fairly rough, was simply considering all
Collections and IDs found as part of the root's hierarchy as to be
overridden.
The new behavior is based on a specific tag added to some ID usages.
Currently, these are only the links from a Collection to its Objects
and children Collections, and the link from an Object to its parent.
The goal of this huge reduction of the 'automatically overridden' set of
data in a hierarchy is to avoid creating liboverrides for 'utils' data,
e.g. a collection used as source of data by a GeometryNode generating
some parametric geometry (Blender Studio use-case: some form of LOD
handling).
In general, it means that only Collections and objects part of the
collection hierarchy of the root collection are now overridden.
This should not change in the typical recommended use-case so far (where
there is a clear root collection to the whole overridden hierarchy, and
it contains all related collections and objects).
But this should allow much less overhead (and viewport pollution, due to
the current principle that local (and therefore liboverridden) objects
have to be instanciated in a Scene) for more complex setups.
Note that the initial idea/change is fairly simple and easy to
implement, but it creates some additional complexity in the partial
resync code, since now some linked data may not be detected as needing
a liboverride anymore when processing a sub-hierarchy, while it would
require it when processing the whole hierarchy.
This required adding some more processing to the util functions which
define which ID should be overridden. It essentially creates a
'reference set' of all reference IDs that should be overridden when
the whole hierarchy is considered, and use this as additional input to
decide which ID to override when processing a sub-hierarchy for the
partial resync.
Pull Request: https://projects.blender.org/blender/blender/pulls/115853
This patches refactors the compositor File Output mechanism and
implements the file output node for the Realtime Compositor. The
refactor was done for the following reasons:
1. The existing file output mechanism relied on a global EXR image
resource where the result of each compositor execution for each
view was accumulated and stored in the global resource, until the
last view is executed, when the EXR is finally saved. Aside from
relying on global resources, this can cause effective memory leaks
since the compositor can be interrupted before the EXR is written and
closed.
2. We need common code to share between all compositors since we now
have multiple compositor implementations.
3. We needed to take the opportunity to fix some of the issues with the
existing implementation, like lossy compression of data passes,
and inability to save single values passes.
The refactor first introduced a new structure called the Compositor
Render Context. This context stores compositor information related to
the render pipeline and is persistent across all compositor executions
of all views. Its extended lifetime relative to a single compositor
execution lends itself well to store data that is accumulated across
views. The context currently has a map of File Output objects. Those
objects wrap a Render Result structure and can be used to construct
multi-view images which can then be saved after all views are executed
using the existing BKE_image_render_write function.
Minor adjustments were made to the BKE and RE modules to allow saving
using the BKE_image_render_write function. Namely, the function now
allows the use of a source image format for saving as well as the
ability to not save the render result as a render by introducing two new
default arguments. Further, for multi-layer EXR saving, the existent of
a single unnamed render layer will omit the layer name from the EXR
channel full name, and only the pass, view, and channel ID will remain.
Finally, the Render Result to Image Buffer conversion now take he number
of channels into account, instead of always assuming color channels.
The patch implements the File Output node in the Realtime Compositor
using the aforementioned mechanisms, replaces the implementation of the
CPU compositor using the same Realtime Compositor implementation, and
setup the necessary logic in the render pipeline code.
Pull Request: https://projects.blender.org/blender/blender/pulls/113982
As I dont quite get the logic of "enforcing a positive quadrant" from
b38be90515 (which broke the previous behavior of 2.79 which was
capable of handling reversed edges as well -- there might be ways to
make that work though), now use the alternative approach of storing the
flipped direction in the kdtree as well.
This has a slight performance hit (only noticable at ~500k edges), but I
believe correctness beats performance here.
Pull Request: https://projects.blender.org/blender/blender/pulls/115951
Currently, the OpenEXR reader can't read single-layer XYZ images as a
combined image. Single-view images will only read the X channel, while
multi-view images will interpret the Z as a depth image and the Y and Z
channels will be treated as float passes.
This patch allows the reading of XYZ channels as combined images. For
single-view images, we just extend the RGB-like channel names we match
to contain XYZ. For multi-view images we only treat the Z channel as a
Depth one if no X and Y channels exists, since the Z in this case is
part of the XYZ image.
Pull Request: https://projects.blender.org/blender/blender/pulls/115290
