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:
Come to some agreement about a solution that could work
Prototype the solution manually and test (this may be hard/impossible)
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:
You import a STEP file with several instances of an assembly, and Rhino creates several different layers: assembly:1, assembly:2, assembly:3
You leave all objects in assembly:1 alone.
You transform all of the objects in assembly:2 uniformly
You move one part within assembly:3 but leave the rest where they were
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.
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.
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.
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.
@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?
…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.)
Hi @brian, I wanted to check in this, we are most 3 years later and this is still a major plain point for us.
More of a paint than 3 years ago as we do more work in engineering and final part design for tooling. I think it will be fine to have mirrored objects as unique, not blocks for now. The rest of what you describe here, I think it’s exactly what’s we need. I’d love to test something.
Any chance this can make it as part of V8, or at least a plug-in/script we can test and perfect, and then you can decide later if it makes in into a shipping product, if ever. If we have a plugin solution we’ll be just as happy.
, isn’t it easier to simply create a separate panel for the nested blocks?