#
How to handle curve object evaluation to mesh data #89676

Closed

opened 2021-07-06 07:21:30 +02:00 by Hans Goudey
·
11 comments

No Branch/Tag Specified

blender-v3.6-release

node-group-operators

main

brush-assets-project

asset-shelf

temp-sculpt-dyntopo

temp-sculpt-dyntopo-hive-alloc

tmp-usd-python-mtl

blender-v2.93-release

blender-v3.3-release

universal-scene-description

asset-browser-frontend-split

temp-sculpt-attr-api

blender-v3.5-release

realtime-clock

sculpt-dev

gpencil-next

bevelv2

microfacet_hair

blender-projects-basics

principled-v2

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

**Labels**

Apply labels

Interest

Alembic

Interest

Animation & Rigging

Interest

Asset Browser

Interest

Asset Browser Project Overview

Interest

Audio

Interest

Automated Testing

Interest

Blender Asset Bundle

Interest

BlendFile

Interest

Collada

Interest

Compositing

Interest

Core

Interest

Cycles

Interest

Dependency Graph

Interest

Development Management

Interest

Eevee & Viewport

Interest

Freestyle

Interest

Geometry Nodes

Interest

Grease Pencil

Interest

ID Management

Interest

Images & Movies

Interest/Import

Export

Interest

Line Art

Interest

Masking

Interest

Metal

Interest

Modeling

Interest

Modifiers

Interest

Motion Tracking

Interest

Nodes & Physics

Interest

OpenGL

Interest

Overrides

Interest

Performance

Interest

Physics

Interest

Pipeline, Assets & IO

Interest

Platforms, Builds & Tests

Interest

Python API

Interest

Render & Cycles

Interest

Render Pipeline

Interest

Sculpt, Paint & Texture

Interest

Text Editor

Interest

Translations

Interest

Triaging

Interest

Undo

Interest

USD

Interest

User Interface

Interest

UV Editing

Interest

VFX & Video

Interest

Video Sequencer

Interest

Virtual Reality

Interest

Vulkan

Interest: Wayland

Legacy

Blender 2.8 Project

Legacy

Milestone 1: Basic, Local Asset Browser

Legacy

OpenGL Error

Meta

Good First Issue

Meta

Papercut

Meta

Retrospective

Meta

Security

Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

Module

Animation & Rigging

Module

Core

Module

Development Management

Module

Eevee & Viewport

Module

Grease Pencil

Module

Modeling

Module

Nodes & Physics

Module

Pipeline, Assets & IO

Module

Platforms, Builds & Tests

Module

Python API

Module

Render & Cycles

Module

Sculpt, Paint & Texture

Module

Triaging

Module

User Interface

Module

VFX & Video

Platform

FreeBSD

Platform

Linux

Platform

macOS

Platform

Windows

Priority

High

Priority

Low

Priority

Normal

Priority

Unbreak Now!

Status

Archived

Status

Confirmed

Status

Duplicate

Status

Needs Info from Developers

Status

Needs Information from User

Status

Needs Triage

Status

Resolved

Type

Bug

Type

Design

Type

Known Issue

Type

Patch

Type

Report

Type

To Do

No Label

Interest

Alembic

Interest

Animation & Rigging

Interest

Asset Browser

Interest

Asset Browser Project Overview

Interest

Audio

Interest

Automated Testing

Interest

Blender Asset Bundle

Interest

BlendFile

Interest

Collada

Interest

Compositing

Interest

Core

Interest

Cycles

Interest

Dependency Graph

Interest

Development Management

Interest

Eevee & Viewport

Interest

Freestyle

Interest

Geometry Nodes

Interest

Grease Pencil

Interest

ID Management

Interest

Images & Movies

Interest/Import

Export

Interest

Line Art

Interest

Masking

Interest

Metal

Interest

Modeling

Interest

Modifiers

Interest

Motion Tracking

Interest

Nodes & Physics

Interest

OpenGL

Interest

Overrides

Interest

Performance

Interest

Physics

Interest

Pipeline, Assets & IO

Interest

Platforms, Builds & Tests

Interest

Python API

Interest

Render & Cycles

Interest

Render Pipeline

Interest

Sculpt, Paint & Texture

Interest

Text Editor

Interest

Translations

Interest

Triaging

Interest

Undo

Interest

USD

Interest

User Interface

Interest

UV Editing

Interest

VFX & Video

Interest

Video Sequencer

Interest

Virtual Reality

Interest

Vulkan

Interest: Wayland

Legacy

Blender 2.8 Project

Legacy

Milestone 1: Basic, Local Asset Browser

Legacy

OpenGL Error

Meta

Good First Issue

Meta

Papercut

Meta

Retrospective

Meta

Security

Module

Animation & Rigging

Module

Core

Module

Development Management

Module

Eevee & Viewport

Module

Grease Pencil

Module

Modeling

Module

Nodes & Physics

Module

Pipeline, Assets & IO

Module

Platforms, Builds & Tests

Module

Python API

Module

Render & Cycles

Module

Sculpt, Paint & Texture

Module

Triaging

Module

User Interface

Module

VFX & Video

Platform

FreeBSD

Platform

Linux

Platform

macOS

Platform

Windows

Priority

High

Priority

Low

Priority

Normal

Priority

Unbreak Now!

Status

Archived

Status

Confirmed

Status

Duplicate

Status

Needs Info from Developers

Status

Needs Information from User

Status

Needs Triage

Status

Resolved

Type

Bug

Type

Design

Type

Known Issue

Type

Patch

Type

Report

Type

To Do

**Milestone**

Set milestone

Clear milestone

No items

No Milestone

**Projects**

Set Project

Clear projects

No project

**Assignees**

Assign users

Clear assignees

No Assignees

**3 Participants**

**Notifications**

**Due Date**

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

**Dependencies**

No dependencies set.

Reference: blender/blender#89676

Reference in New Issue

There is no content yet.

Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?

## Background

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

`BevList`

)`DispList`

)`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:

`DispList`

or to`Mesh`

happened in the modifier stack.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 surfaceThis 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 curveThis is currently what happens-- the curve with pre-tesselation deformation modifiers applied is imported into the node tree.BothPotentially 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:

onlythe wire edges. Any evaluated surface is a mesh.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.

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

Added subscriber: @HooglyBoogly

Added subscriber: @JacquesLucke

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

When using the Object Info node in another object:

When using a Geometry Nodes modifier on the curve object:

(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.

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):

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.

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 : )

Added subscriber: @DuarteRamos

Changed status from 'Confirmed' to: 'Resolved'