2004-april.txt

acis说明文档

to be stitching together a bunch of faces, and add appropriate shells,
lumps, etc.  Since the faces were already stitched together, api_mk_by_faces
has no work to do at the coedge level, so does the trivial work above the
faces and declares success, links the faces together in a list, and declares
success.  Again, they're still stitched to the faces in the other solid.

During FACE collection, you should stitch each face out of the original
solid.  Maybe api_remove_face does this, but I'd be VERY careful about the
condition it leaves the "removed" face in.  Can't promise it doesn't leave
it corrupt or deleted without checking the documentation (and the behavior
-- I don't trust the documentation).  If it were me, I'd splice each face
out of the original solid's list of faces -- make sure the previous face
points to the removed-face's next face, and that the removed-face doesn't
point to a next face.

After collecting the faces, you need to traverse their loops, "splitting"
each coedge that is shared with a face that lives in the original solid.
That is, the EDGEs that are shared by COEDGE pairs that live on separate
solids must be copied so that the COEDGE pairs no longer share EDGEs.  Same
for VERTEXs shared between the old and new solid.  I don't know of an api
function that does this; I'd do it myself.  Also, make sure that the COEDGEs
that were shared across the new solids no longer have partners, and that
every EDGE and VERTEX along the shared boundary points upwards to an
appropriate parent -- the original edge referred to one of the COEDGEs as
its parent, and which one it chose was aribtrary in the original complete
solid.

After these concerns, api_mk_by_faces should be able to construct a partial
solid from the list of faces you supply, and they won't be connected to the
original solids' faces.  And the original partial solid should be
topologically consistent.


Again, I worry greatly about what you're trying to do (my first concern
above).  I've given you here enough rope to hang yourself with.  This is an
area where I personally tread very carefully.

Arlo Ames
[e-mail]

-----Original Message-----
From: kapil karkele [mailto:[e-mail]] 
Sent: Wednesday, April 07, 2004 8:58 PM
To: [e-mail]
Subject: [Acis-alliance] Creating new Solid from selected surfaces


Hi,
I am using Acis R10. In my code I have array of surfaces from Acis Body A 
from which I am creating new body B by calling api api_mk_by_faces and I 
have delete these surfaces from the original solid .
The api api_mk_by_faces works fine.
1)But when I am deleting those surfaces from the orignal solid after that by

calling api_remove_face then I get a error message saying 'Access 
Violation'.
2)If I delete it before api_mk_by_faces then api_mk_by_faces fails saying 
'Access Violation'.
3)I tried api_subtract after api_mk_by_faces  but I get error messge as 
'system inconsistency processing edge coincidence'.
4)I tried healing the new body. As,
api_initialize_healing();
result = api_hh_init_body_for_healing(Newbody);
result = api_hh_auto_heal(Newbody);
CheckOutcome(result);
api_terminate_healing();
Then I got error message as ' Bodies with inconsistencies cannot be healed'.
5) I checked new Body by calling api_check_entity. And this also gives me 
the same error message as above.

Is anywhere I am wrong to creae a new body from set of some surfaces from 
the orignal body?. Also which is the correct way to remove those surfaces 
after that?
Anykind of reply is appreciating.!

-Thanks and regards,
kapil

_________________________________________________________________
Buzz on your screen! Download on your screen. 
http://www.msn.co.in/Download/screensaver/ Keep yourself smiling!

_______________________________________________
Acis-alliance mailing list
[e-mail]
http://lists.cs.columbia.edu/mailman/listinfo/acis-alliance

From alames at sandia.gov  Thu Apr  8 11:13:16 2004
From: alames at sandia.gov (Ames, Arlo)
Date: Thu Apr  8 11:14:38 2004
Subject: [Acis-alliance] Speed related Issues
Message-ID: <[e-mail]>

The api's are slow because you're asking an awful lot of them.

1)api_entity_entity_distance costs time because you're asking an O(n2)
question -- what is the distance from each face on the first object to each
face on the second, and return the minimum.  And, each query is nonlinear in
cost (although this looks fairly constant, as the number of edges on a face
is generally fairly small), as the bounding edges on faces can produce local
concavities.  Each face/face comparison requires computing a surface/surface
interaction, then doing point classification to determine whether the
closest pair of points is actually on the faces being compared.  If not, you
do curve/surface and curve/curve comparisons, and again classify the closest
points to determine whether they're "in".  And this is worse if any of the
faces are NURBS -- the NURBS/anything comparison is costly, as the closest
pairs of points require comparison of patch/patch pairs.  AND, the
classification is worse, because the curves only approximately lie on the
surfaces.

At Sandia, we have developed (and are currently working to get to commercial
availability) software for speeding up such queries.  There is preprocessing
required, and the preprocessing can cost more than a single
api_entity_entity_distance query.  It works well if you have many queries to
perform, and much better if the queries are between the same pair of objects
(a moving object situation).  If you're just comparing one object to
another, we can't help, because Spatial has done a fine job on that version
of the problem.  Sorry, it takes time.


