[cgma-dev] CGM OCC sense issues

Vander Zee, Evan B. vanderzee at anl.gov
Tue Jun 30 08:55:14 CDT 2015 

Hi Patrick,

I've attached the test I made of a different way to build a brick in OCC.  Something like this code would replace the following line of OCCModifyEngine::brick in OCCModifyEngine.cpp as well as the two lines later in the method that move the brick.

TopoDS_Solid S = BRepPrimAPI_MakeBox(wid, dep, hi);

The difference is that I explicitly make the faces from geometry and sew together the faces to make the box.  The explicitly build the geometry to have the normal that you expect.

Remember that the current API for the get_graphics method of CGM passes only a surface.  Given only a surface, there is not enough information to know which volume (if there even is a volume) would be used to give you a "relative" surface normal.  The .brep file does, of course, know which surfaces bound which volumes, so it can use that information to give you a relative surface normal.  I'm not sure how Cubit (or CAD systems in general) "track the surface in some absolute way and relative way" so I guess I don't quite understand what you're getting at there.

My opinion is that CGM should not establish a convention for the direction of surface normal vectors.  It seems pretty tricky to define what that convention is and even more difficult to both provide consistent surface normal directions and be consistent about that convention as the geometry changes.

We are in a software requirements discussion, I guess.  What is the design for CGM?  What is its responsibility?  Who gets to decide?

Regards,

Evan


-----Original Message-----
From: cgma-dev-bounces at mcs.anl.gov [mailto:cgma-dev-bounces at mcs.anl.gov] On Behalf Of Patrick Shriwise
Sent: Friday, June 26, 2015 10:59 PM
To: cgma-dev at mcs.anl.gov
Subject: Re: [cgma-dev] CGM OCC sense issues

Hey Evan,

It would be interesting to see what you have to do during the creation 
of the brick to get the ourward facing normals. It might shed some light 
on how we fix things in the future for this problem. Would you mind 
making a branch with what you've done and putting it online somewhere 
for others to see?

Its interesting that .brep files don't track the surface normals in some 
absolute way and relative way like Cubit does. I don't know a lot about 
the OCC system, but this seems that this is a common functionality among 
CAD systems. If this is not the case, then the loading of a .brep file 
into CGM might require some extra steps to correctly establish these 
sense relationships in the same way we do this for ACIS files.

For the time being, of the two options you've presented for addressing 
this issue, I think that (2) is the better solution. Its my feeling that 
when generating the mesh, the conventions for the directions of normals 
should be established by CGM rather than the underlying CAD package. 
Additionally, because MOAB is designed to be a database rather than a 
generation tool, I don't think that its is MOAB's responsibilty to 
re-orient triangle normals. If this were a MK meshop we were talking 
about, there might be a bit more of a grey area, but even then I think 
its better to establish a convention like this inside the system in 
which the information lies to fix the problem.

Cheers,

Patrick



On 06/26/15 13:57, Vander Zee, Evan B. wrote:
> Patrick,
>
> Thanks for your reply.  I haven't yet committed any changes related to the issue; I've only done research on it and run some experiments in my home directory.  It would be fairly easy to commit a changing to the way that bricks are created, but based on your description of the DagMC process -- that it works by reading a file -- this would not help you directly at all.  Although I haven't carefully reviewed how OCC reads and writes .brep files, I think that the file itself stores information about what direction the normal should be from a surface when you ask for the normal without a context of which volume it should face away from.
>
> Thus if you want to have the convention of outward-facing normal vectors for isolated volumes, you would have to change the .brep file that you are reading.  All that CGM will do for you (once the bugs in coface sense are fixed) is give you a normal direction that agrees with the orientation of the facets you get from get_graphics.
>
> You are correct that the facets created through the iGeom interface get created by calling get_graphics.  When using OCC, the orientation on those facets corresponds to the way OCC represents (and parametrizes) the geometry for the surface.  I can change the way a brick is created so that OCC has a different representation of the geometry behind the facets.  I cannot easily change the way a .brep file is read in or the geometry you will get underneath facets read from the file because we delegate most of that task to the OCC library.
>
> E-mail is probably not the best way to explain this, but in any case, I return to my earlier conclusion that either
> (1) MOAB will have to be aware of whether the surfaces normal is outward and will have to change the facet orientation if the normal is inward
> or
> (2) The interface will have to change when getting graphics so that CGM can know which volume defines the outward direction and CGM will have to change the facet orientation before returning it to MOAB.
>
> The bug in coface sense remains -- I haven't worked on it more since my e-mail two weeks ago -- and I think we agree that needs to be fixed.  That task is currently at the top of my list unless I am directed otherwise from the people who manage my cost code.
>
> -Evan
>
> -----Original Message-----
> From: cgma-dev-bounces at mcs.anl.gov [mailto:cgma-dev-bounces at mcs.anl.gov] On Behalf Of Patrick Shriwise
> Sent: Friday, June 26, 2015 2:49 PM
> To: cgma-dev at mcs.anl.gov
> Subject: Re: [cgma-dev] CGM OCC sense issues
>
> Hey Evan,
>
> It definitely sounds like a step toward what we are going for! We were
> expecting something like what you're describing with the TopoDS_Face not
> updating bridge senses correctly or not checking the bridge sense when
> returning faceting. Fixing OCC for brick creation would be a good step,
> but it really sounds like we should tackle the larger problem at hand
> with the OCC senses.
>
> At this point, it would probably be good to determine the best way to
> fix the issue and create some test cases for it. I should probably take
> a closer look at what you've done so far so we're on the same page as we
> move forward with this.
>
> As for the process DagMC uses to create its surface mesh representation
> in MOAB, a program called dagmc_preproc in MOAB uses the readCGM reader
> to load the file and all facets via direct calles to the CGM
> get_graphics function (no iGeom used here), and topology information via
> MeshSets. Volumes are then tageed with material information and the mesh
> is then ready for analysis.
>
> At any rate, my understanding of the iGeom interface is that even
> volumes created in iGeom are sill faceted using an underlying CGM
> get_graphics call in the same way that readCGM does this in MOAB. IT
> doesn't sound like this should affect the way the facets are returned
> unless you are creating a brick in a very explicit way to ensure the
> normals will be outward facing as a step around for the sense bug
> currently in OCC.
>
> Cheers,
>
> Patrick
>
>
>
> On 06/12/15 16:34, Vander Zee, Evan B. wrote:
>> 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
>


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: makeBox.cpp
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20150630/81b29611/attachment.ksh>

More information about the cgma-dev mailing list