This adds a new `Interpolate Curves` node. It allows generating new curves
between a set of existing guide curves. This is essential for procedural hair.
Usage:
- One has to provide a set of guide curves and a set of root positions for
the generated curves. New curves are created starting from these root
positions. The N closest guide curves are used for the interpolation.
- An additional up vector can be provided for every guide curve and
root position. This is typically a surface normal or nothing. This allows
generating child curves that are properly oriented based on the
surface orientation.
- Sometimes a point should only be interpolated using a subset of the
guides. This can be achieved using the `Guide Group ID` and
`Point Group ID` inputs. The curve generated at a specific point will
only take the guides with the same id into account. This allows e.g.
for hair parting.
- The `Max Neighbors` input limits how many guide curves are taken
into account for every interpolated curve.
Differential Revision: https://developer.blender.org/D16642
During 3D texturing the uv islands are extended in order to fix seam bleeding
for manifold parts of the input mesh. This patch adds a `print_debug` method
on UVIsland that generates a python script. This script can be copy-past
into the Python Console to show the generated geometry.
This script can be extended to show the extracted border and use face colors
for showing internal decisions.
Mesh islands (shells) are now calculated on an as-needed
basis and cached inside of a temp attribute,
`sculpt_topology_island_key`. This attribute is updated
as needed when geometry changes (e.g. the trim brush)
or when mesh visibility changes.
This replaces the old behavior where the "topology" automasking
mode would walk the entire mesh on every stroke.
Based on discussion about T102962, rename the "Face Set Boundaries" node
to "Face Group Boundaries" and the Accumulate Field node's "Group Index"
socket to "Group ID". This convention of "__ Group" and "Group ID" will
be used more in other nodes in the future.
This commit doesn't affect forwards or backwards compatibility.
While we do need higher level utilities for copying attributes
between geometries, this currently isn't used and it's not clear
that it will be the right abstraction in the end.
When all the curves are poly curves, skip the work of building a
separate array of offsets for the evaluated points (which are the
same as the control points). This saves 1-4ms on every reevaluation
in test files with many curves.
Standardizing the process of creating a new CurvesGeometry with
different curve sizes based on an existing curves is helpful, since
there are a few methods to simplify the process that aren't obvious
at first, like filling the offsets with sizes directly and accumulating
them to become sizes.
Also, in the trim curves node, avoid creating the curve types attribute
all the time. Use the special API functions for the types which do
some optimizations automatically. Also use a more consistent
method to copy the curve domain data, and correct some comments.
The same logic from D17025 is used in other places in the curve code.
This patch uses the class for the evaluated point offsets and the Bezier
control point offsets. This helps to standardize the behavior and make
it easier to read.
Previously the Bezier control point offsets used a slightly different standard
where the first point was the first offset, just so they could have the same
size as the number of points. However two nodes used a helper function
to use the same `OffsetIndices` system, so switch to that there too.
That requires removing the subtraction by one to find the actual offset.
Also add const when accessing data arrays from curves, for consistency.
Differential Revision: https://developer.blender.org/D17038
Previously, transforming a clip (scaling, repeat, etc) wouldn't re-calculate the blend-in and blend-out values, leading to over / undershoot, and a visual clip artifact
Old:
{F14045003}
This patch adds re-calculation logic (new `BKE_nlastrip_recalculate_blend()` method) to the blend-in/out on transformations to clamp values, and avoid over/under shoot.
The `BKE_nlastrip_recalculate_blend()` encapsulates the existing logic for both the `rna_NlaStrip_blend_in_set()` and `rna_NlaStrip_blend_out_set()` methods into a single BKE method that we an execute as needed. The fact that blend-in is first decreased, is strictly on the order of calculation. My suspicion is that //if// the blend-in / blend-our values were working as intended, the RNA set methods would update in order, and we'd experience the same thing. In short, the choice here was to linearly combine the logic, without making any assumptions of my own.
while talking things over with @sybren and @RiggingDojo, they are fine with how this currently works, but there a desire to update how the two values interact with each (ratio scale, etc) in the future.
New:
{F14045024}
{F14045025}
Reviewed By: sybren
Maniphest Tasks: T101369
Differential Revision: https://developer.blender.org/D16720
This was the case when using the operator outside of the modifiers panel.
Caused by {rBeae36be372a6}.
In above commit, `DT_layer_items` shared both `DT_TYPE_MPROPCOL_LOOP` |
`DT_TYPE_MLOOPCOL_LOOP` in a single EnumPropertyItem value "Colors".
This is a bit unusual, but probably allowed.
As a consequence, checks for specific datatypes would fail when selecting
such EnumPropertyItem:
- `DT_DATATYPE_IS_MULTILAYERS` (uses `ELEM` to check distinct entries --
would return false)
- `BKE_object_data_transfer_dttype_to_srcdst_index` (would return
`DT_MULTILAYER_INDEX_INVALID`)
These places have now been corrected to take these "special" values into
account.
Another issue was that multiple EnumPropertyItems with the same value
could be created in dt_add_vcol_layers() if attributes of the same
domain, but different color types are in play (could lead to crashes)
and that has also been corrected.
Also: above commit did not give the choice of transfering color
attributes from the vertex domain (only face corner attributes could be
chosen), this has now been added. DT_layer_vert_items (used from the
modifier) already had this included so this was only an issue when using
the operator outside of the modifiers panel.
Since we now feature two domains, the single "VCOL" in the enum has been
split into "COLOR_VERTEX" and "COLOR_CORNER". This will break existing
scripts calling bpy.ops.object.datalayout_transfer and will be marked as
a breaking change in the release notes.
NOTE: there is another bug here when attributes of the same domain, but
different color types are in play and you want to transfer just a single
specific layer (but that is for a separate commit)
Maniphest Tasks: T103400
Differential Revision: https://developer.blender.org/D16935
Goal of this patch is to stop the invocation of OpenGL calls via the bgl module
on a none OpenGL GPU backend, report this as a python deprecation warning
and report this to the user.
## Deprecation warning to developers
```
>>> import bgl
>>> bgl.glUseProgram(0)
<blender_console>:1: DeprecationWarning: 'bgl.glUseProgram' is deprecated and will be removed in Blender 3.7. Report or update your script to use 'gpu' module.
```
## Deprecation message to users
The message to the user is shown as part of the Info Space and as a message box.
{F14159203 width=100%}
{F14158674 width=100%}
During implementation we tried several ideas:
# Use python warning as errors: This isn't fine grained enough and can show incorrect information to the user.
# Throw deprecation as error and use sys.excepthook to report the user message.
This required a custom exception class to identify the bgl deprecation and a CPython handler function to
be set during python initialization. Although this is the most flexible there was a disconnect between the
exception class, exception function and the excepthook registration.
# A variant how we handle autoexec failures. A flag is stored in Global and when set the user message is reported.
Not that flexible, but code is more connected to the boolean stored in the Global struct.
Although using Global struct isn't nice I chose this solution due to its traceability. It is clear to developers
reading the code how the mechanism works by using search all functionality of your IDE.
Reviewed By: MichaelPW, campbellbarton
Maniphest Tasks: T103863
Differential Revision: https://developer.blender.org/D16996
These warnings can reveal errors in logic, so quiet them by checking
if the features are enabled before using variables or by assigning
empty strings in some cases.
- Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs
note that this may be left unset if it's not needed.
- Remove BOOST/OPENVDB/VULKAN references when disable.
- Define INC_SYS even when empty.
- Remove PNG_INC from freetype (not defined anywhere).
There is a utility method on `CurvesGeometry` to build a map of the
curve for each point. Use that in two more places and make sure its
implementation is multithreaded, which gives a slight speedup
in a simple test file.
This changes how we access the points that correspond to each curve in a `CurvesGeometry`.
Previously, `CurvesGeometry::points_for_curve(int curve_index) -> IndexRange`
was called for every curve in many loops. Now one has to call
`CurvesGeometry::points_by_curve() -> OffsetIndices` before the
loop and use the returned value inside the loop.
While this is a little bit more verbose in general, it has some benefits:
* Better standardization of how "offset indices" are used. The new data
structure can be used independent of curves.
* Allows for better data oriented design. Generally, we want to retrieve
all the arrays we need for a loop first and then do the processing.
Accessing the old `CurvesGeometry::points_for_curve(...)` did not follow
that design because it hid the underlying offset array.
* Makes it easier to pass the offsets to a function without having to
pass the entire `CurvesGeometry`.
* Can improve performance in theory due to one less memory access
because `this` does not have to be dereferenced every time.
This likely doesn't have a noticable impact in practice.
Differential Revision: https://developer.blender.org/D17025
Struct members loc/size were misleading as they read as if the object
data stored object level transform channels. Rename these to match RNA
with a `texspace_*` prefix to make it clear these struct members only
apply to texture-space transform.
Also rename ME_AUTOSPACE & ME_AUTOSPACE_EVALUATED to
ME_TEXSPACE_FLAG_AUTO & ME_TEXSPACE_FLAG_AUTO_EVALUATED.
Avoid calling `interpolate_to_evaluate` while evaluating normals,
which has to look up attributes by name for every curve. Also avoid
duplicating the curve type switch in a few functions. I didn't observe
a performance difference, but theoretically this could reduce
overhead for many small curves.
Since 90ea1b7643, node trees have been reevaluated
after many selection operations because nodes are sorted based on
the selection status and an update tag was added for that. However,
for years the node order was allowed to be different between the
original and evaluated copy of node trees.
Though it is a bit sketchy to have that difference in the evaluated
node tree, reevaluations for just selection are very bad, so use a
"smaller" update tag and add a comment for justification.
Differential Revision: https://developer.blender.org/D17023
The order of arguments to memcpy was reversed, which is sadly possible
because the constness `KeyBlock` of keyblock doesn't propagate to
pointers it contains.
Remove:
- IDPropertyTemplate.matrix_or_vector
Matrix & vector types have been deprecated, this wasn't used.
- IDProperty.saved
This was added preemptively but never used, replace with a pad so as
not to hint at a feature that doesn't exist.
The default curve type when there is no "curve_type" attribute is
Catmull ROM. In order to avoid allocating an entire array of values
just to set this default type, remove the attribute instead. This will
be less important when we can store attributes as single values.
Also fix a curve utility API comment.
Since a year and a half ago we've been switching to a new way to
represent what sockets a node should have called "declarations"
that's easier to use, clearer, and more flexible for upcoming
features like dynamic socket counts or generic type sockets.
All builtin nodes with a static set of sockets have switched, but one
missing area has been group nodes and group input/output nodes. These
nodes have **dynamic** declarations which change based on their
properties or the group they're inside of. This patch addresses that,
in preparation for using the same dynamic declaration feature for
simulation nodes.
Generally there shouldn't be user-visible differences, but one benefit
is that user-created socket descriptions are now visible directly in
the node editor for group nodes and group input/output nodes.
The commit contains a few changes:
- Add a node type callback for building dynamic declarations with
different arguments
- Add an `Extend` socket declaration for the "virtual" sockets used
for connecting new links
- A similar `Custom` socket declaration is used for addon-defined socket
- Simplify the node update loop to use the declaration to build update
sockets
- Replace the "group update" functions with the declaration building
- Move the node group input/output link creation to link drag operator
- Make the field status part of group node declarations
(not for group input/output nodes though)
- Some fixes for declarations to make them update and build properly
Differential Revision: https://developer.blender.org/D16850
Under some circumstances (loading autosaves), we end up reading from
files that were saved with the new mesh format (after T95965). When
that happens we should skip the conversion from the old format to
avoid data-loss. This will also give forward compatibility when we
stop saving in the old format completely in 4.0.
Here I mostly just check if the attributes in the new format already
exist. Along with checking for the null status of `Mesh::mvert`, that
should cover the majority of cases.
Fixes T103878
Differential Revision: https://developer.blender.org/D17011
Separating strokes using "selected points" didn't take into account
that points->time can be 0 and thus created points with negative
values in points->time, which should be an impossibility.
This patch fixes this in BKE_gpencil_stroke_delete_tagged_points.
Also, it makes the build modifier's new drawspeed immune
to (erroneous) negative time values, should they arise in other situations.
Reviewed By: antoniov
Differential Revision: https://developer.blender.org/D17006
Use a consistent style for declaring the names of struct members
in their declarations. Note that this convention was already used in
many places but not everywhere.
Remove spaces around the text (matching commented arguments) with
the advantage that the the spell checking utility skips these terms.
Making it possible to extract & validate these comments automatically.
Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo`
which were using brief descriptions.
This makes `GVArrayImpl` and `VArrayImpl` more similar.
Only passing the pointer instead of the span also increases
efficiency a little bit. The downside is that a few asserts had
to be removed as well. However, in practice the same asserts
are in place at a higher level as well (in `VArrayCommon`).
