Inconsistency in Read/Write with OCCT tools

Running a test with the OpenCascade Plugins Read/Write operators has exposed a potential issue where the representation that is written with BRepToos::Write is inconsistent with the shapes that are stored under the hood in the TopeDS_Shape.

This is illustrated when loading the attached STEP file, writing it back as a BRep file, and then reloading the BRep file.

Visually the models appear to be nearly identical, but upon closer inspection of the model entities there are missing entities from the original model representation.

Plugin Code: https://gitlab.kitware.com/cmb/plugins/opencascade-session
Test Data: https://data.kitware.com/#user/606b71c62fa25629b95d7506/folder/60db51872fa25629b9a21d75

@dcthomp @Bob_Obara @aron.helser @johnt Do you guys have any thoughts on this?

what model entities are missing? to write a STEP file, a TopoDS_Shape needs to be translated, and that translation (from BRep_Tools::Write) may be missing those types of entities. Maybe try using the STEPControl_Writer for writing?

I am writing a BRep file from the internal shapes. The original model that was a STEP file seems to import correctly.

Right, but that shape may be simplified in the export to STEP process. Here are some options for how that export occurs: STEPControl_StepModelType.hxx File Reference - Open CASCADE Technology Documentation

Notice that some options do potentially remove geometry.

I think the issue here is that he’s not exporting to STEP but writing the imported data out in OCC’s native file format.

All I can think to do is identify what entities are not being saved by

  • importing the step file
  • running the “save” operation which writes a .smtk and a .brep file
  • importing the .brep file (which will assign new, non-conflicting uuids to all shapes) and using 2 TopoDS iterators to see where the mismatches are and how they might be related.
Privacy Notice