This was not done originally, because one had to iterate over all curves
to get the number of points which had some overhead. Now the number
of points is stored all the time anyway.
The `fix_link_cycles` function added in rB2ffd08e95249df2a068dd did not
handle the case correctly when there are multiple cycles going through
the same socket.
Existing path selection & new path picking included without UV's.
Now limit objects to those with UV's.
Also remove use of CTX_wm_view3d(C) in the UV editor it would be NULL,
but it doesn't makes sense to use the 3D viewport for UV operations
even if it was available.
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.
Swap-buffers was being deferred (to prevent it being called
from the event handling thread) however when it was called the
OpenGL context might not be active (especially with multiple windows).
Moving the cursor between windows made eglSwapBuffers report:
EGL Error (0x300D): EGL_BAD_SURFACE.
Resolve this by removing swapBuffer calls and instead add a
GHOST_kEventWindowUpdateDecor event intended for redrawing
client-side-decoration.
Besides the warning, this results an error with LIBDECOR window frames
not redrawing when a window became inactive.
Fixes the packing operators that use ED_uvedit_pack_islands_multi
Also fixes UV Select Similar with hidden UV islands.
Packing operators using GEO_uv_parametrizer should remain unchanged.
Add a check to BM_elem_flag_test(efa, BM_ELEM_HIDDEN).
Note that BM_mesh_calc_face_groups doesn't easily support XOR of flags,
requiring logic to be moved to a preprocess step on BM_ELEM_TAG.
Regression in rBe3075f3cf7ce.
Differential Revision: https://developer.blender.org/D17055
Path selection support from [0] didn't account for multiple objects in
edit-mode. Now picking the UV also picks the object to operate on.
[0]: ea5fe7abc1
Add:
- ED_object_in_mode_to_index
- ED_object_in_mode_from_index
Useful for operators that act on a non-active object in multi-edit mode,
so the index can be stored for the operators exec function to read back
the value when redoing an action. Needed to resolve T102680.
Fixes bug where other islands sometimes get their masks cleared (or
filled) in strange circumstances. Still need to figure out the
correct behavior for spherical falloff.
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.
Add an RNA API function that gives an array of the normals for every control point.
The normals depend on the `normal_mode` attribute, which can currently be
minumum twist or Z-up, though more options are planned. Normals are currently
evaluated on the evaluated points and then sampled back to the control points.
Because that can be expensive, a normal mode that only does a first evaluation
on control points may be important
The function is intended to be used by Cycles, so it doesn't have to implement
the calculation of normals itself. They can be interpolated between control points
and normalized.
For best performance, the function should only be called once, since it does the
full calculation for every control point every time it is called.
Differential Revision: https://developer.blender.org/D17024
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.
The reverse iteration added in e091291b5b didn't handle
the case where there are no nodes properly. Thanks to Iliya Katueshenock
for investigating this.
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.
The default when there is no cyclic attribute is that none of the curves
are cyclic. In the mesh to curve node, avoid creating the attribute with
just false to save time and memory usage. Also avoid looking up the
attribute twice in the trim node.
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
Split the algorithms that find duplicates.
This improves readability and helps us find areas for optimization.
It may also facilitate the implementation of generic utilities.
No functional changes.
Differential Revision: https://developer.blender.org/D16918
