Maniphest T71137

off-by-one bug in spline interpolation produces wrong geometry
Closed, ResolvedBUG

Assigned To
Sebastian Parborg (zeddb)
Authored By
Miguel G. (ghaspias)
Oct 27 2019, 6:38 PM
Tags
  • Modeling
  • BF Blender
Subscribers
Miguel G. (ghaspias)
Philipp Oeser (lichtwerk)
Ray Molenkamp (LazyDodo)
Sebastian Parborg (zeddb)

Description

System Information
Operating system: Windows 10
Graphics card: Intel HD

Blender Version
Broken: version: 2.81 (sub 15), branch: master, commit date: 2019-10-14 23:04, hash: 695cbf5eef79, type: Release
build date: 2019-10-14, 23:24:09
platform: Windows

Worked: (optional)

Short description of error

Spline last segment normal is not interpolated. Symmetric 3D curve produces assymmetric extrusion.

Exact steps for others to reproduce the error

  1. Create a bezier circle.
  2. Set the curve extrusion to 1

3 In edit mode, move one control point vertically.

  1. The result is not symmetric.

The issue is only apparent when extrusion is applied, but may be there regardless. It seems to only apply to closed splines.
This occurs independently of the spline type: Bezier, Poly or Nurbs.

It appears that when computing the normals for extrusion, the last interpolated segment (from the last to the first control point) is not computed correctly.

I tried to find the exact source of the error in the code, but could not find it. If someone points me to the correct location in the code, I will try to submit a patch.

Revisions and Commits

rB Blender
Abandoned

Related Objects

Mentioned Here
rB23a4149778c8: Fix "minimum twist" curve flipping issue

Event Timeline

Miguel G. (ghaspias) created this task.Oct 27 2019, 6:38 PM
Miguel G. (ghaspias) edited projects, added BF Blender (2.81), Modeling; removed BF Blender.Oct 27 2019, 6:41 PM
Miguel G. (ghaspias) added a comment.Oct 27 2019, 6:48 PM

Attached image.

Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 50.Oct 28 2019, 12:45 PM
Philipp Oeser (lichtwerk) edited projects, added BF Blender; removed BF Blender (2.81).
Philipp Oeser (lichtwerk) added a subscriber: Philipp Oeser (lichtwerk).

Can confirm this is not symmetrical.
Doing the same in 2.79 will result in something symmetrical.
Appending the 2.80 curve into 2.79 will result in the same non-symmetrical result though...

Needs some further investigation...

Miguel G. (ghaspias) added a comment.Oct 28 2019, 2:19 PM

I found that just switching direction of the segments (bpy.ops.curve.switch_direction()) gives the correct behaviour... but then it also gives a totally different extrusion [see image below, compare with exact same curve, only direction switched, from previous image]! Why, if the extrusion is symmetric in both directions? Should this be filled as another bug?

Philipp Oeser (lichtwerk) added a subscriber: Sebastian Parborg (zeddb).Oct 28 2019, 2:21 PM

first issue: a new cyclic curve in 2.8 will show this [wasnt the case in 2.79]
only way to get it symmetrical is using high values for twist_smooth

second issue: opening (symmetrical looking) 2.79 curves in 2.8 are now non-symmetrical as well
This was caused by rB23a4149778c8

@Sebastian Parborg (zeddb) : is this something you are interested in?

Sebastian Parborg (zeddb) claimed this task.Oct 28 2019, 2:58 PM

I can take a look at it when I have time. That won't be in a while though...

Miguel G. (ghaspias) added a comment.Oct 28 2019, 7:35 PM

Hi, thanks @Philipp Oeser (lichtwerk) for tracking that change!
Now that I have a starting point, I'll try to fix this during this week.
@Sebastian Parborg (zeddb) do you know if there is a bug report for the issue your patche addressed?

Sebastian Parborg (zeddb) added a comment.EditedOct 28 2019, 9:13 PM

@Miguel G. (ghaspias) this is what the change I did fixed:


Previously, the curve would flip sometimes when control points were moved. This seemed to be because it took too many segments into account when computing the twist (not just the start and the end points).

Here you have the example file:

Miguel G. (ghaspias) added a comment.Oct 28 2019, 11:54 PM

Thank, Sebastian.
It seems that the issue reported in this bug is fixed by reverting your commit, but that requires finding a new fix for the original twist issue.

Regarding my previous comment:

In T71137#802057, @Miguel G. (ghaspias) wrote:

I found that just switching direction of the segments (bpy.ops.curve.switch_direction()) gives the correct behaviour... but then it also gives a totally different extrusion [see image below, compare with exact same curve, only direction switched, from previous image]! Why, if the extrusion is symmetric in both directions? Should this be filled as another bug?

