New surface data-block #100127

New Issue

Hans Goudey · 2022-08-01T19:30:33+02:00

Hans Goudey commented

2022-08-01 19:30:33 +02:00

Background

Historically, surfaces, curves, and text object data has been grouped in the Curve data-block.
This is more of a historical relic than proper design, since there is little similarity in the data stored for each type.
With #95355, we already have a new data-type for curves that doesn't include the other two.
Any development of NURBS surfaces in Blender should probably head in that direction too.

Over the years there have been various attempts to contribute to and improve surfaces in Blender,
but the messy state of the code and design has made this hard.

Proposal

New Surface data-block that holds a grids of control points (separate arrays for positions, weights, and knot spans)
Surface data-blocks have an implicit evaluated surface (evaluated after modifiers) (just a Mesh internally for now) Surface object supports attributes per control point
- Multiple evaluation methods could be supported, with NURBS as the equivalent to the existing feature-set
Geometry Nodes is the main method to interact with the data prodecurally
Some nodes could output a changed surface, other nodes create meshes or curves, etc. Surface to Mesh and Sample Surface with UV are two obvious nodes
Edit mode ported from existing surface edit mode
- Initially there wouldn't need to be any changes

Future

"Solid" CAD objects are created with surface patches, so having a proper surface data-block
accessible procedurally opens door for future improvements there. Various libraries like OpenCASCADE
(used by FreeCAD) could be used to manipulate surfaces in Blender. While Blender doesn't need to
become a complete CAD tool, opening up different workflows is a more general improvement for artists too.

