Move some of the functionality of `ANIM_armature_runtime_refresh()` into
a function of its own (`ANIM_armature_bonecoll_active_runtime_refresh()`).
It will be called from another place as well in upcoming commits.
No functional changes.
The GPU compositor incorrectly extrapolates values of RGBA curves node.
That's because the code introduces a half-pixel offset to the color
values since they will be used to sample the curve maps. Those same
values are then used for extrapolation, which shouldn't take the
half-pixel value into account.
This patch fixes that by computing sampler coordinate in a separate
step.
Pull Request: https://projects.blender.org/blender/blender/pulls/116586
Adds API to allow usage of specialization constants in shaders.
Specialization constants are dynamic runtime constants which can
be compiled into a shader pipeline state object (PSO) to improve
runtime performance by reducing shader complexity through
shader compiler constant-folding.
This API allows specialization constant values to be specified
along with a default value if no constant value has been declared.
Each GPU backend is then responsible for caching PSO permutations
against the current specialization configuration.
This patch adds support for specialization constants in the
Metal backend and provides a generalised high-level solution
which can be adopted by other graphics APIs supporting
this feature.
Authored by Apple: Michael Parkin-White
Authored by Blender: Clément Foucault (files in gpu/test folder)
Pull Request: https://projects.blender.org/blender/blender/pulls/115193
The new 2.5.x version of OIIO came with the OpenEXR Core library enabled
by default. Unfortunately it's not quite ready to be used so disable it
for now.
The current issue will prevent DWA-A/B from loading correctly. There may
also be a potential ZIPS compression related quirk that upstream is
still working through as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/116591
There are some tragic design flaws with the Microsoft STL
implementation of `std::dequeue`. Unless we implement our
own similar data structure or use an implementation from
another library, the change isn't worth it.
This reverts commit b26cd6a4b9.
This reverts commit cc11ba33d9.
This reverts commit c929d75054.
This reverts commit bd3d5a750d.
Some common headers were including this. Separating the includes
will ideally lead to better conceptual separation between CustomData
and the attribute API too. Mostly the change is adding the file to
places where it was included indirectly before. But some code is
shuffled around to hopefully better places as well.
The main goal is removing bmesh.hh from BKE_paint.hh, since that
includes it in many more files than necessary. Also remove more
includes from sculpt_intern.hh.
GSQueue dates back over 21 years, past the initial git commit. Nowadays
we generally prefer to use data structures from the C++ standard library
or our own C++ data structures. Previous commits replaced this container
with `std::queue` in a few areas. Now it is unused and can be removed.
OIIO was including imaths half.h when it did not
need to, leading to build errors in lite builds.
This issue had been fixed already upstream but
was not yet included in the version we use.
Commit 91b27ab637 reveals the error.
The Poly Build code was using the wrong mesh to access the evaluated
coordinates.
It was accessing the original mesh, which wasn't affected by modifiers
or editing.
The most ideal meshes would be either the cage or even the deform, as
these better correspond to the geometry seen by the user.
This patch unifies the behavior of the scale node by removing the arbitrary limit of scaling images. The change applies to scale and transform nodes.
Note: with this change, Blender can crash for large resizing factors (around 10 000 x 10 000 relative factors). We think it's very unlikely users will run into this issue, so we agreed errors coming from failed memory allocation won't be handled, as is the case for GPU compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/114764
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.
Sybren A. Stüvel
Clément Foucault
Omar Emara
Jason Fielder
Jesse Yurkovich
Hans Goudey
Andres Stephens
Ray Molenkamp
Germano Cavalcante
Habib Gahbiche
Aras Pranckevicius
Casey Bianco-Davis
Jeroen Bakker
Campbell Barton
Iliya Katueshenock
Jacques Lucke
Pratik Borhade
Brecht Van Lommel
Miguel Pozo