STP doesn't recognize solids

Hi,

this is probably a more general question, but I am putting it here in the Developer category because I wonder if I can do something to solve this programmatically.

Namely,
when one exports solids (closed polysurfaces) from Rhino as STP, when opened in different software (like eDrawingsfor example) they are split into surfaces.

Some software might recognize them as solids (I think Inventor does, but I am not sure), however I would like some consistency and to understand the problem. The fact that when I reimport STP to Rhino I have the option to “Join Surfaces” makes me wonder if they are actually exported and saved in their exploded version?

So the main question is, can something be done to the solids (User strings, user data?) so that the STP recognizes them as such?

I know that some software distinguishes also assemblies and parts…is it possible to mark rhino geometry as such (using custom code I mean)? Although that would be a second, much more advanced question.

For now I would like the solids to be recognized as solids, and assemblies and parts would be a nice plus.

Thanks.
Milos

Step files should be solids. Edrawings isn’t really a representative example.

Back in the day when I was working with engineers and exported STEP files frequently this used to be the case IF I modelled with too low tolerance. If you model with 0.01 units accuracy Rhino will accept surfaces this far apart when joining up, but if the receiving software uses 0.001 units accuracy when it reads in the STEP then those gaps will not be interpreted as joined.

That said, STEP does support solids and Rhino can write them, so try a different export schema when exporting and check in different softwares. Reading the STEP back into Rhino is also an option, to see if the file behaves properly.

Try this schema:

1 Like

Actually, you might want to uncheck “Split closed surfaces” in the STP export.

Yes, test that out. Some cad programs don’t operate with closed spheres as single surfaces like Rhino does, and needs these to be multiple surfaces, but test it out.

If you’re using RhinoCommon Rhino.FileIO.FileStp.Write(...), set Rhino.FileIO.FileStpWriteOptions.SplitClosedSurfaces to false

From my personal experience, there is no other way than to make sure that the geometry is properly set-up before exporting.

Usually in this case the importing software is a typical Mechanical CAD (MCAD) style software using a hierarchy consisting of assemblies, sub-assemblies and parts. (e.g. Catia, Inventor, Solidworks, Creo, etc.).

MCADs typically have two ways of importing a STP (which may be auto-detected):

  1. import as “single part”
  2. import as “assembly” by interpreting the STP contents as a hierarchy

Since MCAD default modeling tolerances are likely set to 0.001 mm (or even smaller), the Rhino polysurface solid should fulfil this tolerance as well.

“single part” STP export:
Ensure that there is only one single closed solid polysurface exported per individual STP. Additional extra solids may or may not confuse the importing software. If the “single part” consists of multiple solids, it should be considered as an assembly.

“assembly” STP export:
A hierarchy consisting of nested block instances (=the “assemblies”), where the final “leaf” block instances (=the “parts”) of the nested block tree each contain a single closed polysurface. The topmost block instance (=the “root/main assembly”) can be exported to get an “assembly” step - which then still must be imported as an assembly by MCAD.

Just as @Holo and @JimCarruthers pointed out, this must still be tested by the importing software.

1 Like

Thanks Michael for the thorough explanation.

For now…blocks are the solution!

Once I turned every solid into a block, then it was recognized as solid. I guess that was needed to create the proper assembly hierarchy.

Greetings,
Milos