I have just published a new Tool in the Plugin Store named rake_and_splay (after the chairmaker's convention for naming the front and side view angles of a compound tilted leg). This Tool is intended to facilitate working with compound angled geometry including typical Windsor chair legs and compound mitered joints. It both calculates the important derived angles for you and draws helper geometry in your model. You can use the geometry for drawing and aligning the parts, and also as a learning tool for visualizing the leg or joint.

Steve

Very nice Dave! I have tried various methods for smoothing the "corners" of cabriole legs, with mixed success and often a lot of work needed to get the area around the top of the foot right. I'd be very interested in any info you can provide on how you went about this.

Steve

The heart of your problem is that intersect_with is an instance method of the Entities collection class. So, you need to create a temporary Entities collection and copy one of the Faces into it. For instance (assuming that the Faces are drawn in model coordinates - otherwise you will need to use something other than the identity Transformation):

temp_ents = Sketchup.active_model.entities.add_group.entities # can reuse this if purge between pairs of Faces
temp_ents.add_face(face1.edges)
ident = Geom;;Transformation.new
intersect_arr = temp_ents.intersect_with(false, ident, temp_ents, ident, false, face2)

Because it is all Ruby, I don't know whether this will actually be any faster than letting the built-in function handle the whole thing though.

Steve

Regarding your first question, no, you are not doing something wrong. It is just a matter of definitions. The plugin is maintaining a constant red axis width, but you probably want it to maintain a constant cross-section perpendicular to the sides of the part.

I vaguely remember having seen a plugin for bent pipes, but can't remember where. You'll have to research that...

@jiminy-billy-bob said:

rbs files aren't safe anyway. There are rbs unscramblers.
I tested one to see how safe rbs would be, and it works reeaaally well. It outputs a perfectly clean rb file.

So yeah, I would not protect sensitive stuff with that.

This falls into the realm of the old cliche "locks only keep honest people honest". The decryption key and code for rbs are necessarily embedded in the SketchUp application, and the same key is used for all rbs files. Any competent hacker can easily defeat the rbs scrambling. As JBB points out, several have already published code to do so.

So the question isn't whether rbs is secure (it clearly is not), it is whether you believe there are enough dishonest people in the world that you will lose significant intellectual property value when they unscramble your rbs. The same question applies to the potential backdoor via the debugger.

Steve

@dacastror said:

Jim thank you very much for the answer, it is what I needed

I have another question related to text, how I can increase the font size when use draw_text?

In brief: you can't. This has been discussed elsewhere with regard to MacBook Pro Retina, where the font draw_text uses is so small it is very hard to read.

@driven said:

@ Steve
do you think the two are unrelated?
john

It's possible they have the same cause, but I am not sure how to prove that.

The man page for the locale command says:

 LANG         Used as a substitute for any unset LC_* variable.  If LANG is unset, it will
              act as if set to "C".  If any of LANG or LC_* are set to invalid values, locale
              acts as if they are all unset.

So the behavior you get is consistent with LANG not being set by SU when it launches a subshell. Also, if you set ENV[LANG] to a specific locale such as "en_US.UTF-8" in the Ruby Console before doing the %x, the other variables all follow.

So far as I can tell, SU doesn't launch a separate process for a WebDialog (at least I don't see one reported in Activity Monitor). I don't know what environment a WebDialog gets...can it be read from javascript?

Steve

@avariant said:

I haven't had a chance to look at the debugger yet but the first thing I thought when I read about was, is this a backdoor that can be used to defeat the .rbs encrypted rubies? Does the debugger reveal anything about the current line of execution, or does it just deliver line numbers? When displaying data about a variable, does it volunteer variable names or does it just respond with a value?

I would be very disappointed to find out it did.

You raise some very interesting questions.

If, as I suspect, the rbs unscrambler is an SU facility that decodes the rbs before handing it to a standard Ruby interpreter, then the plaintext source and all other aspects of your plugin would indeed be visible to the debugger. Exploiting this hole isn't as easy as it might sound, since you have to somehow stop Ruby at a breakpoint before the ide commands will work - a bit like shooting in the dark - but I can see that some clever person may find a way.

