| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Correct trim for cyclical curves mentioned in T101379, splitting the
curves if the start/endpoint is at the 'loop point'.
Correct implementation based on comments in D14481, request was made to
use 'foreach_curve_by_type' to computing the point lookups.
Included corrections from D16066 as it may not be a adopted solution.
Exposed selection input by adding it as input to the node.
Note: This is disabled for 3.4 to avoid making UI changes in Bcon3.
Differential Revision: https://developer.blender.org/D16161
|
|
These functions provided little benefit compared to simply setting
the function pointers directly.
|
|
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
|
|
https://wiki.blender.org/wiki/Style_Guide/C_Cpp#C.2B.2B_Type_Cast
This was discussed in https://devtalk.blender.org/t/rfc-style-guide-for-type-casts-in-c-code/25907.
|
|
`CurveEval` was added for the first iteration of geometry nodes curve
support. Since then, it has been replaced by the new `Curves` type
which is designed to be much faster for many curves and better
integrated with the rest of Blender. Now that all curve nodes have
been moved to use `Curves` (T95443), the type can be removed,
along with the corresponding geometry component.
|
|
The trim functionality is implemented in the geometry module, and
generalized a bit to be potentially useful for bisecting in the future.
The implementation is based on a helper type called `IndexRangeCyclic`
which allows iteration over all control points between two points on a
curve.
Catmull Rom curves are now supported-- trimmed without resampling first.
However, maintaining the exact shape is not possible. NURBS splines are
still converted to polylines using the evaluated curve concept.
Performance is equivalent or faster then a 3.1 build with regards to
node timings. Compared to 3.3 and 3.2, it's easy to observe test cases
where the node is at least 3 or 4 times faster.
Differential Revision: https://developer.blender.org/D14481
|
|
Using the same `GeometryComponentFieldContext` for all situations,
even when only one geometry type is supported is misleading, and mixes
too many different abstraction levels into code that could be simpler.
With the attribute API moved out of geometry components recently,
the "component" system is just getting in the way here.
This commit adds specific field contexts for geometry types: meshes,
curves, point clouds, and instances. There are also separate field input
helper classes, to help reduce boilerplate for fields that only support
specific geometry types.
Another benefit of this change is that it separates geometry components
from fields, which makes it easier to see the purpose of the two concepts,
and how they relate.
Because we want to be able to evaluate a field on just `CurvesGeometry`
rather than the full `Curves` data-block, the generic "geometry context"
had to be changed to avoid using `GeometryComponent`, since there is
no corresponding geometry component type. The resulting void pointer
is ugly, but only turns up in three places in practice. When Apple clang
supports `std::variant`, that could be used instead.
Differential Revision: https://developer.blender.org/D15519
|
|
Previously, curves sculpt tools only worked on original data. This was
very limiting, because one could effectively only sculpt the curves when
all procedural effects were turned off. This patch adds support for curves
sculpting while looking the result of procedural effects (like deformation
based on the surface mesh). This functionality is also known as "crazy space"
support in Blender.
For more details see D15407.
Differential Revision: https://developer.blender.org/D15407
|
|
Previously, things like materials, symmetry, and selection options
stored on `Curves` weren't copied to the result in nodes like the
subdivide and resample nodes. Now they are, which fixes some
unexpected behavior and allows visualization of the sculpt mode
selection.
In the realize instances and join nodes the behavior is the same as
for meshes, the parameters are taken from the first (top) input.
I also refactored some functions to return a `CurvesGeometry` by-value,
which makes it the responsibility of the node to copy the parameters.
That should make the algorithms more reusable in other situations.
Differential Revision: https://developer.blender.org/D15408
|
|
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is
accessible from RNA and C code. The second is implemented with `GeometryComponent`
and is only accessible in C++ code. The second is widely used, but only being
accessible through the `GeometrySet` API makes it awkward to use, and even impossible
for types that don't correspond directly to a geometry component like `CurvesGeometry`.
This patch adds a new attribute API, designed to replace the `GeometryComponent`
attribute API now, and to eventually replace or be the basis of the other one.
The basic idea is that there is an `AttributeAccessor` class that allows code to
interact with a set of attributes owned by some geometry. The accessor itself has
no ownership. `AttributeAccessor` is a simple type that can be passed around by
value. That makes it easy to return it from functions and to store it in containers.
For const-correctness, there is also a `MutableAttributeAccessor` that allows
changing individual and can add or remove attributes.
Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer
to the owner of the attribute data. The second is a pointer to a struct with
function pointers, that is similar to a virtual function table. The functions
know how to access attributes on the owner.
The actual attribute access for geometries is still implemented with the `AttributeProvider`
pattern, which makes it easy to support different sources of attributes on a
geometry and simplifies dealing with built-in attributes.
There are different ways to get an attribute accessor for a geometry:
* `GeometryComponent.attributes()`
* `CurvesGeometry.attributes()`
* `bke::mesh_attributes(const Mesh &)`
* `bke::pointcloud_attributes(const PointCloud &)`
All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`.
Differential Revision: https://developer.blender.org/D15280
|
|
This is clearer about what is actually happening (VArray is small
enough to be a by-value type and is constructed on demand, while
only the generic virtual array is stored).
|
|
Replace tot/amount & size with num, in keeping with T85728.
|
|
Similar to 245722866d6977c8b, just another function I missed before.
|
|
Ref T95355
|
|
This commit changes `CurveComponent` to store the new curve
type by adding conversions to and from `CurveEval` in most nodes.
This will temporarily make performance of curves in geometry nodes
much worse, but as functionality is implemented for the new type
and it is used in more places, performance will become better than
before.
We still use `CurveEval` for drawing curves, because the new `Curves`
data-block has no evaluated points yet. So the `Curve` ID is still
generated for rendering in the same way as before. It's also still
needed for drawing curve object edit mode overlays.
The old curve component isn't removed yet, because it is still used
to implement the conversions to and from `CurveEval`.
A few more attributes are added to make this possible:
- `nurbs_weight`: The weight for each control point on NURBS curves.
- `nurbs_order`: The order of the NURBS curve
- `knots_mode`: Necessary for conversion, not defined yet.
- `handle_type_{left/right}`: An 8 bit integer attribute.
Differential Revision: https://developer.blender.org/D14145
|
|
f3ef0763b41155e623 introduced a file by mistake, and didn't add
a new enum type to many switch cases. Sorry for the noise.
|
|
Though this is less aesthetically pleasing, it makes the transition to the
new curves type (T95941) a bit simpler, and it has to be done anyway.
|
|
This will make the transition to the new curves data structure
a bit simple, since the handle types can be copied directly between
the two. The change to CurveEval is simple because it is runtime-only.
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
This flag is only used a few small cases, so instead
of setting the flag for every node only set the
required flag for the nodes that require it.
Mostly the flag is used to set `ntype.flag = NODE_PREVIEW`
For nodes that should have previews by default which
is only some compositor nodes and some texture nodes.
The frame node also sets the `NODE_BACKGROUND` flag.
All other nodes were setting a flag of 0 which has no purpose.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D13699
|
|
|
|
Some nodes didn't check the type of the link's socket for filtering.
Do this with a combination of manually calling the node tree's validate
links function and using the helper function for declarations.
Also clean up a few cases that added geometry sockets manually
when they can use the simpler helper function.
|
|
This commit adds a search menu when links are dragged above empty
space. When releasing the drag, a menu displays all compatible
sockets with the source link. The "main" sockets (usually the first)
are weighted above other sockets in the search, so they appear first
when you type the name of the node.
A few special operators for creating a reroute or a group input node
are also added to the search.
Translation is started after choosing a node so it can be placed
quickly, since users would likely adjust the position after anyway.
A small "+" is displayed next to the cursor to give a hint about this.
Further improvements are possible after this first iteration:
- Support custom node trees.
- Better drawing of items in the search menu.
- Potential tweaks to filtering of items, depending on user feedback.
Thanks to Juanfran Matheu for developing an initial patch.
Differential Revision: https://developer.blender.org/D8286
|
|
The `node_storage` functions to retrieve const and mutable structs
from a node are generated by a short macro that can be placed at the
top of each relevant file. I use this in D8286 to make code snippets
in the socket declarations much shorter, but I thought it would be
good to use it consistently everywhere else too.
The functions are also useful to avoid copy and paste errors,
like the one corrected in the cylinder node in this commit.
Differential Revision: https://developer.blender.org/D13491
|
|
With this commit, we no longer use the prefixes for every node type
function like `geo_node_translate_instances_`. They just added more
places to change when adding a new node, for no real benefit.
Differential Revision: https://developer.blender.org/D13337
|
|
This puts all static functions in geometry node files into a new
namespace. This allows using unity build which can improve
compile times significantly (P2578).
* The name space name is derived from the file name. That makes
it possible to write some tooling that checks the names later on.
The file name extension (`cc`) is added to the namespace name as
well. This also possibly simplifies tooling but also makes it more
obvious that this namespace is specific to a file.
* In the register function of every node, I added a namespace alias
`namespace file_ns = blender::nodes::node_geo_*_cc;`. This avoids
some duplication of the file name and may also simplify tooling,
because this line is easy to detect. The name `file_ns` stands for "file
namespace" and also indicates that this namespace corresponds to
the current file. In the beginning I used `node_ns` but `file_ns` is more
generic which may make it more suitable when we want to use unity
builds outside of the nodes modules in the future.
* Some node files contain code that is actually shared between
different nodes. For now I left that code in the `blender::nodes`
namespace and moved it to the top of the file (couldn't move it to
the bottom in all cases, so I just moved it to the top everywhere).
As a separate cleanup step, this shared code should actually be
moved to a separate file.
Differential Revision: https://developer.blender.org/D13330
|
|
This cleans up part of the code that still set the flag manually. Also, this
change helps with D13246 because it makes it easier to tag the node
tree as changed when the availability of a socket changed.
|
|
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
|
|
As part of the refactor to the node declaration builders, we had hoped
to add a regular expression specifically for these socket names, but
recent discussions have revealed that using the translation marker
macros is the preferred solution.
If the names and descriptions were exposed to RNA, these would not
be necessary. However, that may be quite complicated, since sockets
are all instances of the same RNA types.
Differential Revision: https://developer.blender.org/D13033
|
|
Previously, every node had to create warnings for unsupported input
geometry manually. Now this is automated. Nodes just have to specify
the geometry types they support in the node declaration.
Differential Revision: https://developer.blender.org/D12899
|
|
Previously, when the start input was greater than the end input,
the spline was resized to a single point. That is correct, but the
single point wasn't placed properly along the spline. Now, it is
placed according to the "Start" value, as if the trim started, but
couldn't continue because the "End" value was smaller.
This behavior is handled with a separate code path to keep each
simpler and avoid special cases. Any cleanup to reduce duplication
should focus on making each code path shorter separately rather
than merging them.
Also included are some changes to `lookup_control_point_position`
to support cyclic splines, though this single-point method is still
disabled on cyclic splines for consistency.
|
|
|
|
Re-alphabetize the main add menu.
Rename Node ID Names:
FloatCompare => CompareFloats
AttributeCapture => CaptureAttribute
Boolean => MeshBoolean
CurveFill => FillCurve
CurveFillet => FilletCurve
CurveReverse => ReverseCurve
CurveSample => SampleCurve
CurveResmaple => ResampleCurve
CurveSubdivide => SubdivideCurve
CurveTrim => TrimCurve
MaterialReplace => ReplaceMaterial
MeshSubdivide => SubdivideMesh
EdgeSplit => SplitEdges
Differential Revision: https://developer.blender.org/D12865
|
|
Attribute Capture => Capture Attribute
Curve Fill => Fill Curve
Curve Fillet => Fillet Curve
Curve Reverse => Reverse Curve
Curve Sample => Sample Curve
Curve Subdivide => Subdivide Curve
Curve Trim => Trim Curve
Material Assign => Assign Material
Material Replace => Replace Material
Mesh Subdivide => Subdivide Mesh
Float Compare => Compare Float
Boolean => Mesh Boolean
Differential Revision: https://developer.blender.org/D12798
Task: https://developer.blender.org/T91682
|
|
This update allows the Trim Curve node to use float field inputs
for the start and end inputs. These fields are evaluated on the
spline domain.
Differential Revision: https://developer.blender.org/D12744
|
|
As described in T91672, often it can be much more efficient to run each
node only on the unique geometry of the instances, rather than realizing
all instances and potentially processing redundant data. Sometimes the
performance difference can be completely smooth vs. completely unusable.
Geometry nodes used to hide that choice from users by always realizing
instances, but recently we have decided to expose it. So this commit
makes nodes run once per unique reference in the entire tree of nested
instances in their input geometries, continuing the work started in
rB0559971ab377 and rBf94164d89629f0d2. For the old behavior, a realize
instances node can be added before the nodes, which is done in the
versioning code.
Differential Revision: https://developer.blender.org/D12656
|
|
The default end factor should be 1. The proper value for the default end
length is somewhat arbitrary, but it shouldn't be zero.
|
|
Incorrect renaming and use of enum after search and replace.
|
|
|
|
The enum called "interpolate" was really a choice of methods for mapping
inputs to positions on the curve, whereas the "sample" enum was used to
define a way to create a whole set of new points from the curve, without
any input parameters. The "re-sample" vs. "sample" naming makes that
distinction better.
|
|
This implements the initial core framework for fields and anonymous
attributes (also see T91274).
The new functionality is hidden behind the "Geometry Nodes Fields"
feature flag. When enabled in the user preferences, the following
new nodes become available: `Position`, `Index`, `Normal`,
`Set Position` and `Attribute Capture`.
Socket inspection has not been updated to work with fields yet.
Besides these changes at the user level, this patch contains the
ground work for:
* building and evaluating fields at run-time (`FN_fields.hh`) and
* creating and accessing anonymous attributes on geometry
(`BKE_anonymous_attribute.h`).
For evaluating fields we use a new so called multi-function procedure
(`FN_multi_function_procedure.hh`). It allows composing multi-functions
in arbitrary ways and supports efficient evaluation as is required by
fields. See `FN_multi_function_procedure.hh` for more details on how
this evaluation mechanism can be used.
A new `AttributeIDRef` has been added which allows handling named
and anonymous attributes in the same way in many places.
Hans and I worked on this patch together.
Differential Revision: https://developer.blender.org/D12414
|
|
Previously, built-in nodes had to implement "socket templates"
(`bNodeSocketTemplate`) to tell Blender which sockets they have.
It was nice that this was declarative, but this approach was way
too rigid and was cumbersome to use in many cases.
This commit starts to move us away from this rigid structure
by letting nodes implement a function that declares the sockets
the node has. Right now this is used as a direct replacement
of the "socket template" approach to keep the refactor smaller.
It's just a bit easier to read and write.
In the future we want to support more complex features like
dynamic numbers of sockets and type inferencing. Those features
will be easier to build on this new approach.
This new approach can live side by side with `bNodeSocketTemplate`
for a while. That makes it easier to update nodes one by one.
Note: In `bNodeSocketTemplate` socket identifiers were made
unique automatically. In this new approach, one has to specify
unique identifiers manually (unless the name is unique already).
Differential Revision: https://developer.blender.org/D12335
|
|
|
|
|
|
The code used `Spline::LookupResult` in a way that referred to evaluated
points and control points interchangeably. That didn't affect the logic,
but the code became harder to read. Instead, introduce a local struct
to contain the data in a more obvious way.
|
|
This node implements shortening each spline in the curve based on
either a length from the start of each spline, or a factor of the
total length of each spline, similar to the "Start & End Mapping"
panel of curve properties.
For Bezier curves, the first and last control points are adjusted
to maintain the shape of the curve, but NURB splines are currently
implicitly converted to poly splines.
The node is implemented to avoid copying where possible, so it outputs
a changed version of the input curve rather than a new one.
Differential Revision: https://developer.blender.org/D11901
|
