Add_arc etc.

kyyu

Here is a quick diagram.

Dan Rathbun

I've read a lot but still. That coin won't drop.

Have you seen my recent post "Ruby Newbie's Guide to Getting Started" ??

I suggest you follow the steps I outlined.. go thru those tutorials for standard Ruby.

So for the purpose of learning and remembering I would [b]like to create (lots of) cheatsheets that contain all the information per method.

First of all Alex Schreyer has created a Sketchup Cheatsheet.

But spending the time to bascially retype the entire Sketchup API is not going to help you understand Ruby. The SU API is simply a set of extra modules and classes, that extend Ruby so it can be used for Sketchup script automation.
You must understand standard Ruby in order to use the Sketchup API effectively.

It seems to me that you are focusing on the little details (such as arguments for specific methods,) instead of reaching a higher level understanding of object-oriented event-driven programming with Ruby. (You should not worry about argument lists for methods anyway, as many methods have variable argument lists.)

If you have read books and tutorials on Ruby, and don't understand yet, then I suggest backing up and find some generic books or tutorials on object-oriented programmimg (OOP.) Do the same for generic event-driven programming. Web searches etc. You need to grasp these concepts, as OOP is much different then the old sequential programs (BASIC & Fortran,) and although it may look similar to procedural programmimg (Pascal, Ada, etc.) it's much different.

After you expose your mind to those concepts... go back and reread the Ruby tutorials and books, and then hopefully, you may have your own personal "Ruby Epihany."

After that "it's all downhill" !

Dan Rathbun

@wo3dan said:

I would like the sheet to also have an image with all that information visualized.

Now THAT is a very good idea as an extension to the API docs... as Kwok Yu's example above shows.

TIG

@kyyu said:

Here is a quick diagram.
Arc Arguments Explanation Diagram

Thanks - a very clear and simple explanation...

Wo3Dan

Thanks to you all for responding.

Hi Tig,

So no space is allowed in variable names. Underscore “replaces” the space and makes multiple_word_variables possible, and more or less weld the words, leaving a visual gap, thereby allowing to make it easier to read. (correct me if I’m wrong, please).

I’ve read about variables and their scope. And I’ve carefully (re)read your answer, trying to remember all that. But I’m not there yet. (step by step, as you hopefully will understand).

I do want to tackle the simple things first by …. oneliners, to see what they do. To make the cheatsheets with that little figure accompanying the text, to explain all the arguments and their options on how to “feed” them.

Well, you hit the nail when you say: make a oneliner and alter arguments to see what happens. I do use Alexander's ruby code editor inside sketchup to already do that.
But "feeding" the arguments, that IS my problem for now.
I can see that changing the radius from say 300 to 300.mm will change it from 300 inches to 300mm, exactly the way I want. But I would expext the interpreter to return an error when I feed 300.degrees for the radius. It still works? I don’t recognize the mathematical relation in that from the result on screen).

The first array, [x,y,z] for center is understandable too. Three coordinates.
(although again, degrees are accepted. The mathematical result again is escaping me. And I know, degrees don’t make sense here.)

What puzzles me the most are array 2 and 3. I can even alter them to get a straight arc (collinear segments). I would have expected them to accept coordinates, just like the center, a point in space.
Try
arc = Sketchup.active_model.entities.add_arc
[100,0,0], [0,1,0], [0,1,0], 1000, 3.degrees, 110.degrees
arc.length

So what I’m actually looking for is: what can I feed those arguments with, what makes them work to get predictable results for each arc one can think of. And that info should be (for me at least) implemented in a general figure. for the add_arc method.

Hi Kwok Yu,
That is exactly what I’m talking about. But your figure still has to many loose ends. It still isn’t clear on how to “feed” the add_arc method. All the possibilities and the limitations on what NOT to use.
You have xaxis along X and normal straight up. But I want them some arbitrary directions and what was fed to the method. I hope this make sense. Once I have that figure complete, no more text to read other than a few notes with the figure, like you did.
Also thanks for mentioning the “right hand”-rule!

Hi Dan,

I did have your “Ruby Newbie’s Guide to Getting Started” printed before.
(Not hanging over my bed though).
I’ve also seen and printed Alexander’s cheatsheets. (I do use his ruby code editor as a plugin).
And I already had the Class index printed and also the complete list of Google SketchUp Ruby API, methods etc. There may be new information at the link you gave so I will check again.
I’m happy to see that the idea to visualize all of the text info with all its possibilities in just a little figure isn’t such a bad idea. Once I have the add_arc I gues it will be easy to transform that to a next sheet
for add_circle, add_ curve and add_ngon etc.
I know, once you have used/programmed ruby for a while like you guys, there’s (maybe) no need for the sheets anymore. But then there will be others who want to learn.

