This resolves two issues:
1. On macOS the GPU Compute device would be disabled by default unless
the user opens user preferences. This is unexpected behaviour ever
since 09ba1486f8224
2. Fixes incorrect automatic denoiser display settings and errors in
terminal related to the denoising UI on macOS if the user hasn't opened
user preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/123911
Fixes an issue where Blender would crash if the OptiX denoiser was
selected, but an unsupported GPU device (E.g. Intel GPU) was
selected in preferences.
This crash would occur because Cycles uses the device in preferences
to setup the denoiser, and there was no check stopping an unsupported
GPU from being used to try and setup and run the denoiser.
Pull Request: https://projects.blender.org/blender/blender/pulls/124001
The root cause was some code that tries to omit keying loc, rot, or
scale based on the current transform mode and pivot type. The idea is
sound, but for it to work properly it also needs to know if more than
one object is being transformed or not. Notably, this bug affected the
scale transform mode as well, not just the rotation transform mode as
reported in #123961.
This fixes the issue by passing a flag down that informs that code
whether more than one object is being transformed, and using that flag
to correctly omit loc/rot/scale when possible.
PR #123998
Pull Request: https://projects.blender.org/blender/blender/pulls/123998
Among other things, this enables using various methods on a collection
of `RNAPath`s (e.g. `Vector<RNAPath>`) that depend on the equality
operator being implemented.
The specific implementation and semantics used are based on a review
from and discussion with Bastien Montagne (mont29).
PR #123998
Changes the the extension repositories in the preferences while
update notifications were running could raise an exception.
Resolve by only calculating outdated extensions for
repositories that still exist.
When performing framebuffer transition on legacy opengl platforms, some
state was uninitialized. Resulting in incorrect behavior and crashes.
Note that this doens't fix the black cube on legacy platforms. With this PR we
might be able to reproduce the issue on modern HW.
Pull Request: https://projects.blender.org/blender/blender/pulls/123989
When a registered class has a non-registered superclass,
rna_info.BuildRNAInfo entered an eternal loop.
The while loop in `rna_info.get_py_class_from_rna` was not mutating the
variables within the loop nor the variable in its condition, meaning it
would loop infinitely if the loop didn't exit in its first iteration.
When yielding registered classes in `subclasses_recurse`, the function
was erroneously checking if the class' superclass was registered rather
than checking the class itself, causing registered classes to be skipped
if their superclass was not also registered. If the class to be found
was skipped, the while loop would not exit in its first iteration and
would thus loop infinitely.
The while loop has been modified to iterate through each base rna type
until there is no further base type.
The `subclasses_recurse` function now correctly checks whether the
subclass is registered, not its superclass, when determining if the
subclass should be yielded.
Besides the fix, no functional changes are expected, the generated
Python API docs remain unchanged.
Ref: !108256
Previously add-ons were sorted by category & name, remove the category
only sorting by name since the category is no longer displayed and
isn't part of extension meta-data. Now the add-ons are sorted by name
(case insensitive).
Details:
- Store add-ons modules sorted to avoid having to sort on every redraw.
- addon_utils.modules() now returns an iterator.
In `ui_popup_block_position` popup blocks are scaled with the owner
button region scale which wasn't being done for layout panel bounds.
This applies the scale applied to the popup block to layout panels
bodies and headers.
Also when calculating layout-panels headers and bodies the offset
`layout_panel_y_offset` is applied in place, this because this value
can also be affected by this scale.
This solves the original issue described in #122411 and reverts the
regression #123807.
Ref !123980
- Skip leading slash from drive letters.
- Use back-slashes.
While these weren't exactly bugs, it seemed like an error when the
path name wasn't what users would expect. Relates to #123994.
If a freeze-frame retiming key was added to either a transition or
freeze-frame segment when the strip was selected, Blender would crash.
The issue is that `SEQ_retiming_add_key` returns `nullptr` if the start
key of the current segment is one of these types, and never bothers to
cancel the operation if this happens.
Instead, it only attempts to get a key at the current frame with
`SEQ_retiming_key_get_by_timeline_frame`. This is redundant, since there
are already checks to see if that key exists in `SEQ_retiming_add_key`.
Remove this code and move up the other `nullptr` check to fix the bug.
Pull Request: https://projects.blender.org/blender/blender/pulls/123981
Currently, many retiming operators are able to operate on all selected
strips. However, if strips that do not support retiming are selected
(e.g. color strips), attempting to perform these operations will crash
Blender. The operators are only polled away if the active strip does
not support retiming -- this is not resilient enough.
This patch fixes the issue by checking each strip to make sure it
supports retiming. Some of the operators do not necessarily crash
without this fix (`retiming_show`, `retiming_key_add`), but still benefit
from exiting early if the current strip does not permit the functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/123975
Every retiming operator works on selected strips. However, the reset
retiming operator only works on the active strip.
This patch standardizes the behavior so that all selected strips have
their retiming reset. This gives more control to the user to reset
many strips' retiming in bulk.
Pull Request: https://projects.blender.org/blender/blender/pulls/123973
Caused by incorrect output of `SEQ_give_frame_index` for effect strips.
Also since output value is float, it has to be truncated to integer,
when image bufferes are rendered for the effect.
Pull Request: https://projects.blender.org/blender/blender/pulls/123914
The sample distribution was biased toward 0, which
created sharper details than expected.
However the downside is that the subsurface is now
more jittery because of the low amount of samples.
The "repository" in links from the generated HTML was only valid when
the URL did not contain a path component.
Resolve by supporting relative "repository".
This simplifies referencing the JSON from a generated HTML since
a relative link doesn't need to know the repositories absolute URL
to the destination.
This was caused by the light culling system not
allocating enough tiles to cover the sphere lightprobe
render target.
Taking the max size between the lightprobe target and
the film fixes the issue.
Fixes#117444
The function direction_to_fisheye_lens_polynomial computes the inverse of
fisheye_lens_polynomial_to_direction.
Previously the function worked almost correctly if all parameters except k_0
and k_1 were zero (in that case it was correct except for flipping the x-axis).
I replaced the fixed-point iteration (?) by Newton's method and implemented a
test to make sure it works correctly with a wider range of parameter sets.
Pull Request: https://projects.blender.org/blender/blender/pulls/123737
Blender doesn't render the scene even though a Cryptomatte node exists.
That's because Blender only considers Render Layer nodes, but
Cryptomatte node can reference scenes as well. This patch fixes that by
putting Cryptomatte nodes into consideration.
Pull Request: https://projects.blender.org/blender/blender/pulls/123814
Extensions with a manifest that can't be parsed caused can exception
in the add-ons UI.
Account for errors loading the manifest, falling back to dummy values
& show a warning that the exceptions manifest could not be parsed.
Changes to an extensions manifest weren't accounted for.
This was particularly a problem for "System" extensions which aren't
intended to be managed inside Blender however the problem existed for
any changes made outside of Blender.
Now enabled extensions are checked on startup to ensure:
- They are compatible with Blender.
- The Python wheels are synchronized.
Resolves#123645.
Details:
- Any extension incompatibilities prevent the add-on being enabled
with a message printing the reason for it being disabled.
- Incompatible add-ons are kept enabled in the preferences to avoid
loosing their own preferences and allow for an upgrade to restore
compatibility.
- To avoid slowing down Blender's startup:
- Checks are skipped when no extensions are enabled
(as is the case for `--factory-startup` & running tests).
- Compatibility data is cached so in common case,
the cache is loaded and all enabled extensions `stat` their
manifests to detect changes without having to parse them.
- The cache is re-generated if any extensions change or the
Blender/Python version changes.
- Compatibility data is updated:
- On startup (when needed).
- On an explicit "Refresh Local"
(mainly for developers who may edit the manifest).
- When refreshing extensions after install/uninstall etc.
since an incompatible extensions may become compatible
after an update.
- When reloading preferences.
- Additional info is shown when the `--debug-python` is enabled,
if there are ever issues with the extension compatibility cache
generation not working as expected.
- The behavior for Python wheels has changed so they are only setup
when the extension is enabled. This was done to simplify startup
checks and has the benefit that an installed but disabled extension
never runs code - as the ability to install wheels means it could
have been imported from other scripts. It also means users can disable
an extension to avoid wheel version conflicts.
This does add the complication however that enabling add-on which is
an extension must first ensure it's wheels are setup.
See `addon_utils.extensions_refresh(..)`.
See code-comments for further details.
This was caused by the denoiser of the slight out of focus
pass having too much influence at low CoC values.
Making the transition start at 0.5 fixes the issue.
Fixes#123822
This happened in scenes with high light count and
with some local light being culled.
The culled lights indices would still be processed
and load undefined data. This undefined data
might be interpreted as a sunlight and go into
the cascade setup loop with an undefined number
of levels.
This created loops of 1 billion iteration per thread
which triggered the TDR on windows.
The fix is to skip the culled light indices.
Fixes#123413Fixes#123190