Commit Graph

24 Commits

Author SHA1 Message Date
e9f82d3dc7 Curves: Remove redundant custom data pointers
These mutable pointers present problems with ownership in relation to
proper copy-on-write for attributes. The simplest solution is to just
remove them and retrieve the layers from  `CustomData` when they are
needed. This also removes the complexity and redundancy of having to
update the pointers as the curves change. A similar change will apply
to meshes and point clouds.

One downside of this change is that it makes random access with RNA
slower. However, it's simple to just use the RNA attribute API instead,
which is unaffected. In this patch I updated Cycles to do that. With
the future attribute CoW changes, this generic approach makes sense
because Cycles can just request ownership of the existing arrays.

Differential Revision: https://developer.blender.org/D15486
2022-07-19 18:01:04 -05:00
d58072caf4 Fix: missing geometry copy before modifying it
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.
2022-07-12 16:27:06 +02:00
b876ce2a4a Geometry Nodes: new geometry attribute API
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
2022-07-08 16:16:56 +02:00
c7e4c43072 Cleanup: Remove unused BKE_spline.hh includes 2022-06-05 21:00:03 +02:00
44bac4c8cc Cleanup: use 'e' prefix for enum types
- CustomDataType -> eCustomDataType
- CustomDataMask -> eCustomDataMask
- AttributeDomain -> eAttrDomain
- NamedAttributeUsage -> eNamedAttrUsage
2022-06-01 15:38:48 +10:00
ceff1c2f65 Cleanup: spelling, unbalanced doxy sections 2022-05-25 12:46:55 +10:00
ee363ee7b3 Cleanup: Use standard variable names for curves 2022-05-13 18:44:09 +02:00
42e275a7d4 Cleanup: use '_num' suffix, mostly for curves & spline code
Replace tot/amount & size with num, in keeping with T85728.
2022-05-11 13:38:00 +10:00
be0417d690 Cleanup: Move curve length field input to blenkernel
To use in the geometry module when the resample curves code
is moved there (T97448).
2022-05-05 12:41:48 +02:00
f431be224f Curves: Cache the number of curves of each type
Remembering the number of curves of every type makes it fast to know
whether processing specific to a single curve type has to be done.
This information was accessed in quite a few places, so this should be
an overall reduction in overhead for the new curves type.

The cache is computed eagerly, in other words every time after changing
the curve types. In order to reduce verbosity I added helper functions
for some common ways to set the types.

Differential Revision: https://developer.blender.org/D14732
2022-04-25 13:40:07 -05:00
078aa677b6 Fix: Curves: Add missing builtin attribute definition 2022-04-13 17:05:35 -05:00
a8ee279aa9 Fix: Use consistent type for nurbs order attribute
An 8 bit integer should be enough for now. We can change this if we ever
want to allow increasing the order past 256.
2022-04-13 17:00:18 -05:00
ceed37fc5c Curves: Port tangent and normal calculation to the new data-block
Port the "Normal" and "Curve Tangent" nodes to the new curves data-block
to avoid the conversion to `CurveEval`. This should make them faster by
avoiding all that copying, but otherwise nothing else has changed.

This also includes a fix to move the normal mode as a built-in curve
attribute when converting to and from `CurveEval`. The attribute is
needed because the option is used implicitly in many nodes currently.

Differential Revision: https://developer.blender.org/D14609
2022-04-09 12:46:30 -05:00
502d16e667 Fix: Various fixes and cleanups in new curves code
- Use "curve" instead of "spline" in comments
- Use non-plural variable names
- Tag topology dirty after resolution modified rather than positions
- Reorder enum values to change which value is zero (and the default)
- Remove a duplicate unused variable
2022-04-08 17:50:00 -05:00
b84255f590 Curves: Port legacy curve viewport drawing to the new data-block
Instead of using `CurveEval` to draw the curve wire edges, use
the new `Curves` data-block, which is already built as part of
an object's evaluated geometry set whenever there is a
`CurveComponent`.

This means that we can remove `Curve`'s temporary ownership
of `CurveEval` for drawing (added in 9ec12c26f1),
which caused a memory leak as described in T96498.

In my testing this improved performance by around 1.5x during
viewport playback, back to the performance of 3.1 before the
curve data structure transition started.

The next step of using the GPU to do the final curve evaluation
for the viewport is described in T96455, but is unrelated.

Differential Revision: https://developer.blender.org/D14551
2022-04-05 11:36:12 -05:00
5c80543c43 Cleanup: Move geometry set fields to a separate header
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
2022-04-01 08:40:45 -05:00
6e72e3fdb2 Cleanup: Further renaming in new curves code
A follow-up to e253f9f66d. Follow the policy from T85728
completely (using "num" as a prefix) and rename another function.
2022-03-24 20:48:08 -05:00
e253f9f66d Cleanup: Adjust naming in new curves code
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
2022-03-23 23:05:46 -05:00
3e16f3b3ef BLI: move generic data structures to blenlib
This is a follow up to rB2252bc6a5527cd7360d1ccfe7a2d1bc640a8dfa6.
2022-03-19 08:26:29 +01:00
887ccb8537 Fix T96152: Crash realizing curve instances
The "curve_type" was transferred to instances because it isn't a
built-in curve attribute. Then it was interpolated as a point
domain attribute from the instance domain in the realize
instances node.

The fix was just missing from 9ec12c26f1.
`curve_type` needs to be marked as a built-in attribute.
2022-03-04 22:28:57 -05:00
94a4dddb1b Fix: Don't tag curves component cache dirty for radius
Changing the radius does not invalidate a cache on
`CurvesGeometry`.
2022-02-28 17:28:54 -05:00
9ec12c26f1 Geometry Nodes: Begin conversion to new curves
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
2022-02-28 10:46:34 -05:00
06bc20f61a Fix: Errors in previous cleanup commit
f3ef0763b4 introduced a file by mistake, and didn't add
a new enum type to many switch cases. Sorry for the noise.
2022-02-22 22:15:03 -05:00
f3ef0763b4 Cleanup: Use new curves type enum for CurveEval
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.
2022-02-22 21:52:48 -05:00