Natural drawing speed fails for strokes that are pasted or duplicated.
This is due to the `init_time` attribute being transferred from previous stroke
to the new, resulted in the same values. This further calculates wrong
`build_factor` inside `get_factor_from_draw_speed`. To further explain
this, `gap_delta_time = -prev_end_time` which evaluates `start_time=0` for
the duplicated curve. To avoid this situation, make sure `gap_delta_time`
is positive. So `start_time` will be > 0.
Pull Request: https://projects.blender.org/blender/blender/pulls/134329
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
The stroke index was wrong when a influence filter is active in the
modifier, this would lead to crashes. Now corrected this by only
iterating duplicated strokes in front of the curves geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/134038
The issue was that the topology of the drawing changes when the bezier
curves get resampled to poly curves in the armature modifier.
This means that the crazyspace code fails to find deformed positions
with the same length as the original positions.
The fix does multiple things:
* First, we make sure that we create an `GeometryComponentEditData` in
weight paint mode.
* When the armature modifier runs, we remember the current positions in
this component.
* Then, we store the curve offsets and weights _before_ converting the
bezier curves.
* Finally we deform the positions stored in the edit hint component
(which have the same length as the original positions).
Since the resampling just adds new points, there might be a way to
avoid running the armature deformation a second time on the edit
hints, but I'll leave that for another day as a performance improvement.
In any case, this is only done when we actually need the deformation
(e.g. in weight paint mode when we paint the weights).
Pull Request: https://projects.blender.org/blender/blender/pulls/134030
The Subdivision Modifier used "Levels" and the Multiresolution Modifier used "Level". This difference is changed to be "Levels" for both, which aligns with similar UI terminology where plural forms indicate adjustable values, such as "Render Samples".
Ref blender/blender-manual#105098
The algorithm to calculate face corner normals had a vertex normal
input, with the intention to pre-populate corner normals for vertices
with no sharp connected edges. However corner normals are calculated
separately for these fully sharp vertices later anyway, so this whole
step was completely redundant. Removing the vertex normals calculation
reduces memory usage and improves performance. In a test file with a
character with custom normals, this changed improved the playback FPS
by 15%, from 41 to 47 FPS. The impact will usually be lower than that
but it should be noticeable in other scenes too.
Pull Request: https://projects.blender.org/blender/blender/pulls/133884
The handling of influence vertexgroups was incomplete/inconsistent.
Some prior work was already done in 08539618cd, c452d5d9e8,
782a4c9d85, 0fd3f3c216, 434f94b254, 82ea972834, f6b820ccb7,
00968fe6db .
Now that the inverting is handled consistently, we can move that part
out of specific modifier code an into the generic retrieval function
`greasepencil::get_influence_vertex_weights` -- resulting in all
modifiers using it behaving the same.
There were some modifiers already handling
`GREASE_PENCIL_INFLUENCE_INVERT_VERTEX_GROUP`, however even those still
had one issue: if no vertexgroup was set, invert would still have been
calculated (this issue is also resolved with this PR).
Remaining modifiers that were offering influence vertexgroups (e.g.
Noise) but ignoring it now work correctly.
NOTE: there are still modifiers handling influence vertexgroups outside
of `greasepencil::get_influence_vertex_weights`:
- Armature (has own code for this in
`BKE_armature_deform_coords_with_curves`)
- Shrinkwrap (has own code for this in `shrinkwrapParams_deform`)
- Thickness (this rather special behavior is untouched)
Pull Request: https://projects.blender.org/blender/blender/pulls/133426
Having a small voxel size meant typing in zero would clamp the
voxel size to a small number which was often small enough to hang
calculating large voxels which would eventually fail to allocate
memory & crash.
Instead, allow a zero value but bypass calculation.
See #130526.
Behavior was not consistent across modifiers
- Opacity
-- strokes were using inverted weights only when
MOD_GREASE_PENCIL_OPACITY_USE_WEIGHT_AS_FACTOR was OFF, fills however
when MOD_GREASE_PENCIL_OPACITY_USE_WEIGHT_AS_FACTOR was ON
- Tint
-- strokes and fills were using inverted weights only when
MOD_GREASE_PENCIL_TINT_USE_WEIGHT_AS_FACTOR was ON
- others (Envelope, Lattice, Noise, Offset ) were ignoring inverting the
influence vertex group alltogether (but that is reported in #133055 and
will be handled separately, see below)
- others (Hook, ... ) were always inverting it, which is correct
This pull requeset only corrects this for Opacity and Tint (in the way
that now weights are always inverted, no matter if "Use Weight As
Factor" is used).
This also paves the way to a more general fix for #133055 (which intends
to move the weight inversion to the very general
greasepencil::get_influence_vertex_weights)
Pull Request: https://projects.blender.org/blender/blender/pulls/133310
This patch automatically grays out input values which can't affect the output
currently. It works with inputs of group nodes, geometry nodes modifiers and
node tools.
To achieve this, it analyses the node tree and partially evaluates it to figure
out which group inputs are currently not linked to an output or are disabled by e.g.
some switch node.
Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874
Related info in blog post:
https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility
Follow up task for designing a UI that allows hiding sockets: #132706
Limitations:
* The inferencing does not update correctly when a socket starts being
animated/driven. I haven't found a good way to invalidate the cache in a good
way reliably yet. It's only a very short term problem though. It fixes itself
after the next modification of the node tree and is only noticeable when
animating some specific sockets such as the switch node condition.
* Whether a socket is grayed out is not exposed in the Python API yet. That will
be done separately.
* Only a partial evaluation is done to determine if an input affects an output.
There should be no cases where a socket is found to be unused when it can actually
affect the output. However, there can be cases where a socket is inferenced to be used
even if it is not due to some complex condition. Depending on the exact circumstances,
this can either be improved or the condition in the node tree should be simplified.
Pull Request: https://projects.blender.org/blender/blender/pulls/132219
This was true for Opacity or Tint modifiers where influence vertexgroups
were having an effect on strokes, but were ignored for fills.
This was also the case for GPv2 / 4.2, but there is no apparent reason
for not doing this on fills (if we are doing it for strokes).
NOTE: it was actually in use if "Use Weight as Factor" was used (but
that only means weights should be used directly, otherwise [when used as
influence], weights should be multiplied).
Pull Request: https://projects.blender.org/blender/blender/pulls/133306
The weights were only used when "Use Weight as Factor" was used (this is
wrong though, that button uses the weights directly, otherwise the
Factor has to be multiplied by the weights -- as done in all other
modifiers [and in 4.2])
Pull Request: https://projects.blender.org/blender/blender/pulls/133297
Two things not behaving as in GPv2:
- points outside the influence vertexgroup were getting zero opacity (as
opposed to 1.0 in GPv2)
- Opacity Factor was multiplied in (even though it shouldnt and is
rightfully greyed out)
I assume the a misunderstanding in c02f3c94d9.
Pull Request: https://projects.blender.org/blender/blender/pulls/133208
One should be able to set the modifier `Highest` value lower then the
`Lowest`, in fact this is probably the more common usecase (getting high
values in the vertexgroup when something is close by and getting lower
values the further away from the target we get).
Now change code so we do exactly like we do for meshes.
NOTE: for grease pencil (as opposed to meshes), the Vertex Weight
Proximity modifier has a button to flip the output values, this can
probably stay for convenience.
Stumbled over this checking on #133055
Pull Request: https://projects.blender.org/blender/blender/pulls/133092
If I read code correctly, at least offset/translation and scale happen
in the Curve domain only in GPv3, so having vertexgroups influence per
point does not really make sense for this modifier.
Therefor, remove the influence vertexgroup from this modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/133102
The modifier would write to all weights, not respecting if a vertex was
not part of the influence vertex group.
If the vertex is not part of the influence vertex group (its weight is
0.0), dont touch the existing weights (just continue happily).
Pull Request: https://projects.blender.org/blender/blender/pulls/133098
Resolve regression introduced in [0] intended to fix another regression
introduced in [1] to resolve an assert from [2] (a C++ cleanup).
Recent changes made the array modifier return early with the start-cap's
mesh however this meant the required custom-data layers wouldn't
necessarily exist on the returned mesh, causing selection to crash.
Besides this the same logic was missing from the end-cap.
Resolve by restoring the logic from before [1],
adding a check to prevent the assert.
[0]: 9ad6957574
[1]: 8b2556e8d8
[2]: cb62ab5b28
- "Strength" in the context of Grease Pencil, deals with opacity, and
adjusts the brush stroke alpha.
- "Strength" can mean measurable units like 'noise', 'light', etc.
- Anything else using physical strength in a generic concept.
Issue reported by Hoang Duy Tran.
- In the context of mesh extrusion, "Fill" means "Fill the rim of an
extruded edge loop" (verb).
- In the context of the file browser, it means select every file
between beginning and end.
- In the context of an image, fill the tile with generated image.
Issue reported by Hoang Duy Tran.
`flip_axis` is currently an enum RNA property. This makes impossible to
toggle the individual axis. Now fixed by converting the property to
boolean. UI drawing code is same as done for mirror modifier.
New enum values are introduced for each axis
Resolves#70237
Pull Request: https://projects.blender.org/blender/blender/pulls/132849
A separate function is declared/defined `uiLayoutPanelPropWithBoolHeader`,
it will add a boolean property to the panel.header.
Clear decorate and separator flag, otherwise they will offset the panel
header horizontally and also adds animate decorator on the right side.
Resolves#131623.
Pull Request: https://projects.blender.org/blender/blender/pulls/132726
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
