`GVolumeGrid` and `VolumeGrid<T>` are basically pointer wrappers.
Assigning a nullptr is possible and allowed by code, but node socket
code doesn't currently check if a grid pointer is null before accessing
it.
Disallow null grid pointers in socket values. Asserts are added for this
purpose. The Points-to-SDF node checks the grid value before writing to
output.
Pull Request: https://projects.blender.org/blender/blender/pulls/122996
Fixes#116567
The issue was with a flag that skips a particular post-evaluation step
specially for the Child Of constraint. The flag wasn't getting properly
unset when the constraint target was removed, and therefore that
post-evaluation step was getting erroneously skipped in some cases.
This commit fixes the issue by always setting the flag appropriately in
the Child Of evaluation function itself. This is admittedly rather
hacky, but no more hacky than the existence of the flag in the first
place.
Pull Request: https://projects.blender.org/blender/blender/pulls/122881
This changes fixes a wrong mesh as a result of apply base mesh from the Multires modifier
In the previous code some corner vertices where incorrectly assigned to null and skipped form processing as a safety guard
that was only relevant when the mesh had hidden faces in edit mode. The hidden corner vertices bug is handled now when checking
> if (corner_x_index < 0 || corner_y_index < 0) {
> continue;
> }
Since the patch that caused this error was a fix to a previous infinite loop bug,
I also tested and made sure this updated patch still fixes the original issue it was trying to fix.
Note: This PR replaces #122845 due to a large amount of git rebase issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/122859
The attribute API defined in `attribute.cc` was dependent on
the assumption that `ID`s are always the "direct" owners of attributes.
For Grease Pencil drawings, this is not the case. The Grease Pencil ID
stores the attributes for layers, and the attributes for drawings are stored
in `CurvesGeometry` on the drawings themselves.
In order to make use of `rna_attribute.cc`, we need that API to handle
other types of attribute owners.
This adds an `AttributeOwner` which is basically just a type and a
pointer. We replace the `ID` pointers and pass `AttributeOwner`s instead.
For cases where we have to do a switch based on the type, all the
types are handled and the `default` statment is left out. This ensures
that we get a compiler warning when a new `AttributeOwnerType`
is added.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/122765
Mainly correct/update some comments (e.g. missing reference to Boolean
type), and add some notes essentially about issues with current IDProp
String code (see also #86960 ).
No functional change.
The C++ classes that wrap DNA structs should never store any data.
Runtime data needs to be stored on the runtime classes/structs
and anything else needs to be put into DNA.
This adds static asserts to make sure (at compile time) that these
classes have the same size as the DNA structs (i.e. they don't store
additional data).
This fixes a bug that happens when two drawings in the same grease pencil
data-block reference the same array. In this case, the same attribute array
pointer is written to .blend files for both drawings. However, when loading the
.blend file, it was not detected that the data is shared. Instead each drawing
would think that it was the single owner of the array even though it was shared.
The same problem can technically occur for all kinds of shared data, and not
just for grease pencil. However, only grease pencil shows this issue currently,
because it can easily happen that the same attribute is shared between different
`CustomData` within the same data-block. This very rarely happens with meshes or
curves, because different `CustomData` usually have different sizes and don't
share the same arrays.
A previous fix (cc891aa699) solved pretty much the same issues for the case
when two layers in the same `CustomData` share data. This original fix is now
generalized and is integrated with `BLO_read_shared` which makes it less error
prone. For each data-block, the `BlendDataReader` now remembers which shared
data it has loaded before so that it is not loaded again.
In the future this could be extended to support data that is shared between
data-blocks, but that's not as straight forward as one would hope currently. For
various reasons, different data-blocks could store independent data at the same
pointer. I specifically noticed that with a regression test file:
`blender/tests/data/modeling/geometry_nodes/attributes/attribute_statistics.blend`.
To support it, one solution could be to tag `BHead` in .blend files to indicate
that a specific pointer is shared and unique within the entire file. But that's
for another day.
Pull Request: https://projects.blender.org/blender/blender/pulls/122780
The buttons to upgrade or sync extensions called extension
operators via bpy.app.handlers, requiring awkward glue-code
which didn't show error reports in to the user.
Remove these operators and call the upgrade & sync operators directly.
Support for "System" extensions as an alternative to the current
"User" extensions repository.
The purpose of this change is to support bundling extensions for
offline work or in environments where users setting up thier own
extensions isn't desirable, see #122512.
Details:
The default "System" repository on Linux will for example use:
- `/usr/share/blender/4.2/extensions/{system}` For system installs.
- `./4.2/extensions/{system}` For portable installs.
- Blender's default startup now has a "System" repository
which users or administrators may populate.
- Repositories can select between User/System paths,
setting a custom path overrides overrides this setting.
- Add "BLENDER_SYSTEM_EXTENSIONS" (matching "BLENDER_LOCAL_EXTENSIONS").
Ref !122832
Update PBVH GPU argument initialization to prefer using the PBVH mesh
attributes instead of the evaluated mesh attributes for color.
The values can be out of sync due to differences with the evaluated
and original mesh data.
Pull Request: https://projects.blender.org/blender/blender/pulls/122850
Originally this would replace scripts that come bundled with Blender,
but it's unclear how this is useful.
Searching for this online mainly leads to people asking how they can
use it to add scripts. For example in a studio environment you might
want to deploy add-ons and startup scripts for all users.
Even if you wanted to use it for replacement though, it wasn't really
doing that and inconsistent for different types of scripts:
* startup: ignored
* modules: replaces bundled scripts
* presets: adds to bundled scripts
* addons (in 4.1): ignored
* addons_core (in 4.2): ignored
* startup/bl_app_templates_system: replaces bundled scripts
This change makes it add scripts from this path for all. This is a
breaking change, though arguably this feature was just broken to
begin with and not used much in practice because of that.
The alternative would be add a new set of environment variables to
avoid breaking existing behavior. But that also means keeping around the
broken behavior or fixing it in another way.
Supporting multiple paths may be used too, but for now just support
a single one as doing this for all BLENDER_SYSTEM variables is
non-trivial. The main use case for that would be add-ons anyway, and
those will mainly be handled through upcoming
BLENDER_SYSTEM_EXTENSIONS instead.
Ref #122512
Pull Request: https://projects.blender.org/blender/blender/pulls/122689
Seems to be dependent on specific compiler/cmake version.
Is a typical mixture of missing dependencies between libraries,
object files which do not get referenced from other files in the
target, and whole-archive linking of the blender_test target.
Pull Request: https://projects.blender.org/blender/blender/pulls/122801
The code for recalculating bounds was fairly tricky to understand, with a
mixture of various flags, a mixture of recursive and parallel code, and
the "original bounds" concept.
This commit separates that update code into two separate paths. The regular
bounds update is split from the resetting of original bounds, which is only
needed in a few places and is best described by a separate function call.
The bounds update itself is split clearly into a parallel update of leaf node
bounds and a recursive merging of child node bounds.
The high level goals this helps to support are:
1. Use data-oriented storage to replace PBVHNode struct.
2. Document concepts like "original bounds", provide a self-descriptive API.
3. Allow brushes to update bounds themselves, for better CPU cache use.
Pull Request: https://projects.blender.org/blender/blender/pulls/122746
There is a mechanism to store config files in the same folder as the
Blender executable. The typical use case is putting Blender on a USB
drive and taking the config with you.
However the problem is that this is using the 4.2/ folder, which is fine
for config/ but with e.g. addons, studiolights and now extensions this
is mixing user and system files. This requires exceptions, doesn't
work well in some cases and is just generally not great design.
Instead use a folder named portable/ that is separate.
Pull Request: https://projects.blender.org/blender/blender/pulls/122778
Previously, the "Simplify" option was a world space distance threshold.
This meant that zooming in and out of the view changed the way
this option behaved. There were complaints from artists about this.
This change improves two things:
* The simplify algorithm uses the screen space coordinates rather than the
3D positions.
* The UI setting is in pixels making it much easier to tweak (no need
for values in the 1e-4 range).
Pull Request: https://projects.blender.org/blender/blender/pulls/122719
In GPv2 the brush strength was it's own setting in the
`brush->gpencil_settings`. Now we just use the `brush->alpha`
like all other brushes.
Note: The versioning will be done when GPv3 becomes the default.
Pull Request: https://projects.blender.org/blender/blender/pulls/122565
The Film-like curve mapping option in the RGB Curves node in the
compositor produces bad results when editing its RGB curves. That's
because Film-like curve mapping only works with the combined curve by
definition, since it is a hue preserving mapping. Furthermore, the
Film-like option ignored the white balancing step altogether.
To fix this, we hide the current curve option for the File-like option
and only allow editing the combined curve, handing the same case for
versioning and RNA updates. Further, we port the implementation from the
realtime compositor which is both correct and takes white balancing into
account.
Pull Request: https://projects.blender.org/blender/blender/pulls/122762
