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.

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.