Here's an example from one of my extensions:

if(not file_loaded?(__FILE__))
  cmd = UI;;Command.new("RakeAndSplay") {Sketchup.active_model.select_tool(SLBPlugins;;RakeAndSplayTool.get_tool)}
  cmd.menu_text = "Rake and Splay"
  if(Sketchup.version.to_i >= 16)
    if(RUBY_PLATFORM =~ /darwin/)
      cmd.small_icon = Sketchup.find_support_file("rake_and_splay.pdf", "Plugins/SB_rake_and_splay")
      cmd.large_icon = Sketchup.find_support_file("rake_and_splay.pdf", "Plugins/SB_rake_and_splay")
    else
      cmd.small_icon = Sketchup.find_support_file("rake_and_splay.svg", "Plugins/SB_rake_and_splay")
      cmd.large_icon = Sketchup.find_support_file("rake_and_splay.svg", "Plugins/SB_rake_and_splay")
    end
  else
    cmd.small_icon = Sketchup.find_support_file("rake_and_splay_16.png", "Plugins/SB_rake_and_splay")
    cmd.large_icon = Sketchup.find_support_file("rake_and_splay_24.png", "Plugins/SB_rake_and_splay")
  end
  tb = UI;;Toolbar.new("Rake and Splay").add_item(cmd)
  tb.restore if tb.get_last_state == 1
  UI.menu("Tools").add_item cmd
end
file_loaded(__FILE__)

@pixero said:

Does anyone know if there is something special that needs to be done in the scripts code to use SVG icons or can we just put SVG icons in the plugins directory?

The icon files are given explicitly by the plugin code, which has to choose between the old png for SketchUp versions prior to 2016, and between svg and pdf for Windows vs Mac. It doesn't take a lot of code, but has to be changed, and no, simply dropping a svg file into the folder won't do the trick.

Another bug! Handling regular expressions can sometimes be subtle. Here it caused the operation to process any original groups with the same leading digits multiple times because it would match both wall1 and wall13 (etc.) when looking for things to group together. Processing more than once messed up the transformations that place objects in the model.

