BLI code for enums that are meant to be used as "bit flags" defined
an ENUM_OPERATORS macro in BLI_utildefines.h. This cleans up things
related to said macro:
- Move it out into a separate BLI_enum_flags.hh header, instead of
"random bag of things" that is the current place,
- Update it to no longer need manual indication of highest individual
bit value. This originally was added in a31a87f89 (2020 Oct), in
order to silence some UBSan warnings that were coming
from GPU related structures (looking at current GPU code, I don't
think this is happening anymore). However, that caused actual
user-visible bugs due to incorrectly specified max. enum bit value,
and today 14% of all usages have incorrect highest individual
bit value spelled out.
- I have reviewed all usages of operator ~ and none of them are
used for directly producing a DNA-serialized value; all the
usages are for masking out other bits for which the new ~
behavior that just flips all bits is fine.
- Make the macro define flag_is_set() function to ease check of bits
that are set in C++ enum class cases; update existing cases to use
that instead of three other ways that were used.
Pull Request: https://projects.blender.org/blender/blender/pulls/148230
The issue was that the data-blocks of two different undo steps were detected to
be identical, even if the attributes changed. That's because even if the
implicitly-shared data was different, they were turned into the same pointer by
cadb3fe5c5 on write.
This patch makes it so that for undo steps, implicitly shared data does not use
the pointer stability feature (in a sense, implicit-sharing itself provides
pointer stability for undo steps already).
The main tricky aspect is that we need to know if a pointer is implicitly shared
in `writestruct_at_address_nr` and oftentimes that's called before the
corresponding shared data is actually written with `BLO_write_shared`. The
solution is to enforce that the blend-write code has to know what pointers are
implicitly-shared before they are written the first time. The simplest way to
ensure that is to call `BLO_write_shared` first. However, that's not always
possible, especially when the pointer is directly embedded in an ID. Therefore,
there is a new `BLO_write_shared_tag` function that can be used in such cases.
The undo performance for the file in #141262 is still fixed with this change.
Pull Request: https://projects.blender.org/blender/blender/pulls/148144
This speeds up drawing of the UI of the Geometry Nodes modifier, especially for
very large node trees like in the files from #146949.
A couple previous commits and #147883 speed up the inferencing significantly
already. However, there is a certain limit to how fast this can be on large
complex node trees. While there is some more optimization potential, this patch
implements a cache on the Geometry Nodes modifier level. This means that as long
as the inputs and the node tree stays the same, the inferencing only has to
happen once, instead of on every redraw.
The main difficulty with this cache is that we don't have a good way to
invalidate it eagerly when any of the modifier inputs changes. That can
hopefully become simpler with #138117. For now, we have to check all input
values on redraw to check if anything has changed compared to the last redraw
and recompute the cache if there is any change.
Pull Request: https://projects.blender.org/blender/blender/pulls/147930
- Add an explicit check with a better error message than "Out of memory"
- Initialize SDefVert so the later null checks don't try to free
uninitialized data.
Pull Request: https://projects.blender.org/blender/blender/pulls/147723
These types of buttons do not automatically extract and translate the
label when specified specifically. This commit adds the missing
translation macros.
Some issues reported by Alexandr Fatih.
Move the selection flag for pose bones, from the (edit)bone to the
pose bone.
Previously having multiple instances of armatures in pose mode at the
same time caused issues because selecting a pose bone on one armature
would automatically select it on all instances of it.
This is now fixed since the selection state is stored on the pose bone
(Object level) Doing so breaks API compatibility with 4.5 since the
RNA property on the Bone no longer affects the pose bone. Instead,
there is a new property on the pose bone for that.
Due to this change, some runtime flags for the transform system also
had to be moved to the pose bone. This is due to the fact that these
flags are used by the transform system to pass information between
functions. If we keep the flag at the bone level, this wouldn't work
with armature instances. See `bPoseChannelRuntimeFlag`
Fixes#117892
Pull Request: https://projects.blender.org/blender/blender/pulls/146102
Support sync selection in the UV editor, with face-corner selection,
so it's possible to select individual UV vertices/edges in the UV editor
without UV's attached to the same underlying edge also becoming selected.
There is limited support for maintaining the UV selection when selecting
from the 3D viewport, common operations such as picking &
box/circle/lasso select support this, however other selection operations
such as "Select Random" or "Select Similar" will clear this data,
causing all UV's connected to selected mesh elements to become selected.
We may add support for additional operators as needed.
Details:
- UV Sync Selection is now enabled by default.
- In edit-mode the UV selection is stored in BMLoop/BMFace which are
written to custom-data layers when converted to a Mesh.
- To avoid unnecessary overhead - this data is created on demand.
Operators may clear this data - selecting all or none do so,
as there is no reason to store this data for a uniform selection.
- The Python API includes functions to synchronize the selection to/from
UV's as well as flushing based on the mode.
- Python scripts that manipulate the selection will either need to clear
this synchronized state or maintain it.
See:
- Design task: #78393.
- Implementation task: #131642.
Ref !138197
Add two common building blocks for volume-grid workflows.
- **Voxelize** turns all active tiles into fully dense voxels. For fog
volumes, this will mean the "inside" sparse tiles will become
individually adjustable voxel values.
- **Prune** is the opposite action as voxelize. It can be important for
certain workflows when large regions of constant values are created.
The node can collapsed those regions into more efficient tiles or
inner nodes. There are a few modes which are each useful for
different use cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/147148
This PR makes it so that when the `delta_time` attribute does not exist
or is equal to zero, the Grease Pencil Strokes will default to one
second to be drawn.
This feature existed in the legacy modifier but was not implemented in
GPv3.
Pull Request: https://projects.blender.org/blender/blender/pulls/146950
This adds support for showing various stats of volume grids in the spreadsheet:
* Extent: Number of voxels in each direction of the bounding box of the grid.
* Voxels: Total number of active voxels in the grid. This includes all voxels
which are stored in tiles (e.g. one leaf tile contains 512 voxels).
* Leaf Voxels: Number of active voxels stored in leaf nodes. This does not
contain any voxels that are part of tiles.
* Tiles: Number of active tiles in the grid.
* Size: Estimated size of the volume grid in memory.
All these stats are cached on the volume grid now. A new `tag_tree_changed`
method has been added to invalidate the cache. Computing these stats is not
cheap (but not more than a few ms even for large grids). That mainly means that
we can't do it for socket inspection because that would cause too much overhead.
However, doing it just for the grids that are currently visible in the
spreadsheet seems fine and useful.
This also adds some general improvements to the spreadsheet:
* Support `int64_t` and `int3` columns.
* Draw ints with thousand separators.
* Support showing ints as number of bytes such as `23 MB`.
Pull Request: https://projects.blender.org/blender/blender/pulls/147191
To support setting the custom `CurveMapping` to a well defined preset,
there exist a number of operators that are hardcoded to apply a
particular preset to a particular curve.
This commit begins to replace this functionality and make it part of the
template itself, allowing the preset to be applied to any curve. For
now, it only supports either positive or negative slopes, primarily for
the brush usecases.
The `brush.curve_preset` and `brush.sculpt_curves_falloff_preset`
operators are unneeded after this change and have been removed.
Notably, these preset controls have not been added elsewhere, they can
be added on a case by case basis in future commits by interested
modules.
Pull Request: https://projects.blender.org/blender/blender/pulls/146847
* Add adaptive subdivision properties natively on the subdivision surface
modifier, so that other engines may reuse them in the future. This also
resolve issues where they would not get copied properly.
* Remove "Feature Set" option in the render properties, this was the last
experimental one.
* Add space choice between "Pixel" and "Object". The latter is new and can
be used for object space dicing that works with instances. Instead of
a pixel size an object space edge length is specified.
* Add object space subdivision test.
Ref #53901
Pull Request: https://projects.blender.org/blender/blender/pulls/146723
Often displaying the "Manage" panel is not very useful, or at least it
isn't worth taking up the screen real-estate. This commit adds an option
for showing the panel in the modifier, and adds an option to the node
group which is used to initialize the modifier option when creating a
modifier for a node group asset.
Pull Request: https://projects.blender.org/blender/blender/pulls/146775
Geometry Nodes used a `PropertiesVectorSet` in some places to allow
constant-time `IDProperty` access by name in a group. This used to be a
bottleneck in node groups with hundreds of inputs. Now this separate hash table
is not necessary anymore, because it's `IDProperty` groups now support this
directly since 6cb2226f13.
This also adds a `IDP_GetPropertyFromGroup_null` utility function to be able to
do this refactor more safely. Null pointers were allowed before.
Pull Request: https://projects.blender.org/blender/blender/pulls/146152
Addresses #145680.
In one (relatively extreme) test file with the surface deform modifier,
memory usage goes from 14 GB to 4 GB, and an annoying freeze
from preparing an undo step after every operation is gone.
Pull Request: https://projects.blender.org/blender/blender/pulls/145705
This was added for a fairly specialezed use case and is no longer being used
as far as we know. A future replacement would be to add a USD/Hydra procedural,
for which most of the groundwork already exists.
Pull Request: https://projects.blender.org/blender/blender/pulls/146021
Left for future work:
* Freestyle modifiers, dynamic paint, legacy texture mapping
* Editor colors: should be changed to sRGB?
* Studio light preferences: also sRGB, though less clear
Pull Request: https://projects.blender.org/blender/blender/pulls/145476
Functions for convert between the color types and ostream support are
now outside the classes.
Many files were changed to fix cases where direct includes for headers
were missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/145756
When line art is first developed, curves objects does not exist yet, now
it is added to line art so it will be read and take part in feature line
generation and occlusion tests.
This patch also adds "Line Art" panel for curves object, just like other
objects supported by line art.
Pull Request: https://projects.blender.org/blender/blender/pulls/145296
This commit modifies the `OBJECT_OT_multires_base_apply` operator to
take in a new parameter which determines whether the final heuristic of
adjusting for a subdivision surface modifier applies.
Resolves#124553
Pull Request: https://projects.blender.org/blender/blender/pulls/145055
This argument is always passed as null. Removing it simplifies the
transition to `AttributeStorage`. Nowadays it seems that most more
complicated interpolation needs are not handled directly by the
CustomData system.
Pull Request: https://projects.blender.org/blender/blender/pulls/145197
The main idea is to switch Bake from Multires from legacy DerivedMesh
to Subdiv. On the development side of things this change removes a lot
of code, also making it easier easier to rework CustomData and related
topics, without being pulled down by the DerivedMesh.
On the user level switch to Subdiv means:
- Much more closer handling of the multi-resolution data: the derived
mesh code was close, but not exactly the same when it comes to the
final look of mesh.
Other than less obvious cases (like old DerivedMesh approach doing
recursive subdivision instead of pushing subdivided vertices on the
limit surface) there are more obvious ones like difference in edge
creases, and non-supported vertex creases by the DerivedMesh.
- UV interpolation is done correctly now when baking to non-base level
(baking to multi-resolution level >= 1).
Previously in this case the old derived mesh interpolation was used
to interpolate face-varying data, which gives different results from
the OpenSubdiv interpolation.
- Ngon faces are properly supported now.
A possible remaining issue is the fact that getting normal from CCG
always uses smooth interpolation. Based on the code it always has been
the case, so while it is something to look into it might be considered
a separate topic to dig into.
The problem was that the `Subdivide Modifier` would not apply catmull clark
smoothing to the first and last points when a curve was cyclical.
This also fixes a mistake were the smoothing would read from the same data
as writing, leading to the shape to be skewed.
Pull Request: https://projects.blender.org/blender/blender/pulls/144529
This follows the other CMake "modernization" commits, this time for
`bf_intern_openvdb` and the OpenVDB dependency itself.
The difference with this one is that `intern/openvdb` becomes an
"optional" dependency itself. This is because downstream consumers often
want to include this dependency rather than openvdb directly, so this
target must also be optional. Optional, in this case, means the target
always exists but may be entirely empty.
Summary
- If you are using BKE APIs to access openvdb features, then use the
`bf::blenkernel` target
- If you are only using `intern/openvdb` APIs then use the
`bf::intern::optional::openvdb` target (rare)
- For all other cases, use the `bf::dependencies::optional::openvdb`
target (rare)
context: https://devtalk.blender.org/t/cmake-cleanup/30260
Pull Request: https://projects.blender.org/blender/blender/pulls/137071
Previously line art uses the same thickness value as found in grease
pencil before blender v4.3 for generating strokes, now everything is
migrated to using "radius", so it makes more sense to change that it to
using "radius" so it's consistent with everywhere else.
Pull Request: https://projects.blender.org/blender/blender/pulls/144121
Replaces the `FPS` macro with `scene->frames_per_second()`.
The macro has two major issues:
* It hides that it depends on a `Scene *` variable named `scene`.
* It makes debugging harder.
This is now replaced with a member function on the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/144127
The case when no mesh can be retrieved from the shrinkwrap target object can be
retrieved was not handled. It was handled by `ensure_shrinkwrap_cache_data` but
the calling function didn't check if the cache was actually created.
`BKE_modifier_get_evaluated_mesh_from_evaluated_object` can return null for an
object that would usually have a mesh but the object has not been evaluated yet,
as can be the case when there is a depsgraph cycle.
From my current understanding, the issue existed without 83325d1fd. Changing the
hash just made the depsgraph do different scheduling decisions so that now the
shrinkwrap was evaluated before the target object. The order in which these two
things are evaluated is arbitrary when there is a depsgraph cycle.
Pull Request: https://projects.blender.org/blender/blender/pulls/143757
The dash modifier creates final result by combining filtered/processed
and unfiltered strokes, but this result could be empty. The code assumes
valid joined geometry when it's sometimes not the case. This patch did
a null check and it worked as it should.
Pull Request: https://projects.blender.org/blender/blender/pulls/143424
