@kaas said:

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

Well, the simplicity of the model is one thing - but if out thumbnail generating code has become slower writing pixels then the model content doesn't matter...
This is still on our todo list to investigate.

@wbarnes05 said:

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.

The API docs needs updating in general to make the hierarchy more clear. There are many inconsistencies. We have a big todo item to improve the whole developer site. Stay tuned.

@wbarnes05 said:

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.
We had to pull some tricky shimming to prevent breaking stuff. I wasn't able to do a 100% compatibility, but I think we have a near 99% use case coverage. Main one is C Extensions doing low level type checks for Floats which used to work, but not any more.

@brighter3d said:

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?

It's a bit vague - what exactly doesn't work of these calls? Do you see Ruby's packing methods returning different results?
Is the DLL you are calling actually 64bit?
Does the function you are calling actually use ints - or are you using some other type that might be different on 64bit OS?

On a side note - the Win32API has been deprecated for a long time. It has many limitations and is easy to cause crashes with. The recommended now is using Fiddle.

@glenn said:

It’s stable & fast, not sure if that has to do with bug fixes (from 2014) or 64bit?

That would be the number of bug fixes we did unrelated to 64bit.

Ah - I see. Yea tapping into the handles of applications like that will usually be fragile and one usually need a good amount of error handling.

No code examples? Or anything we can run to test?

@anton_s said:

thats an error from ams_WindowSettings. It's incompatible with SU2015 32 or 64 bit.

? I wouldn't expect any compatibility issues with SU2015 32bit...

@tig said:

@tt_su said:

Can you send me the original tool that splat? I'll see if I can dig into the guts of this to be sure.
I've PM'd you v2.6 which has the Bugsplat issue in v2015, and current v2.7 which works OK...

So a few weeks ago I investigated a similar issue - a tool that was using select_tool a lot to switch functionality of the tool instead of using stages. Nothing wrong with that per se, but we have a bug in SketchUp where under certain circumstances SU is trying to call the old tool after it was removed from the tool stack. It's filed as an issue internally for us to look at - though a fix for SU2015 didn't make it.

When I investigated this the first time it was happening in SU2014 - so you have been "lucky" it hasn't happened to you until now. Why SU2015 provoked it in your case I'm not 100% sure, could be due to memory corruption what manifest itself differently in 64bit or simply that fact it's a new binary of SketchUp.

I personally use tool juggling in Vertex Tools, but then I use push_tool and pop_tool to nest the tools on the stack instead of replacing which select_tool. That might be one workaround to use.

@jason_maranto said:

However I will be expecting a noticeable performance gain with 3rd party engines rendering within SketchUp's process.

The effect should mainly be that SketchUp doesn't crash as the render engine consumes more memory. Performance improvements would be the result of other changes and optimizations.

@josephkim626 said:

For some reason, "Select Coplanar Faces" results some other parallel faces selected that aren't necessarily "Coplanar"?

The menu name is misleading - it's Same Direction instead of truly coplanar.

Can you send me the original tool that splat? I'll see if I can dig into the guts of this to be sure.

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

I don't recall all the details right now, but I think I ran into an issue some time ago where selecting a new tool in the mouse event might cause a crash. I need to dig into my notes.

@tig said:

@tt_su said:

@tig said:

There's a BugSplat after the seemingly successful creation of geometry, as the tool exits.

Did you submit the splat?
Yes: Under 'TIG' within the last hour or so...

Hmm... something is happening in SketchUp!CRubyTool::UpdateVCB after SketchUp!CRubyTool::OnLButtonDown. The stack trace is a bit junk after that though. I need to dig deeper. But do you have the snippet of what the tool does in OnLButtonDown? Are you by any chance selecting a new tool?

By the way, what version of Raytracer and TT_Lib do you have installed? (Can you verify with full version numbers reported under Preferences > Extensions please?)

Found it! I'll inspect. Thanks.

@tig said:

There's a BugSplat after the seemingly successful creation of geometry, as the tool exits.

Did you submit the splat?

@krisidious said:

Seems to me that less things were broken this time around than with 2014... I'm quite pleased.

In SU2014 we changed the Ruby engine to a brand new one. In SU2015 we only added 64bit. So if you installed SU2015 32bit there should be no broken extensions. And even in 64bit only some with binaries would break.

Hm..
Did you submit the BugSplats?
If you did, did you enter any info in the description or name that I can use to look it up? If you didn't, can you submit one and add some info I can use to look it up in the database?

@numerobis said:

But copying geometry could be improved...

Yea - we really want to improve geometry creation. The FaceFinder improvements in SU2015 was one step into that.