Add_arc etc.

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.