I think this may come down to how SU implements the debugger ide library. That is, the ide could detect that the source file is rbs and refuse to debug it. This is possible because the SU debugger library implements the ide protocol itself, it does not use the standard debug interface or Gem.

Steve

@driven said:

@tt_su said:

So this only happen on OSX, not on Windows?

as far as I'm aware it's a mac thing...

I think it's because the internal bash env locale defaults to "C" if not implicedly set

> %x(locale)
> LANG=
> LC_COLLATE="C"
> LC_CTYPE="C"
> LC_MESSAGES="C"
> LC_MONETARY="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_ALL=

whereas same call in 'Terminal.app'

LANG="en_US"
> LC_COLLATE="en_US.UTF-8"
> LC_CTYPE="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_ALL="en_US.UTF-8"

because it is set...
john

I think this is because SU does not set ENV["LANG"] when launching the subshell.

Steve

@fredo6 said:

Note that Charly2008 has advised on a solution to the problem of Retina with a 3rd party utility software. See this post.

Fredo

Charly2008's suggestion modifies the logical dpi used by the display system, which causes OpenGL to scale logical pixels onto the physical pixels. Whereas this makes displayed items larger, it can also cause the screen to become slightly blurry because unless the logical scale is an integer, the system has to interpolate pixels. Aside from the blur, the effect is the same as if you had a lower pixel count screen in the first place.

For many resolutions you do not need third-party software. The "scaled" option on the Display Preferences lets you choose among a variety that Apple has set up. The third-party software just offers a greater range of choices.

Aerilius makes valid points. The issue is not with pixel counts as such, but with high dpi. That is, small physical pixels due to high pixel counts on a small screen. That's why people using 26 inch monitors with comparable pixel counts have not been beefing about this - their physical pixels are large enough to see (ironically, just about double the size from a MBP retina). But the pixel counts are going higher and higher, even on large monitors, and sooner or later Trimble will need to find a way to cope with this. In the meantime, we will have to live with it...

@pbacot said:

I never noticed that about editing scene names-I guess I don't use the retina screen as much as I thought for SU. I use it often enough for drawing and it IS hard/impossible to see selection and various inferences. Looks great but not for serious work. It also cannot display some plugin menu bars correctly. I hope this is a universal issue with some other SW affected and Apple will have to figure it out. We have incredible resolution now--it's a shame that that does not always mean we can see graphics more clearly.

No, it's a Trimble/SketchUp issue, not Apple. It stems from the way SU sets up OpenGL to utilize the Retina display at full resolution. There are places they did not take into account the tiny size of a single pixel (or where the way they tried did not work as expected). Alas, the combination of Mac and Retina is such a tiny fragment of the market that it does not seem likely that fixing this will get priority...

Bugs have been submitted to Trimble about the issues you list with Retina, but as of the current release of 2014 none of them have been fixed. The workaround for the scene name edit is to use the Scenes manager, where the text is large enough to see. There is nothing you can do about the others.

Steve

@dan rathbun said:

Steve, my original idea is morphing into something overly complicated.

I never wanted to imply a "world edition" of any Group or ComponentInstance instance object.

I really meant that the origin (which is actually a property of a transformation object,) be returned in world co-ordinates instead of local co-ordinates. (So the instance object is not changed.)

But this only within some scope mechanism. (A method block is only one such example.)

Copying an instance into the world model entities, is easy enough now.

I did not intend something that modified the model directly. I was aimed at simplifying virtual calculations.

So I guess I miss the point of the code block you suggested...what would it be iterating over?

Whimper! Bugra (or whoever) please, please! We Mac users are dying of envy....

Steve

@dan rathbun said:

@tt_su said:

Like an optional argument in Vertex.position perhaps - that takes a transformation argument?
Brainstormin'

Umm. I was thinking more of a .world_position() instance method for Group and ComponentInstance classes.
But this may not be the most helpful.

