Recently there was a request by @CogentDesign, and as you see above he was happy about my code. But I don’t!
I had some more time and realised creating groups can cause slowdown and/or non responsive SU for a long time, for more then certain amount of cages. So I decided to create as a component instances (groups still an option…).
But if I fix it, I decided that I’ll make it a little more “fancy” … however still not checks all possible wrong inputs and so on, but here we are:
dezmo_support_birdcage.rbz (29.4 KB)
You can install it using Extension Manager. (It’s not signed, so take that into account with your EM settings.)
You will get:
No warranties! (Use it at your own risk!)
Menu Under Extension: “Wireframe BirdCages” (You can assign shortcut.)
Two toolbar. The first one with the ugly icon is the main one.
(The second one - nice beer - you can ignore, use, close…whatever, there is no obligation, no promise, just a possibility! There will be no negative or positive consequences at all. )
You can enter the lengths as a current unit (integer, float number) or use regular SketchUp format, 1549mm or 5’1" for example. It will be displayed always according the settings in Model info/Units.
The last entered values will be remembered during the current session. (If you restart SU, the defaults loaded.)
You can undo the operation with one click (or Ctrl+z).
The created cage component definition name will be “Cage-” + x-y-z sizes (if you chose to create groups - witch is not recommended - the name also numbered at the end)
The instance names will contains its “location” in a matrix and number by the order of creation.
The Braces components definition name will be “X” or “Y” + “Braces” + the number of diagonals + the length of one diagonal.
The length unit format in the names also based on the the settings in Model info/Units.
You will get a summary info at the end. (Also printed out to Ruby Console)
Tags applied as requested in the above mentioned topic. (Best use with color by tag, and edge color by material in the Style settings)
Should work on older version of SU up to current and upcoming, also on Mac, however I did not tested.
Looking forward to trying this update on Monday Dezmo.
For explanation purposes I found it easier to describe a small cube as a group, then copied in all directions. But what I am actually doing once the overall structure is built is Exploding it back into edges. I knew that exploding would delete any duplicate edges.
This then allows me to easily quantify the edges when isolating them on the Layers. So the grouped cubes were purely just to get the idea across for the coding.
Moving forward, I would then like to apply my 3D componentry to the edges after the wireframe cube is complete, for presentation purposes. I think doing this manually will be fine, but obviously an automated process would be amazing!
Actually the report at the end of the creation, counting the edges once if they are in a same location …
…check it out when you can, have a great weekend!
It’s an interesting irony that when creating a great number of identical objects, groups are slower than component instances (probably because each copy is unique?), but when creating a great number of distinct objects components are slower (probably due to creating thumbnail images and assuring unique names?).
Oh yeah. I haven’t thought all about that yet. Your assumption…should be right, I guess.
The code could certainly be further refined, e.g. using the EntitiesBuilder, since the instances will be exploded anyway… but in this use case perhaps just good enough for now.
That is true if the user copied it.
However the the Group #copy method - what is used here or the original snippet - make it unique without calling #make_unique.
Try in an empty model:
m = Sketchup.active_model
g = m.entities.add_group
cp = g.entities.add_cpoint(ORIGIN)
puts m.definitions.to_a
g.copy
m.definitions.to_a
It seems ambiguous in the Ruby API documentation. It just says Group#copy returns a new Group object. Although the GUI makes a new instance of the same ComponentDefinition, @dezmo’s snippet seems to show this is not what the Group#copy method does. On the other hand, I clearly remember some extension author (don’t remember who) observing that he uses only groups because creating a huge number of components was very slow and got progressively slower as more components were made.
The question arises whether creating lots of new component definition and place its instance once, or creating one component definition and place several instances of one definition was the case?
Perhaps using group.copy to create new group (definition) as slow as creating new component definition and place one instance. Perhaps generating the thumbs for component definition makes it more slow than the group.copy ?!
I might check it out later…
It just occurred to me… Maybe this can be used: