Show "Loading..." now when file list loading is unfinished, but no item is
visible yet.
Would show "No items" earlier which is misleading, because the file
loading job may simply not have started yet, or found no relevant files
yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/123029
Having the sun extracted is mandatory to keep
the same look and avoid too much light
leaking compared to EEVEE-Legacy. But adding
shadows might create performance overhead and
change the result in a very different way.
So we disable shadows in older file.
The UI Module has decided that popup tooltips should never be scaled
with local 2D region zooming. Instead they should only follow the
global resolution scale. This PR just removes tooltip aspect to do so.
Pull Request: https://projects.blender.org/blender/blender/pulls/122854
Wasn't exactly clear what this was doing before, and the logic using it
requires a bit of brain gymnastics to follow (with negations, nested
if's and continue's).
This should not happen and any failure here should be considered a bug.
But for end users better not to hang Blender, and to have a better
diagnostic for developers in bug reports.
Ref #82483
Pull Request: https://projects.blender.org/blender/blender/pulls/123023
CTX_data_ensure_evaluated_depsgraph should not be used in drawing code.
This triggered a depsgraph updated which in turn called
DRW_notify_view_update. This would bind the GPU context a second time
and hang due to recursive mutex calls.
Issue wasn't directly related to material assets or the shader editor.
Simpler steps to reproduce:
- Open Asset Browser
- Change Asset Browser to different editor type
- Open new file (Ctrl+N)
The asset browser would remain in storage as inactive editor, including
pointers to the asset system. When opening a new file, the asset system
would get freed before the asset browser, which would then access
dangling pointers as part of its own freeing process.
Part of the issue is that `SpaceType.exit()` doesn't get called in this
case, which would remove the asset system references before the asset
system is freed. Will address this in a follow up in main, but best to
not depend on the `exit()` callback too much. Easy to do here.
The resulting .pyd files for a debug build had wrong filenames.
MaterialX and OpenImageio used incorrect soabi tags, while usd
had a double _d_d postfix.
These changes should not affect linux+mac
Light linking was never working correctly in volume segment with light
tree, because `sd->object` was not assigned, thus
`light_link_receiver_nee(kg, sd)` always returned `OBJECT_NONE`, causing
the light tree sample to fail. This problem was revealed by fdc2962beb
since now the same light is used for volume segment and volume.
Also ensure we don't sample position on the light if sampling from
volume segment is failed, by setting `emitter_id` to `EMITTER_NONE` in
such cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/122999
Legacy Actions can become a layered Action, simply by removing all the
legacy FCurves and adding a layer or binding. This means that
`Action::idroot` can be non-zero, while it should be zero for layered
Actions. This is now enforced in `Action::layer_add()` and
`Action::binding_add()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/123004
Add the color for the new keytype 'generated' to the VSE theme settings
as well.
This includes the versioning code that loads the default from the scene.
Without this, the preference would be initialised to black.
Note that the 'Blender Light' theme does not have any colors for any of
the key types, so I also didn't add the 'generated' type there.
Pull Request: https://projects.blender.org/blender/blender/pulls/123005
The Action selector (in the Action editor) now lists all layered
Actions. Legacy Actions are limited to specific ID types (via their
`idroot` property), whereas layered Actions are not (it's their Bindings
that are limited in this way, not the Actions themselves).
Pull Request: https://projects.blender.org/blender/blender/pulls/123003
Add (partially disabled) systematic tests that for all IDProp types, the
returned value from direct idprop subscription and RNA-based
`path_resolve` return the same data.
NOTE: This does not work currently for 'composite' types (`IDP_ARRAY` and
`IDP_GROUP`).
The following code in py console would return a python string object,
instead of the expected bytes one.
```python
value = b"Hello World"
key = "a"
C.object[key] = value
C.object[key]
>>> b"Hello World"
C.object.path_resolve('["%s"]' % key)
>>> "Hello World"
```
Now it will return a byte object as it should.
Found while investigating #122843 .
