- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Bad pcurve after api_conver t_to_splin e()
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
01-26-2009 10:18 PM
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.
Re: Bad pcurve after api_conver t_to_splin e()
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-04-2009 02:15 AM
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
Re: Bad pcurve after api_conver t_to_splin e()
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-05-2009 12:08 AM
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
Re: Bad pcurve after api_conver t_to_splin e()
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-10-2009 11:07 AM
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/Approximation
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

