Add_arc etc.

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.

honkinberry

I'm sorry, I'm just not following.
I'm Susan, I'm standing at the origin, and I'm pointing at at object down the negative Green axis, at 270 degrees relative to me. It is a car, and it is driving in counter-clockwise circle around me. As it drives counter-clockwise towards a point located at my 90 degrees, the resultant path it drew was a D shape, not a C shape.

I've dealt with arcs extensively with AutoCAD, and as I said, this is just taking the exact arc in AutoCAD and recreating here in SketchUp. But some of my arcs are getting reversed, and I can't figure out what I'm supposed to be accounting for.

--J

thomthom

Right, I see.

Maybe SketchUp normalize the start and end angle - because swapping the values around creates the same arc. ??

You might have to use negative angles.

honkinberry

Ah, I'm starting to get it.
I made the same mistake when I was a 19 year-old programmer.
If the arc crosses 0 degrees, it will get reversed.
So you're right, Sketchup is sort of normalizing the arc. Or put more accurately, it's a bug -- it assumes the start angle to be less than the end angle.
So easy enough fix -- if (start > end) start = start - 360.degrees
Thank you sir!

--J

thomthom

Probably be good to make a wrapper for the add_arc method.