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 is done based on the render sample count so that it doesn't impact
sampling quality. It's similar in spirit to the adaptive table size in D16561,
but in this case for performance rather than memory usage.
Differential Revision: https://developer.blender.org/D16726
The first two dimensions of scrambled, shuffled Sobol and shuffled PMJ02 are
equivalent, so this makes no real difference for the first two dimensions.
But Sobol allows us to naturally extend to more dimensions.
Pretabulated Sobol is now always used, and the sampling pattern settings is now
only available as a debug option.
This in turn allows the following two things (also implemented):
* Use proper 3D samples for combined lens + motion blur sampling. This
notably reduces the noise on objects that are simultaneously out-of-focus
and motion blurred.
* Use proper 3D samples for combined light selection + light sampling.
Cycles was already doing something clever here with 2D samples, but using
3D samples is more straightforward and avoids overloading one of the
dimensions.
In the future this will also allow for proper sampling of e.g. volumetric
light sources and other things that may need three or four dimensions.
Differential Revision: https://developer.blender.org/D16443
While it helps on many scenes, it can be disruptive for existing scenes and
for benchmarks the differences in timing can be confusing. So be a bit more
conservative and only it enable it for new scenes.
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.
The use of a struct for device strings caused the CUDA compiler to
generate byte arrays as the argument type, whereas OSL generated
primitive integer types (for the hash). Fix that by using a typedef
instead so that the CUDA compiler too will use an integer type in the
PTX it generates.
Maniphest Tasks: T101222
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
Allow keyboard layouts which include "dead keys" to enter diacritics
by calling MapVirtualKeyW even when not key_down.
See D16770 for more details.
Differential Revision: https://developer.blender.org/D16770
Reviewed by Campbell Barton
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