Also a special thanks to Chris Fullmer for his excelent video tutorial about creating determined selections edge lengths. I just found it back again due to Larsen and his “ruby code snippets” thread.

TIG

In Ruby all "pointers" like class, method, constants, variables etc can't contain spaces because Ruby takes that as a break, signaling the next 'command' is due etc. As I explained there are other rules about starting variables [and methods] with a lowercase letter and constants [and classes] with uppercase letter.
Otherwise a 'name' can contain letters, numbers and underscores only [a-zA-Z0-9_] - with no other punctuation or accented characters allowed.
A name like mynewvariable is acceptable, but hard to read unless you are German! and you are used to compound words like obersturmbannführer

can make reading the name easier because it naturally splits it up like in normal English writing - this is called 'snake' format because it's a bit like a snake slithering along the ground - e.g.

my_new_variable etc
The other common format is called 'camel' because it has 'humps' - this has no 'spaces' but capitalizes each word in the name thus - myNewVariable.
You can use either format - it depends on your preference - just be consistent and sensible.
Incidentally ' mynewvariable' is a useless name as it does not give you a clue as to what it does! Whereas ' radius' and ' new_radius' do......

Wo3Dan

Hi TIG,

Thanks for explaning the underscore and the ‘camel’ and sure, I will try to be consistent and sensible in choosing variable names. Herr_Obersturmbahnführer isn’t going to be one of them. Different country.
That still leaves me with the questions about what can be “fed” to each argument. What sort of input leads to predictable / desirable results. The first [array] and even more the second and third [arrays] puzzles me.

An other odd example for the last two arguments:
The Google Ruby API says start_angle 15 radians and end_angle 35 radians. Does this make sense?
It results in a 360 degrees arc with 24*(35-15)/(2*PI) > 76 = 77 segments. I can’t imagine using such figures, spinning around the center to create the desired number of segments.
0.degrees and 360.degrees and the optional 77 would do almost the same (creates a circle instead of 360 degrees arc) and is quite understandable.

Once I have the input(format) sorted out I can make the cheatsheet figure and leave the text for this method behind me. Hopefully other ruby_newbies can take advantage of the sheets, if I do things right.

TIG

The 'arrays' you mention... One is a 'Point' for the center [x, y, z] where x/y/z can be 'float' - e.g. [1.2, 3.4, 5.6] when they will be used as SUp's 'base-units' [inches] and the center will be 1.2" to the right of the origin [along x/red-axis], 3.4" along the y/green-axis from the origin, and 5.6" above the origin along the z/blue-axis.
If you want to input these in other units then use a suffix so [1.2, 3.4.m, 567.mm] will displace it 1.2" in x, 3.4 meters in y and 567 millimeters in z. A point in Sketchup can be represented by a three item array of x/y/z OR a Point3d they are pretty much interchangeable but a few specialized methods like polygon-mesh want Point3d rather than an array - to make a Point3d you'd use point=Geom::Point3d(1.2, 3.4, 5.6) instead of [1.2, 3.4, 5.6].
the other array is a 'Vector' it can be represented by an array [0, 0, 1] or a vector=Geom::Vector3d(0, 0, 1) this is a 'direction'. The 'up' vector in Sketchup is the Z_AXIS which is equivalent to [0, 0, 1] while 'down' is [0, 0, -1]... similarly X_AXIS, right/left are [1, 0, 0] and [-1, 0 0], and Y_AXIS, in/out are [0, 1, 0] and [0, -1, 0]... vectors at odd angles might look like this [0.1, 0.3, -0.5]. You can get the vector between two points thus pt1.vector_to(pt2).
The built-in constants for ORIGIN, Z_AXIS and X_AXIS could all be used instead of passing an array when you make your arc - it would then be centered at the origin, its 'normal' would be 'up' and the start/end angles measured from the X_AXIS [red].
As with most CAD type applications angles are in radians internally (2Pi is a circle = 360 degrees) - to make it easier to code Sketchup has a method to swap between radians and degrees - so typing angle=90.degrees is the same as typings angle=Math::PI/2 but easier to read and less likely to an error...
Hope this all helps..........

david.

