Expose the "Connected" mode from the weld modifier in the
"Merge by Distance" geometry node. This method only merges
vertices along existing edges, but it can be much faster
because it doesn't have to build a KD Tree of all selected
points.
Differential Revision: https://developer.blender.org/D14321
Add "for_write" on function names that retrieve mutable data arrays.
Though this makes function names longer, it's likely worth it because
it allows more easily using the const functions in a non-const context,
and reduces cases of mistakenly retrieving with edit access.
In the long term, this situation might change more if we implement
attributes storage that is accessible directly on `CurvesGeometry`
without duplicating the attribute API on geometry components,
which is currently the rough plan.
Differential Revision: https://developer.blender.org/D14562
Change uses of "Hair" in Render Settings UI in the property editor
and the "Hair Info" node to use the "Curves" name to reflect the
design described in T95355, where hair is just a use case of a more
general curves data type.
While these settings still affect the particle hair system,
the idea is that if we have to choose one naming scheme to align
with, we should choose the option that aligns with future plans
and current development efforts, especially since the particle
system is considered a legacy feature.
A few notes:
- "Principled Hair BSDF" is not affected since it's meant for hair.
- Python API property identifiers are not affected.
Differential Revision: https://developer.blender.org/D14573
The last length value was not initialized, and all length values were
moved one position towards the front of each curve incorrectly.
Also fix an assert when a curve only had a single point.
color attribute system.
This commit removes sculpt colors from experimental
status and unifies it with vertex colors. It
introduces the concept of "color attributes", which
are any attributes that represents colors. Color
attributes can be represented with byte or floating-point
numbers and can be stored in either vertices or
face corners.
Color attributes share a common namespace
(so you can no longer have a floating-point
sculpt color attribute and a byte vertex color
attribute with the same name).
Note: this commit does not include vertex paint mode,
which is a separate patch, see:
https://developer.blender.org/D14179
Differential Revision: https://developer.blender.org/D12587
Ref D12587
This commit moves declarations that depend on `FN_field.hh` out of
`BKE_geometry_set.hh` into `BKE_geometry_fields.hh`. This helps to
reduce the number of areas that need to depend on the functions module,
which recently came in in review of D11591.
In the future we may have a library of standard field inputs in order to
make composing algorithms easier, so it makes sense to have a header
that could contain them and some basic related utilities relating the
concepts of geometry and fields.
Reducing use of unnecessary headers may also reduce compilation time.
Differential Revision: https://developer.blender.org/D14517
This commit ports the "Set Handle Positions" and "Set Hanle Type"
nodes to use the new curves data-block. The nodes become simpler
and likely much faster too, though they're usually not the bottleneck
anyway.
Most of the code is ported from `BezierSpline` directly. The majority
of the complexity comes from the interaction between different
automatically calculated handle types. In comparison `BezierSpline`,
the calculation of auto handles is done eagerly-- mostly because it's
simpler. Eventually lazy calculation might be good to add.
Differential Revision: https://developer.blender.org/D14464
It's better to use some local/stable identifiier to avoid relying on
the data not being freed in between creating the search menu and
the exec function. This is similar to c473b2ce8b.
This commit re-implements the resample curve node to use the new curves
type instead of CurveEval. The largest changes come from the need to
keep track of offsets into the point attribute arrays, and the fact
that the attributes for all curves are stored in a flat array.
Another difference is that a bit more of the logic is handled by
building of the field network inputs. The idea is to let the field
evaluator handle potential optimizations while making the rest of the
code simpler.
When resampling 1 million small poly curves,the node is about 6
times faster compared to 3.1 on my hardware (500ms to 80ms).
This also adds support for Catmull Rom curve inputs.
Differential Revision: https://developer.blender.org/D14435
There were multiple issues at hand here:
- The default value has been changed to `{0, 0, 1}` see: rB25f1783673de636a6f0ca4457df8c05bc685981a
- The output needs the subtype set `PROP_DIRECTION`
- The noder properties were missing in `node_composit_set_butfunc`
Fixes T96860
Using the evaluated lengths cache from 72d25fa41d, re-implement
the curve parameter node with the new data structure. Conceptually
it works the same way, but the code is restructured and cleaned up
a bit as well. This also adds support for Catmull Rom curves.
Differential Revision: https://developer.blender.org/D14461
Rename "size" variables and functions to use "num" instead,
based on T85728 (though this doesn't apply to simple C++
containers, it applies here). Rename "range" to "points" in
some functions, so be more specific.
Differential Revision: https://developer.blender.org/D14431
The Output Properties > Output panel now has a Color Management subpanel to
override scene settings. When set to Override instead of Follow Scene, there
are settings to:
* For OpenEXR, choose a (linear) colorspace for RGBA passes
* For other file formats, use different display/view/look/exposure/gamma
These settings affect animation render output, image save of renders and the
compositor file output node. Additionally, the image save operator and
compositor file output nodes also support overriding color management.
Includes some layout changes to the relevant panels to accomdate the new
settings and to improve consistency. Ideally subpanels would be used to better
organize these settings, however nodes and operators don't currently support
creating subpanels.
Differential Revision: https://developer.blender.org/D14402
Connecting to some sockets of a few nodes via the drag link search
would fail and trigger an assert, because the picked socket wasn't
available. This was due to some sockets only being available with
certain settings.
This patch fixes these cases by adding the availability conditions of
the socket to the node declaration with the `make_available` method
or manually adding a `node_link_gather_search` function.
Differential Revision: https://developer.blender.org/D14283
Currently there is a "calc_face_normal" argument to mesh to bmesh
conversion, but vertex normals had always implicitly inherited whatever
dirty state the mesh input's vertex normals were in. Probably they were
most often assumed to not be dirty, but this was never really correct in
the general case.
Ever since the refactor to move vertex normals out of mesh vertices,
cfa53e0fbe, the copying logic has been explicit: copy the
normals when they are not dirty. But it turns out that more control is
needed, and sometimes normals should be calculated for the resulting
BMesh.
This commit adds an option to the conversion to calculate vertex
normals, true by default. In almost all places except the decimate
and edge split modifiers, I just copied the value of the
"calc_face_normals" argument.
Differential Revision: https://developer.blender.org/D14406
Make a copy of ImageFormatData that contains the effective color management
settings, and pass that along to the various functions. This will make it
possible to add more complex logic later.
For compositing nodes, passing along view and display settings through
many functions made it harder to add additional settings, so just get those
from the scene now.
Differential Revision: https://developer.blender.org/D14401
Also fixes missing code to read/write/free/copy color management settings
in various places. This can't be set through the UI currently, but still
should be handled consistently.
Create a function on CurvesGeometry that can also be used for an edit
mode operator in the future. Dealing with CustomData directly means the
code is a bit more verbose than would be ideal, but this would be a
simple thing to clean up in the future if we get an attribute API here.
Also change the reverse node to first work on a read-only geometry
component, and only get write access if there is a curve selected.
Differential Revision: https://developer.blender.org/D14375
This will mostly just remove the overhead of converting
to and from the old curves type, though it also does open
some opportunities for multi-threading in the future.
Make the new curves' translate and transform functions also affect
the handle position attributes.
Differential Revision: https://developer.blender.org/D14372
Remove the conversion to and from `CurveEval` by supporting the
new Curves data-block in the node. This allows for some simplifications
to the code, as well as a fix for transfering curve domain attributes
when duplicating the curve domain.
The performance improvements (obverved through the timings overlay)
can be relatively massive with many curves. When duplicating 10000
4-point curves to become 2 million curves, I observed an approximate
150x improvement, from about 3 seconds to about 20ms.
- Pass less redundant information in function arguments.
- Use `IndexRange` more instead of direct offset calculations.
- Use specific geometry component types for specialized functions.
- Use const arguments.
- Declare variables closer to where they are created or used.
- Remove some redundant logic.
- Simplify the description for the output geometry.
