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
This fixes a kernel crash on NVidia GP100.
This splits the tilemap finalize shader into another shader
and split the valid tile gather into its own loop.
Simplifying the shader seems to avoid the issue. But the
cause of the issue remains unknown.
Pull Request: https://projects.blender.org/blender/blender/pulls/123850
When preview is downscaled and transformation origin is not the center
of the image, this causes unexpected offset. This happened, because one
matrix combined image downscaling, so it fits into preview and user
defined scale. When origin was not center of the image, this results in
incorrect offset.
Solved by splitting 1 matrix in `sequencer_image_crop_transform_matrix`
into 2 matrices. First matrix just centers and scales image to expected
size. Second matrix performs rest of transform operations. This code is
bit easier to read as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/123776
Delete operator was shared for strips and retiming keys, which was not
ideal. Operator logic relied on invoke function setting proper context
which was also hidden from users.
Split these operators and make dedicated operators for removing retiming
keys - `SEQUENCER_OT_retiming_key_delete`.
This operator returns `OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH` if
executed in non-retiming context, or no key is selected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123767
Caused by floating point error in `BLI_rctf_transform_pt_v()`
The error is not fixed, but intead of recalculating each strip offset
with this function, only offset for {0, 0} is calculated and added to
easch strip.
Pull Request: https://projects.blender.org/blender/blender/pulls/123825
The code which is responsible for applying data from coordinate grids to
displacement grids could be run as part of modifier evaluation, hence
using the safe version of accessing mesh data was returning a nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/123907
The GPU compositor frees some of the cached resources when it gets
canceled during interactive editing, making the experience less smooth.
This is because when the compositor gets canceled mid-evaluation, some
of the operations won't get the chance to mark their used resources as
still in use.
To fix this, we skip the cache manager reset after canceling,
effectively only resetting when a full evaluation happens, giving all
operations the chance to keep their cached resources.
Pull Request: https://projects.blender.org/blender/blender/pulls/123886
Linked images that share the same name as an image in the file will fail
to load in the GPU compositor. That's because cached resources are keyed
using only their ID name, while they should also be keyed by the library
name.
Pull Request: https://projects.blender.org/blender/blender/pulls/123898
This was the case when the slot index in the active object is greater
than the available slots of other selected objects.
Code was trying to avoid searching all materials by using
`BKE_object_material_get` to get an appropriate index (an addition to
D4441 added in 6b39dc7672). That function has the behavior of clamping
if a target index is greater than the available slots (for good
reasons), so we cant rely on the slot index being the same if
`BKE_object_material_get` finds a material. So in essence, this is not
what we want to use in this case.
Now use the much simpler `BKE_object_material_index_get` to get the
index [this might be less performant in certain scenarios, dont think
this is critical though and correctness should beat performance here]
Pull Request: https://projects.blender.org/blender/blender/pulls/123718
Instead of having the Rigify meta-rigs directly in the 'Add → Armature`
menu, move them into 'Add → Armature → Rigify Meta-Rigs`.
This also removes the " (Meta-Rig)" suffix from every individual
meta-rig menu item.
This serves multiple purposes:
- It's now clear that these meta-rigs come from Rigify.
- The built-in 'Single Bone' armature now has similar visual weight as
the 'Rigify Meta-Rigs' menu item.
- Opens up the menu in a fairer way to other add-ons, to add their own
entries in a similar way.
Pull Request: https://projects.blender.org/blender/blender/pulls/123833
Run `make format` to reformat the Rigify code. It now adheres to the
global Blender code style standard, rather than having its own style.
Most of the changes are simply adding spaces around operators, newlines
below docstrings, and changing some indentation.
Note that this does not reformat any stored-as-multiline-strings code
blocks.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123833
The fix is to set local-space Limit Rotation constraints to use the
legacy behavior from pre-4.2. The legacy behavior isn't meaningful/
useful for other spaces, so we leave those constraints alone.
This is one part of a two-part fix for blender/blender#123105. The other part
is blender/blender#123361, which adds the Legacy Behavior option to the Limit
Rotation constraint.
Reviewed-on: https://projects.blender.org/extensions/rigify/pulls/4
Reviewed-by: Sybren A. Stüvel <sybren@blender.org>
