[cgma-dev] CGM OCC sense issues

[Vander Zee, Evan B.]

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 at mcs.anl.gov [mailto:cgma-dev-bounces at mcs.anl.gov] 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:shriwise at wisc.edu] 
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:shriwise at wisc.edu]
> 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:shriwise at wisc.edu]
>> 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