ends of curves do not fit #36007

New Issue

Alexander N. · 2013-07-04T14:46:03+02:00

Alexander N. commented

2013-07-04 14:46:03 +02:00

%%%--- Operating System, Graphics card ---
Windows 7 64bit,

- Blender version with error, and version that worked ---

all tested versions (2.65a, 2.66a, 2.67b, 2.67RC1, 2.67 r57951)

- Short description of error ---

the ends of curves pieces with bevel does not fit, compared to a continues curve with same bezier_points values (co, tile, handle_left, handle_right, ...)
i would expect, that when i cut a curve in pieces, i get the exact same "flow" of full curve...

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

open the attached blend file.
the yellow curve is the full curve.
the red one is that with one part of the full curve,
the green one is that with the other part of the full curve.
i expect that there is no gap and no overlapping between the red and the green one.

%%%

%%%--- Operating System, Graphics card --- Windows 7 64bit, - Blender version with error, and version that worked --- all tested versions (2.65a, 2.66a, 2.67b, 2.67RC1, 2.67 r57951) - Short description of error --- the ends of curves pieces with bevel does not fit, compared to a continues curve with same bezier_points values (co, tile, handle_left, handle_right, ...) i would expect, that when i cut a curve in pieces, i get the exact same "flow" of full curve... - Steps for others to reproduce the error (preferably based on attached .blend file) --- open the attached blend file. the yellow curve is the full curve. the red one is that with one part of the full curve, the green one is that with the other part of the full curve. i expect that there is no gap and no overlapping between the red and the green one. %%%

Alexander N. commented

2013-07-04 14:46:03 +02:00

Changed status to: 'Open'

Alexander N. commented

2013-07-04 15:12:34 +02:00

%%%the ends/caps are not aligned to their curve handles - not orthogonal to the handles
i think that describes it more accurately%%%

%%%the ends/caps are not aligned to their curve handles - not orthogonal to the handles i think that describes it more accurately%%%

Brecht Van Lommel commented

2013-07-04 16:13:58 +02:00

%%%Confirmed, it gets closer as you increase the curve resolution, looks like it's using the tangent of the second-to-last segment for the last.%%%

Alexander N. commented

2013-07-05 08:39:26 +02:00

%%%yes, if you increase the resolution, it will get a bit closer, but even at 64 (max) it is still very visible. i think starting of a resolution of 4 or 5, there are enough "curve subdevisions" available to align the ends/starts/caps (both sides of the curve) exactly along their handles.
i writing on an import add-on script, where i need to get rid of these gaps and overlappings... (http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/FuturePinball_FPx) (for the wire ramps there are wires, that do not fit to the rings, on to the neighbor wire)

%%%

%%%yes, if you increase the resolution, it will get a bit closer, but even at 64 (max) it is still very visible. i think starting of a resolution of 4 or 5, there are enough "curve subdevisions" available to align the ends/starts/caps (both sides of the curve) exactly along their handles. i writing on an import add-on script, where i need to get rid of these gaps and overlappings... (http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/FuturePinball_FPx) (for the wire ramps there are wires, that do not fit to the rings, on to the neighbor wire) %%%

Sergey Sharybin commented

2013-07-08 13:12:18 +02:00

%%%This is like how bevel used to be calculated for ages: first/last bevel points are using the same rotation/tangent as second/previous-to-last points.

I did some tests a while ago about this actually, and here's WIP patch: http://www.pasteall.org/43869/diff Wasn't entirely happy with what's going on there (and still not entirely happy). This thing requires much bigger cleanup.

Brecht, generally speaking i wouldn't consider this is a bug, just nice thing to be solved. And definitely wouldn't want to start changing stuff for 2.68. Your opinion here?%%%

%%%This is like how bevel used to be calculated for ages: first/last bevel points are using the same rotation/tangent as second/previous-to-last points. I did some tests a while ago about this actually, and here's WIP patch: http://www.pasteall.org/43869/diff Wasn't entirely happy with what's going on there (and still not entirely happy). This thing requires much bigger cleanup. Brecht, generally speaking i wouldn't consider this is a bug, just nice thing to be solved. And definitely wouldn't want to start changing stuff for 2.68. Your opinion here?%%%

Alexander N. commented

2013-07-08 13:56:51 +02:00

%%%hi Sergey,
for me it is okay, if it will not be fixed for next upcoming release 2.68, i don't want delay delivery of 2.68.
but please don't forget that there is one who need it... ;)

... thank you.

PS.: do you know, if it is planned to implement & add some curve snap options to the UI ('snap to curve point', 'snap to curve handle point', 'snap to curve' - similar to the existing snap options for mesh in the UI - snap to vertex, snap to edge, snap to face, ...) ???%%%

