How to handle curve object evaluation to mesh data #89676

New Issue

Hans Goudey · 2021-07-06T07:21:30+02:00

Hans Goudey commented

2021-07-06 07:21:30 +02:00

Background

Currently curves in Blender evaluate to quite a few different data structures:

The control points (Bezier, NURBS, or Poly)
A cache of evaluated points, also used for curve deform (BevList)
A "mesh-like" data structure for storing the implicitly created surfaces or wire edges, visible only when there are no modifiers (DispList)
Finally, and in addition to the previous items, mesh data, when there are modifiers (Mesh).

You might think this mess of data structures doesn't necessarily influence users, but it inevitably does, as can be expected when the internal representation differs from what is presented in the UI by a lot over the years. Here are some of the downsides of this approach:

Other than the flag "work on control points" with a little icon in the modifier header, historically it has been nearly impossible to tell where the implicit conversion to DispList or to Mesh happened in the modifier stack.
The conversions influence things like what happens with curve deform, what other modifiers referencing the curve object see, and often things like what is exported. The different cases were often handled inconsistently, and the result could be hard to predict.
Coding features for curves was difficult because of this lack of clarity, and they often end up less intuitive.

The generated surface, either "Mesh" or "DispList" historically had to be "part of the curve" because objects could only really evaluate to their original data type. Now, with the concept of geometry sets, we have so much more flexibility-- a curve object can evaluate to a mesh, a curve, a point cloud, or even a volume, and even all at the same time! And the result is easy to understand because of nodes and features like the spreadsheet.

The Problem

In geometry nodes, curve data is just the control points, and the evaluated points implicitly. Any surface generation happens explicitly with nodes like the curve to mesh node. This is what users expect, because these are the data types they recognize in Blender.

However, during evaluation, curve objects still generate surface data, the data generated when changing settings in the "Geometry" panel of curve objects.

So, which data do we import when we import a curve into geometry nodes? Whether through a modifier on the curve object or the object info node?

The implicitly generated surface This makes the "Geometry" panel as useful as it could be, but since the data would be a mesh, using the curve nodes wouldn't be possible.
Only the curve This is currently what happens-- the curve with pre-tesselation deformation modifiers applied is imported into the node tree.
Both Potentially a very weird option, this would be equivalent to importing the joined result of the curve to mesh node with the original curve and outputting that. Maybe a useful option, but is significantly more complicated.

The Proposal

Here is my proposed solution to this problem:

In terms of evaluated data, a curve uses the definition from geometry nodes: it is only the wire edges. Any evaluated surface is a mesh.
In the short term (to get the modifier working on curve objects), curve objects are imported into geometry nodes as a curve, unless the items in the "Geometry" panel are changed so that the curve has an implicit surface, in which case it would be imported as a mesh.
In the longer term (for 3.0 potentially), phase out these implicit surface options, as they are possible to create with nodes.

In general I think node-based versions of these features will be significantly more flexible, more powerful, and easier to understand even. These implicit evaluation options would be replaced by a few nodes-- the "Curve to Mesh" node, "Curve Trim" ("Start & End Mapping"), "Curve Sample" (transferring taper from another curve), and "Curve Fill" (2D curves) nodes in the future. The options could be moved with versioning so old files still worked.