I now realize that I have probably mixed 2.80 and 2.81. The bug is not present in 2.80, although if you open a file from 2.81 in 2.80 the incorrect geometry will still be there -- and apparently that is fixed by (in 2.80) switching the orientation of the curve, albeit with some side effects.

Just to be sure: what is the relation between 'twist' and what is designated in the interface by 'tilt'? Are both the same thing, or are they handled in different levels? (Should this type of question be placed in the developer forum, rather than in the bug report? I am a newbie, excuse me if I am abusing the bug report...)

Sebastian Parborg (zeddb) added a comment.EditedOct 29 2019, 11:58 AM

It's fine to continue with technical discussions about the issue in question on the bug tracker.

The "twist" in this case is the automatic orientation that the Twist Method in the curve settings calculates.
The tilt is decoupled from this and is like an offset that is applied later in the calculations.

So the orientation that the twist method calculates in the 0 degree angle that the tilt is applied on top of.

I think I saw some specific symmetry code for cyclic curves in the code. So if I'm not remembering wrong, I guess we might have to change some code in there.

But I am open for suggestions of course. Let me know what you figure out. (You can also add some comments in the code to document what it is actually doing better)

It would be nice to have both of these issues fixed. Thanks for helping out. If you have any more questions, just ask :)

Dalai Felinto (dfelinto) removed Sebastian Parborg (zeddb) as the assignee of this task.Dec 23 2019, 1:45 PM
Dalai Felinto (dfelinto) added a project: Tracker Curfew.
Sebastian Parborg (zeddb) claimed this task.Jan 15 2020, 2:39 PM
Sebastian Parborg (zeddb) changed the subtype of this task from "Report" to "Bug".
Sebastian Parborg (zeddb) removed a project: Tracker Curfew.
Philipp Oeser (lichtwerk) added a comment.Feb 13 2020, 4:09 PM

I have to backflip on the root of the issue being rB23a4149778c8...
(still a mystery why I bisected this down to that commit)

I can see those non-symmetrical results in 2.79 as well.
Issue remains.

Sebastian Parborg (zeddb) changed the task status from Confirmed to Needs Information from User.Mar 2 2020, 3:14 PM

@Miguel G. (ghaspias) Unless you can help us any further, then this doesn't seem to be a regression to me.

The behavior we observe is present in 2.79 too.

Sebastian Parborg (zeddb) closed this task as Archived.Mar 23 2020, 12:18 PM

More than 7 days without reply, closing.

Miguel G. (ghaspias) added a comment.Jul 12 2021, 1:37 AM

This issue is still present in latest releases and in master. I finally had some time to look at the (extremely confusing) code and found the root cause of the issue -- which was in fact in the line we where looking at. Patch submitted.

Miguel G. (ghaspias) changed the task status from Archived to Resolved.Jul 12 2021, 1:38 AM
Philipp Oeser (lichtwerk) reopened this task as Needs Triage.Jul 12 2021, 7:28 AM

If the patch has not landed, the reoort should not be closed

Miguel G. (ghaspias) added a comment.Jul 13 2021, 6:58 PM

@Philipp Oeser (lichtwerk) sorry, I am a newbie...

Campbell Barton (campbellbarton) changed the task status from Needs Triage to Confirmed.Aug 3 2021, 2:34 AM
Campbell Barton (campbellbarton) moved this task from Backlog to Bugs (Curve/Surface) on the Modeling board.
Campbell Barton (campbellbarton) closed this task as Resolved by committing rBcf7219421490: Fix T71137: curve minimum twist producing wrong geometry.Aug 19 2021, 9:13 AM
Campbell Barton (campbellbarton) added a commit: rBcf7219421490: Fix T71137: curve minimum twist producing wrong geometry.
Campbell Barton (campbellbarton) added a commit: rB67c48314baa5: Revert "Fix T71137: curve minimum twist producing wrong geometry".Tue, Jan 24, 6:44 AM
Campbell Barton (campbellbarton) added a commit: rB36a82314a0f5: Fix T71137: curve minimum twist producing wrong geometry.
Ray Molenkamp (LazyDodo) added a commit: rB9ad051140c10: Revert "Fix T71137: curve minimum twist producing wrong geometry".Wed, Jan 25, 7:01 PM
Ray Molenkamp (LazyDodo) reopened this task as Confirmed.Wed, Jan 25, 7:18 PM
Ray Molenkamp (LazyDodo) added a subscriber: Ray Molenkamp (LazyDodo).

Had to revert due to failing tests

Campbell Barton (campbellbarton) closed this task as Resolved by committing rB564673b8ea28: Fix T71137: curve minimum twist producing wrong geometry.Thu, Jan 26, 7:49 AM
Campbell Barton (campbellbarton) added a commit: rB564673b8ea28: Fix T71137: curve minimum twist producing wrong geometry.