When exporting animation (one .obj file per animation frame), the old
Python OBJ exporter used to emit frame number with leading zeros, e.g.
"000012" which made sorting files by frame easier. The new C++ OBJ
exporter does not do that.
Fix that by reintroducing leading zeros. However, use 4 digits
("0012") since that matches 4 digits used in many other places, and
also it's very unlikely that someone would export more than several
thousand frames into OBJ. If that happens, it all works correctly
anyway, just without leading zeroes.
Fixes#116520
- OIDN doesn't need to be build for debug builds on windows, while
it's mostly C++ code its public API is C
- Python was not found by the HIP build
- Level Zero was downloaded during the build.
This builds on top of f824476bd5 to show
panels in the geometry nodes modifier. It also changes the two existing panels
to use the new layout panels.
The open-close state of the panels is stored in the modifier itself. It contains a
mapping from panel id to the corresponding state flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/116472
Both inside/outside was hiding verts that are within `isect_point_planes_v3`.
For VisArea::Outside, verts outside the box should be hidden (same for
"show").
Pull Request: https://projects.blender.org/blender/blender/pulls/116412
This modify the GBuffer layout to store less bits per closures.
This allows packing all closures into 64 bits or 96 bits.
In turn, this reduces the amount of data stored for most
usual materials.
Moreover, this contain some groundwork for the getting rid of the
hard-coded closure type. But evaluation shaders still use
the hard-coded types.
This adds tests for checking packing and unpacking of the gbuffer
doesn't loose any data.
Related to #115966
Pull Request: https://projects.blender.org/blender/blender/pulls/116476
GPU module assumes that image and textures uses different bind
namespaces. In Vulkan this isn't the case, leading that some shaders
generate incorrect bind types, when the state has bindings that are not
used by the shader, but would conflict due to namespace differences.
This PR will only return the binding when after validating it is from
the expected namespace. This removes several validation warnings.
This was done in order to debug EEVEE using modern toolsets. These
toolsets don't support OpenGL and we use Vulkan as a workaround if
possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/116465
This adds support for so called "layout panels" which are panels that are created as part
of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI.
The initial use case for this are panels in the geometry nodes modifier. This patch provides
a better solution compared to what was attempted in #108565.
### Problems with Existing Approaches
Currently, there are two ways to create these expandable sections:
* One can define a new `Panel` type for each expandable section and use the `parent_id`
to make this a subpanel of another panel. This has a few problems:
* `uiLayout` drawing code is more scattered, because one can't just use a single function
that creates the layout for an entire panel including its subpanels.
* It does not work so well for dynamic amounts of panels (e.g. like what we need for
the geometry nodes modifier to organize the inputs).
* Typically, Blender uses a immediate-ui approach, but subpanels break that currently
and need extra handling.
* The order of panels is not very explicit.
* One can't interleave subpanels and other ui elements, subpanels always come at the
end of the parent panel.
* Custom solution using existing `uiLayout`. This is done in the material properties. It
also has a few problems:
* Custom solutions tend to work slightly different in different places. So the UI is less unified.
* Can't drag open/close multiple panels.
* The background color for subpanels does not change.
### Solution
A possible solution to all of these problems is to add support for panels to `uiLayout` directly:
```cpp
/* Add elements before subpanel. */
if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) {
/* Add elements in subpanel, but only of the panel is open. */
}
/* Add elements after subpanel. */
```
Integrating subpanels with `uiLayout` has some benefits:
* Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate.
* It becomes trivial to have a dynamic number of potentially nested subpanels.
* Resolves all mentioned problems of custom subpanel solutions.
### Open/Close State
The most tricky thing is to decide where to store the open/close state. Ideally, it should
be stored in the `region` because then the same layout panel can be opened and closed
in every region independently. Unfortunately, storing the state in the region is fairly
complex in some cases.
For example, for modifier subpanels the region would have to store an open/close state
for each panel in each modifier in each object. So a map with
`object pointer + modifier id + panel id` as key would be required. Obviously, this map
could become quite big. Also storing that many ID pointers in UI data is not great and
we don't even have stable modifier ids yet. There also isn't an obvious way for how to
clear unused elements from the map which could become necessary when it becomes big.
In practice, it's rare that the same modifier list is shown in two editors. So the benefit of
storing the open/close state in the region is negligible. Therefor, a much simpler solution
is possible: the open/close state can be stored in the modifier directly. This is actually
how it was implemented before already (see `ui_expand_flag`).
The implementation of layout panels in this patch is *agnostic* to how the open/close
state is stored exactly, as long as it can be referenced as a boolean rna property. This
allows us to store the state in the modifier directly but also allows us to store the state
in the region for other layout panels in the future. We could consider adding an API that
makes it easy to store the state in the region for cases where the key is simpler.
For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`.
### Python API (not included)
Adding a Python API is fairly straight forward. However, it is **not** included in this patch
so that we can mature the internal API a bit more if necessary, before addon developers
start to depend on it. It would probably work like so:
```python
if panel := layout.panel("Mesh Settings", ...):
# Add layout elements in the panel if it's open.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113584
`PyArg_ParseTupleAndKeywords` does not initialize variable corresponding
to optional arguments that aren't passed by Python. Thanks to Germano for
initial investigation.
`Move to collection` popup shows collections of active armature. So when
bone of "non-active" armature is selected, crash will be triggered after
assigning it a bone-collection of active armature.
To fix the crash, remove multi-object editing code since it's only
possible to operate on active armature/object
Pull Request: https://projects.blender.org/blender/blender/pulls/116328
The Metal and Vulkan backend checks if the vertex shader uses
`gl_PointSize` in order to set the correct parameters for point
rendering. The `eevee_deferred_tile_compact` shader uses point
rendering, but is only used as dummy geometry. The vertex
shader ignored the incoming input data, but didn't set the
`gl_PointSize` which generated incorrect shader pipelines.
It was detected on Vulkan, but Metal uses a similar workaround.
Pull Request: https://projects.blender.org/blender/blender/pulls/116463
By setting the RNA property flag `PROP_EDITABLE` on `armature.collections`,
the UIList understands that it's editable and will show "Double click to
rename" in the tooltip.
Note that this does not make the array itself editable; assignment like
`collections[0] = collections[1]` will still be refused.
Mistake in 89e3ba4e25 and 451c054d9b. Though I'm not
exactly sure why, it looks like the result layer needs to be filled with
"default" values before the transfer.
The return value of `get_rotation_mode_path` was stored in a
`blender::StringRef` which caused the memory of the string to
be freed to early.
Fix by returning a `blender::StringRef`
Interestingly this seems to be only an issue on ASAN builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/116434
Blender crashes when changing the source of the image node to Generated
then to something else, then making any changes to the image. This is
just due to a nullptr GPU texture.
This is because Blender resets the path of the image when changed to
Generated source.
When slipping meta strip, effect position was not updated. These updates
are limited to VSE core code, so function `SEQ_time_slip_strip()` was
added to resolve this issue.
This also simplifies operator code, so it does not have to deal with
recursion and doesn't need to hold quite detailed strip state for when
operator is cancelled.
Pull Request: https://projects.blender.org/blender/blender/pulls/113200
No functional changes.
Split off from: #116189
Extract code to build the keying set menu from
`ANIM_keying_sets_enum_itemf`
to be able to later use the same code from a different menu
function so the label can be changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116332
Editability checks shouldn't just check for linked data & library
overrides, but also for the type of library override. A "system
override" should still not be editable by users.
This fixes#115310: Bone collections can be added to system-overridden
(i.e. non-user-editable) armatures