## Background Currently curves in Blender evaluate to quite a few different data structures: 1. The control points (Bezier, NURBS, or Poly) 2. A cache of evaluated points, also used for curve deform (`BevList`) 3. A "mesh-like" data structure for storing the implicitly created surfaces or wire edges, visible only when there are no modifiers (`DispList`) 4. Finally, and in addition to the previous items, mesh data, when there are modifiers (`Mesh`). You might think this mess of data structures doesn't necessarily influence users, but it inevitably does, as can be expected when the internal representation differs from what is presented in the UI by a lot over the years. Here are some of the downsides of this approach: - Other than the flag "work on control points" with a little icon in the modifier header, historically it has been nearly impossible to tell where the implicit conversion to `DispList` or to `Mesh` happened in the modifier stack. - The conversions influence things like what happens with curve deform, what other modifiers referencing the curve object see, and often things like what is exported. The different cases were often handled inconsistently, and the result could be hard to predict. - Coding features for curves was difficult because of this lack of clarity, and they often end up less intuitive. The generated surface, either "Mesh" or "DispList" historically had to be "part of the curve" because objects could only really evaluate to their original data type. Now, with the concept of geometry sets, we have so much more flexibility-- a curve object can evaluate to a mesh, a curve, a point cloud, or even a volume, and even all at the same time! And the result is easy to understand because of nodes and features like the spreadsheet. ## The Problem In geometry nodes, curve data is just the control points, and the evaluated points implicitly. Any surface generation happens explicitly with nodes like the curve to mesh node. This is what users expect, because these are the data types they recognize in Blender. However, during evaluation, curve objects still generate surface data, the data generated when changing settings in the "Geometry" panel of curve objects. ![image.png](https://archive.blender.org/developer/F10213055/image.png) So, which data do we import when we import a curve into geometry nodes? Whether through a modifier on the curve object or the object info node? - **The implicitly generated surface** This makes the "Geometry" panel as useful as it could be, but since the data would be a mesh, using the curve nodes wouldn't be possible. - **Only the curve** This is currently what happens-- the curve with pre-tesselation deformation modifiers applied is imported into the node tree. - **Both** Potentially a very weird option, this would be equivalent to importing the joined result of the curve to mesh node with the original curve and outputting that. Maybe a useful option, but is significantly more complicated. ## The Proposal Here is my proposed solution to this problem: 1. In terms of evaluated data, a curve uses the definition from geometry nodes: it is *only* the wire edges. Any evaluated surface is a mesh. 2. In the short term (to get the modifier working on curve objects), curve objects are imported into geometry nodes as a curve, unless the items in the "Geometry" panel are changed so that the curve has an implicit surface, in which case it would be imported as a mesh. 3. In the longer term (for 3.0 potentially), phase out these implicit surface options, as they are possible to create with nodes. In general I think node-based versions of these features will be significantly more flexible, more powerful, and easier to understand even. These implicit evaluation options would be replaced by a few nodes-- the "Curve to Mesh" node, "Curve Trim" ("Start & End Mapping"), "Curve Sample" (transferring taper from another curve), and "Curve Fill" (2D curves) nodes in the future. The options could be moved with versioning so old files still worked.

Hans Goudey commented

2021-07-06 07:21:30 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Hans Goudey commented

2021-07-06 07:21:30 +02:00

Added subscriber: @HooglyBoogly

Jacques Lucke commented

2021-07-06 13:24:40 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-07-06 13:24:40 +02:00

I might be missing something but here is my take on it.

When using the Object Info node in another object:

If the final evaluated curve object is a mesh (regardless of whether the mesh comes from a modifier of from the curves geometry settings), import the data as a mesh.
If the final evaluated curve contains the (possibly displaced) tessellated curve, import that as a poly splines.
If the final evaluated curve has no surface and no modifier tessellated the curve, import all splines with their original spline types with (possibly deformed) control points.

When using a Geometry Nodes modifier on the curve object:

If the curve has been converted to a mesh already, load the data as a mesh.
If the curve has been tessellated already but has no mesh, load the data as poly splines.
If the curve has no surface and is not yet tessellated, load all splines with their original spline types.

(Both cases are pretty much the same really.)

In the long term, I agree that we should phase out the geometry settings on curves and replace them with prebuild node groups that can just be used instead.
The currently automatic conversion from control points to evaluated points and from evaluated points to mesh can be replaced with modifiers/nodes in versioning code.

I might be missing something but here is my take on it. When using the Object Info node in another object: * If the final evaluated curve object is a mesh (regardless of whether the mesh comes from a modifier of from the curves geometry settings), import the data as a mesh. * If the final evaluated curve contains the (possibly displaced) tessellated curve, import that as a poly splines. * If the final evaluated curve has no surface and no modifier tessellated the curve, import all splines with their original spline types with (possibly deformed) control points. When using a Geometry Nodes modifier on the curve object: * If the curve has been converted to a mesh already, load the data as a mesh. * If the curve has been tessellated already but has no mesh, load the data as poly splines. * If the curve has no surface and is not yet tessellated, load all splines with their original spline types. (Both cases are pretty much the same really.) ---- In the long term, I agree that we should phase out the geometry settings on curves and replace them with prebuild node groups that can just be used instead. The currently automatic conversion from control points to evaluated points and from evaluated points to mesh can be replaced with modifiers/nodes in versioning code.

Hans Goudey commented

2021-07-13 05:23:41 +02:00

