[cgma-dev] CGM OCC sense issues

Fri Jun 12 16:34:35 CDT 2015

Patrick,

I haven't had as much time to dig into this issue lately as I would like, but I have been putting some time into understanding OpenCascade, and I am making some progress.

It turns out that I can change the way that OCC-based CGM makes a brick, and if I use the lower-level APIs, it appears that I can sew together a box based on underlying geometric surfaces that have the outward-facing normal that you want.  Although I have not confirmed it through testing, I think that changing this would fix the particular test that you sent to me.

I suspect that it would not fix all of the issues you are seeing, though.  We could probably guarantee that several other of the iGeom methods that create geometric objects would give outward facing normals, but I'm not sure we could achieve that with all of the iGeom methods.  Swept volumes, for example, might be a problem.  In any case, I'm quite certain that I could not make any guarantees when you are reading geometry from a file on disk, and I stick with my earlier conclusion that the right thing to do is to make MOAB and DagMC check the coface sense.

Would it help you if I change the way that OCC constructs a brick so that all surfaces of the brick have outward-facing normals?  What about other iGeom volumes?  Are you building all of the volumes you need for DagMC with iGeom geometry creation methods?

Even if I change the way certain OCC volumes are constructed, the coface sense will be broken for OCC geometry in some situations, and that's a bigger problem.  I've discovered that there is an OCCCoFace object that no longer does anything useful but, based on commented-out code, may at one time have been used to initialize the coface senses for OCC geometry.  I think we should get rid of the OCCCoFace class.

The direction of the normal that is returned from the closest_point(...) and evaluate(...) methods of an OCCSurface is controlled in an entirely different way from the OCCCoFace, relying on the orientation flag of an OCC library object called a TopoDS_Face.  I think the snippets of code that update the TopoDS_Face orientation are incomplete and unreliable, but some of the time this will make CGM compute the correct normal.  By itself the orientation of this TopoDS_Face does not affect the OCC library's computation of the normal or its computation of the triangles returned from get_graphics, so the relevant computations have to flip things explicitly inside CGM.  I don't think TopoDS_Face is the right place to track whether the normal should be flipped, but I don't yet have a complete proposal for how CGM should completely fix the coface sense bug in OCC.  My current favorite idea is to query OCC to get the senses, but I'm not sure that can be done in a computationally efficient way and I haven't solved all the issues, such as how that would interact with the bridge sense.

-Evan

-----Original Message-----
From: cgma-dev-bounces at mcs.anl.gov [mailto:cgma-dev-bounces at mcs.anl.gov] On Behalf Of Tim Tautges
Sent: Friday, May 15, 2015 2:30 PM
To: cgma-dev at mcs.anl.gov
Subject: Re: [cgma-dev] CGM OCC sense issues

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: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
>

-- 
Timothy J. Tautges
Manager, Directed Meshing, CD-adapco
Phone: (631) 629-3139 (internal: x29130)
Mobile/Gvoice: (608) 354-1459
timothy.tautges at cd-adapco.com