File path for SketchUp tools

Can anyone direct me to the Ruby code for the default SketchUp tools? I am interested in looking at how the arc tool works and would like to make something similar as an extension, but with my own customizations that suit my needs. I am using SU23.

I don’t believe the native tools are coded with Ruby.

1 Like

Interesting. Do you know the language they are coded in and if I can pass that information through externally, kind of like an extension.

I don’t know the language they are coded in but I expect re-engineering the code would be a violation of the EULA. You should check on that. There are already extensions that can draw various sorts of arcs. They are coded in Ruby. Instead of reinventing the wheel why don’t you look at them. Maybe they already do what you need.

Well, there are issues with that for my use case. I want extreme precision, and some of the arc creation tools don’t always offer it. When I go to code my own, I get some really good precision, but I notice that some of the last values are a bit different.

For example, lets say I want to find the arc length of an arc of radius 30 and a central angle of 45 degrees. Mathematically, that’s very simple (Math::PI/4)*30.

But when I take that value, and assign it to the appropriate start and end angles, it produces a nearly perfect value.

____Actual: 23.561944901923449288469825…
_Extension: 23.561944901923447
SU Arc tool: 23.56194490192345

Edit: (added those underscores to get it to align for better visibility.)

What is interesting is when I throw in a massive 200 digit calculation and just skip all the math in the editor it gives me the same result as the arc tool does. I know this sounds stupid because I am nitpicking over a ridiculously small decimal value but I just want to make the best tool possible.

What kind of work requires that level of precision in sketchup? If it’s for something related with quantum physics I’m sure you’re not using the right software.

1 Like

Or the right kind of computer. All digital devices have a limit to the precision of numbers they can handle. For current commercial computers it is 64 bits. I understand the practical limit is lower in most software (for instance, I seem to remember that AutoCad numbers are 32-bit).

Check this thread:

It might explain why the result of your extension is less accurate than the native tool’s result compared to the actual calculated, despite it’s higher number of digits beyond the decimator.

1 Like

You are running into the limits of the IEEE double precision floating point format. To increase the precision of the math you can install the float-formats ruby gem.

In the Ruby console, type these commands to install the float-format Gem and test the operations.

Gem.install 'float-formats'
require 'float-formats'

PI = Flt::IEEE_decimal128('3.14159265358979323846264338327950288419716939937510582097494459230')
divisor = Flt::IEEE_decimal128('4.0')
multiplier = Flt::IEEE_decimal128('30.0')
result = (PI / divisor) * multiplier
puts result.to_text #> 23.56194490192344928846982537459627

1 Like

So I need a bit of an experiment. I used the following code and measured the line lengths of some non-terminating decimal values. I used 1 1/3, 10 1/3, 100 1/3, 1000 1/3, 10000 1/3, 100000 1/3. The edges were made with the line tool and typed these values in the measurement field.

selected_edge = selection.find { |entity| entity.is_a?(Sketchup::Edge) } edge_length = selected_edge.length.to_f


Can anyone explain this pattern? I understand why the decimal places descend, but why does SketchUp round 3 to 4 for some of them? And would using decimal128 to generate these edges with code alleviate this issue?

This code will print the values that you specified as they appear in the in the ruby console along with the IEEE Double Precision representation that is actually used in computations. If you would like some insight into the binary representations of these floats try this link

def self.print_value(value)
  puts "The value rounded to 15 significant digits is #{ value }"
  puts "The best Double Precision representation of this number is #{ sprintf("%.50f", value) }"

one_third = 1.0/3.0

numbers = [ 1.0 + one_third,
            10.0 + one_third,
            100.0 + one_third,
            1000.0 + one_third,
            10000.0 + one_third,
            100000.0 + one_third,
            1000000.0 + one_third
numbers.each { | value | print_value(value) }

Note: Edited to add a link to a better IEEE-754 floating Point Converter


Honestly it’s senseless to use more than 5 decimals in a program like sketchup.

… especially because SketchUp has an internal tolerance of 0.001 inch.

Any points closer than this become coincident.

If the poster is worried about nanoinches … they can model at a high scale factor.