Yeah, I think that's ideally how it would work. I've basically implemented that in the patch, with a caveat of not including the second option, the poly spline from a tessellated displaced DispList. The tessellated data is stored separately (it's not even used for curve deform), in a different format. Converting it to a poly spline you also lose the overridden tangents from the start and end of a Bezier spline. So that second part you mention is a little more complicated in reality anyway.

For the versioning to node implementations, we need a few more things (this list is mostly to keep track of this myself):

Curve trim node (in progress)
Curve sampling for the taper options, (in progress)
Curve fill for 2D curves (in progress)
Supporting bevel and extrusion on 2D curves
UV output on curve to mesh node
Normal smoothing (not sure how to implement this)
Curve profile widget input node
The other interpolation methods for Bezier curves (hopefully it's okay to use the same value for radius and tilt).

Yeah, I think that's ideally how it would work. I've basically implemented that in the patch, with a caveat of not including the second option, the poly spline from a tessellated displaced `DispList`. The tessellated data is stored separately (it's not even used for curve deform), in a different format. Converting it to a poly spline you also lose the overridden tangents from the start and end of a Bezier spline. So that second part you mention is a little more complicated in reality anyway. --- For the versioning to node implementations, we need a few more things (this list is mostly to keep track of this myself): - Curve trim node (in progress) - Curve sampling for the taper options, (in progress) - Curve fill for 2D curves (in progress) - Supporting bevel and extrusion on 2D curves - UV output on curve to mesh node - Normal smoothing (not sure how to implement this) - Curve profile widget input node - The other interpolation methods for Bezier curves (hopefully it's okay to use the same value for radius and tilt).

Jacques Lucke commented

2021-07-13 13:35:05 +02:00

Converting it to a poly spline you also lose the overridden tangents from the start and end of a Bezier spline.

Not sure I understand that. What overridden tangents are we talking about?

> Converting it to a poly spline you also lose the overridden tangents from the start and end of a Bezier spline. Not sure I understand that. What overridden tangents are we talking about?

Hans Goudey commented

2021-07-14 04:02:10 +02:00

In #89676#1190644, @JacquesLucke wrote:

Converting it to a poly spline you also lose the overridden tangents from the start and end of a Bezier spline.

Not sure I understand that. What overridden tangents are we talking about?

Sorry, that was really vague. Here's what I meant. Bezier splines can get their first and last tangents from the last handles, while on poly splines that information doesn't exist.
{F10223628 size=full}

Actually though, having thought about it more, I think there is another reason to avoid using implicit to-poly behavior on curves-- making it clear to the user what is deformed.
Previously all we had was the little flag in the header of curve modifiers, but with nodes this can be much more explicit. That would unify the idea that the position attribute, i.e. "what is deformed" corresponds to what you would move in edit mode. If you have a curve resample node (with an "Evaluated" mode maybe), and you deform afterwards, it's more clear than if the evaluation happens implicitly.

> In #89676#1190644, @JacquesLucke wrote: >> Converting it to a poly spline you also lose the overridden tangents from the start and end of a Bezier spline. > > Not sure I understand that. What overridden tangents are we talking about? Sorry, that was really vague. Here's what I meant. Bezier splines can get their first and last tangents from the last handles, while on poly splines that information doesn't exist. {[F10223628](https://archive.blender.org/developer/F10223628/image.png) size=full} Actually though, having thought about it more, I think there is another reason to avoid using implicit to-poly behavior on curves-- making it clear to the user what is deformed. Previously all we had was the little flag in the header of curve modifiers, but with nodes this can be much more explicit. That would unify the idea that the position attribute, i.e. "what is deformed" corresponds to what you would move in edit mode. If you have a curve resample node (with an "Evaluated" mode maybe), and you deform afterwards, it's more clear than if the evaluation happens implicitly.

Jacques Lucke commented

2021-07-14 11:57:10 +02:00

Okay, so instead of creating the poly spline, you're just creating mesh now, right? Fine with me.
Socket inspection makes checking the behavior of your patch so much easier :D

Okay, so instead of creating the poly spline, you're just creating mesh now, right? Fine with me. Socket inspection makes checking the behavior of your patch so much easier :D

Hans Goudey commented

2021-07-14 13:58:34 +02:00

In #89676#1191078, @JacquesLucke wrote:
Okay, so instead of creating the poly spline, you're just creating mesh now, right? Fine with me.
Socket inspection makes checking the behavior of your patch so much easier :D

Yep, exactly!

These quality of life improvements do seem to have multiplying benefits : )

> In #89676#1191078, @JacquesLucke wrote: > Okay, so instead of creating the poly spline, you're just creating mesh now, right? Fine with me. > Socket inspection makes checking the behavior of your patch so much easier :D Yep, exactly! These quality of life improvements do seem to have multiplying benefits : )

Duarte Farrajota Ramos commented

2021-09-12 00:38:57 +02:00

Added subscriber: @DuarteRamos

Jacques Lucke commented

2021-09-17 15:51:57 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2021-09-17 15:51:57 +02:00

Jacques Lucke self-assigned this 2021-09-17 15:51:57 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

How to handle curve object evaluation to mesh data #89676

Background

The Problem

The Proposal