I have a STEP file from a client, and it’s rather complicated. It’s also organized differently than I’m used to.
The hundreds of parts are seemingly joined or part of block instances. I’ve exploded those. But the real issue, is that ALL of the useful part names for their product, are listed in the “blocks” tab. But NOT in the “Layers” tab. So, when I go to export an .OBJ to use in animation, I don’t get the full number of parts exported, as individual pieces. Instead, I get a few mass groupings, and there’s nothing I can do to separate them in the animation program.
Is there any way to have all of the individual parts, or at least all of the blocks, distributed to individual layers?
As an update, I’m still hoping for help here.
One thing I have noticed, is that in the imported STEP file, essentially every single part is only called “polysurface”. There seems to be no names associated with any of the objects I highlight, despite the fact that there were a number of obviously related names, in that “blocks” layer. Honestly, I have no idea what in the world to do with that “blocks” layer, because even selecting any of those, never highlights a single part or surface.
Hi sneather- I do have a RhinoScript that does exactly this, but I’ll need to re-write as a Python script for you to be able to use it on Rhino for Mac. I’ll look at doing that.
Wow. Thank you!
So, on a larger scale, is what I’m describing making sense? Is this a common issue with some STEP file imports - where Rhino reads multiple block instances?
I’m trying to figure out whether some of these issues are arising because of how Rhino reads these STEP files (coupled with my obvious inexperience with Rhino) or whether the fault lies with the procedures arising when the client is making and exporting the file, to begin with/
Yes, it makes sense but not in terms of how data is organized in STEP files with respect to your need to use layers.
If there was a direct and obvious way to translate imported STEP file data into a layer organization, we would do it.
Hi jb, There is a logical way to do this, at least guess pretty well- it’s what the script does; the resistance has been that the function does not really belong in the importer, it should be a post process, standalone command so that it can work in a more general case… The other thing is it has been a rare enough request that it seemed not to require a command in Rhino, the script seemed to be good enough- I kind of think we may need to think about that again. -In any case, as I see now looking at the code, the old script is pretty junky and it will not hurt to make it better in Python and potentially add it as a real command from there.
I totally agree with what @pascal writes.
Granted, it has stopped driving me crazy about 6 or so years ago but that doesn’t mean I don’t still think that the current behavior is wrong.
So…being that I’m kind of on the clock on this. Baring any new or modified scripts, does anyone have a suggestion (or two) on what I might be able to do to organize all the various parts into usable layers?
I am working on it as I get a chance - no ETA yet…
@sneather - here is a really messy cut that may help for now- note that I think there is a bug in the block exploder such that some instances are not correctly returned to the doc as exploded objects , they just disappear- I am checking on this, but… pay attention, just in case.
No checking for invalid characters in the names is done yet.
No purging of unused definitions is done yet. Run Purge once you’re satisfied that all the bits are there.
I’ll update this as I go but this might get you started.
Looks like being way less code than my previous RhinoScript mess…
So, checking further, it looks like it’s Blocks that contain bad geometry that cannot be added back to the document.
@sneather I updated the script to trap the bad objects - they are left as block instances. The rest should work - still need to check for invalid characters.Incidentally- use this with RunPythonScript.
New:ExplodeBlocksToLayers.py (2.5 KB) @wim , when this is working correctly and doing all the checking etc. I’ll make it into a plug-in - my guess is it will be much more efficient than the old one you have.
Hi, and thanks for the continued work!
I didn’t realize your post was actually being updated, so I hadn’t realized you were providing new information.
A couple things:
I’m so inexperienced using Rhino, that I’m afraid I’m not familiar with the steps necessary to run a script, and how specifically to set up the proper Rhino file.
I’m also becoming more curious about what is actually the root cause of my STEP file import issues. I tested a new and different STEP file, from a totally different client, and it ALSO comes into Rhino in the same exact fashion as the model I first started posting about here. I think it originated in Solidworks, but I can’t be 100% certain. All I know, is it imports as all block instances, and even once I explode those, every single part is only titled “polysurface” - and are all in one layer.
Is it possible that there is something very necessary which needs to occur, if someone is to export a STEP (or other) file from a CAD program like Solidworks? Something specific to the way Rhino imports those files?
I ask all this, because I’m likely going to be working with more complex files, from these various clients, and I really need to fine-tune the workflow, so that I’m not scrambling to use scripts are work-arounds, just to properly organize their files.
Just to test, I tried running that latest script. But it failed to do anything. The STEP file imported, as always, on one layer and with block instances. Rhino warned: “unknown or unimplemented command”.
Maybe I’m doing something wrong. Same thing happened again for me.
Just to repeat what I’m doing:
I’m importing the STEP file.
I’m going to edit > select objects > block instances
Then, once selected, I go to commands > read from file - and I select your script
It then immediately opens the import window.
That’s what I have tried, numerous ways. Each time I enter that command, it gives me the warning: “unknown or unimplemented command”. Is it possible Python isn’t available in my version of Rhino?