Value and usage inferencing can be done independently. Usage-inferencing uses
the value-inferencing but not the other way around. Extracting value-inferencing
makes the separation more clear and also simplifies potentially reusing the
value-inferencing code later on.
Pull Request: https://projects.blender.org/blender/blender/pulls/145492
When instanced meshes were using FBX geometric transforms, the code
was not telling ufbx to create proper adjustment helper nodes due to
UFBX_GEOMETRY_TRANSFORM_HANDLING_MODIFY_GEOMETRY_NO_FALLBACK flag.
That flag was put in earlier, before import of armatures was solidified,
turns out using the proper flag (UFBX_GEOMETRY_TRANSFORM_HANDLING_MODIFY_GEOMETRY)
is not a problem anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/145527
Underlying reason here is just that whenever a region gets too large to
still be displayed in an area, it simply gets hidden.
This is expected (but also reported elsewhere, see #122277).
It has seen some reports though and it seems we can actually prevent the
AssetShelf from getting too high (and thus being hidden) in case many
rows are used and preview size is increased by automatically decreasing
row count.
Pull Request: https://projects.blender.org/blender/blender/pulls/145117
This applies an OpenColorIO display, view and look transform on a color
in the scene_linear colorspace.
In general, OpenColorIO configurations do not contain a colorspace for
every view + display, especially if they are modern configs using the
display colorspace and shared view mechanisms. Nor do they include looks.
So the Convert Colorspace node is not sufficient.
Additionally, we would like to avoid making the colorspace list too long
in the default config, as we are adding many new views and transforms.
Exposure, gamma curves and white point functionality are not included
in this node, as there are native ways of doing that in the compositor.
These settings are marked non-editable in the Python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/145069
How to reproduce:
- Load an image with random values
- Set sampler size to 1 (default)
- Sample a random image on a pixel
- Set sampler size to 64 (max)
- Sample the same image on the same pixel
- Notice how the value doesn't change
Pull Request: https://projects.blender.org/blender/blender/pulls/145318
Mistake in refactor of Relocate code in a1abf9a64e, the handling of
cases where a valid (exisitng, missing linked placeholder ID) was not
found in the searched library(-ies) was not handled properly in the new
code.
These need to be ignored by remapping from old to new (relocated) IDs,
since it's better to keep the placeholder 'empty reference' IDs, than
remap to null!
Multiple previous changes made resource pools obsolete. Resource
pools were used to keep track of resources when the frame is rendered.
Multiple frames can be rendered at the same time and resources could
overlap.
This has been replaced (not this commit) to be part of the render graph
and when an submission has completed the resources are recycled.
Continuation of: https://projects.blender.org/blender/blender/pulls/145408
Pull Request: https://projects.blender.org/blender/blender/pulls/145511
Add the `SKIP_SAVE` option to the 'Paste Global Transform' operator
properties.
This fixes a bug with following repro steps:
- Specify a relative object
- Use relative copy/paste
- Try to use non-relative copy/paste
- It will fail because after you used the relative paste operator, the
`use_relative` property is saved for ever as True.
Pull Request: https://projects.blender.org/blender/blender/pulls/145262
Previously, if a user extruded a curve with the Pen tool and held down
the `Ctrl` modifier key, the right handle would always be moved
independently. This should not happen when extruding a curve from
the beginning.
This pull request adds a check that will determine if the left handle
is currently selected when extruding a curve. This is the case, when
extruding a curve from the beginning. Then, the left handle will be
moved independently, instead of the right handle.
Pull Request: https://projects.blender.org/blender/blender/pulls/145235
When baking to textures, bake only to selected (and active) images, as
opposed to all active images. previously the targets were all active
images in all materials. This made it very unclear which images were
baked to, as images can be active without being selected. It also made
it impossible to *not* bake to any image in a material since there is
always an active image as long as an image texture node exists. This
often lead to accidentally overwriting images of existing PBR materials.
Baking only to selected images fixes the workflow where you have a model
with multiple materials where you only want to bake some of them. For
example a model with a PBR material for the roof and a procedural bricks
material for the walls. On export you want to bake the procedural
bricks, but not the PBR roof.
This is an API breaking change.
Pull Request: https://projects.blender.org/blender/blender/pulls/137389
This PR adds code for setting the Quality of Service (QoS) level of the
process on Windows. This can, e.g., make sure that on hybrid systems
P-cores are utilized even when the app window is out of focus.
In the following cases, it is adjusted from the default behavior:
- In wm_jobs.cc the QoS level is raised while a priority job is running.
- The command line option `--qos [high|eco|default]` can be used to
change the QoS level of the process.
- By default, the QoS level is raised for the EEVEE performance tests,
as they check viewport rendering performance and would otherwise be
reliant on never going out of focus to not get a downgraded QoS level.
By default, they are created with an out of focus window at the time
of landing this PR. This PR makes sure that they actually measure the
animation replay performance attainable during real-world use.
Pull Request: https://projects.blender.org/blender/blender/pulls/144224
Errors produces by the viewport compositor always persists even after
their cause is fixed. That's because the error message is not cleared
before execution, which this patch fixes.
Multiple previous changes made resource pools obsolete. Resource
pools were used to keep track of resources when the frame is rendered.
Multiple frames can be rendered at the same time and resources could
overlap.
This has been replaced (not this commit) to be part of the render graph
and when an submission has completed the resources are recycled.
Pull Request: https://projects.blender.org/blender/blender/pulls/145408
The material slot index check in `add_single_point_and_curve` in
`grease_pencil_pen.cc` would check if the selected material slot index
was not 0.
I think the idea was to check if there isn't any active material slot
selected, in which case
`const int material_index = this->vc.obact->actcol - 1;`
would return -1.
This PR just changes the check value from 0 to -1.
Pull Request: https://projects.blender.org/blender/blender/pulls/145473
The Clay and Clay Strips brush have a built-in hardcoded Plane Offset of
0.40m and 0.18m, respectively. This value is added to the displacement
scalar after the pressure sensitivity is factored into the calculation,
leading to the pre-bundled essential assets not responding to tablet
pressure when enabled and potentially confusing behavior otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/144382
Caused by #143974.
Allow `use_sequence_detection` and `use_placeholders` to be
automatically drawn by `sequencer_add_draw_check_fn` when applicable
instead of unconditionally adding it to the UI.
Ordering of these two can be preserved by swapping the original
`RNA_def_boolean` calls.
Pull Request: https://projects.blender.org/blender/blender/pulls/145431
This commit changes the internal storage and user-facing representation
of the brush size values (`size` and `unprojected_size`) from radius
to diameter.
This has a number of benefits:
* While the radius is more helpful for many internal operations, it is
more natural to estimate the size of a brush by the diameter
* Because the pixel size is stored as an integer, users are currently
unable to make brushes that have an odd numbered diameter, notably
preventing the ability to make single pixel brushes.
Internally, the `Brush` and `UnifiedPaintSettings` size values are
versioned to double their on-disk values. The relevant `BKE` functions
that access the data return the radius at runtime, and any internal
`struct`s that stored radius continue to do so.
The 'Radius' text for brushes is changed to 'Size' and all references
to it in descriptions are changed to 'size' as well.
Resolves#134204
Pull Request: https://projects.blender.org/blender/blender/pulls/142495
Continuing #140360
This PR moves keyframe theme properties from editors into Common.
Besides Dope Sheet, keyframe properties were in:
- Sequencer (almost all types, and might use more in the future)
- 3D Viewport, where the active object name overlay used a separate Object Keyframe color when
it had keyframes on the current frame. Now it uses the common Keyframe Selected color, instead
of having its own property just for this little text.
- Keyframes in Movie Clip Editor were hard-coded white, now they use a common Keyframe color.
Selected colors used wrong long key selected color, now they use common Keyframe Selected color.
- Movie Clip Editor also used separate colors for what it called "Strips", but they are visually
the exact same thing as "long keys" in Dope Sheet, so they use common long key colors now.
There are Keyframe Border properties in Dope Sheet, Sequencer, and NLA, but they're not shared
because they're drawn on very different backgrounds, in different sizes, with different fill colors, so
it's difficult to make one color work for all of them, and it can restrict customization and accessibility.
Video in PR
---
Details:
- Long keys in Dope Sheet/Clip Editor and Strips in NLA used the same internal "strip" attribute.
Those needed to be separated to properly use long key colors in common, without worrying
about affecting unrelated things, and those two are as unrelated as they can get.
To properly separate them I added new "long_key" attributes, and corresponding
`TH_LONGKEY` and `TH_LONGKEY_SELECT`.
- Long keys in Movie Clip Editor had hardcoded alpha. Now they use alpha of the theme color.
Pull Request: https://projects.blender.org/blender/blender/pulls/144259
This commit changes the face_ptex_offset from a manually managed int
array to a blender::Array. This required a number of changes:
* The `Subdiv` struct is no longer trivial, so MEM_new and MEM_delete
need to be used
* The Draw module API has an overloaded set of `origindex_buffer`
methods created to take in a Span instead of an int pointer and size
Pull Request: https://projects.blender.org/blender/blender/pulls/141702
In RNA access code, when trying to 'decode' a given property into valid
data, if the existing storage IDProperty for a runtime-defined RNA
property was detected as invalid (e.g. wrong dimensions for an
array...), code was trying to remove that property from the user-defined
IDProperties (custom properties) instead of the system ones.
Mistake from the original IDProperty split commit (7276b2009a).
Don't init duplis if `dupli_list` is empty.
Otherwise, the `data->dupli_parent` "leaks" into the next objects.
This also asserts that dupli iteration properties are set to default
values when calling `deg_iterator_duplis_init`.
Pull Request: https://projects.blender.org/blender/blender/pulls/145407
Currently, sequencer structs contain several pointers to data within
other structs. These pointers need to be remapped as the structs are
reallocated when reading from blend files. That has worked so far
because the pointers are exactly the values from the Blender session
that saved the file. With the implementation of #127706, the pointers
in the file aren't "real" anymore, and we can't offset them to get the
struct that contained the data. I'm working on the pointer stability
solution now to address a memfile undo performance regression
in 5.0 due to the `AttributeStorage` read/write design.
This commit replaces these 4 mid-struct pointers to point to the
containing strips instead, and uses some trivial logic to access the
fallback root sequence channels and strips. This makes the pointer
remapping on file load possible again.
This change is backward compatible but not forward compatible.
Second try after #144626
Pull Request: https://projects.blender.org/blender/blender/pulls/144878
When copying grease pencil strokes, `BKE_object_material_get()` was used
to retrieve the material ID, but the index starts at 1 instead of 0,
this caused the pasted material to be wrong. Now the index is properly
incremented to 1 when copying.
Pull Request: https://projects.blender.org/blender/blender/pulls/145398
The pose library registered a double-click keymap item for the file
browser keymap, because that was the only way to add keymap items to the
asset browser (which is just the file browser under the hood). Since
450f428434, the pose library apply & blend operators are available in
more contexts, since their check for an active asset was moved from the
operator poll to the operator execution. So the pose apply operator
would end up triggering.
The poll function could be adjusted somehow to return false in this
case, e.g. by checking if it's executed from a file browser (not an
asset browser).
However, the operator should be independent of where it's called from.
So instead this registers a separate keymap for the asset browser, so
the pose library operators can be registered exclusively for the asset
browser.
