Two commits that basically do the same thing for two `enum`s: give
them a name.
- the `IDWALK_…` enum → `LibraryForeachIDFlag`.
- the `IDWALK_CB_…` enum → `LibraryForeachIDCallbackFlag`.
This way the flags are type-safe, and it's known where values come
from. This is much preferred (at least by me) to just having `int
flags`.
Uses of `0` have been replaced with `IDWALK_NOP` and `IDWALK_CB_NOP`,
as those have the same value and are of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`. And another one in the opposite
direction.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int`
though.
No functional changes.
----------
I intend to land this PR as its two separate commits. I just put them in the same PR so the buildbot can handle them in one go, and we don't have a stack of highly relatled PRs.
In the future this could also apply to the `IDWALK_RET_…` enum. This one I left out, though, because a proper cleanup there would also have to include their ambiguity on whether they are bitflags (like the enums in this PR) or not. Their values and the code in `BKE_lib_query_foreachid_process()` implies they are bitflags, but in practice they are never or'ed together and just used as discrete values.
Pull Request: https://projects.blender.org/blender/blender/pulls/131803
The material returned by `BKE_object_material_get` could be nullptr when
the material is somehow not a grease pencil material and this situation
needs to be handled. This is likely caused by faulty file from previous
verisons.
Pull Request: https://projects.blender.org/blender/blender/pulls/131714
This only affected the drawing of the modifier UI, not the actual evaluation.
There was a missing check for the object type before retrieving the data from it.
`.release()` is technically fine but semantically wrong here. First,
release is meant to take ownership from the unique_ptr, meaning
at best it's "weird" to not do anything with the pointer afterwards.
Second, the runtime struct with the unique_ptr was just default
constructed, which means the unique_ptr will be empty anyway.
This avoids assuming that `BKE_ntree_update_main` has run on a node tree before
the depsgraph is build. The update code already finds the dependencies to
determine if a relations update is necessary or not. To avoid detecting these
dependencies again (which requires iterating over all the nested nodes), they
were cached on the node group so that they can be used when the depsgraph is
build.
However, since the update code does not run in all necessary cases yet
(#131598), this does not work currently. This patch fixes the situation by
removing the optimization of not having to find all dependencies again when the
depsgraph is build.
This optimization can be introduced again after we can be more sure that the
node tree update code runs whenever the node tree changes (which is what #131665
tries, but requires more discussion).
Pull Request: https://projects.blender.org/blender/blender/pulls/131685
There could be strokes that have zero lengths (a dot), in this case a
NaN factor was given to the final build function, leading to invalid
index when accessing arrays. Now `get_stroke_factor` will return either
0.0f or 1.0f (depending on input factor) when stroke has zero total
length.
Pull Request: https://projects.blender.org/blender/blender/pulls/131683
The layer mask used by the armature modifier can be incomplete, in which case
the indices may not match the edit hints list of layer data. The actual
layer index must be used instead.
Also fixes a build error on Win64 ARM which cannot compile a parallel_for_each
over an index range.
Pull Request: https://projects.blender.org/blender/blender/pulls/131620
Grease Pencil v3 did not have crazyspace support yet. Without this sculpting on
deformed geometry (e.g. on top of an armature modifier) will yield incorrect
offsets because the tool writes to original data based on deformed positions.
This patch adds computation of local deformation matrices which are stored in
the `GeometryComponentEditData`. Those matrices are then used to convert local
deformation of the evaluated geometry back to a deformation of the original
geometry. All the relevant sculpt tools support the crazyspace correction now,
using the `compute_orig_delta` helper function.
Computing the deformation matrices should happen alongside modifier evaluation
for any deforming modifier. This has been implemented for the armature modifier,
others can be added.
A fallback implementation for curves could also be added for modifiers that
don't have an easy way to calculate local transformation. A "natural"
orientation for both the original and deformed positions is calculated, then the
difference yields deform matrices. For meshes the approach is to use the surface
normal and a stable tangent space. For curves the common local coordinate frame
based on parallel transport might be used.
Currently crazyspace correction for the _Clone_ tool does not work because of
#131496.
Pull Request: https://projects.blender.org/blender/blender/pulls/131499
Line Art modifier `runtime->object_dependencies` can be empty when first
loaded, this can be triggered when loading as library overrides. This
fix guards this kind of situation.
Pull Request: https://projects.blender.org/blender/blender/pulls/131591
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
Previously, the data-block dependencies were always detected in
`update_depsgraph` in `MOD_nodes.cc`. This would only be called when something
called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph
rebuild after each operation in the node editor, as that would be expensive.
However, that also meant that we often had to add data-block dependencies that
are not actually used, but might be used if the user changed e.g. a link. A
typical example for that is a object socket that has a default value, but the
socket is also linked.
Now, the dependencies referenced by the node tree are collected by the node tree
update code which runs after all changes. This way we can detect whether the
dependencies have changed. Only if they have changed, a depsgraph rebuild is
triggered. This now allows also taking into account the mute status of nodes and
whether an input is linked.
There are still more things that could be taken into account. Most obviously
whether a node is connected to an output. This can be done later. The most
tricky aspect here is probably that we also have to consider all viewer nodes as
output, because at the time the node runs, it's not known which viewer will
actually be used (which depends on other editors).
This also cleans up some special cases we had for e.g. the scene time node where
we always had to trigger a depsgraph rebuild when it was added/removed because
of its time dependence. This is now part of a more general system.
This fixes#109219.
Pull Request: https://projects.blender.org/blender/blender/pulls/131446
Some editors are not redrawn while baking, but the properties editor currently
is and therefore needs this special check.
Eventually, we should rename or split the `is_rendering` flag to make it
more obvious that it also means baking.
Move `CD_CUSTOMLOOPNORMAL` to the newly added
`CD_PROP_INT16_2D` generic attribute type. This is similar to
previous commits moving specific custom data types.
The attribute name is `custom_normal`. When the attribute with
that name is on the face corner domain, the code will interpret it
as stored in the existing deformation-invariant spherical coordinate
space.
The API remains the same, with the additional opportunity to edit
custom normal data as an attribute directly (which admittedly is fairly
unintuitive currently).
See #130484.
Pull Request: https://projects.blender.org/blender/blender/pulls/130689
Avoid rebuilding BVH trees when meshes are copied.
Similar to the other uses of the shared cache system,
this can arbitrarily improve performance when meshes
are copied but not deformed and BVH building is the
main bottleneck. In a simple test file I got a 6x speedup.
The amount of code is also reduced and the system is
much simpler overall-- built out of common threading
patterns like `SharedCache` with its double-checked lock.
RAII is used in a few places to simplify memory management
too.
The downside is storing more `SharedCache` items in the
mesh runtime struct. That has a slight cost when copying
a small mesh many times, but we have ideas to improve that
in the future anyway (#104327).
Pull Request: https://projects.blender.org/blender/blender/pulls/130865
`interace_panel_has_socket` should return true when panel has
at least a socket of type input or hidden in modifier. That way, panel
drawing code won't be executed.
Pull Request: https://projects.blender.org/blender/blender/pulls/130958
These are converted on startup to the new type. There are still
some references left, mostly where it looked like there still needs
to be changes to properly deal with the new object type.
Grease pencil build modifier additive mode has two problems that is
causing crashes and wrong build result when drawing in additive mode:
- Not assigning `dst_to_src_curve` for previously built curves.
- The way `previous_drawing` was acquired was wrong, this gives a zero
stroke count for additive build mode, which prevented the crash while
not in drawing mode (not on key frame), but is in fact incorrect for
the algorithm.
This PR handles these problems and additive mode now works correctly
and without crashes while drawing new frames.
Pull Request: https://projects.blender.org/blender/blender/pulls/130952
These are useless now that PointerRNA has explicit default values, and
become a problem when real constructors are added to this struct. Simply
use the default empty value initialization instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/130927
Ensure no bezier curves for offset modifier, this makes it consistent
with the rest of the grease pencil modifiers for now and we will make
bezier support for the rest of the modifiers later.
Pull Request: https://projects.blender.org/blender/blender/pulls/130901
Grease pencil tint modifier in gradient mode did not do alpha mix with
the original stroke color, making original color completely black even
when gradient color has alpha. Now fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/130575
The `fmt::format` can process the format string at compile time. Currently, we
don't seem to be using that as we don't use `FMT_STRING`. Starting with C++20,
that will be the default though, and one has to explicitly opt out in places
where the string is not known at compile time using `fmt::runtime(...)`.
Currently, our code does not compile as C++20 because of that. Unfortunately, we
have many places with runtime format strings, because of i18n.
Pull Request: https://projects.blender.org/blender/blender/pulls/130392
The bug occurred when the user changed the camera of the scene.
The lineart modifier was not updating when changing the camera, but only
when changing other elements in the scene or moving the camera.
This is resolved by adding a depsgraph update for scene parameters, such
as when changing the camera.
Testing:
Add two cameras, add a Grease Pencil Collection Line Art, go into camera
perspective view and then switch to the other camera.
The Grease Pencil Line Art now updates automatically.
Co-authored-by: YimingWu <chengdulittlea@noreply.localhost>
Pull Request: https://projects.blender.org/blender/blender/pulls/129935
Cleanup to simplify code by using common terms like _first_ and _last_ in context
of predicate applying in a range just like we do for spans and range containers.
Pull Request: https://projects.blender.org/blender/blender/pulls/130380
GPv3 build modifier in "Nature Drawing Speed" mode didn't finish
building a frame when the time it took to draw those strokes by hand is
greater than the frame duration. Previous fix#129894 is only effective
for "Number of Frames" build mode. This fix moved the timing scaling
into `get_build_factor` and `get_factor_from_draw_speed` for more
granulated control in different modes.
Pull Request: https://projects.blender.org/blender/blender/pulls/130199
The cache mechanism for line art is changed during migration to GPv3,
however the code path failed to handle following cases which could lead
to a few problems:
- Line art cache isn't deleted after last line art modifier because it
coule be hidden, causing memory leaks.
- A modifier inside a multiple line art modifier sequence that doesn't
use cache would prematurely delete line art cache, causing subsequent
line art modifier to give empty result.
- When the first line art modifier is hidden (in viewport/render), the
cache is not created correctly, leading to crashes.
Now the new code logic addresses these problems properly by:
- Making sure the last visible line art modifier deletes cache.
- Giving a fresh cache pointer for modifiers that doesn't use global
cache.
- Line art cache is correctly ensured when there are modifiers that
are hidden
Pull Request: https://projects.blender.org/blender/blender/pulls/129953
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
Previously, some places used `curves.points_num() == 0` some other
places `curves.curves_num() == 0` to check if the geometry is empty.
Rather than having these two ways, add an `is_empty()` function
that replaces all these different checks.
Also update the curves geometry tests to use this function.
Pull Request: https://projects.blender.org/blender/blender/pulls/130168
When the duration of a frame is shorter than the build time specified in
the modifier, build modifier should shorten the build time to allow the
frame to be fully built within the frame duration. This fix made the
timing behaviour the same as GPv2.
Pull Request: https://projects.blender.org/blender/blender/pulls/129894
The issue was that if the `delta_time` attribute didn't exist, the drawing
would appear immediatley.
In case we don't have any drawing speed information, the fix
makes it so that we fallback to use the number of frames
to build the strokes.
Pull Request: https://projects.blender.org/blender/blender/pulls/130035
