IEGS export duplicate curves

[jeffallen]

In dupcurve.zip, there are two sections in the wing. In the IEGS export for the wing, there are more curves than strictly necessary to define the wing (screen cap from Creo's "import data doctor", which gives detailed info on what data is coming in during an import):

There are 24 objects of type curve:

jalle@DESKTOP-HC7LR7D UCRT64 /c/Users/jalle/Desktop
$ grep ^126 dupcurve.igs
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,          5P    119
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,          9P    195
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         29P    331
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         33P    343
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         53P    568
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         57P    643
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         61P    656
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         65P    729
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         85P    884
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         89P    896
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         93P    967
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,         97P    980
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        117P   1200
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        121P   1273
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        125P   1286
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        129P   1366
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        149P   1526
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        153P   1539
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        157P   1604
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        161P   1617
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        181P   1812
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        185P   1892
126,72,1,0,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        205P   2030
126,16,1,1,0,1,0,0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,        209P   2100

For example, each surface has 4 curves around it's outside. But that causes duplicate curves at the end caps, and on each "bulkhead" in the wing profile. My ideal number of curves here would be 10: 2 for the leading edge, 2 for the trailing edge, and 2 each for the 3 stations. Having the chord curve in the end caps is annoying, but manageable.

I don't know if this is expected behavior, accidental expected behavior, or a bug.

It came to my attention because when importing into Creo in order to get a very clean, simple, native-to-Creo structure, I needed to get rid of all of these extra curves. (There are built-in simplification algorithms in Creo, of course, but I don't want them moving my splines around and messing up my aero surfaces.)

[jeffallen]

I was experimenting with STEP export as well, and there I found that I've only got the surfaces, and no curves. That's a problem, because I want the surfaces to be lofted as native Creo objects, not imported bspline surfaces, so that the Creo model is simpler and more native, even if it's driven off of curves from OpenVSP.

[ramcdona]

Can you please screen shot and attach the exact settings you used when exporting the IGES file?

[jeffallen]

Settings:

The log:

Transfer Mesh Settings
Fetching Bezier Surfaces
Update Wakes
Cleanup
Loading Bezier Surfaces
Clean Merge Surfs
Identify CompID Names
Build Grid
Intersect 1/8
Intersect 2/8
Intersect 3/8
Intersect 4/8
Intersect 5/8
Intersect 6/8
Intersect 7/8
Intersect 8/8
BuildChains
LoadBorderCurves
MergeInteriorChainIPnts
SplitBorderCurves
IntersectSplitChains
BuildCurves
Binary Adaptation Curve Approximation
Exporting Files
Done

To be clear, I don't find that the curves are wrong per se, just that they are duplicative, and I'm wondering if this on purpose, accidental, etc.

[ramcdona]

Thanks for the clarification. Most importantly, you're using the trimmed surfaces feature (not the un-trimmed feature available under the file-export menu).

When two surfaces meet, we calculate a curve of intersection. That curve exists in XYZ coordinates, but also in UV coordinates of surface A and UV coordinates of surface B. If it is a boundary curve, it can be expressed as a set of control points along the boundary of surface A and also along the boundary of surface B.

These boundary curves apply along feature lines -- the Geom as a whole is split into separate surfaces along feature lines.

In OpenVSP, the SurfA and SurfB representations of these split-line boundaries will always have identical control points, but this is not true for all forms of CAD. In general, it is possible for a curve to have two different representations that are approximately equal in XYZ.

It may be possible for us to recognize this situation and re-use curves more intelligently. However, figuring that out will take a deep dive into the code for writing out intersected STEP and IGES files.

This kind of activity might be in the plan of work in the coming months, but it won't be a near-term thing.

I will keep this issue open to document this question, but don't expect any movement in the short term.