View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0033618 | Community | OCCT:Data Exchange | public | 2024-03-01 12:59 | 2024-03-14 14:15 |
| Reporter | ebknudsen | Assigned To | ika | ||
| Priority | normal | Severity | minor | ||
| Status | new | Resolution | open | ||
| Platform | Linux | OS | Ubuntu 20.04 | ||
| Product Version | 7.7.0 | ||||
| Summary | 0033618: STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. | ||||
| Description | In certain cases the step-element DEGENERATE_TOROIDAL_SURFACE gets a wrong orientation. It happens when the surface in question is created by a revolve-operation in a certain subset of case, when the toroid minor axis rotation point is to the left of the revolve axis and the surface is not cut above the center plane of the toroid. See attached sketches in degenerate_toroid_bowls-2.pdf. When the minor axis rotation point is above the cut plane or to the right of the revolving axis things work as expected. | ||||
| Steps To Reproduce | Compile and run the attached sample program glfwocct build upon the sample glfw-program distributed with OCCT, and run it with any of the supplied .step files as argument. All of the versions named "*_left_below_*.step" fail, whereas "*_right_* and "*_above_*" all work as expected. From examining the resulting shapes it seems the orientation of the curve generating the surface gets interpreted in the wring direction, meaning instead of using the short path from point to point the long path is chosen. | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
| related to | 0031672 | new | dpasukhi | Data Exchange, STEP reader - Surface wrongly recognized as degenerate torus |
| has duplicate | 0033622 | closed | STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. | |
| has duplicate | 0033619 | closed | STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. | |
| has duplicate | 0033620 | new | ika | STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. |
| has duplicate | 0033621 | closed | STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. |
|
|
glfw_deg_toroids.zip (48,965 bytes) |
|
|
I have a similar problem with shapes created trough a revolution (around an axis) of a profile composed of conic arcs. The geometry is created in freeCAD and it lookds good inside of it. But it becomes messy when exported in a step file (annexed below) and imported in Catia. The geometry seems ok in FreeCAD even when I reimport the step file inside of it. You may look also at https://github.com/realthunder/FreeCAD/issues/966. Screenshot from 2024-03-07 13-06-42.png (192,408 bytes) catiaImport2.png (120,982 bytes) CMP_FILTER_V7.step (41,984 bytes) |
|
|
Degenerated torus one of the most difficult object for OCCT, we process only outer degenerated surface, but STEP ask for internal degenerated surface. Limon or Lens is result of self-intersection. We need to update mathematical formula. The most comfortable issue to develop is 0031672 |
|
|
I do not think that my geometry is a degenerated torus. Here below is the profile I was revolving. It is composed of a elliptic arcs connected with linear segments. In the exported step file one of the generated surfaces appears as: #82 = SURFACE_OF_REVOLUTION('',#83,#88); #83 = ELLIPSE('',#84,3.628211247935,1.202639037158); #84 = AXIS2_PLACEMENT_3D('',#85,#86,#87); I think that that the surface is correct and that the problem is in the representation of bounding curves. In example the largest face shown in the Catia import is bad because it is not properly limited by the boundary curves. It seems to me that the curve orientation (which usually defines the inner part of a face) is wrongly defined in Opencascade. I have tried also with another commercial CAD System which produced the same result as Catia so I think the it is OCC (not Catia) that has the wrong curve orientation. Screenshot from 2024-03-07 15-05-11.png (148,052 bytes) |
|
|
Wrt. deg. toroids: I agree that definitely it is not easy - I am not sure I quite agree with your conclusion though. From what I can see in (most of) my test cases - it is when the inner solution is asked for, that things work. Nevertheless, I'd be happy to contribute some work here if I can - but being new to the code-base it takes some time to figure out exactly where these things are defined. Any help as to where to start looking would be greatly appreciated and helpful. I will take a look at the other issue pointed to (0031672). |
|
|
Wrt the revolution surface, I downloaded the step, and tried displaying it with my edited glfw-viewer for step-files - this time compiled with OCCT 0.7.8. This appears to have worked fine, interestingly. Maybe updating will solve that particular prob. revolution_surface.png (40,431 bytes) |
|
|
Hi ebknudsen, in fact this step file was created with FreeCAD and it displays well in FreeCAD or in any other SW based on Opencascade. But it displays very badly in commercial CADs (I have tried with Catia and ZW3D). So, in my opinion, the step file is wrong because the orientation of boundary curves is good for OCC but it is not compliant with the step format. |
|
|
Hi wsteffe, Oh I get it now, I misunderstood you, sorry. That is at least circumstantial evidence that OCCT has it the wrong way then. I don't have access to the STEP-standard, so I have no way of verifying either the one or the other I am afraid. |
|
|
Actually it is not only a problem of inconsistency with step standard. I firstly discovered that the annexed struccture had a problem when I was trying to mesh it with my EmCAD code (https://github.com/wsteffe/EmCAD) which is based on OpenCascade. The produced mesh files include the normal vectors associated with mesh points belonging to non planar faces. So, looking inside of this file, I have seen that on the curved surfaces generated by the revolution of elliptic arcs, the normal vectors were flipping in the opposite direction near some boundary curves. This is a very strange behaviour that I am not able to explain. |
|
|
Interesting - FYI I noticed my problem when I tried to create 3D surface meshes using OpenCascade with my CAD_to_OpenMC code (https://github.com/openmsr/CAD_to_OpenMC). This uses OCCT through a python layer (cadquery). |
|
|
Perhaps now I have understood what was happening with my mesh. The elliptic arcs I have used in my profile are all centered on the revolution axis. In this situation if only half ellippse is used (the part lying on one side of the revolution axis) a complete (360 deg) revolution generates a rotational ellipsoid. But because (as it appears from the annexed step file lines) the full elllipse is used,the complete revolution generates two overlapping ellipsoids. These ellipsoids have opposite orientations as it can easely be checked that extending the earth latitude coordinate beyond the 90 deg of the north pole. This explains why I was observing flipping normals. I was putting the mesh points (generated by gmhs) on the associated face F with following code: Handle(Geom_Surface) GS = BRep_Tool::Surface(F); GeomAPI_ProjectPointOnSurf proj(pnt, GS); proj.LowerDistanceParameters(u,v); GeomLProp_SLProps props(GS,u,v,1,0.001); gp_Vec n=props.Normal(); But proj.LowerDistanceParameters(u,v) may find one of two solutions which have same positions but opposite nomal orientations. The actual solution was randomly flipping from one orientation to the other. |
|
|
That seems plausible - It suggests a randomness (perhaps caused by numerical precision) depending on which solution happened to be picked. Perhaps the commercial solutions you have tried had more strict conventions. In my case with degenerate toroids I'm no closer to a solution. I first have to find where in the OCCT-libs the inner/outer selection is interpreted. |
|
|
Hy ebknudsen, I was looking at your examples in the annexed pdf document. In the firts example you are saying "the toroidal surface is cut by a plane above the center plane of the toroid." But it is not clear to me what is the center plane of the toroid. If by toroid you mean the surface geberated by the extrusion of the full circle the central plane should pass trough the circle center. But in the firts picture the circle center is above (not below) the cut plane. |
|
|
Hi @wsteffe, I'll try to explain what I mean. If I think of the torus as being generated by circle with radius r_minor being "swept" along a circle with radius r_major, then what I mean with the torus center plane is the plane spanned by the r_major-circle. Of course this means that the generating circle (with radius r_minor) has its center in that plane. In my examples a bowl-shape is created by cutting the torus with a plane parallel to the torus center plane. If the cut-plane is above the torus center plane this means that the center of the generating circle (r_minor) is below the cut-plane which is what I mean by below in my file names. Perhaps my choice of convention was not very intuitive, for this I am sorry. I hope that made it clear? |
|
|
Hi @ebknudsen,, It is clear but in the first picture it seems to me that the circle center is above the cut plane by a distance of 05. So because the center plane pass trough the circle center also the center plane is above the cut plane. But in the text you are saying the opposite (the cut is above the centerplane). |
|
|
Ah I see, I have made a mistake in making the zip-file. Assuming you mean the file "bowl_fc_outside_below.step". This should not have been included in the test suite. In fact it does not even have a toroid in it. Apologies. In fact "bowl_rb.step" was included by mistake as well. |
|
|
Hi @ebknudsen, actually I looked only at the pdf file (not the step files). |
|
|
Hi again @wsteffe. Yes I see that I've made a mistake there as well - I obviously meant to write below - not above. Thanks for pointing that out. I'll fix that and upload a new version of the pdf. |
|
|
degenerate_toroid_bowls-2.pdf (341,392 bytes) |
|
|
I have fixed the orientation problem uf surface normals using u,v coordinates that are stored by gmsh in the surface meshing algorithms (which operate in th 2D space). In this way I may avoid using the OCC projection on the underlying surface (GeomAPI_ProjectPointOnSurf) which was the source of ambiguity. So I may conclude that the problem is only in the importing/exporting of step files while all seem to be coeherent inside of OCC data structures. Regarding the step problem I suspect that OCC makes use of a different parametrization of the conic/circular curves placed in the revolved profile. The useful portion the generated surface is clearly defined by the lower and upper limits of this parameter but if another CAD makes use of a different parametrization (probably only a different origin of the periodic parameter) it may easily select a different portion of the toroidal surface leading. |
|
|
Question @dpasukhi: Do you know if anyone is working on the degenerate toroid formulation to extend it to also possibly handle the second kind of surface? I'd be happy to do some work here, and if someone is actively pursuing the issue it is better to collaborate. |
|
|
Hello, the current issue is not a part of ongoing release. At the moment OCCT team have no assigned person who working on that issue. Previously, the number of problem files was low and the priority of the issue going to be low, now we will analyze the priority again for the next release. Best regards, Dmitrii. |
|
|
Hi @ebknudsen, You said that your test cases were created with a sweep along a circular path but you could have used instead a revolution around the circle axis. I think it would be interesting if you may recreate your test cases in this way. The revolution feature is used more often than sweep feature. If you may demonstrate that this issue affects also revolved shapes it could get a higher priority. |
|
|
@wsteffe In fact I did use a revolution operation. When I wrote "swept" it was meant purely for the sake of clarifying what my geometry was supposed to be, not the way it was generated. |
|
|
Hi @dpasukhi, Thanks for the heads up. I will then see if we can free up some resources to examine the problem and hopefully come up with a prototype solution. |
|
|
Hi @dpasukhi, but looking at https://tracker.dev.opencascade.org/roadmap_page.php, it seems that this issue is scheduled for release 7.8.1 (which I think shuld be the next one) and assigned to ika. Isn't true ? |
|
|
Hi. No, the target version was updated not by our team. Ika is the person who will need to detect the target. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-03-01 12:59 | ebknudsen | New Issue | |
| 2024-03-01 12:59 | ebknudsen | Assigned To | => ika |
| 2024-03-01 12:59 | ebknudsen | File Added: degenerate_toroid_bowls.pdf | |
| 2024-03-01 12:59 | ebknudsen | File Added: glfw_deg_toroids.zip | |
| 2024-03-01 14:49 | ebknudsen | Assigned To | ika => ebknudsen |
| 2024-03-01 14:51 | ebknudsen | Relationship added | has duplicate 0033622 |
| 2024-03-01 14:51 | ebknudsen | Assigned To | ebknudsen => ika |
| 2024-03-01 14:52 | ebknudsen | Relationship added | has duplicate 0033619 |
| 2024-03-01 14:53 | ebknudsen | Relationship added | has duplicate 0033620 |
| 2024-03-01 14:53 | ebknudsen | Relationship added | has duplicate 0033621 |
| 2024-03-04 15:07 | ebknudsen | Description Updated | |
| 2024-03-04 16:31 | ebknudsen | Description Updated | |
| 2024-03-07 15:40 | wsteffe | Note Added: 0115262 | |
| 2024-03-07 15:40 | wsteffe | File Added: Screenshot from 2024-03-07 13-06-42.png | |
| 2024-03-07 15:40 | wsteffe | File Added: catiaImport2.png | |
| 2024-03-07 15:40 | wsteffe | File Added: CMP_FILTER_V7.step | |
| 2024-03-07 16:22 | dpasukhi | Relationship added | related to 0031672 |
| 2024-03-07 16:24 | dpasukhi | Note Added: 0115263 | |
| 2024-03-07 17:21 | wsteffe | Note Added: 0115265 | |
| 2024-03-07 17:21 | wsteffe | File Added: Screenshot from 2024-03-07 15-05-11.png | |
| 2024-03-07 18:17 | ebknudsen | Note Added: 0115266 | |
| 2024-03-07 18:22 | ebknudsen | Note Added: 0115267 | |
| 2024-03-07 18:22 | ebknudsen | File Added: revolution_surface.png | |
| 2024-03-07 18:51 | wsteffe | Note Added: 0115269 | |
| 2024-03-07 19:04 | ebknudsen | Note Added: 0115270 | |
| 2024-03-07 19:14 | ebknudsen | Note Edited: 0115270 | |
| 2024-03-07 19:40 | wsteffe | Note Added: 0115271 | |
| 2024-03-07 20:04 | ebknudsen | Note Added: 0115273 | |
| 2024-03-07 20:04 | ebknudsen | Note Edited: 0115270 | |
| 2024-03-08 10:47 | wsteffe | Note Added: 0115275 | |
| 2024-03-08 11:03 | ebknudsen | Note Added: 0115276 | |
| 2024-03-08 11:37 | wsteffe | Note Added: 0115278 | |
| 2024-03-08 12:49 | ebknudsen | Note Added: 0115282 | |
| 2024-03-08 13:03 | wsteffe | Note Added: 0115283 | |
| 2024-03-08 14:16 | ebknudsen | Note Added: 0115284 | |
| 2024-03-08 14:18 | ebknudsen | Description Updated | |
| 2024-03-08 14:57 | wsteffe | Note Added: 0115285 | |
| 2024-03-08 15:27 | ebknudsen | Note Added: 0115286 | |
| 2024-03-08 15:29 | ebknudsen | Note Added: 0115288 | |
| 2024-03-08 15:29 | ebknudsen | File Added: degenerate_toroid_bowls-2.pdf | |
| 2024-03-08 15:29 | ebknudsen | File Deleted: degenerate_toroid_bowls.pdf | |
| 2024-03-08 15:30 | ebknudsen | Description Updated | |
| 2024-03-08 19:20 | wsteffe | Note Added: 0115292 | |
| 2024-03-11 12:23 | ebknudsen | Note Added: 0115301 | |
| 2024-03-11 15:56 | dpasukhi | Note Added: 0115302 | |
| 2024-03-12 11:22 | wsteffe | Note Added: 0115323 | |
| 2024-03-12 12:20 | ebknudsen | Note Added: 0115326 | |
| 2024-03-12 12:59 | ebknudsen | Note Added: 0115327 | |
| 2024-03-12 12:59 | ebknudsen | Note Edited: 0115327 | |
| 2024-03-14 13:19 | wsteffe | Note Added: 0115361 | |
| 2024-03-14 14:15 | dpasukhi | Note Added: 0115362 | |
| 2024-03-14 14:15 | dpasukhi | Target Version | 7.8.1 => |