model = Sketchup.active_model
ents = model.active_entities
groups = ents.grep(Sketchup;;Group).find_all{|e| e.name=~/^wall/ }
walls=[]
groups.each{|e| walls << e.name.split('-fram-')[0] }
walls.uniq!
walls.sort!
model.start_operation('wall_grouper', true)
walls.each{|w|
  puts w
  es = groups.find_all{|e| e.name =~ /^#{w}-/ } # both errors were here
  gp = ents.add_group(es) if es[0]
  gp.name = w
}
res = model.commit_operation
puts "operation committed = #{res}"

A minor error: in line 12 it should have been groups, not ents:

model = Sketchup.active_model
ents = model.active_entities
groups = ents.grep(Sketchup;;Group).find_all{|e| e.name=~/^wall/ }
walls=[]
groups.each{|e| walls << e.name.split('-fram-')[0] }
walls.uniq!
walls.sort!
model.start_operation('wall_grouper', true)
 walls.each{|w|
  puts w
  es = groups.find_all{|e| e.name =~ /^#{w}/ } # error was here
  gp = ents.add_group(es) if es[0]
  gp.name = w
 }
model.commit_operation
puts

It gets slower because the burden of maintaining the database of geometry and coordinating it between the CPU and GPU gets heavier when the model is very large - even if the entire model will fit in RAM memory.

I think you are a victim of numerical precision effects during the intersection calculations.

That particular rafter template is aligned almost, but not quite exactly, down a (softened and smoothed) sequence of edges in the roof surface (see attached image where I've labelled some vertices). So, in this case you are looking to find intersections between the rafter face and the edges in the roof that are almost in the plane of the face. The other rafter templates go askew to the edges in the roof surface, so they intersect faces with faces. In my experience, the intersect operation is very sensitive to tiny differences when finding intersections between a face and other edges because they require testing finite-precision calculations. The fact that the relevant geometry is in different group contexts, requiring a sequence of transformations to unify them for testing, compounds the sensitivity and makes it vary from edge to edge, which is why some worked and some didn't. The fact that you got intersections when you moved the rafter slightly to the side supports my analysis. Another way to fix it would be to open the roof context, edit-copy the edges running down the plane of the rafter, back out of there and open the rafter context, and paste in place. Then run the intersect operation. Then it works, probably because of eliminating transformations between contexts.

What you are seeing is a limitation known as "bleed through" of the OpenGL viewing system used by SketchUp. To decide what to show (i.e. what is "in front") it uses a finite amount of data to represent the depth of each object into the view. At some distance, this representation loses the ability to decide which object is closer, and the one that is behind can be seen bleeding through the one in front. There are various workarounds. Sometimes you can make the nearer object thicker, which increases the distance before they can't be separated in the view. Or, you may hide the edges of the farther object so that they aren't displayed.

SketchUp Pro 2017 and SketchUp Make 2017 are both available from the official Trimble download page, just be careful to click the correct one:

Download All | SketchUp | SketchUp

Download All | SketchUp

(www.sketchup.com)

The pixel size of an image is just a parameter of the camera or image program that created the image; it has nothing to do with reality. I usually note the actual size of the item in the image, draw a rectangle that matches one dimension of the item, and then use File->Import with "Use as Texture" selected. Click one corner of the rectangle and then the diagonally opposite corner and the texture will be created sized to the real dimensions.

There are a couple of flaws in your code. First, you push Entities into the Array referenced by the variable grp and then immediately reassign grp to refer to your new Group. Second, you never added any content to the Group. The garbage collector in SketchUp Ruby is very aggressive about reaping empty Groups!

Did you try zoom-extents? Very often dwg contents are placed very far from the model origin and as @pcmoor observed unless you set options to not preserve origin they will be way off screen after the import. Also, there are some kinds of contents that the importer does not capture. Text and items that depend on CAD extensions are two examples.

Failure to save shortcuts sounds like a typical problem with registry permissions due to incorrect installation of SketchUp. If you still have the installer available or can find a copy (your profile says you are using SketchUp 2014 so that might be tricky), right-click the installer, choose "Run as Administrator", and then "repair". Note that the "Run as Administrator" option is not equivalent to being logged on as administrator.

@jgb said:

SU users seem to have better luck at seeing a new feature they suggested than seeing a fix to something they suggested.

Yeah, both feature requests and bug reports vanish into the Trimble jungle, many of them never to be seen again. We all know that the development team is resource limited, but they have never revealed how they choose priority among the many items.

SketchUp's inference engine constantly guesses what you are trying to accomplish and prefers a particular snap based on its best guess. Sometimes that guess is not the snap you wanted, especially when there are alternatives very close together. As you note, the result can be quite frustrating.

You have to help the inference engine by doing something that steers its guess to what you really wanted. Obviously one approach is to zoom in close enough that the difference between the possibilities is very clear, but clipping can make this non viable and increased sensitivity of the cursor when zoomed in tight can make it difficult to control. Another approach is to hover the cursor over something that gives the inference engine a clue about what you really want, for example hovering over an edge until the "on edge" tip shows. But the inference engine sometimes determinedly goes for a different snap even after you try to help it. This behavior is why ability to turn off snaps is a very frequent feature request.

I too do not have a monitor to investigate this behavior and you didn't give a list of extensions/plugins that misbehave so I can't look at them to see what they do. As of SU 2016 the Ruby API supports vector icons (svg on Windows, pdf on Mac) for toolbars. Your profile says SU 2018, so scaling ought to work. Any extension that has been revised to use vector icons should see them scaled. The older-style png icons will not be scaled.

But I have read that there are remaining issues with very-high-dpi displays when the scaling is set to more than 150%. You write that you have set 300%. You may be encountering that issue - though I can't explain why it would affect some extensions and not others.

https://support.microsoft.com/en-us/help/14200/windows-compress-uncompress-zip-files

As I mentioned earlier, .rbz is just a renaming of .zip. You may have to change it back to .zip to get unzip to recognize it.

What file are you attempting to open? If you are trying to open the .rbz file, that is a zip archive file (i.e. compressed) just relabeled so SketchUp recognizes it. You have to unzip it and open a specific .rb file within it. If you see .rbe or .rbs files in the unzipped archive, then they are encrypted ruby.

I interpret "blob" to mean "binary large object", that is, a sizeable chunk of otherwise opaque binary data. You might need to pack your blob into a Ruby type that set/get_attribute handles correctly. Test with specific examples to see whether what you have survives the round trip or needs to be packed.

There seems to be either strange semantics or an outright bug in the label text tool applied to vertices in groups. The displayed coordinates seem to be reversed from what I would expect! In the attached screenshot, I created a 5x4x3 group at the origin, moved a copy 3 along the red axis, and then a second copy 2 more. Then I labeled vertices in the copy nearer to the origin without opening it for edit. The coordinates displayed are the ones for the vertices in the group's component definition's coordinates despite the fact that the group is not open for edit! I would have expected model coordinates. Then I opened the right-most copy for edit and labeled vertices within the group. These labels display the locations in the model's global coordinates, when I would have expected definition coordinates!

Equally strange, if the objects are components instead of groups, I can't even label vertices without opening for edit. Instead, the label tool displays the instance name (or definition name if the instance name is blank) of the component!

So, no wonder you are getting confused when using this tool on groups and components!

You need to realize that there are multiple coordinate systems in action within SketchUp. Every component definition specifies the location of its points with reference to its own local coordinates. If the points are within a sensible distance of the local coordinate origin, there are no issues internal to the definition. But when an instance of that definition is placed in the model, the locations are transformed from the definition's local coordinates to the model's global coordinates. In your case, this amounts to adding about 1676890 inches (over 300 miles) to the location of every vertex. That large offset consumes almost all of the available precision in the internal representation, causing relatively small differences to be lost to underflow when you deal with the model. The effects start to be serious at about 30 miles from the model origin.