2)  api_facet_entity has run time proportional to it's output size.  The
size of the output can be  proportional to the SQUARE of the fineness of a
given parameter -- change the adjacent angle criteria, and for doubly-curved
surfaces the facet count grows quadratically.  Faceting is a lot harder for
faces having many edges, particularly if those edges are very close to one
another.  The easy cases are where you have few edges, far from each other
(in parameter space).  Again, Spatial has done a good job of making sure the
faceter is fast -- it's as good as it gets in terms of the geometric
algorithm.  OK, so a given mesh manager can do a better job of catching the
facet data, so yes, it can help, but in general the problem is what it is.
If you like LINKED_MESH_MANAGER's performance, figure out what it does that
helps, then roll your own.  Writing a mesh manager isn't that hard (I
generally figure a day or two for a new one).

Arlo Ames
[e-mail]

-----Original Message-----
From: kapil karkele [mailto:[e-mail]] 
Sent: Wednesday, April 07, 2004 10:49 PM
To: [e-mail]
Subject: [Acis-alliance] Speed related Issues


Hi,
I am using Acis R10. There are many api's which I think are slow.
1)api_entity_entity_distance : To find out shortest distance betn two 
entities I am using this api which is very slow in computation. Is there any

alternative for this?
2) api_facet_entity :- Depending upon the normal tolerance (the angle 
between the surface normals at the two adjacent nodes of a facet) this api 
takes time. Increasing this value improves speed but faceting performance is

hampered. Is there any other workaround to this? Actually in R11 there are 
different mesh managers like LINKED_MESH_MANAGER  which is used to speed up 
the faceting but I have to use R10 .
3)get_body_box : This is the api which takes time depending on body size.

Can I improve the speed in these kind of situations?
Thanks and regards,
kapil

_________________________________________________________________
Post Classifieds on MSN classifieds. http://go.msnserver.com/IN/44045.asp 
Buy and Sell on MSN Classifieds.

_______________________________________________
Acis-alliance mailing list
[e-mail]
http://lists.cs.columbia.edu/mailman/listinfo/acis-alliance

From alames at sandia.gov  Thu Apr  8 14:09:45 2004
From: alames at sandia.gov (Ames, Arlo)
Date: Thu Apr  8 14:10:16 2004
Subject: [Acis-alliance] how to obtain FACE parameter
Message-ID: <[e-mail]>

In order to ask about the radius of a cylindrical face, yes, indeed, the
surface is really an elliptical cone, and yes, you do have to determine it
is a cylinder, etc.  This is genuinely the problem you face.  The parameters
are what they are.

Re determining height, you could ask for the center point of the
EDGE->CURVE->ELLIPSE center, but be wary -- if you are only dealing with a
right circular cylinder, and the bounding faces are planes, and the
intersection curves are circular ellipses, your query is correct.  But, if
any of the assumptions are incorrect (e.g. the cylinder has a hole in it,
there is a slot at the end of your cylinder, etc) you may have problems.  It
is possible for a cylindrical face to have any number of loops (1-infinity);
you may have trouble determining which loop.  It is possible even if you
have a right circular cylinder that the "end" loops (if such actually occur)
could consist of multiple elliptical curves, or for them to consist of
spline curves, etc.  If you are constructing all of the geometry, and know
that you will always be the only one constructing the geometry, then you can
probably write something as limited as you suggest.  But if you are going to
be importing geometry, or if the geometry can be modified, you may need
something very different.  If I were going to measure the "height" of a
cylindrical face, I'd examine the curves.  For straight curves, I'd duly
note the positions along the cylinder's axis.  For ellipses, if the normal
of the ellipse were parallel with the normal of the cylinder, I'd use the
center.  For all other ellipses and all spline curves, I'd probably rotate
the edge to a coordinate system where the cylinder axis was 


-----Original Message-----
From: shen [mailto:[e-mail]] 
Sent: Thursday, April 08, 2004 10:42 AM
To: Ames, Arlo
Subject: Re: [Acis-alliance] how to obtain FACE parameter


"Ames, Arlo" wrote:

> Look at the documentation of the member functions for FACE.  You will 
> find a function that returns a SURFACE.  SURFACEs can be cast to 
> various subtypes (e.g. PLANE, CONE).  Seek a member function to the 
> SURFACE that returns a surface (lower case).  "surface" objects can be 
> cast to subtypes as well. There are member functions to tell you what 
> type of surface you're dealing with.  Each surface object has a set of 
> parameters that can be extracted.  I expect you can find the specific 
> member functions in the documentation; if not, I'll look them up.
>

