Home
Reply
Regular Contributor
Vi2
Posts: 55

Bad pcurve after api_convert_to_spline()

I have detected the bad pcurve after api_convert_to_spline() in both ACIS 8.0 and ACIS 18.0. See pcurve #10 in splined model (attachment N 2).

 

I don't know what I should ask. :( Perhaps, for information only, because I have splitted this FACE into 3 parts.
Spatial Employee
Alex
Posts: 15

Re: Bad pcurve after api_convert_to_spline()

Hello Vi2

 

I took a look at the pcurve and it seems OK to me. What is making you think that there is a problem with it?

--

Alex Lyons, Spatial

 

Regular Contributor
Vi2
Posts: 55

Re: Bad pcurve after api_convert_to_spline()

From  part106_splined.sat:

-9 edge $-1 -1 $-1 $16 -1.954768762248577 $17 0.10471975513459925 $6 $18 forward @7 unknown T -13.375 ... #
-10 pcurve $-1 -1 $-1 0 forward { exppc nubs 2 open 13
    -1.954768762248577 2 -1.7831447191333125 2 -1.6115206760180478 2 -1.4398966329027831 2 -1.2682725897875184 2
    -1.0966485466722538 2 -0.92502450355698884 2 -0.75340046044172415 2 -0.58177641732645957 2 -0.41015237421119483 2
    -0.23852833109593008 2 -0.066904287980665417 2 0.10471975513459925 2
    8.8817841970012523e-016 0.9739159452440127
    1.0667818668916738 0.54290809375586313
    2.1915000390620096 0.30042025331200217
    3.3162182112323375 0.057932412868142456
    4.4658255621818777 0.011089502880397006
->    6.5968240204343029 0.10723642424395753             should be approximately 5.615433 -0.035753
    6.7561510079671949 0.11442497911226113
    7.896869102802996 0.26460336533187157
    8.9951806959491556 0.60739041866676946
    10.09349228909532 0.95017747200166969
    11.117126147586484 1.4755012229627686
    12.140760006077642 2.0008249739238648
    13.059639121781652 2.6932500531175041
    13.978518237485659 3.3856751323111407
    14.76564356733045 4.2248563014814637
    15.552768897175241 5.0640374706517894
    16.185012664807598 6.02531741835866
    16.817256432439962 6.986597366065542
    17.276041682063834 8.0417312032164894
    17.734826931687703 9.0968650403674332
    18.006673367033699 10.214850208052138
    18.278519802379698 11.332835375736856
    18.355439872646556 12.480822580527665
->    18.35242447542959 12.640283145110336               should be approximately 18.433186 13.641144
    18.312093537652714 14.773068196403585
    0.001

    spline forward { ref 0 } I I I I
    } 0 0 #
-18 ellipse-curve $-1 -1 $-1 0 -14.5 0 0 1 0 0 0 13.375 1 F -1.954768762248577 F 0.10471975513459925 #

 

Also see comment inside attached picture.

 

BR

Vita

 

pcurve10.jpg
Spatial Employee
Brian
Posts: 20

Re: Bad pcurve after api_convert_to_spline()

Hi Vita,

 

My understanding is that the pcurve is not accurate enough for a workflow you have implemented. Without knowing your workflow, I can recommend two possible approaches for what I think is the geometry service you need: finding a surface point (uv) corresponding to a  point on an edge.

 

A high level approach is to use the function api_approx - the signature that takes a coedge - and make your own 2-D B-spline curve (bs2_curve), which is sufficiently accurate for your workflow. I suggest you look at the tech article on approximations for more details:

http://doc.spatial.com/r19/index.php/Approximations

 

A low-level approach, which avoids creating new auxiliary geometry, is as follows: you can evaluate the edge curve to get an xyz point, then evaluate the pcurve to get a uv point, and then use both the xyz point and uv point as in inputs, to the method curve::point_perp, on the edge curve (the pcurve uv is the input guess). You will have to pay attention to the sense method of both the edge and coedge, which makes this approach more complicated.

 

In ACIS, the internal pcurves are not required to have a fixed accuracy, in order to meet competing requirements, such as lightweight. That is one reason you may find these internal pcurves are not sufficiently accurate for your workflow.


Hope this helps,

Brian