STEP unit conversion and meshing

Hello,

For 99% of my STEP files, I use the conversion from the static interface:

Interface_Static::SetCVal("xstep.cascade.unit", "M")

And the BRepMesh_IncrementalMesh and it works as expected.

For some reason, I have a STEP file composed of an assembly of shells, and meshing fails as all triangulations are Null for all faces.
Strangely if I comment the static interface or set it to "MM", meshing/triangulation works and everything is fine.

Is there a new option for converting to Meters ?

NOTE: CAD Assistant opens 100% of my files, so I'm pretty sure this is a missing option of a bug.

Kirill Gavrilov's picture

Is there a new option for converting to Meters ?

OCCT 7.6 has introduced a new interface for managing length units conversion while importing into XCAF document as alternative to previously used "xstep.cascade.unit" (which is still supported for backward compatibility) - XCAFDoc_DocumentTool::SetLengthUnit().

NOTE: CAD Assistant opens 100% of my files,

You may play with length units in CAD Assistant as well - see "System units" in "Import/Export options" in Settings.

Strangely if I comment the static interface or set it to "MM", meshing/triangulation works and everything is fine.

This might happen when model becomes smaller than global constants like Precision::Confusion() and similar, used by OCCT algorithms as smallest allowed tolerance values. You should be careful to use different length units due to these side effects and select units suitable for your real models considering these global OCCT constants. E.g. it is likely not a bug of BRepMesh_IncrementalMesh or other OCCT, but a limitation by design.

Antoine H's picture

Thanks for your answer. I tried to use this new fonction and the result is the same.
For both STEPs that work/dont work, the unit is mm.

Another info:
Both STEP are about 10-30cm long, so no small parts that would get below Confusion();
For the STEP that is not working, which is made of a few parts, only one part (shell) seems to cause problems. If I export the STEP without this shell, then the meshing works with/without unit conversion. As soon as there this shell part, meshing only works if I don't do any conversion using both of the above method (and read it as plain mm). Confusion() is on me :)

Kirill Gavrilov's picture

Both STEP are about 10-30cm long, so no small parts that would get below Confusion();

Sorry if my description looked confusing - I didn't meant the size of entire part, but the lower-level geometry and topology definition, like distances between B-Spline nodes, vertex/edge/face tolerances, etc.

Antoine H's picture

Ok that clearer then.

Another test:
- Loading a STEP in mm units , checking with XCAFDoc_DocumentTool::GetLengthUnit(doc, conv_val) gives conv_val=0.001, Fine
- Loading a STEP in m unites, checking with XCAFDoc_DocumentTool::GetLengthUnit(doc, conv_val) gives conv_val=0.001, Very strange !
- Loading a STEP in mm units , checking with XCAFDoc_DocumentTool::GetLengthUnit(doc, conv_val, UnitsMethods_LengthUnit_Meter) gives conv_val=0.001, Fine
- Loading a STEP in m unites, checking with XCAFDoc_DocumentTool::GetLengthUnit(doc, conv_val, UnitsMethods_LengthUnit_Meter) gives conv_val=0.001, Very strange !

Kirill Gavrilov's picture

Loading a STEP in m unites

What does it mean?

Antoine H's picture

Loading a document that was exported from Fusion360 with Meters as the document unit.
A simple cube of 1000mx500mmx250mm has cartesian points like this :
#156=CARTESIAN_POINT('',(0.,0.,0.));
#157=CARTESIAN_POINT('Origin',(1.,0.5,0.));
#158=CARTESIAN_POINT('',(1.,0.5,0.));
#159=CARTESIAN_POINT('',(0.,0.5,0.));
#160=CARTESIAN_POINT('',(1.,0.5,0.));
#161=CARTESIAN_POINT('',(0.,0.5,0.25));

1m, 0.5m, 0.25m.

It seams that the STEPCAFControl_Reader does not seem to catch the unit in the file, causing bad conversions, tiny edges etc..

Kirill Gavrilov's picture

Loading a document that was exported from Fusion360 with Meters as the document unit.

You are exporting exactly the same model - why would you expect different import results?

Loading a STEP in m unites, checking with XCAFDoc_DocumentTool::GetLengthUnit(doc, conv_val) gives conv_val=0.001, Very strange !

XCAFDoc_DocumentTool::GetLengthUnit() has nothing to do with the length units of imported file, it defines units into which file should be converted during import process. So reported value wouldn't change until you will call SetLengthUnit() or similar method.

Dmitry Pasukhin's picture

Hi,

It seams that the STEPCAFControl_Reader does not seem to catch the unit in the file, causing bad conversions, tiny edges etc..

All file's length and angle units, attached to the entity, should be processed correctly. (they scaled to the system unit).

This case seems very strange. STEPCAFControl_Reader ensures that if the document does not have its own length unit, a global static variable value(scale unit) will be set to the document.

In addition, the STEPCAFControl_Reader sets the used length unit in the document as an attribute. You can always check it out. If in your document exists only MM attribute, MM unit is used for read.

Can you check if the length units exist in the document before read process? By default, a new document does not contain a length units attribute. If the attribute is created by you, or the document is reused, then the static variable will not be used when reading (the attribute has a higher priority).
Additionally, can you check the MASS or AREA of the imported shapes?

GProp_GProps aProps;
BRepGProp::VolumeProperties(aShape, aProps);
Standard_Real aVolume = aProps.Mass();

BRepGProp::SurfaceProperties(aShape,aProps,0.001);
Standard_Real anArea = aProps.Mass();

Best regards,
Dmitry.