Changes in 2015

kwalkerman

Hi - I thought I would create a place to log some changes in SU 2015. I just started playing with 2015 and I've noticed one change that will be pretty significant for some tools:

In previous versions of SU, x,y and z coordinates of a Point3d were always returned as a float with the units being inches. Similarly, the length of an edge was always returned as a float with the units being inches. In SU 2015, the x,y and z coordinates of a Point3d are returned as a "Length" with the units being the current model units. The length of an edge is handled the same way.

The area of a face is still a float, with the units being square inches.

This seems like a bad move for backwards compatibility.

AdamB

Yep, got caught by that during testing LightUp x64

Workaround is to always invoke #to_f

Dan Rathbun

I must have special 2013 and 2014 versions, because the x, y and z getter methods always return Length class instances on my installs.

The API docs don't say what the class is, just that a value is returned.

Dan Rathbun

And point.to_a STILL returns [ Float, Float, Float ] on all my installs.

So it follows that:
x = point.to_a.x

1.0
x.class
Float

kwalkerman

yes, all those workarounds work... But wouldn't it have made more sense to leave point.x as a float as it has always been? In 2015 to convert any number to a length, you just have to do num.to_l so if you wanted point.x as a length all you would need to do is: point.x.to_l ... and all of us who wrote code years ago don't have to go back and tease out the old code...

This one hasn't tripped me up as much as I thought it would so far... just needed to add .to_f in a few places.

Dan Rathbun

@kwalkerman said:

But wouldn't it have made more sense to leave point.x as a float as it has always been?

But I disagree! It does NOT return Float on ANY of the previous versions back to v8 that I have installed.

It always returns a Length instance.

Make sure you do not have some plugin like "Sketchy Physics" that changes API classes installed.

kaas

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

t = Time.now f = "c:/box.skp" d = Sketchup.active_model.definitions.load f puts (Time.now - t)

edit: added some test code.

Create a simple box in R2014 and save as a skp file (in the code above, in the root of C).
ReStart Sketchup2014 (to prevent 'recursive errors')
run the above code in a ruby editor - 0.3 seconds
Start Sketchup 2015, run the above code - 0.84 seconds

It's half a second difference but it gets annoying fast if a user has to pick & load multiple components (and don't want to pre-load all of them). It breaks the snappy flow of the plugin.

Question: any way to avoid this. Looked in the changelog / bugfixes for 2015 but can't find anything related.

tt_su

@kwalkerman said:

In previous versions of SU, x,y and z coordinates of a Point3d were always returned as a float with the units being inches.
Similarly, the length of an edge was always returned as a float with the units being inches.

That doesn't sound right. The Point3d class was never changed. And when I test this in SU2014 I'm seeing same results in SU2015 as in previous versions.

SU2015
` Sketchup.version
15.0.9350

ORIGIN.z.class
Length

Sketchup.active_model.entities.add_line([0,0,0],[9,9,9]).length.class
Length`

SU2014
` Sketchup.version
14.1.1282

ORIGIN.z.class
Length

Sketchup.active_model.entities.add_line([0,0,0],[9,9,9]).length.class
Length`

SU2013
` Sketchup.version
13.0.4812

ORIGIN.z.class
Length

Sketchup.active_model.entities.add_line([0,0,0],[9,9,9]).length.class
Length`

If you see different result, can you try with no extensions loaded?

@kwalkerman said:

"Length" with the units being the current model units.

A length store it's value as a float. It's just that the to_s method is different so it will print using the model units.

tt_su

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Is this with any SKP? Can you share that SKP?

tt_su

@dan rathbun said:

But I disagree! It does NOT return Float on ANY of the previous versions back to v8 that I have installed.

Confirmed - our source code has always been returning Length objects for Point3d members and Edge lengths.

Dan Rathbun

@tt_su said:

@dan rathbun said:

But I disagree! It does NOT return Float on ANY of the previous versions back to v8 that I have installed.

Confirmed - our source code has always been returning Length objects for Point3d members and Edge lengths.

Interestingly,... the API does not actually say what the return class is. IT says "value".

Dan Rathbun

@tt_su said:

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Is this with any SKP? Can you share that SKP?

Bigger thumbnail = more loading time? (guessing)

tt_su

@dan rathbun said:

Interestingly,... the API does not actually say what the return class is. IT says "value".

Yea... one of the many improvements to be made.

kaas

@tt_su said:

Is this with any SKP? Can you share that SKP?
Any skp will take longer to load with that code in SU 2015 compared to SU2014.. at least on my system. Would like to see if anyone else could confirm or even better, have a solution.

Brighter3D

SU2015 can be installed in two versions 32 and 64bit.
Is there a way to check which is installed from ruby api?

Sketchup.version
returns: 15.0.9350

driven

from the API

 if Sketchup.respond_to?(;is_64bit?) && Sketchup.is_64bit?
   # Load 64bit binaries.
 else
   # Load 32bit binaries.
 end

Brighter3D

Thanks!

Brighter3D

Packing float value into two integers, and passing to double parameter function,
seems no longer works in 64bit SU2015.

passF = Win32API.new(mydll,"PassDouble",["L","L"],"V")

packedF = [rubyFloat].pack("D").unpack("LL")
passF.call(packedF[0],packedF[1])

Any tips?

wbarnes05

I noticed the change regarding the Length class a few days ago in the API. What's weird is that the API states that the parent of Length is Object starting in SU 2015. That had me worried as it implies that mathematical operations will no longer work on an instance of Length. However everything continued to work ok in my plugin when running in SU 2015.

I ran a few tests in 2015 and found the following:

length = 4.to_l
4"
length.is_a? Integer
false
length.is_a? Float
true
length.is_a? Length
true
length.class.superclass
Numeric
length.class.ancestors
[Length, Numeric, Comparable, Object, Kernel, BasicObject]

It would appear then that the API is incorrect and should be changed to show that Numeric is the parent class.

kaas

@dan rathbun said:

@kaas said:

I just noticed in one of my plugins that loading a single small skp file (to use as a component definition) seems to take almost 1 second whereas the same code in SU 2014 loads the skp instantly.

Bigger thumbnail = more loading time? (guessing)

I can't imagine. The box.skp testfile I created was just a rectangle with an extrusion.

Still looking for a solution. I tested all kinds of files and the result is always the same: loading a skp file as a component definition takes 2 to 3 times as much in SU2015 compared to SU2014 with the code above.
I tested disabling all plugins. I also tested loading SU2015 skp files (I wanted to rule out it took additional conversion time from SU2014 to SU2015).

Any suggestions / workarounds ?