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: [email protected] [mailto:[email protected]] On Behalf Of Patrick Shriwise Sent: Friday, June 26, 2015 2:49 PM To: [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Tim Tautges Sent: Friday, May 15, 2015 2:30 PM To: [email protected] 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:[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