@tig said:

Last thing first, a 'variable' name must start with a lowercase letter ...

A minor clarification is that variable names can also start with an underscore, eg,

_foo_bar

I don't think this is a commonly used naming convention.

TIG

@david. said:

@tig said:

Last thing first, a 'variable' name must start with a lowercase letter ...

A minor clarification is that variable names can also start with an underscore, eg,

_foo_bar

I don't think this is a commonly used naming convention.

I have also used that very naming method in 'my Unix days', so I knew which were 'my' variables... BUT I recommend you avoid it... UNLESS you have a VERY good reason Please just use 'radius', 'new_radius', 'last_radius' etc...etc.............

Wo3Dan

@tig said:

.....be 'float' - e.g. [1.2, 3.4, 5.6] when they ....you'd use point=Geom::Point3d(1.2, 3.4, 5.6) instead of [1.2, 3.4, 5.6].
.........%(#FF4000)[[I edited out these typo errors to avoid confusing others: TIG ]]
Hope this all helps..........

Thanks TIG,

Yes, it helps. I've got the add_circle working as expected.
In add_arc there still are some things about both vectors that I need to sort out.
I can see why in some cases I got arcs segments all collinear.

b.t.w. Why would the API mention (as a learning example for add_arc) two "wako"angles in radians, to have a 1145 degrees arc as a result?

thomthom

@wo3dan said:

b.t.w. Why would the API mention (as a learning example for add_arc) two "wako"angles in radians, to have a 1145 degrees arc as a result?

Because the API docs like to keep you on your toes. The author probably intended them to be degrees. (Would have been a nice example of the .degrees method: 45.degrees)

Word of advice: don't trust the API docs to be correct. Least not provide best practice examples. (For instance, it notoriously use .typename to compare entity types - which is horribly slow. Instead .is_a() should be used. So many plugins run slow because of this.)

david.

Note that is_a? will return true if the object is of the same class or a member of any of the object's super classes. Use instance_of? to be more specific with regard to class membership.

thomthom

Usually it doesn't matter

Wo3Dan

@thomthom said:

@wo3dan said:

b.t.w. Why would the API mention (as a learning example for add_arc) two "wako"angles in radians, to have a 1145 degrees arc as a result?

Because the API docs like to keep you on your toes. The author probably intended them to be degrees. (Would have been a nice example of the .degrees method: 45.degrees)

Word of advice: don't trust the API docs to be correct. Least not provide best practice examples. (For instance, it notoriously use .typename to compare entity types - which is horribly slow. Instead .is_a() should be used. So many plugins run slow because of this.)

Thanks Thomas, for the warning. I'll keep that in mind.
As for the advise.....printed and saved for use later.
I'll take things step by step, making usefull examples (at last for me), more or less according TIG's advise about the one_liners. Besides that I try snippets and alter them. And read and try to memorize the huge amount of info.
Step by step I hope to get there in the end.
Thanks again.

thomthom

Yea, that's how I got started.
Small little tasks that piece by piece let me wrap my head around how it all worked.

honkinberry

I'm having a devil of a time with add_arc, and this seemed the best place to ask.

I have, for instance,


entities.add_arc ORIGIN, X_AXIS, Z_AXIS, 100, 4.6998, 1.6823

Which should make an arc roughly resembling the curve of an upper-case D.
But instead it's making a C.
Start angle is 4.6998, end angle is 1.6823....
So, what am I missing???

--J

thomthom

4.6998 and 1.6823 radians is 269.278704555584 and 96.3886898748584 degrees which gives you an arc of 172.890014680726. That sounds like a C shape to me.

Where do you get your numbers from?

This, will be D-like:
entities.add_arc ORIGIN, X_AXIS, Z_AXIS, 100, 5.degrees, 175.degrees

This will be a true half-circle:
entities.add_arc ORIGIN, X_AXIS, Z_AXIS, 100, 0, 180.degrees

honkinberry

Those are the values from the Arc in AutoCAD.
If the Start is roughly 270 degrees, and the End is roughly 90 degrees, that is a D shape, not a C shape.
Angles accrue in counter-clockwise fashion, yes? So from Start angle, one begins slowly spinning in a counter-clockwise fashion until reaching the End angle.

--J

thomthom

Yea, it seems to be counter-clockwise - and then the C-shape makes sense. If you use the Protractor and uses the same angles to add guides, then adding then counter-clockwise from the X-axis places them exactly where add_arc draws the arc.