File path for SketchUp tools

[YaoLee9]

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.

[DaveR]

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

[YaoLee9]

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

[DaveR]

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.

[YaoLee9]

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.

[francisquitof]

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.

[Anssi]

@francisquitof

I’m sure you’re not using the right software.

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).

[MikeWayzovski]

Check this thread:

Small Radius: Distorted Geometry

I think you guys have hit on all the right points already in this discussion— SketchUp is like all CAD systems in that it handles floating point numbers with fixed precision. Practically speaking, SketchUp carries 16 significant digits— 12 in front of the decimal place, 4 after. Internally, SketchUp uses ‘inches’ as its dimensional unit. Without taking on position on the metric vs. imperial system, technically this is really only a semantic difference. But the net result is that SketchUp can re…

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.

[sWilliams]

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

[YaoLee9]

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

Results:
_____1.3333333333333333
____10.333333333333334
___100.33333333333333
__1000.3333333333334
_10000.333333333334
100000.33333333333

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?

[sWilliams]

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) }"
  puts
end

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) }
nil

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

[francisquitof]

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

[DanRathbun]

… 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.