May 2015 - cgma-dev - mailman3.cels.anl.gov

Re: [cgma-dev] CGM OCC sense issues
by Tim Tautges 15 May '15

15 May '15

On 05/15/2015 10:03 AM, Vander Zee, Evan B. wrote: > Patrick, > > I'll widen this discussion to the CGMA dev list. Sorry for the length of my e-mail, but this is a complex issue, and > I want to be as clear as I can. > Yes to both discussing on the list and being precise even if it requires length. This is an important and complex issue. > The way I see it, the forward orientation/sense of a (parametric) geometric edge should be the direction that the > edge is traversed when the parameter increases from its minimum to its maximum. Similarly, the forward > orientation/sense of a (parametric) geometric entity surface should be something that can be determined from the > parametrization, i.e. it should give a normal that follows the right hand rule where the first vector is the tangent > in the direction of increasing parameter u, the second vector is the tangent in the direction of increasing v, and > the normal direction is the cross product of these two vectors. > In the above paragraph, orientation is the right term to use; sense is traditionally meant to convey *relative* orientation. Although the conventions for orientation of edge/face with respect to parameterization can be either, I don't know of any cases where it isn't as you describe above. That said, I don't have a lot of experience with various engines, so take that FWIW. > I can't change the way that OCC chooses to parametrize geometric surfaces internally when we ask it to build a brick > with BRepPrimAPI_MakeBox(). The orientations you see on the triangles correspond to the underlying geometry as it is > stored in OCC after calling that method. There is also an OCC location transformation matrix that can be applied to > that underlying geometry, but it is the identity matrix in this case. I don't think the right thing to do here would > be to have CGM implement the MOAB convention for OCC, which would require a lot of changes to conditionally switch > the parameters used for the parameter space, conditionally reverse the orientation of the triangles of OCC's > get_graphics triangulation, and so on. Rather I think MOAB and DagMC should always use CGMA's coface sense (whether > or not the model is "stand alone") to determine what the sense is, and should be able to reverse the triangles for > graphics if needed. One invariant that should always hold is that all the facets (edge or tri) should be consistently oriented with themselves for a given entity. So, for edges the end of one edge should always be the beginning of another (or empty), and tris should be consistently oriented (edge shared between two should have opposite senses in them). I think this is one of the bugs Patrick was seeing. I agree that the coface sense (which is really the basis of the RefFace's sense wrt the volume) should be used to interpret the facets of the face. > > Admittedly there is still a bug in CGMA for OCC -- the coface senses are wrong in your example -- but that is the > direction I think we should go to try to fix this issue. > > One of the reasons I argue for this is that the geometry query engine allows users to call get_graphics with a > surface. A surface may exist in CGM without being associated with any BasicTopologyEntity, such as a RefFace. Even > if it is associated with a RefFace, it might not bound any volume. These sorts of things make it hard to define what > the "outward" normal is supposed to be in a general fashion. > Yes, "outward" only makes sense wrt a volume. > By the way, although I have some guesses, I'm not that familiar with what the TopologyBridge bridge sense in CGMA is > supposed to mean, so I'd appreciate comments from anyone who can explain it. Think of the bridge sense as the interpretation of the geometric surface normal with respect to the RefFace. As a historical note, that's needed to handle the case of a shared RefFace (between two volumes) and its behavior when you delete one of the volumes. If the RefFace's sense is forward wrt the underlying surface from the volume being deleted, you don't want that RF's normal to switch direction after the deletion. Instead you just flip the bridge sense. - tim It might be possible to use the bridge > sense to implement the convention that MOAB and DagMC rely on, but I don't think that's what it's for. There's also > a geometry sense defined for RefFace and for Surface. As far as I can tell, the method on RefFace is never used and > the method on Surface is used in only two places in OCCSurface where SLProps are used to compute normals. The > implementation of get_geometry_sense() and its two uses appear to be similar to what would be needed to make OCC > follow the convention, but it would need to be checked in a lot more places to complete the implementation. > > -Evan > > -----Original Message----- From: Patrick Shriwise [mailto:[email protected]] Sent: Thursday, May 14, 2015 6:42 PM To: > Vander Zee, Evan B. Subject: Re: CGM OCC sense issues > > Hey Evan, > > Taking into consideration that these models were created stand alone, we would expect all of the surfaces to have > forward senses and the triangles to have outward pointing normals. MOAB and DagMC both rely on this convention when > creating the surface meshes from the graphics facets. > > If there are adjacent volumes, the sense tags in MOAB can be used to orient the triangle normals in the proper > direction, but only if the normals consistently agree with the forward sense, outward normals convention. > > This is how we gather information about whether points are inside or outside of volumes, etc. > > Patrick > > On 05/14/2015 04:41 PM, Vander Zee, Evan B. wrote: >> I've been focusing on the occ_cube_test. In that test it looks like the triangles that are returned from >> get_graphics are consistently oriented within each face of the cube, however, some of the triangles (surfaces 1, 3, >> 5) are oriented to have inward normals and others (surfaces 2, 4, 6) are oriented to have outward normals. >> >> As I've thought about it more, it seems that this is all okay, but that the cofaces in CGM should have reversed >> senses. (All of the coface senses and bridge senses are forward in the current implementation.) Does this agree >> with your expectation, or would you expect all of the normals of the triangles to be outward (which is hard to >> define for geometric faces that are shared between two volumes)? >> >> The issue that I was facing has to do with coedge orientation in CGM for OCC geometry. I thought it might have an >> impact on how face senses were built as well, but so far it appears it does not. >> >> -Evan >> >> -----Original Message----- From: shriwise [mailto:[email protected]] Sent: Thursday, May 14, 2015 1:55 PM To: >> Vander Zee, Evan B. Subject: Re: CGM OCC sense issues >> >> Ah I see. Sorry, I was thinking of a different issue with get_graphics built on OCC in which the triangle normals >> were not matching the surface senses. >> >> Maybe it will help in the future with that problem though. >> >> Cheers, >> >> Patrick >> >> On 05/14/2015 10:53 AM, Vander Zee, Evan B. wrote: >>> Thanks, Patrick. The issue you are running into seems to be different from mine. It is unaffected by the change >>> that I made to fix my issue. I think your issue is caused by a problem in get_graphics, but I haven't finished >>> analyzing it yet. >>> >>> -Evan >>> >>> -----Original Message----- From: shriwise [mailto:[email protected]] Sent: Wednesday, May 13, 2015 12:47 PM To: >>> Vander Zee, Evan B. Subject: Re: CGM OCC sense issues >>> >>> Hey Evan, >>> >>> I can help you out there. >>> >>> I made a CGM-based program which will retrieve faceting data for a cube (or any model I think) and print it to >>> screen along with the expected triangle normals as MOAB would interpret them. >>> >>> It is located here https://github.com/Pshriwise/ggtest if you'd like to give it a try. >>> >>> The make system for that program is a little shaky so apologies for that. >>> >>> I hope it helps! >>> >>> Cheers, >>> >>> Patrick >>> >>> >>> >>> On 05/13/2015 12:42 PM, Vander Zee, Evan B. wrote: >>>> Yesterday I did a deep dive from MeshKit down through CGM into OCC, looking for issues with the way that sense >>>> is represented. I was having a specific problem getting the wrong face/edge sense for a cylinder that was >>>> created in OCC. >>>> >>>> It is hard to understand all of the different ways that the term "sense" is used in CGM, with sense entities, >>>> bridge senses, CubitSense, and so on, but if all of my guesses are correct, then the source of my specific >>>> problem is in OCCQueryEngine and the way it is creating the CoEdge sense entities in CGM as it interprets the >>>> OCC geometry. I was able to get the expected results for my specific situation in CGM by changing the code in >>>> OCCQueryEngine; however, I'm not confident that what I have done will work correctly in other situations. >>>> >>>> I'd like some help gathering some test cases to check this change. They can become part of the CGM tests and >>>> may help improve our poor test coverage for that package. Specifically, can Paul or Patrick send me or point >>>> me to a program using only OCC-based CGM that gets the wrong normals with the current code? Rajeev, you >>>> mentioned copy_attrib in CGM when this issue came up. I looked at copy_attrib and see that there is an issue, >>>> but I don't see how it's related to sense. If that problem is related to the sense issue, can you explain that >>>> in an e-mail? Do any of you know other tests in CGM that check whether the sense is correct? >>>> >>>> -Evan > -- Timothy J. Tautges Manager, Directed Meshing, CD-adapco Phone: (631) 629-3139 (internal: x29130) Mobile/Gvoice: (608) 354-1459 timothy.tautges(a)cd-adapco.com

1 0

Re: [cgma-dev] CGM OCC sense issues
by Vander Zee, Evan B. 15 May '15

15 May '15

By the way, I would have no problem with CGMA implementing a get_graphics method for a CoFace or Shell. Then the context of outward normal is known, and CGMA could reverse the triangles as needed to provide outward normals for MOAB or DagMC. -Evan -----Original Message----- From: cgma-dev-bounces(a)mcs.anl.gov [mailto:[email protected]] On Behalf Of Vander Zee, Evan B. Sent: Friday, May 15, 2015 10:04 AM To: CGMA Development Subject: Re: [cgma-dev] CGM OCC sense issues Patrick, I'll widen this discussion to the CGMA dev list. Sorry for the length of my e-mail, but this is a complex issue, and I want to be as clear as I can. The way I see it, the forward orientation/sense of a (parametric) geometric edge should be the direction that the edge is traversed when the parameter increases from its minimum to its maximum. Similarly, the forward orientation/sense of a (parametric) geometric entity surface should be something that can be determined from the parametrization, i.e. it should give a normal that follows the right hand rule where the first vector is the tangent in the direction of increasing parameter u, the second vector is the tangent in the direction of increasing v, and the normal direction is the cross product of these two vectors. I can't change the way that OCC chooses to parametrize geometric surfaces internally when we ask it to build a brick with BRepPrimAPI_MakeBox(). The orientations you see on the triangles correspond to the underlying geometry as it is stored in OCC after calling that method. There is also an OCC location transformation matrix that can be applied to that underlying geometry, but it is the identity matrix in this case. I don't think the right thing to do here would be to have CGM implement the MOAB convention for OCC, which would require a lot of changes to conditionally switch the parameters used for the parameter space, conditionally reverse the orientation of the triangles of OCC's get_graphics triangulation, and so on. Rather I think MOAB and DagMC should always use CGMA's coface sense (whether or not the model is "stand alone") to determine what the sense is, and should be able to reverse the triangles for graphics if needed. Admittedly there is still a bug in CGMA for OCC -- the coface senses are wrong in your example -- but that is the direction I think we should go to try to fix this issue. One of the reasons I argue for this is that the geometry query engine allows users to call get_graphics with a surface. A surface may exist in CGM without being associated with any BasicTopologyEntity, such as a RefFace. Even if it is associated with a RefFace, it might not bound any volume. These sorts of things make it hard to define what the "outward" normal is supposed to be in a general fashion. By the way, although I have some guesses, I'm not that familiar with what the TopologyBridge bridge sense in CGMA is supposed to mean, so I'd appreciate comments from anyone who can explain it. It might be possible to use the bridge sense to implement the convention that MOAB and DagMC rely on, but I don't think that's what it's for. There's also a geometry sense defined for RefFace and for Surface. As far as I can tell, the method on RefFace is never used and the method on Surface is used in only two places in OCCSurface where SLProps are used to compute normals. The implementation of get_geometry_sense() and its two uses appear to be similar to what would be needed to make OCC follow the convention, but it would need to be checked in a lot more places to complete the implementation. -Evan -----Original Message----- From: Patrick Shriwise [mailto:[email protected]] Sent: Thursday, May 14, 2015 6:42 PM To: Vander Zee, Evan B. Subject: Re: CGM OCC sense issues Hey Evan, Taking into consideration that these models were created stand alone, we would expect all of the surfaces to have forward senses and the triangles to have outward pointing normals. MOAB and DagMC both rely on this convention when creating the surface meshes from the graphics facets. If there are adjacent volumes, the sense tags in MOAB can be used to orient the triangle normals in the proper direction, but only if the normals consistently agree with the forward sense, outward normals convention. This is how we gather information about whether points are inside or outside of volumes, etc. Patrick On 05/14/2015 04:41 PM, Vander Zee, Evan B. wrote: > I've been focusing on the occ_cube_test. In that test it looks like the triangles that are returned from get_graphics are consistently oriented within each face of the cube, however, some of the triangles (surfaces 1, 3, 5) are oriented to have inward normals and others (surfaces 2, 4, 6) are oriented to have outward normals. > > As I've thought about it more, it seems that this is all okay, but that the cofaces in CGM should have reversed senses. (All of the coface senses and bridge senses are forward in the current implementation.) Does this agree with your expectation, or would you expect all of the normals of the triangles to be outward (which is hard to define for geometric faces that are shared between two volumes)? > > The issue that I was facing has to do with coedge orientation in CGM for OCC geometry. I thought it might have an impact on how face senses were built as well, but so far it appears it does not. > > -Evan > > -----Original Message----- > From: shriwise [mailto:[email protected]] > Sent: Thursday, May 14, 2015 1:55 PM > To: Vander Zee, Evan B. > Subject: Re: CGM OCC sense issues > > Ah I see. Sorry, I was thinking of a different issue with get_graphics > built on OCC in which the triangle normals were not matching the surface > senses. > > Maybe it will help in the future with that problem though. > > Cheers, > > Patrick > > On 05/14/2015 10:53 AM, Vander Zee, Evan B. wrote: >> Thanks, Patrick. The issue you are running into seems to be different from mine. It is unaffected by the change that I made to fix my issue. I think your issue is caused by a problem in get_graphics, but I haven't finished analyzing it yet. >> >> -Evan >> >> -----Original Message----- >> From: shriwise [mailto:[email protected]] >> Sent: Wednesday, May 13, 2015 12:47 PM >> To: Vander Zee, Evan B. >> Subject: Re: CGM OCC sense issues >> >> Hey Evan, >> >> I can help you out there. >> >> I made a CGM-based program which will retrieve faceting data for a cube >> (or any model I think) and print it to screen along with the expected >> triangle normals as MOAB would interpret them. >> >> It is located here https://github.com/Pshriwise/ggtest if you'd like to >> give it a try. >> >> The make system for that program is a little shaky so apologies for that. >> >> I hope it helps! >> >> Cheers, >> >> Patrick >> >> >> >> On 05/13/2015 12:42 PM, Vander Zee, Evan B. wrote: >>> Yesterday I did a deep dive from MeshKit down through CGM into OCC, looking for issues with the way that sense is represented. I was having a specific problem getting the wrong face/edge sense for a cylinder that was created in OCC. >>> >>> It is hard to understand all of the different ways that the term "sense" is used in CGM, with sense entities, bridge senses, CubitSense, and so on, but if all of my guesses are correct, then the source of my specific problem is in OCCQueryEngine and the way it is creating the CoEdge sense entities in CGM as it interprets the OCC geometry. I was able to get the expected results for my specific situation in CGM by changing the code in OCCQueryEngine; however, I'm not confident that what I have done will work correctly in other situations. >>> >>> I'd like some help gathering some test cases to check this change. They can become part of the CGM tests and may help improve our poor test coverage for that package. Specifically, can Paul or Patrick send me or point me to a program using only OCC-based CGM that gets the wrong normals with the current code? Rajeev, you mentioned copy_attrib in CGM when this issue came up. I looked at copy_attrib and see that there is an issue, but I don't see how it's related to sense. If that problem is related to the sense issue, can you explain that in an e-mail? Do any of you know other tests in CGM that check whether the sense is correct? >>> >>> -Evan

1 0

Re: [cgma-dev] CGM OCC sense issues
by Vander Zee, Evan B. 15 May '15

15 May '15

Patrick, I'll widen this discussion to the CGMA dev list. Sorry for the length of my e-mail, but this is a complex issue, and I want to be as clear as I can. The way I see it, the forward orientation/sense of a (parametric) geometric edge should be the direction that the edge is traversed when the parameter increases from its minimum to its maximum. Similarly, the forward orientation/sense of a (parametric) geometric entity surface should be something that can be determined from the parametrization, i.e. it should give a normal that follows the right hand rule where the first vector is the tangent in the direction of increasing parameter u, the second vector is the tangent in the direction of increasing v, and the normal direction is the cross product of these two vectors. I can't change the way that OCC chooses to parametrize geometric surfaces internally when we ask it to build a brick with BRepPrimAPI_MakeBox(). The orientations you see on the triangles correspond to the underlying geometry as it is stored in OCC after calling that method. There is also an OCC location transformation matrix that can be applied to that underlying geometry, but it is the identity matrix in this case. I don't think the right thing to do here would be to have CGM implement the MOAB convention for OCC, which would require a lot of changes to conditionally switch the parameters used for the parameter space, conditionally reverse the orientation of the triangles of OCC's get_graphics triangulation, and so on. Rather I think MOAB and DagMC should always use CGMA's coface sense (whether or not the model is "stand alone") to determine what the sense is, and should be able to reverse the triangles for graphics if needed. Admittedly there is still a bug in CGMA for OCC -- the coface senses are wrong in your example -- but that is the direction I think we should go to try to fix this issue. One of the reasons I argue for this is that the geometry query engine allows users to call get_graphics with a surface. A surface may exist in CGM without being associated with any BasicTopologyEntity, such as a RefFace. Even if it is associated with a RefFace, it might not bound any volume. These sorts of things make it hard to define what the "outward" normal is supposed to be in a general fashion. By the way, although I have some guesses, I'm not that familiar with what the TopologyBridge bridge sense in CGMA is supposed to mean, so I'd appreciate comments from anyone who can explain it. It might be possible to use the bridge sense to implement the convention that MOAB and DagMC rely on, but I don't think that's what it's for. There's also a geometry sense defined for RefFace and for Surface. As far as I can tell, the method on RefFace is never used and the method on Surface is used in only two places in OCCSurface where SLProps are used to compute normals. The implementation of get_geometry_sense() and its two uses appear to be similar to what would be needed to make OCC follow the convention, but it would need to be checked in a lot more places to complete the implementation. -Evan -----Original Message----- From: Patrick Shriwise [mailto:[email protected]] Sent: Thursday, May 14, 2015 6:42 PM To: Vander Zee, Evan B. Subject: Re: CGM OCC sense issues Hey Evan, Taking into consideration that these models were created stand alone, we would expect all of the surfaces to have forward senses and the triangles to have outward pointing normals. MOAB and DagMC both rely on this convention when creating the surface meshes from the graphics facets. If there are adjacent volumes, the sense tags in MOAB can be used to orient the triangle normals in the proper direction, but only if the normals consistently agree with the forward sense, outward normals convention. This is how we gather information about whether points are inside or outside of volumes, etc. Patrick On 05/14/2015 04:41 PM, Vander Zee, Evan B. wrote: > I've been focusing on the occ_cube_test. In that test it looks like the triangles that are returned from get_graphics are consistently oriented within each face of the cube, however, some of the triangles (surfaces 1, 3, 5) are oriented to have inward normals and others (surfaces 2, 4, 6) are oriented to have outward normals. > > As I've thought about it more, it seems that this is all okay, but that the cofaces in CGM should have reversed senses. (All of the coface senses and bridge senses are forward in the current implementation.) Does this agree with your expectation, or would you expect all of the normals of the triangles to be outward (which is hard to define for geometric faces that are shared between two volumes)? > > The issue that I was facing has to do with coedge orientation in CGM for OCC geometry. I thought it might have an impact on how face senses were built as well, but so far it appears it does not. > > -Evan > > -----Original Message----- > From: shriwise [mailto:[email protected]] > Sent: Thursday, May 14, 2015 1:55 PM > To: Vander Zee, Evan B. > Subject: Re: CGM OCC sense issues > > Ah I see. Sorry, I was thinking of a different issue with get_graphics > built on OCC in which the triangle normals were not matching the surface > senses. > > Maybe it will help in the future with that problem though. > > Cheers, > > Patrick > > On 05/14/2015 10:53 AM, Vander Zee, Evan B. wrote: >> Thanks, Patrick. The issue you are running into seems to be different from mine. It is unaffected by the change that I made to fix my issue. I think your issue is caused by a problem in get_graphics, but I haven't finished analyzing it yet. >> >> -Evan >> >> -----Original Message----- >> From: shriwise [mailto:[email protected]] >> Sent: Wednesday, May 13, 2015 12:47 PM >> To: Vander Zee, Evan B. >> Subject: Re: CGM OCC sense issues >> >> Hey Evan, >> >> I can help you out there. >> >> I made a CGM-based program which will retrieve faceting data for a cube >> (or any model I think) and print it to screen along with the expected >> triangle normals as MOAB would interpret them. >> >> It is located here https://github.com/Pshriwise/ggtest if you'd like to >> give it a try. >> >> The make system for that program is a little shaky so apologies for that. >> >> I hope it helps! >> >> Cheers, >> >> Patrick >> >> >> >> On 05/13/2015 12:42 PM, Vander Zee, Evan B. wrote: >>> Yesterday I did a deep dive from MeshKit down through CGM into OCC, looking for issues with the way that sense is represented. I was having a specific problem getting the wrong face/edge sense for a cylinder that was created in OCC. >>> >>> It is hard to understand all of the different ways that the term "sense" is used in CGM, with sense entities, bridge senses, CubitSense, and so on, but if all of my guesses are correct, then the source of my specific problem is in OCCQueryEngine and the way it is creating the CoEdge sense entities in CGM as it interprets the OCC geometry. I was able to get the expected results for my specific situation in CGM by changing the code in OCCQueryEngine; however, I'm not confident that what I have done will work correctly in other situations. >>> >>> I'd like some help gathering some test cases to check this change. They can become part of the CGM tests and may help improve our poor test coverage for that package. Specifically, can Paul or Patrick send me or point me to a program using only OCC-based CGM that gets the wrong normals with the current code? Rajeev, you mentioned copy_attrib in CGM when this issue came up. I looked at copy_attrib and see that there is an issue, but I don't see how it's related to sense. If that problem is related to the sense issue, can you explain that in an e-mail? Do any of you know other tests in CGM that check whether the sense is correct? >>> >>> -Evan

1 0

Re: [cgma-dev] iGeom & Cubit Groups
by Timothy Tautges 01 May '15

01 May '15

They appear as igeom entity sets. - tim On May 1, 2015 3:42 PM, "Andrew Davis" <andrew.davis(a)wisc.edu> wrote: > Hi All > > Does anyone have an example of how an iGeom program would access groups > from an ACIS file? > > Do they appear as entitysets, or do I try to retrieve them from a tag > called "Group" > > Thanks > > Andy >

1 0

iGeom & Cubit Groups
by Andrew Davis 01 May '15

01 May '15

Hi All Does anyone have an example of how an iGeom program would access groups from an ACIS file? Do they appear as entitysets, or do I try to retrieve them from a tag called "Group" Thanks Andy

1 0