%%%hi Sergey, for me it is okay, if it will not be fixed for next upcoming release 2.68, i don't want delay delivery of 2.68. but please don't forget that there is one who need it... ;) ... thank you. PS.: do you know, if it is planned to implement & add some curve snap options to the UI ('snap to curve point', 'snap to curve handle point', 'snap to curve' - similar to the existing snap options for mesh in the UI - snap to vertex, snap to edge, snap to face, ...) ???%%%

Brecht Van Lommel commented

2013-07-08 14:40:06 +02:00

%%%It's definitely too late to fix this in 2.68. Looking at the code, it indeed isn't strictly a bug, just old code that could be made smarter.

Sergey, will leave it up to you to decide if you want to fix this or consider it a todo item for later, I can't really estimate how difficult it is to get this fixed properly. The patch seems to work OK in some simple tests here, except for the Tangent twisting method. I don't understand the code here well enough at the moment to judge this.%%%

%%%It's definitely too late to fix this in 2.68. Looking at the code, it indeed isn't strictly a bug, just old code that could be made smarter. Sergey, will leave it up to you to decide if you want to fix this or consider it a todo item for later, I can't really estimate how difficult it is to get this fixed properly. The patch seems to work OK in some simple tests here, except for the Tangent twisting method. I don't understand the code here well enough at the moment to judge this.%%%

Alexander N. commented

2013-07-08 14:57:26 +02:00

%%%attached "...v2 (expected)" - files that shows, in cyan color, the curve as it should look like in different resolutions 1, 2, 3, 4, 5 & 12, the can align without any gap / overlapping / visible seam.
i simulated by extend the original (green) curve and converted to mesh and cutted the extension away.

do you mean that this result will be possible?

(i really have to learn how to compile blender and how to apply diffs...)%%%

%%%attached "...v2 (expected)" - files that shows, in cyan color, the curve as it should look like in different resolutions 1, 2, 3, 4, 5 & 12, the can align without any gap / overlapping / visible seam. i simulated by extend the original (green) curve and converted to mesh and cutted the extension away. do you mean that this result will be possible? (i really have to learn how to compile blender and how to apply diffs...)%%%

Sergey Sharybin commented

2013-07-08 15:04:04 +02:00

%%%Brecht, patch indeed doesn't work fully correct for tangent twisting and 2D curves. When i was working on this patch it became too much spagetty of exceptional cases. I hope to get rid of bevel_list_cyclic_fix_3D and do some smarter calculation which shall be more clear for understanding what's going on. I wouldn't mind working on this issue after the release. Marked the report as "after 2.68 release".

Alexander, if i understand you correct, it'll be possible, yes (with some exceptions listed above).%%%

%%%Brecht, patch indeed doesn't work fully correct for tangent twisting and 2D curves. When i was working on this patch it became too much spagetty of exceptional cases. I hope to get rid of bevel_list_cyclic_fix_3D and do some smarter calculation which shall be more clear for understanding what's going on. I wouldn't mind working on this issue after the release. Marked the report as "after 2.68 release". Alexander, if i understand you correct, it'll be possible, yes (with some exceptions listed above).%%%

Sergey Sharybin commented

2013-07-31 07:20:15 +02:00

%%%Do have a patch which seems to be as clear as it could be, and seems to be working. But wouldn't mind other devs to look into it.

Brecht, are you around for this? :)%%%

%%%Do have a patch which seems to be as clear as it could be, and seems to be working. But wouldn't mind other devs to look into it. Brecht, are you around for this? :)%%%

Brecht Van Lommel commented

2013-07-31 17:33:26 +02:00

%%%The code looks simple and ok to me, but I found some strange results with twisting. Attached curve_bevel_twist.blend, compare with and without the patch, with the patch it has some ugly twisting at the end that wasn't there before.%%%

Sergey Sharybin commented

2013-08-06 04:34:33 +02:00

%%%Brecht, thanks for the test! Fixed the issue with minimal twist. It appears i only need to make sure quat for the last bevel point is correct.

As for Z-Up, your file will behave different in 2.68 and current trunk. But this is because z-up might easily flip quat depending on the direction of bevel segment. It might happen in any place within the curve. Attached curve_bevel_twist1.blend which demonstrates how flipping happens inbetween of two CV, happens in both 2.68 and patch. Wouldn't actually consider this is a bug, it's just how math works for Z-Up.

Also attaching updated patch.%%%

%%%Brecht, thanks for the test! Fixed the issue with minimal twist. It appears i only need to make sure quat for the last bevel point is correct. As for Z-Up, your file will behave different in 2.68 and current trunk. But this is because z-up might easily flip quat depending on the direction of bevel segment. It might happen in any place within the curve. Attached curve_bevel_twist1.blend which demonstrates how flipping happens inbetween of two CV, happens in both 2.68 and patch. Wouldn't actually consider this is a bug, it's just how math works for Z-Up. Also attaching updated patch.%%%

Brecht Van Lommel commented

2013-08-06 08:29:44 +02:00

%%%Patch looks good to me now and works as expected in tests. So as far as I'm concerned this is ok to commit.%%%