This implements a von-Kries-style chromatic adaption using the Bradford matrix.
The adaption is performed in scene linear space in the OCIO GLSL shader, with
the matrix being computed on the host.
The parameters specify the white point of the input, which is to be mapped to
the white point of the scene linear space. The main parameter is temperature,
specified in Kelvin, which defines the blackbody spectrum that is used as the
input white point. Additionally, a tint parameter can be used to shift the
white point away from pure blackbody spectra (e.g. to match a D illuminant).
The defaults are set to match D65 so there is no immediate color shift when
enabling the option. Tint = 10 is needed since the D-series illuminants aren't
perfect blackbody emitters.
As an alternative to manually specifying the values, there's also a color
picker. When a color is selected, temperature and tint are set such that this
color ends up being balanced to white.
This only works if the color is close enough to a blackbody emitter -
specifically, for tint values within +-150. Beyond this, there can be ambiguity
in the representation.
Currently, in this case, the input is just ignored and temperature/tint aren't
changed. Ideally, we'd eventually give UI feedback for this.
Presets are supported, and all the CIE standard illuminants are included.
One part that I'm not quite happy with is that the tint parameter starts to
give weird results at moderate values when the temperature is low.
The reason for this can be seen here:
https://commons.wikimedia.org/wiki/File:Planckian-locus.png
Tint is moving along the isotherm lines (with the plot corresponding to +-150),
but below 4000K some of that range is outside of the gamut. Not much can
be done there, other than possibly clipping those values...
Adding support for this to the compositor should be quite easy and is planned
as a next step.
Pull Request: https://projects.blender.org/blender/blender/pulls/123278
The `create_liquid_geometry` still used the older attributes
API to write the velocities.
This replaces the use of `BKE_attribute_new` with
the newer attribute API.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123854
It is possible that the file does not have Grease Pencil paint
yet, leading to a crash in the BKE_paint_init().
The simple fix is to swap the order of acquiring the paint
pointer and the code which ensures that this paint exists.
This reverts commit cb76781be7, and fixes
the issues from original da05bff96c commit (missing initialization
of a pointer in copy constructor in some cases, and forgot to handle
one allocated string in the move constructor).
Many thanks to @julianeisel for finding the actual issues here.
This one was a bit more involved than the previous ones, since the
mismatch was intentional here, and happened on a non-trivial type.
It was done because the new object (managed by the `unique_ptr`) steals
the internal data of the original object. Calling `MEM_delete` (and
therefore the destructor of the `AssetMetaData` object) would then lead
to access-after-free and double-freeing errors.
This is addressed by adding two new 'copy' and 'move' constructors to this type.
The copy one ensures that deep-copy of internal data happens as expected, and
allows to simplify greatly the code in `BKE_asset_metadata_copy`, which
becomes a mere wrapper around it.
The move one allows `make_unique` to properly steal (and clear) the internal
data of the source object, which can then safely be deleted.
Pull Request: https://projects.blender.org/blender/blender/pulls/123693
Part of #118145.
Rewrite the application of brush hardness, filtering for 3D view clipping
and brush distance factor calculation to operate on arrays of data rather
than a single element at a time.
In the benchmark file from the task above, this improves performance by
5%, from 0.58s to 0.55s. I expect that's mainly because constant checks
have been moved out of the hot loops, avoiding function call overhead,
and because in some cases we avoid doing division for every element.
Pull Request: https://projects.blender.org/blender/blender/pulls/123671
The function `CurvesGeometry::offsets()` would return a span pointing to
`nullptr` with a size of `1` if there were no curves in the geometry.
This was already changed for `offsets_for_write()` in
c3365666e5, which retuns an empty span.
Do the same for `offsets()` now.
Pull Request: https://projects.blender.org/blender/blender/pulls/123772
Provide a convenient way to access a writable directory for extensions.
This will typically be accessed via:
bpy.utils.extension_path_user(__package__, create=True)
This API is provided as some extensions on extensions.blender.org
are writing into the extensions own directory which is error prone:
- The extensions own directory is removed when upgrading.
- Users may not have write access to the extensions directory,
especially with "System" repositories which may be on shared network
drives for example.
These directories are only removed when:
- Uninstalling the extension.
- Removing the repository and its files.
When removing a repository & files a valid module name was assumed.
While this should always be the case, add an additional check so in
the unlikely event of memory/file corruption (especially `..`)
recursively removing files outside the repository is never allowed.
The value was set and transfered to `MeshBatchCache`but never
actually used. Even then, this is clearly not a good solution to the
problem the comments mentioned. If that happens if would be
better to solve it in a different way.
Addresses #121240.
Instead of allocating a new array and recalculating mesh triangulation
every time the user enters sculpt mode, reuse the mesh's existing cache.
Currently in order to avoid recalculating triangulation on every brush update
(which would typically be necessary because the triangulation direction
depends on vertex positions), add a mechanism to "freeze" the cache to
skip recalculations until the user exits sculpt mode. That even avoids
recalculation if vertex positions aren't affected. This is necessary because
we can't use the cache in a dirty state; tagging the cache dirty frees the
triangulation array.
Removing the duplicate triangles array reduces memory usage by 384 MB
in a 16 million vertex sculpt, and makes entering sculpt mode 125ms faster
(tested on a Ryzen 7840u).
In the long term, I hope we find a different solution that's a bit more
transparent and hopefully more integrated with the caching system
in general. In the meantime, this is a relatively safe low impact change
that helps document the needs for such a system anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/123638
Some tests would access system paths somehow, which implicitely creates
the static `m_systemPaths` variable, but would not explicitely call
`GHOST_DisposeSystemPaths` at the end to release it.
Noticeable when disabling the `WITH_TESTS_SINGLE_BINARY` option.
This updates the settings in `BKE_gpencil_brush_preset_set`
to better match the behavior of the brushes in GPv2.
Changes:
* Use a default spacing of 100%. Only the airbrush and the rough pencil need a lower spacing (higher density).
* Use the pen pressure setting for the radius.
* Update the `draw_angle_factor` for the marker chisel.
In some cases, sculpt code currently creates undo steps that are stored
in `step_init` in the undo stack, but then skips actually pushing them.
That can happen when an operator is cancelled (like the transform
operator in #123172) or because pushes in "nested operator calls"
are currently explicitly disabled. That happens when calling the brush
operator from a script.
It turns out the undo code never freed the `step_init`, probably because
it assumed it would be pushed to be part of the stack afterwards.
Personally I'm not convinced that separating undo step creation into
two stages with `step_encode_init` and `step_encode` is a great design
or a necessary one, but I'm trying not to get into that deeper right now.
Fixes#123172
Pull Request: https://projects.blender.org/blender/blender/pulls/123331
Calling `MEM_freeN` on data allocated with `MEM_new` is bad, since it
will not call a destructor matching the one invoked as part of
`MEM_new`.
While in practice cases fixed below were 'not a problem' currently, as
they are trivial Cpp types (and therefore their destructor is doing
nothing), `MEM_freeN` has no way to ensure it is dealing with such a
trivial data type, so allowing such mismatch is dirty and dangerous.
Note that almost all fixed cases look more like unintentional mistakes
(mis-usages of `MEM_new` instead of `MEM_cnew`).
NOTE: There is one more (known!) case in the asset code, which fix is
slightly less trivial, and will go through a separate PR.
NOTE: This is a by-product of some work to detect such invalid usages of
`MEM_freeN` on memory chunks allocated with `MEM_new`.
Pull Request: https://projects.blender.org/blender/blender/pulls/123691
If a non-instanced collection is linked, any collection exporters on the
linked collection would be active and invokable. This is probably not
desired as it could inadvertently overwrite files from the original.
Disable the operators in this case.
See PR for how each of the various append/link scenarios behave.
Pull Request: https://projects.blender.org/blender/blender/pulls/123149
This is an alternative fix to #123524.
This is necessary, because `sculpt_update_object` is run after
the mesh is evaluated, but before the geometry depsgraph operation
is done. Only after this depsgraph node is done, `DEG_object_geometry_is_evaluated`
will return true.
This approach of `unchecked` methods has been preferred for now
over moving the call to `BKE_sculpt_update_object_after_eval`
to a separate depsgraph node or after depsgraph evaluation.
Blender would crash if it tried to convert a grease pencil
data-block with strokes that used the editcurve.
This was because of a wrong assertion that assumed
to work with a poly curve.
The fix moves the assertion to the correct place where
we handle the poly curves.
While the evaluated result is not well defined, we expect Blender to not crash
when there are dependency cycles.
The evaluation of one object often takes the evaluated geometry of another
object into account. This works fine if the other object is already fully
evaluated. However, if there is a dependency cycle, the other object may not be
evaluated already. Currently, we have no way to check for this and were mostly
just relying on luck that the other objects geometry is in some valid state
(even if it's not the fully evaluated geometry).
This patch adds the ability to explicitly check if an objects geometry is fully
evaluated already, so that it can be accessed by other objects. If there are not
dependency cycles, this should always be true. If not, it may be false
sometimes, and in this case the other objects geometry should be ignored. The
same also applies to the object transforms and the geometry of a collection.
For that, new functions are added in `DEG_depsgraph_query.hh`. Those should be
used whenever accessing another objects or collections object during depsgraph
evaluation. More similar functions may be added in the future.
```
bool DEG_object_geometry_is_evaluated(const Object &object);
bool DEG_object_transform_is_evaluated(const Object &object);
bool DEG_collection_geometry_is_evaluated(const Collection &collection);
```
To determine if the these components are fully evaluated, a reference to the
corresponding depsgraph is needed. A possible solution to that is to pass the
depsgraph through the call stack to these functions. While possible, there are a
couple of annoyances. For one, the parameter would need to be added in many new
places. I don't have an exact number, but it's like 50 or so. Another
complication is that under some circumstances, multiple depsgraphs may have to
be passed around, for example when evaluating node tools (also see
`GeoNodesOperatorDepsgraphs`).
To simplify the patch and other code in the future, a different route is taken
where the depsgraph pointer is added to `ID_Runtime`, making it readily
accessible similar to the `ID.orig_id`. The depsgraph pointer is set in the same
place where the `orig_id` is set.
As a nice side benefit, this also improves the situation in simple cases like
having two cubes with a boolean modifier and they union each other.
Pull Request: https://projects.blender.org/blender/blender/pulls/123444
Store library filepath so we can find the right datablock.
Tested to work with the brush assets project branch, as this
currently does not affect anything in main.
Pull Request: https://projects.blender.org/blender/blender/pulls/123449
