View Issue Details

IDProjectCategoryView StatusLast Update
0033618CommunityOCCT:Data Exchangepublic2024-09-27 01:50
Reporterebknudsen Assigned Todpasukhi  
PrioritynormalSeverityminor 
Status newResolutionopen 
PlatformLinuxOSUbuntu 20.04 
Product Version7.7.0 
Summary0033618: Data Exchange, STEP-import - Support of DEGENERATE_TOROIDAL_SURFACE
DescriptionIn 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 ReproduceCompile 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.
TagsNo tags attached.
Test case number

Attached Files

  • glfw_deg_toroids.zip (48,965 bytes)
  • Screenshot from 2024-03-07 13-06-42.png (192,408 bytes)
  • catiaImport2.png (120,982 bytes)
  • CMP_FILTER_V7.step (41,984 bytes)
  • Screenshot from 2024-03-07 15-05-11.png (148,052 bytes)
  • revolution_surface.png (40,431 bytes)
  • degenerate_toroid_bowls-2.pdf (341,392 bytes)

Relationships

related to 0031672 newdpasukhi Community Data Exchange, STEP Import- Surface wrongly recognized as degenerate torus 
related to 0029233 closedsmoskvin Open CASCADE Data Exchange - Incorrect result of conversion to the STEP format. 
has duplicate 0033622 closed Community STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. 
has duplicate 0033619 closed Community STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. 
has duplicate 0033620 closedika Community STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. 
has duplicate 0033621 closed Community STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. 

Activities

ebknudsen

2024-03-01 12:59

developer  

glfw_deg_toroids.zip (48,965 bytes)

wsteffe

2024-03-07 15:40

reporter   ~0115262

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)

dpasukhi

2024-03-07 16:24

administrator   ~0115263

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

wsteffe

2024-03-07 17:21

reporter   ~0115265

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)

ebknudsen

2024-03-07 18:17

developer   ~0115266

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).

ebknudsen

2024-03-07 18:22

developer   ~0115267

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)

wsteffe

2024-03-07 18:51

reporter   ~0115269

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.

ebknudsen

2024-03-07 19:04

developer   ~0115270

Last edited: 2024-03-07 20:04

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.

wsteffe

2024-03-07 19:40

reporter   ~0115271

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.

ebknudsen

2024-03-07 20:04

developer   ~0115273

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).

wsteffe

2024-03-08 10:47

reporter   ~0115275

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.

ebknudsen

2024-03-08 11:03

developer   ~0115276

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.

wsteffe

2024-03-08 11:37

reporter   ~0115278

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.

ebknudsen

2024-03-08 12:49

developer   ~0115282

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?

wsteffe

2024-03-08 13:03

reporter   ~0115283

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).

ebknudsen

2024-03-08 14:16

developer   ~0115284

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.

wsteffe

2024-03-08 14:57

reporter   ~0115285

Hi @ebknudsen, actually I looked only at the pdf file (not the step files).

ebknudsen

2024-03-08 15:27

developer   ~0115286

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.

ebknudsen

2024-03-08 15:29

developer   ~0115288

degenerate_toroid_bowls-2.pdf (341,392 bytes)

wsteffe

2024-03-08 19:20

reporter   ~0115292

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.

ebknudsen

2024-03-11 12:23

developer   ~0115301

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.

dpasukhi

2024-03-11 15:56

administrator   ~0115302

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.

wsteffe

2024-03-12 11:22

reporter   ~0115323

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.

ebknudsen

2024-03-12 12:20

developer   ~0115326

@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.

ebknudsen

2024-03-12 12:59

developer   ~0115327

Last edited: 2024-03-12 12:59

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.

wsteffe

2024-03-14 13:19

reporter   ~0115361

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 ?

dpasukhi

2024-03-14 14:15

administrator   ~0115362

Hi. No, the target version was updated not by our team. Ika is the person who will need to detect the target.

dpasukhi

2024-09-18 15:14

administrator   ~0116706

The possible and optimal solution - convert the DEGENERATE_TOROIDAL_SURFACE into BSpline during conversion.
Will be tested in the ongoing time.
(The same workaround done for export)
see 0029233

Issue History

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 =>
2024-09-18 15:14 dpasukhi Note Added: 0116706
2024-09-18 15:14 dpasukhi Assigned To ika => dpasukhi
2024-09-25 10:59 dpasukhi Summary STEP-import of DEGENERATE_TOROIDAL_SURFACE can be misinterpreted. => Data Exchange, STEP-import - Support of DEGENERATE_TOROIDAL_SURFACE
2024-09-27 01:50 dpasukhi Relationship added related to 0029233