| Age | Commit message (Collapse) | Author |
|---|
|
Unused after 05952aa94d33eeb, 410a6efb747f188, and e9f82d3dc7eebad.
|
|
When allocating new `CustomData` layers, often we do redundant
initialization of arrays. For example, it's common that values are
allocated, set to their default value, and then set to some other
value. This is wasteful, and it negates the benefits of optimizations
to the allocator like D15082. There are two reasons for this. The
first is array-of-structs storage that makes it annoying to initialize
values manually, and the second is confusing options in the Custom Data
API. This patch addresses the latter.
The `CustomData` "alloc type" options are rearranged. Now, besides
the options that use existing layers, there are two remaining:
* `CD_SET_DEFAULT` sets the default value.
* Usually zeroes, but for colors this is white (how it was before).
* Should be used when you add the layer but don't set all values.
* `CD_CONSTRUCT` refers to the "default construct" C++ term.
* Only necessary or defined for non-trivial types like vertex groups.
* Doesn't do anything for trivial types like `int` or `float3`.
* Should be used every other time, when all values will be set.
The attribute API's `AttributeInit` types are updated as well.
To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and
`CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional
changes yet. Follow-up commits will change to avoid initializing
new layers where the correctness is clear.
Differential Revision: https://developer.blender.org/D15617
|
|
A geometry component may reference read-only geometry.
In this case it has to be copied before making changes to it.
This was caused by rBb876ce2a4a4638142.
|
|
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
|
|
* Make the class names more consistent.
* Implement missing move-constructors and assignment-operators.
|
|
- CustomDataType -> eCustomDataType
- CustomDataMask -> eCustomDataMask
- AttributeDomain -> eAttrDomain
- NamedAttributeUsage -> eNamedAttrUsage
|
|
Replace tot/amount & size with num, in keeping with T85728.
|
|
This is a follow up to rB2252bc6a5527cd7360d1ccfe7a2d1bc640a8dfa6.
|
|
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
|
|
This is similar to f8fe0e831ec14cc521e03df, which made the change to the
handle position attributes. This commit removes the way that setting the
`position` attribute also changes the handle position attributes. Now,
the "Set Position" node still has this behavior, but changing the
attribute directly (with the modifier's output attributes) does not.
The previous behavior was a relic of the geometry nodes design
from before fields and the set position node existed.
This makes the transition to the new curves data structure simpler.
There is more room for optimizing the Bezier case of the set position
node in the future.
|
|
The handle position attributes `handle_left` and `handle_right` had
rather complex behavior to get expected behavior when aligned or auto/
vector handles were used. In order to simplify the attribtue API and
make the transition to the new curves data structure simpler, this
commit moves that behavior from the attribute to the "Set Handle
Positions" node. When that node is used, the behavior should be the
same as before. However, if the modifier's output attributes were used
to set handle positions, the behavior may be different. That situation
is expected to be very rare though.
|
|
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 commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
|
|
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 commit moves the normal field input to `BKE_geometry_set.hh`
from the node file so that normals can be used as an implicit input to
other nodes.
Differential Revision: https://developer.blender.org/D13779
|
|
Also add groups in some files.
|
|
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
|
|
For some underlying data (e.g. spans) we had two virtual array
implementations. One for the mutable and one for the immutable
case. Now that most code does not deal with the virtual array
implementations directly anymore (since rBrBd4c868da9f97a),
we can get away with sharing one implementation for both cases.
This means that we have to do a `const_cast` in a few places, but
this is an implementation detail that does not leak into "user code"
(only when explicitly casting a `VArrayImpl` to a `VMutableArrayImpl`,
which should happen nowhere).
|
|
|
|
Differential Revision: https://developer.blender.org/D13271
|
|
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
|
|
This is a better and more general fix for T92511 and T92508 than
the ones that I committed before.
Previously, we tagged caches dirty when first accessing attributes.
This led to incorrect caches when under some circumstances. Now
cache invalidation is part of `OutputAttribute.save()`.
A nice side benefit of this change is that it may make things more
efficient in some cases, because we don't invalidate caches when
they don't have to be invalidated.
Differential Revision: https://developer.blender.org/D13009
|
|
This fixes T92511, but there is still the more general problem
described in T92508.
|
|
No virtual array should be returned instead of returning an empty span.
|
|
After the addition of the `id` attribute in rB40c3b8836b7a, the `exists`
function assumed that all attributes were stored in the custom data.
|
|
In order to address feedback that the "Stable ID" was not easy enough
to use, remove the "Stable ID" output from the distribution node and
the input from the instance on points node. Instead, the nodes write
or read a builtin named attribute called `id`. In the future we may
add more attributes like `edge_id` and `face_id`.
The downside is that more behavior is invisible, which is les
expected now that most attributes are passed around with node links.
This behavior will have to be explained in the manual.
The random value node's "ID" input that had an implicit index input
is converted to a special implicit input that uses the `id` attribute
if possible, but otherwise defaults to the index. There is no way to
tell in the UI which it uses, except by knowing that rule and checking
in the spreadsheet for the id attribute.
Because it isn't always possible to create stable randomness, this
attribute does not always exist, and it will be possible to remove it
when we have the attribute remove node back, to improve performance.
Differential Revision: https://developer.blender.org/D12903
|
|
All attributes should be writeable, it is now only needed for the
legacy `normal` attribute on meshes.
|
|
Calculating the number of points is overkill here, if there are many splines.
The `exists` check just needs to know if there are any points at all.
|
|
This commit exposes left and right bezier handles as an attribute.
Interaction basically works like edit mode. If you move an aligned
handle, it also moves the opposite handle of the control point.
The difference is that you can't edit "Auto" or "Vector" handles,
you have to first use the "Set Handle Type" node. That gives the handle
types a bit more meaning in the node tree-- changing them in edit mod
is more like a "UI override".
The attributes are named `handle_start` and `handle_end`,
which is the same name used in the curve RNA API.
A new virtual array implementation is added which handles the case of
splines that don't have these attributes, and it also calls two new
functions on `BezierSpline` to set the handle position accounting
for aligned handles.
The virtual arrays and attribute providers will be refactored
(probably templated) in the future, as a next step after the last
built-in curve attribute provider has landed.
Differential Revision: https://developer.blender.org/D12005
|
|
The generic domain interpolation algorithms didn't quite work for
selections. The interpolation would do unexpected things that
were different than the results in edit mode. The new behavior
is supposed to be the same as edit mode, although we also have
to handle face corner selections here.
Currently the code assumes that all boolean attributes should be
handled that way. I'm not sure of why that wouldn't be the case,
but if we ever need non-selection boolean attributes, that could
be supported too.
Differential Revision: https://developer.blender.org/D12488
|
|
With this commit, curve objects support the geometry nodes modifier.
Curves objects now evaluate to `CurveEval` unless there was a previous
implicit conversion (tessellating modifiers, mesh modifiers, or the
settings in the curve "Geometry" panel). In the new code, curves are
only considered to be the wire edges-- any generated surface is a mesh
instead, stored in the evaluated geometry set.
The consolidation of concepts mentioned above allows remove a lot of
code that had to do with maintaining the `DispList` type temporarily
for modifiers and rendering. Instead, render engines see a separate
object for the mesh from the mesh geometry component, and when the
curve object evaluates to a curve, the `CurveEval` is always used for
drawing wire edges.
However, currently the `DispList` type is still maintained and used as
an intermediate step in implicit mesh conversion. In the future, more
uses of it could be changed to use `CurveEval` and `Mesh` instead.
This is mostly not changed behavior, it is just a formalization of
existing logic after recent fixes for 2.8 versions last year and two
years ago. Also, in the future more functionality can be converted
to nodes, removing cases of implicit conversions. For more discussion
on that topic, see T89676.
The `use_fill_deform` option is removed. It has not worked properly
since 2.62, and the choice for filling a curve before or after
deformation will work much better and be clearer with a node system.
Applying the geometry nodes modifier to generate a curve is not
implemented with this commit, so applying the modifier won't work
at all. This is a separate technical challenge, and should be solved
in a separate step.
Differential Revision: https://developer.blender.org/D11597
|
|
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
|
|
The need for this has come up a few times.
|
|
The curve attribute delete function didn't return whether it was
successful or not.
|
|
Previously, `VArray_For_SplineToPoint` did not take ownership of the
virtual array leading to use-after-free errors.
|
|
This patch adds relatively small changes to the curve draw
cache implementation in order to draw the curve data in the
viewport. The dependency graph iterator is also modified
so that it iterates over the curve geometry component, which
is presented to users as `Curve` data with a pointer to the
`CurveEval`
The idea with the spline data type in geometry nodes is that
curve data itself is only the control points, and any evaluated
data with faces is a mesh. That is mostly expected elsewhere in
Blender anyway. This means it's only necessary to implement
wire edge drawing of `CurveEval` data.
Adding a `CurveEval` pointer to `Curve` is in line with changes
I'd like to make in the future like using `CurveEval` in more places
such as edit mode.
An alternate solution involves converting the curve wire data
to a mesh, however, that requires copying all of the data, and
since avoiding it is rather simple and is in-line with future plans
anyway, I think doing it this way is better.
Differential Revision: https://developer.blender.org/D11351
|
|
- Iterate over the mask directly instead of using an index.
- Use Span slice and copy_from instead of a lower level function.
|
|
This commit adds interpolation from the point domain to the spline
domain and the other way around. Before this, spline domain attributes
were basically useless, but now they are quite helpful as a way to use
a shared value in a contiguous group of points.
I implementented a special virtual array for the spline to points
conversion, so that conversion should be close to the ideal performance
level, but there are a few ways we could optimize the point to spline
conversion in the future:
- Use a function virtual array to mix the point values for each spline
on demand.
- Implement a special case for when the input virtual array is one of
the virtual arrays from the spline point attributes. In other words,
decrease curve attribute access overhead.
Differential Revision: https://developer.blender.org/D11376
|
|
|
|
With this patch you will be able to add and remove attributes from curve
data inside of geometry nodes. The following is currently implemented:
* Adding attributes with any data type to splines or spline points.
* Support for working with multiple splines at the same time.
* Interaction with the three builtin point attributes.
* Resampling attributes in the resample node.
The following is not implemented in this patch:
* Joining attributes when joining splines with the join geometry node.
* Domain interpolation between spline and point domains.
* More efficient ways to call attribute operations once per spline.
Differential Revision: https://developer.blender.org/D11251
|
|
There is no need for a special "copy" method with a copy constructor,
which will be necessary to explicitly copy attributes anyway.
|
|
|
|
Use the `CurveEval` function introduced in the last commit.
|
|
|
|
Not allowing external direct access to the vector of splines in the
curve will help for things like reallocating custom data when a spline
is added or removed.
|
|
This commit exposes the first spline control point attributes. The
implementation incorporates the attributes into the virtual array
system, providing efficient methods to flatten the data into a
contiguous array and to apply changes from a flattened array. This
is only part of the eventual goal, which includes changes to run
attribute nodes separately for each spline to completely avoid copying.
So far `tilt` and `radius`, the two generic attributes common to
all spline types, are implemented. The more complex `position`
attribute is also added. It requires some special handling for Bezier
splines, where the control point handles need to be moved along with
the control points. To make that work I also added automatic handle
recalculation to the Bezier spline.
Differential Revision: https://developer.blender.org/D11187
|
|
The sections aren't helpful at the moment, but I will add more code
here soon that will benefit more from the visual separation.
|
|
Retrieving data from the component can be done in a separate function
to save some repetition.
|
|
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
|
