The function was highly related to the apply modifier operator,
and only used once. This was too specific to be in the blenkernel,
especially in a mesh conversion file.
After switching over to using start_frame / end_frame, scaling an NLA strip didn't scale the strip, it just repeated the action.
Now withing the NLA transform code, we look for TFM_TIME_EXTEND / TFM_TIME_SCALE transform mode, and handle the update to strip scale accordingly
Since rB8014180720d8, all paint modes support orbiting around last
stroke, so [a] the comment there is out of date and [b] the fallback
case of orbiting around the center will never be used (unless there is
no stroke information - but BKE_paint_stroke_get_average handles that
anyways).
Spotted while looking into T101766.
Maniphest Tasks: T101766
Differential Revision: https://developer.blender.org/D16779
The problem was the bake function was using the evaluated
data and must use the original data.
The problem was caused by commit: rBcff6eb65804d: Cleanup: Remove duplicate Bake modifier code.
Fix by Philipp Oeser
Editmode should display the original (non-evaluated) points unless there
is something like an "On Cage" option of a modifier [which none of the
curves modifiers have].
This was not the case since the introduction in rBe15320568a29.
So we now draw the editpoints from the original curves. This also means
that original and evaluated curves might not have the same number of
points, so we have to get independent of `proc_point_buf` since that
would possibly create vertexbuffers of different sizes (compared to the
original curves) which is not allowed for a single batch.
- remove the "pos" alias from the vertex buffer format of proc_point_buf
- instead, create a new "edit_points_pos" vertex buffer
- fill that with the original (un-evaluated) curves positions
- dont request `proc_point_buf` anymore
- rename the editpoints flags buffer to be more consistent
And since original and evaluated points might also be in completely
different positions, we also need to draw connecting lines between those
editpoints to not have them float in thin air. For drawing these in
editmode, a simple polyline was chosen (instead of drawing lines in a
resolution that is take from the old particle system -- which is not
depending on points even but has a hardcoded resolution that can only be
upped by the hair_subdiv scene render setting)
- create appropriate batch and indexbuffer for this
- positions vertex buffer can be reused
- reuse particle edit shader (instead of curve edi shader) to get
segment highlighting
{F14055436}
NOTE: this also removes the broken depth handling and instead makes it
work (also XRay is properly taken into account) by binding the correct
overlay framebuffer.
NOTE: to further clarify the distinction between curves drawing (that is
based on the old partice system drawing) and drawing in editmode, the
corresponding vertexbuffers have been moved out of CurvesEvalCache into
CurvesBatchCache directly.
NOTE: drawing the lines in editmode could be improved (taking the "real"
resolution of splines into account, but since this should happen on the
GPU in a compute shader, this is for later)
Potentionally fixes T101889.
Maniphest Tasks: T101889
Differential Revision: https://developer.blender.org/D16281
- Use typed enum for the wrap axis.
- Rename `bounds` to `wrap_region`.
- Take a `rcti` argument instead of an `int[4]`.
- Pair wrap & wrap_region arguments together.
This is an alternative fix to [0] which kept the cursor centrally
located as part of GHOST cursor grabbing which caused T102792.
Now this is done as part of walk mode as it's the operator that most
often ran into this problem although ideally this would be handled by
GHOST - but that's a much bigger project.
[0]: 9fd6dae793
Historically checks for windowing capabilities used platform
pre-processor checks however that doesn't work when Blender is built
with both X11 & Wayland.
Add a capabilities flag which can be used to check which functionality
is supported. This has the advantage of being more descriptive/readable.
This adds a new mirror image extension type for shaders and
geometry nodes (next to the existing repeat, extend and clip
options).
See D16432 for a more detailed explanation of `wrap_mirror`.
This also adds a new sampler flag `GPU_SAMPLER_MIRROR_REPEAT`.
It acts as a modifier to `GPU_SAMPLER_REPEAT`, so any `REPEAT`
flag must be set for the `MIRROR` flag to have an effect.
Differential Revision: https://developer.blender.org/D16432
The `render_color_index` skips attributes with different types
and domains in order to give the proper order for the UI list.
That is a different than an index in the group of all attributes.
The most solid solution I could think of is exposing the name of
the default color attribute. It's "solid" because we always address
attributes by name internally. Doing something different is bound
to create problems. It's also aligned with the design in T98366 and
D15169.
Another option would be to change the way the "attribute index"
is incremented in Cycles. That would be a valid solution, but would
be more complex and annoying.
For consistency, I also exposed the name of the active color attribute
the same way, though it isn't necessary to fix this particular bug.
The properties aren't editable, that can come in 3.5 as part of D15169.
Differential Revision: https://developer.blender.org/D16769
This is essentially a left-over from the initial transition to fields where this was
forgotten. The mesh primitive nodes used to create a named uv map attribute
with a hard-coded name. The standard way to deal with that in geometry nodes
now is to output the attribute as a socket instead. The user can then decide
to store it as a named attribute or not.
The benefits of not always storing the named attribute in the node are:
* Improved performance and lower memory usage when the uv map is not
used.
* It's more obvious that there actually is a uv map.
* The hard-coded name was inconsistent.
The versioning code inserts a new Store Named Attribute node that
stores the uv map immediatly. In many cases, users can probably just
remove this node without affecting their final result, but we can't
detect that.
There is one behavior change which is that the stored uv map will be
a 3d vector instead of a 2d vector which is what the nodes originally created.
We could store the uv map as 2d vector inthe Store Named Attribute node,
but that has the problem that older Blender versions don't support this
and would crash immediately. Users can just change this to 2d vector
manually if they don't care about forward compatibility.
There is a plan to support 2d vectors more natively in geometry nodes: T92765.
This change breaks forward compatibility in the case when the uv map
was used.
Differential Revision: https://developer.blender.org/D16637
This allows choosing the 2d vector type in the Store Named Attribute
node. Similar to byte-colors, there is not a special socket type for this
(currently). In geometry nodes itself, vectors are all still 3d.
The "Loading Asset Libraries" label in the menu would already disappear
before the asset libraries are done loading. It only queried if the
loading was started, not if it was finished. Especially notable when the
asset library was slow to load, e.g. because it is not yet in the asset
index.
This is because OB_MODE_SCULPT_CURVES is not part of OB_MODE_ALL_PAINT
(yet). While there is some chance it ends up there, there are a lot of
more places that need checking and so patch only fixes the report very
isolated.
NOTE: T93501 is related (since the option to show these should also be
hidden in sculptmode)
Maniphest Tasks: T101765
Differential Revision: https://developer.blender.org/D16764
Recently a new geometry node for splitting edges was added in D16399.
However, there was already a similar implementation in mesh.cc that was
mainly used to fake auto smooth support in Cycles by splitting sharp
edges and edges around sharp faces.
While there are still possibilities for optimization in the new code,
the implementation is safer and simpler, multi-threaded, and aligns
better with development plans for caching topology on Mesh and other
recent developments with attributes.
This patch removes the old code and moves the node implementation to
the geometry module so it can be used in editors and RNA. The "free
loop normals" argument is deprecated now, since it was only an internal
optimization exposed for Cycles.
The new mesh `editors` function creates an `IndexMask` of edges to
split by reusing some of the code from the corner normal calculation.
This change will help to simplify the changes in D16530 and T102858.
Differential Revision: https://developer.blender.org/D16732
Fixed more cases where attributes weren't being reinitialized
on switching PBVH mode:
* When PBVH_GRIDS and PBVH_BMESH force attributes into simple
array mode they no longer override simple_array in the
SculptAttributeParams parameters, instead they set a field
in SculptAttribute itself. Thus if the attribute is
reinitialized in another mode it won't retain the simple_array
parameter.
* sculpt_attribute_ensure_ex now calls sculpt_attr_update if
the attribute already exists.
* Fixed a bug from a couple commits ago that set
SculptAttribute.data_for_bmesh wrong.
PBVH draw code now builds coarse triangle index buffers
for multires. Note that the coarse grids can be at any
multires depth but is currently hardcoded to 1.
Previously the sculpt box trim operator always created face sets,
but after face sets became optional it only modified them if they
already existed. Absent a better way to turn the behavior on and off,
the fix is to just always create face sets.
Before f1c0249f34 the material was assigned to the previous
slot rather than the next. Though the behavior is arbitrary, there
is no reason to change it.
The `transform_convert_clip_mirror_modifier_apply` code is made more readable by:
- decreasing indentation;
- removing `axis` and `tolerance` variables;
- renaming `int clip` to `bool is_clipping`;
