- 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`;
The comment of `solve_cubic()` put the coefficients of the to-be-solved
cubic equation in the wrong order. This is now fixed.
No functional change, just a comment fix.
When the line was very thin the precision of the thickness
calculation was not precise enough.
The algorithm has been improved. This affects SVG and PDF.
* Make it clearer that contrib isn't shipped with releases, by already excluding it in beta.
* Improve the UI by hiding the "Testing" enum item in these case.
Differential Revision: https://developer.blender.org/D16729
In preparation to sanatize the mask texture and color texture in sculpt code. In sculpt
mode the mask texture is read from mtex, leaving the mask_mtex when we want to use color
textures in sculpt mode.