Allow attaching trim curves to surface in UV space (https://devtalk.blender.org/t/better-curve-surface-support/21113)
...

### Background Historically, surfaces, curves, and text object data has been grouped in the `Curve` data-block. This is more of a historical relic than proper design, since there is little similarity in the data stored for each type. With #95355, we already have a new data-type for curves that doesn't include the other two. Any development of NURBS surfaces in Blender should probably head in that direction too. Over the years there have been various attempts to contribute to and improve surfaces in Blender, but the messy state of the code and design has made this hard. ### Proposal * New `Surface` data-block that holds a grids of control points (separate arrays for positions, weights, and knot spans) **Surface data-blocks have an implicit evaluated surface (evaluated after modifiers) (just a `Mesh` internally for now)** Surface object supports attributes per control point * Multiple evaluation methods could be supported, with NURBS as the equivalent to the existing feature-set * Geometry Nodes is the main method to interact with the data prodecurally **Some nodes could output a changed surface, other nodes create meshes or curves, etc.** `Surface to Mesh` and `Sample Surface with UV` are two obvious nodes * Edit mode ported from existing surface edit mode * Initially there wouldn't need to be any changes ### Future "Solid" CAD objects are created with surface patches, so having a proper surface data-block accessible procedurally opens door for future improvements there. Various libraries like OpenCASCADE (used by FreeCAD) could be used to manipulate surfaces in Blender. While Blender doesn't need to become a complete CAD tool, opening up different workflows is a more general improvement for artists too. * Allow attaching trim curves to surface in UV space (https://devtalk.blender.org/t/better-curve-surface-support/21113) * ...

👍 5

Hans Goudey commented

2022-08-01 19:30:33 +02:00

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

Hans Goudey commented

2022-08-01 19:30:33 +02:00

Added subscriber: @HooglyBoogly

Iliya Katushenock commented

2022-08-01 19:36:00 +02:00

Added subscriber: @mod_moder

Hans Goudey commented

2022-08-01 19:40:37 +02:00

To clarify, I'm not planning on working on this now, but I'd like to settle on a design so contributors could work on this instead of being turned away. I would be happy to help anyone who wants to work on such a project.

Rygel commented

2022-08-02 04:26:23 +02:00

Added subscriber: @rygelXVI

Yuro commented

2022-08-03 03:03:49 +02:00

Added subscriber: @Yuro

Laurynas Duburas commented

2022-08-04 21:22:12 +02:00

Added subscriber: @laurynas

Laurynas Duburas commented

2022-08-05 16:51:51 +02:00

New Surface data-block that holds a grid of NURBS control points

Will it be only one grid per data-block or few?

separate arrays for positions, weights, and knot spans

Are weights meant to be in a separate array from positions?

> New Surface data-block that holds a grid of NURBS control points Will it be only one grid per data-block or few? > separate arrays for positions, weights, and knot spans Are weights meant to be in a separate array from positions?

Iliya Katushenock commented

2022-08-05 16:54:50 +02:00

This goes along with the idea of the attribute as a separate data block. How the surface geometry structure is organized will depend on the implementation.

Hans Goudey commented

2022-08-05 17:54:57 +02:00

Will it be only one grid per data-block or few?

I think it would be more than one grid, like the current surface object, and like the new "Curves" type.

I'd also imagine a similar approach to the curves object-- the control point data for all grids would be stored contiguously in one array.

Are weights meant to be in a separate array from positions?

Yeah, the idea is to move away from using specific structs like BPoint and instead use generic types like float3 and float.
That way if we want to deform the surface control points, we just need to pass the array to a generic function (like in the set position node, etc.)

>Will it be only one grid per data-block or few? I think it would be more than one grid, like the current surface object, and like the new "Curves" type. I'd also imagine a similar approach to the curves object-- the control point data for all grids would be stored contiguously in one array. >Are weights meant to be in a separate array from positions? Yeah, the idea is to move away from using specific structs like `BPoint` and instead use generic types like `float3` and `float`. That way if we want to deform the surface control points, we just need to pass the array to a generic function (like in the set position node, etc.)

👍 1

Leon Schittek commented

2022-08-05 19:01:19 +02:00

Added subscriber: @lone_noel

Daniel Zimmer commented

2022-08-06 15:53:37 +02:00

Added subscriber: @xrogueleaderx

Paul Larson commented

2022-08-08 19:14:17 +02:00

Added subscriber: @GeorgiaPacific

jorg peters commented

2022-12-12 23:22:23 +01:00

Added subscriber: @surfacionado

jorg peters commented

2022-12-12 23:22:23 +01:00

Hello Hans

we are actually good with just cirrectly rendering Bezier patches
(ie NURBS with maximal number of inserted knots = degree+1 many)
since one can always build spline surfaces in Bezier form (for example using B-splines or Polyhedral Splines).

The question is whether one should do the evaluation and rendering in software (C++)
or
use the tessellation engine (that was introduced for that purpose), i.e. a "shader" program (quite standard)

Hello Hans we are actually good with just cirrectly rendering Bezier patches (ie NURBS with maximal number of inserted knots = degree+1 many) since one can always build spline surfaces in Bezier form (for example using B-splines or Polyhedral Splines). The question is whether one should do the evaluation and rendering in software (C++) or use the tessellation engine (that was introduced for that purpose), i.e. a "shader" program (quite standard)

Hans Goudey commented

2022-12-12 23:32:13 +01:00

Hi @surfacionado. In the end I think it would be important to support both. CPU evaluation would be used to interface with other CPU algorithms. GPU evaluation could be used for rendering, and eventually more generic GPU algorithms as we move some other processing to the GPU.

As for spline types, I think the surfaces could support multiple types, just like the curves (#68981, etc.). I wouldn't imagine it would be too complex to have an initial implementation with a simple type like Bezier patches while keeping the possibility of other types open for the future.
That's basically what we have right now with the GPU evaluation of the new Curves type anyway.

Hi @surfacionado. In the end I think it would be important to support both. CPU evaluation would be used to interface with other CPU algorithms. GPU evaluation could be used for rendering, and eventually more generic GPU algorithms as we move some other processing to the GPU. As for spline types, I think the surfaces could support multiple types, just like the curves (#68981, etc.). I wouldn't imagine it would be too complex to have an initial implementation with a simple type like Bezier patches while keeping the possibility of other types open for the future. That's basically what we have right now with the GPU evaluation of the new `Curves` type anyway.

jorg peters commented

2022-12-13 00:14:29 +01:00

How do we find the Curves implementation in Blender?
If it already uses the Tessellation Engine, it should not be tricky to make the same evaluation sequence happen for Bezier surfaces by seeing how it is linked to the Blender C++ code.

How do we find the Curves implementation in Blender? If it already uses the Tessellation Engine, it should not be tricky to make the same evaluation sequence happen for Bezier surfaces by seeing how it is linked to the Blender C++ code.

Hans Goudey commented

2022-12-14 20:23:16 +01:00

Curves in Blender are undergoing a large rewrite at the moment. To find the new curves type, some terms to search for are Curves, CurvesGeometry, OB_CURVES. Some related tasks are #68981, #95355, #96455.

To use a similar process for surfaces, I do think the first step is a new data-block type as described in this task. It's a bit hard to render arbitrary data without first sending it through depsgraph evaluation.

Curves in Blender are undergoing a large rewrite at the moment. To find the new curves type, some terms to search for are `Curves`, `CurvesGeometry`, `OB_CURVES`. Some related tasks are #68981, #95355, #96455. To use a similar process for surfaces, I do think the first step is a new data-block type as described in this task. It's a bit hard to render arbitrary data without first sending it through depsgraph evaluation.

Paolo Furani commented

2022-12-29 17:56:55 +01:00

Added subscriber: @pafurijaz-4

Pieter Schiettecatte commented

2022-12-31 11:56:18 +01:00

Added subscriber: @Schiette

Bastien Montagne added this to the Core project 2023-02-09 15:42:54 +01:00

Bastien Montagne removed this from the Core project 2023-02-09 18:20:30 +01: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

New surface data-block #100127

Background

Proposal

Future