Arlo,
Your email helps a lot.
But i do not think there are API under "surface" (cone, plane, etc.) that
can be used for extracting the size parameters. For a cylinder, for
instance, it is a "cone". Then i check some API under "CONE"  to decide it a
SURFACE is a cylindrical surface, (see code below, for cylinders, sine angle
must be 0 AND consine angle must be 1 AND radius_ratio must be 1)
      fout << "  sine angle = " << ((CONE*)SURF_ENT)->sine_angle() << "\n";
      fout << "cosine angle = " << ((CONE*)SURF_ENT)->cosine_angle() <<
"\n";
      fout << "radius ratio = " << ((CONE*)SURF_ENT)->radius_ratio() <<
"\n";
      fout << "major axis vector length (major radius) = " <<
(((CONE*)SURF_ENT)->major_axis()).len() << "\n";
Finally, i have to get the EDGE --> CURVE --> ELLIPSE --> center point of
the top and bottom of the surface. The two center points and the cone
direction together is used to compute the "heigth" of the cylinder. Do you
think this is the best way to do it? It still looks very awkward, ist't it?
Again, thank you very much for your help. BTW, your knowledge of ACIS is
amazingly deep and wide: are you a user or a developer of ACIS?

Best regards,

Shen



From alames at sandia.gov  Thu Apr  8 14:18:17 2004
From: alames at sandia.gov (Ames, Arlo)
Date: Thu Apr  8 14:19:56 2004
Subject: [Acis-alliance] how to obtain FACE parameter
Message-ID: <[e-mail]>


>>BTW, your knowledge of ACIS is amazingly deep and wide: are you a user or
a developer of ACIS?

Sorry to have missed shen's question..

I am a user.  I have been developing geometric reasoning applications
against ACIS for about 14 years.  I have written applications in a wide
variety of manufacturing applications, including geometric feature
recognition, solid model construction algorithms, offsetters,
finite-element-analysis-related geometry construction/simplification,
robotic applications, point-cloud to cad recognition, immersive CAD
algorithms, meat cutting, rapid prototyping, ad nauseum.  I've been many of
the places you're going, and hope to help as far as I am able.  Geometry was
invented to embarrass you in front of your funding sources, and maybe I can
help us all avoid a little embarrassment.

Duly note that many of the folks who used to contribute to this list are now
unable to for a variety of political reasons.  I probably would answer a lot
less, and maybe look less knowledgeable, in their presence.  Their
contributions are missed.

Arlo Ames
[e-mail]
505-844-3210

From ihsong at inops.co.kr  Fri Apr  9 01:10:00 2004
From: ihsong at inops.co.kr (Song In-Ho)
Date: Fri Apr  9 01:11:16 2004
Subject: [Acis-alliance] Please help me ACIS attribute derivation
Message-ID: <[e-mail]>

Dear all ACIS alliance members:

I am studing in the methods of acis part name attribute derivation.
InterOp CATIA V5 -> ACIS or InterOp UG -> ACIS

InterOp Mannal described following 

CATIA V5 Attribute         Name 
 ACIS Attribute          ATTRIB_XACIS_NAME +
 
retrieved using the ACIS API function api_find_named_attribute

but api_find_named_attribute function is require input name (attribute name)

more detail using method require 

I can not find the "Part name"

I wanna methods of acis "part name" attribute derivation.

Any help will be appreciated! Thank you.

In-Ho Song
[e-mail]

From alames at sandia.gov  Fri Apr  9 11:02:42 2004
From: alames at sandia.gov (Ames, Arlo)
Date: Fri Apr  9 11:03:16 2004
Subject: [Acis-alliance] Please help me ACIS attribute derivation
Message-ID: <[e-mail]>

Look at your example file in a text editor.  Attributes are named in a style
foo-bar-attrib, where the class bar derives from attrib, foo derives from
bar.  On the same line you'll find other information; pointers are preceeded
by $, null pointers are $-1.  strings are an integer followed by a space,
followed by the number of characters specified in the integer.

You should be able to determine all of this either from the ACIS InterOp
documentation, or by calling your friendly Spatial support person.

Arlo Ames
[e-mail]

-----Original Message-----
From: Song In-Ho [mailto:[e-mail]] 
Sent: Thursday, April 08, 2004 11:10 PM
To: [e-mail]
Subject: [Acis-alliance] Please help me ACIS attribute derivation
Importance: High


Dear all ACIS alliance members:

I am studing in the methods of acis part name attribute derivation. InterOp
CATIA V5 -> ACIS or InterOp UG -> ACIS

InterOp Mannal described following 

CATIA V5 Attribute         Name 
 ACIS Attribute          ATTRIB_XACIS_NAME +
 
retrieved using the ACIS API function api_find_named_attribute

but api_find_named_attribute function is require input name (attribute name)

more detail using method require 

I can not find the "Part name"

I wanna methods of acis "part name" attribute derivation.

Any help will be appreciated! Thank you.

In-Ho Song
[e-mail]

_______________________________________________