Maybe think more of working in "Local" and "World" modes.
And we gave a block form world and (maybe) local methods.
(Sort of the old "with this do that" construct.)

component_instance.world {|inst|
>   # any vertice, point3d, vector3d, etc.,
>   #  accessed within block is in world co-ordinates
> }

?

Seems to me that to avoid complete chaos for Components, it would need to be necessary either to make any "world" version of the Component read-only or else to intercept all of the setter methods on Entities and apply the reverse transformation back to the ComponentDefinition's "local" coordinates. Otherwise, any modifications made to the "world" version within the code block would create a mess in the ComponentDefinition! This seems like a terrible amount of complexity and risk of bugs!

Here's a different idea: what if there was a "export_to_world" method on ComponentInstance that would create a new Group containing copies of the ComponentDefinition's Entities transformed into "world" coordinates per that ComponentInstance's Transformation(s)? Because the copy's Entities would no longer be shared with the ComponentDefinition, there would be no risk of messing it up. Alterations made to the Group would not affect the ComponentDefinition or any of its ComponentInstances.

Steve

@driven said:

I think it's actually failing on the binary image chunks stored in some of the keys...

The property you sought looks like this in XCode on my Mac:

It's a string key and value, So I don't think the issue is with binary chunks, it is as TT says simply that read_defaults wasn't designed to read values that weren't written by write_defaults.

Steve

@driven said:

@slbaumgartner said:

The thing is that the SU API's read/write_default methods are wired specifically to this file. They can not read or write defaults from plists belonging to other apps or from the system in general.
Steve

Steve this is in the com.sketchup.SketchUp.20#{Sketchup.version.to_i} plist; that's why I can't understand not being able to read it...

I looked and found that you are right about this key being there, so I did some poking around and came to the conclusion that the API methods are designed only to deal with two-level entries: (section, variable). If you try to omit one, you get a wrong number of arguments error, and if either is an empty string, you get nothing.

In the plist file this means there is a dict entry in the Root with the section name, and this dict has a key entry with the variable name. But "NSWindow Frame SketchUpDoc" is a single-level key directly in the Root, with no other enclosing dict. I tried using "Root" as the section, but that didn't work either. It seems that the API methods have no way to write or read a Root-level non-dict entry (whether by design or oversight I don't know...).

@driven said:

@slbaumgartner said:

Instead, it reads back values stored using Sketchup.write_default. They are actually kept in a plist file specific to SU, and you can only read values from there, not the system defaults.

so it's a hidden, additional plist?

when you use SU.write_defaults you can retrieve them using both SU read or System read?

and if you change the document size the user/lib/plist is instantly updated...

I can't follow what's occurring...
john

I don't think it is hidden, it is in ~/Library/Preferences/

SU 2014 keeps a couple of plists there. I believe that the one accessed by read/write_defaults is
com.sketchup.SketchUp.2014.plist.

It was intended for plugins to remember their settings until another session.

The thing is that the SU API's read/write_default methods are wired specifically to this file. They can not read or write defaults from plists belonging to other apps or from the system in general.

Steve

@driven said:

how do you return a string from SU using the API method...

I can't retrieve this without using a system call

      mac_window = %x(defaults  read  com.sketchup.SketchUp.20#{Sketchup.version.to_i}  "NSWindow Frame SketchUpDoc").chomp!.split(' ').each{|n| n.to_i}     
> 

returns **["38", "613", "512", "565", "0", "0", "1920", "1178"]**

but every concievable version of

Sketchup.read_default("NSWindow Frame SketchUpDoc", "")

returns nothing...

if I escape the spaces I can return nil, but no values...

I've tried single quote, double quotes, %20 escapes...

I can get back other, keys values, but none like this one, how can it be done?

john

@john, I don't believe that the SU API's Sketchup.read_default is equivalent to the Mac OS command. Instead, it reads back values stored using Sketchup.write_default. They are actually kept in a plist file specific to SU, and you can only read values from there, not the system defaults.

Steve