Proposal: Importing STEP assemblies as nested layers, not nested blocks

I don’t know. Right now we only export AP214AutomotiveDesign, AP214AutomotiveDesignCC2, and AP203ConfigControlDesign. I have no idea what we import - probably a lot more than those.

Merely an importer/exporter. I suppose at some point a Rhino.Inside solution might exist, but we’re not there yet. There’s still the problem of effectively maintaining the data from MCAD in Rhino in a way that it can round trip.

That, and reference geometry for modeling something else. I’m NOT trying to turn Rhino into an MCAD modeler. I’m trying to find a way to make it so that designers can reference MCAD data, and optionally tweak it, in a reasonable way. Maybe this is a pipe dream :slight_smile:

Yeah, that’s way beyond the scope of what I’m trying to figure out here.

That’s an interesting idea… that’s sort of how we’re dealing with Rhino.Inside Revit lately. Revit is to architecture as MCAD is for engineering, and many of the same problems exist - defining certain types of objects with certain characteristics that interact with other types of objects in well-defined ways.

A post was split to a new topic: Rhino Inside CATIA?

That mirrored components become separate in Rhino is completely fine. If I want to import a modified set of surfaces from a mirrored component back into Catia/Solidworks/NX, they will end up in the “master side” anyway, and get mirrored automatically to the other.

Again, what’s important to me is the rotation, and I’m still unclear if the basepoint/transform you are talking about includes it (my testing so far seems to indicate that no, it currently doesn’t, but again, I might be missing something).

@chuck just told me that STEP doesn’t support mirror transforms (only translation and rotation) so I guess my we don’t have to worry about them after all.

Remember that we’re prototyping by hand right now, so anything we do in Rhino to invent a new way of structuring data isn’t going to translate into STEP in a meaningful way. At this point, I’m trying to figure out if there’s any agreement about how a STEP assembly could import into Rhino in a way that has hope of being flexible, editable, and round-trippable.

The steps to solving this problem are:

  1. Come to some agreement about a solution that could work
  2. Prototype the solution manually and test (this may be hard/impossible)
  3. Actually change the STEP import/export code and test it.

@chuck tells me this isn’t going to be easy or quick to implement, even if we get a sane idea of what makes sense.

I believe the quickest solution is to simply change the code of the importer to (as the title says) import nested layers instead of nested blocks. That is currently possible with Python. I see no reason why it could be difficult to implement in Cpp. Also if I’m not wrong the importer is a plugin so messing it up won’t affect Rhino directly. Try it out, we’ll test the WIP and provide feedback.

update: to clarify a bit, the python script that I use is:

  • scanning the nested block
  • creating layers for each block
  • assigning the blocks to the respective 3d object.
  • deleting the blocks

You could simply add this as another checkbox/radio button in the importer gui keep the nested block functionality and if the user prefers create nested layers.

In MCAD, assembly relationships are strictly enforced. In Rhino, assembly relationships would be implied by nested layer membership.

Consider this:

  1. You import a STEP file with several instances of an assembly, and Rhino creates several different layers: assembly:1, assembly:2, assembly:3
  2. You leave all objects in assembly:1 alone.
  3. You transform all of the objects in assembly:2 uniformly
  4. You move one part within assembly:3 but leave the rest where they were
  5. You export as STEP

In this case, the best Rhino can do is to export assembly:1 and assembly:2 as instances of the original assembly, and make up some new assembly for assembly:3.

There would be no warning when the assembly relationship was broken.

Is that adequate?

:thinking:, isn’t it easier to simply create a separate panel for the nested blocks?

A treeview like panel.

1 Like

Probably not; especially if you’re looking to hide/show specific stuff inside the nested blocks or delete parts of the assembly you don’t need. Maybe that’s a completely different set of tools that could solve this problem - more robust nested block pruning tools. I don’t know.


that’s simply amazing!
if would keep step instances as block would make many of my client really happy.

+1000 for me!

@skysurfer - Do you need to round trip back to STEP? Or is a one-way import to nested layers adequate for you?

normally for me is just importing step into rhino but would be a great improvement to be able to export an STEP file with assembly/layer structures.

Nice stuggestion Brian. A lot is quite specific for your use case, and I hope I’ll find the time to wrap my head around it so we can conceive a more general and open user case with good flexibility. That has been Rhino’s strength for years.

Just quickly, I agree that a mirrored geometry is from the CAD world only. The parts should be designed with respective symmetry so that they can be rotated over, and thus actually speed up production.

I like this because it replicates how importing SolidWorks files into Rhino works now, which we find works very well. Each assembly comes in as a layer, with nested layers for each part.

It seems impossible to maintain the rigorousness of an MCAD tree style part/assembly structure while round-tripping though. How do you deal with assemblies that share identical parts? Changing the definition of a part (or block) changes all instances. In the layer setup that would not be the case and on export you could have one part with several definitions.

So I wouldn’t worry about that aspect of it.

There is still the problem though of editing nested blocks in general which would benefit from a tree-type interface. If that was solved the STEP-layer thing wouldn’t be an issue.


1 Like

Yes, as Eric (@ejolley) said, if there was a tree-view like panel just for the nested blocks and if there was a bit more methods in the api to manipulate the objects inside the blocks I would have never had the need to create a script to translate the blocks into layers.

Hi @brian, do you know when we will be able to see this in a WIP build? thx.

1 Like

@brian wish/proposal:
why not having a block editor that is integrated with the layer structure?
block and layer could be used in the same ways and mostly they both need the same options and capabilities.
makes sense?

They have to be separate.
Assemblies from solid-modellers also have layers that should be kept.




I just posted this question:

…so I hope that any future implementation of blocks to layers will take this into account and never produce a layer with only one object in it (it could be an option, I guess, for those who want a nightmare of a file to manage, hehe).

Btw, is there any chance of a solution regarding instanced objects with layers? Can’t remember if this was discussed or not.

(PS. I now found a script by @Pascal that enables me to move BlockDefinitions which was the root cause of all of this, so yeah… if the editing/managing of Blocks in Rhino would have been modernized, as suggested here in 2015, this whole ordeal could have been avoided.)