MantisBT
Mantis Bug Tracker Workflow

View Revisions: Issue #21413 All Revisions ] Back to Issue ]
Summary 0021413: Pipe fails - very sensitive to spine parameterization
Revision 2017-06-28 18:05 by apv
Description 1. Uncompress enclosed pipe-spine.zip. It contains two equal spines, only
differing in precision used when saving in the file (.ok used default 5 or 6
digits, .err - 17)
2. Use DRAWEXE:
Draw> tuya res.err dc1.err 1
Draw> tuya res.ok dc1.ok 1

In OK case the resulting B-Spline is a good pipe surface (Vdeg=5, Vknots=31)
while in ERR case there is some failure (Vdeg=11, Vknots=285). Failure is closer
to the end of the spine (extra twisting resulting in degree increase, etc).
Spine knots have dense distribution closer to the start - this likely
contributes to the failure. However sensitivity seems to high when default
tolerance of pipe algorithm is 1e-04 and knots and poles differ only in <1e-6 scale.

Additional post:

After some investigations I noticed that the issue is rather (or only?) in poles
- if to reduce precision (e.g. to modify *.err file leaving only 7 digits in
every pole coordinate) the algorithm works fine. So it seems like some precision
non-robustness.
I could add some work-around into my code to round up each coordinate to 7
digits on the fly but that would be the least I'd like to do. Ugly hack slowing
down the code, to say the least ...
Revision 2009-10-15 10:35 by bugmaster
Description 1. Uncompress enclosed pipe-spine.zip. It contains two equal spines, only
differing in precision used when saving in the file (.ok used default 5 or 6
digits, .err - 17)
2. Use DRAWEXE:
Draw> tuya res.err dc1.err 1
Draw> tuya res.ok dc1.ok 1

In OK case the resulting B-Spline is a good pipe surface (Vdeg=5, Vknots=31)
while in ERR case there is some failure (Vdeg=11, Vknots=285). Failure is closer
to the end of the spine (extra twisting resulting in degree increase, etc).
Spine knots have dense distribution closer to the start - this likely
contributes to the failure. However sensitivity seems to high when default
tolerance of pipe algorithm is 1e-04 and knots and poles differ only in <1e-6 scale.

Additional post:

After some investigations I noticed that the issue is rather (or only?) in poles
- if to reduce precision (e.g. to modify *.err file leaving only 7 digits in
every pole coordinate) the algorithm works fine. So it seems like some precision
non-robustness.
I could add some work-around into my code to round up each coordinate to 7
digits on the fly but that would be the least I'd like to do. Ugly hack slowing
down the code, to say the least ...


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker