I work with a team using several different software and I often receive Sketchup files to work on in Rhino8. We have inserting .skp files working fairly well with named components coming into Rhino as blocks. What doesn’t work as expected is when I insert an updated .skp, it doesn’t update the existing instances of those blocks; it creates an iterated new version. so block “component#5614 01” will be 'component#5614 02" and both will be present in the file. I can then replace the 01 with 02 using ReplaceBlock command, but this is cumbersome for files with many many blocks. Questions:
Is there a way to insert an updated .skp file and have it update all instances of the blocks contained within that file rather than creating a new version of each block?
What is the best method for inserting the .skp file, as a block imbedded, as a block imbedded and linked, as a group, as individual objects? I find it makes no difference since the block components of the .skp file are iterated as new blocks regardless, and none can be updated atomically.
failing being able to update the blocks atomically when inserting the updated .skp, is there a more effecient way of updating the 01 version of each block to the 02 version of each block all at once? ie selecting all the 01 blocks at once and swapping them to all of the 02 blocks.
As you can see here each time a skp is inserted that contains components(blocks) it creates a new version with an iterated number. What would be preferable is if Rhino asked if you would like to replace the block or keep both, the same way it does when you insert a Rhino file with blocks in it.
So if you inserted this into a Rhino file, then made an edit to the .skp in Sketchup, saved and reinserted it, the expected behavior would be to get a dialogue to keep both blocks, or redefine blocks, but it just creates new iterated blocks, not giving the option to replace blocks with the new definition.
The way I would set this up is to save the each skp file as Rhino file. Then insert those individual rhino models into master model. You can actually insert them as referenced/linked blocks so they automatically update. Then when you get a new skp file open it as do a save as overwriting the existing Rhino model.
I am using Rhino 8. Your SystemInfo would be helpful, so we can test on the same version and OS. Do this by opening Rhino, and type the command SystemInfo .
Copy and paste the “text” results into your reply.
I would avoid Embed and Link/Embed with nested blocks.
There are open issues regarding the handling of nested block collisions. Can you try Link?
You can Link all SKPs to a 3DM, and then link the 3DMs to the main 3DM file.
This way the duplicate named objects will not have a “collision” that results in the unique naming with the 01, 02 … decorations. These are difficult and deeply embedded with in existing code, so hopefully will be tackled in a WIP of Rhino soon.
RH-12052/No-Replace-on-Nested (private)
RH-12094/Nested-Block-Not-Redefining (private)
Download this zip. Unzip and open the 3DM.
The SKP is linked to the 3DM and mirrored and arrayed. OFFICE-FOOT_A_QTY-2.zip (47.6 KB)
Let us know if this works better for you.
If it does not, I may need you to email tech@mcneel.com better for testing this.
So, I have a couple of observations. If you insert an .skp that has multiple components and has groups, all of the group info is destroyed if you insert as a block rather than as individual objects. This isn’t the biggest concern though. I am very hesitant to use linked blocks on anything other than my most fundamental components, because I do component based machining and it just seems like a terrible idea to have a bunch of machining files that have been verified to work, suddenly get out of whack because a block definition is changed in a separate file. So it has been my policy to only use embedded blocks, not linked at all in my machining files. if I need to update a block in the file, I just reinserted it and update the block.