Sketchup is Inacurrate???

[jeff hammond]

@jbacus said:

Really, guys- I checked out of this thread for a couple days and it... wow. I love the detail and the impassioned argument on all sides. Also, you're losing me with respect to the actual changes you want made. Maybe someone could summarize for me? It would be helpful.

john
.

basically, this:

(which would also apply to 3D offsets such as seen with the follow me tool)

[jeff hammond]

@driven said:

before you recieve another 27 pages of replies...

my synopsis, boiled down to..

@unknownuser said:

Create a new tool by exposing, existing, functionality of arcs and circles and cardinal points.

or is it possible to add those things through a 'ruby'?

john

hey john..
see, i think that's more complex etc than what's necessary.. they don't need to make a new tool.. just fix a pre-existing one..

[DesertRaven]

@unknownuser said:

@jbacus said:

Really, guys- I checked out of this thread for a couple days and it... wow. I love the detail and the impassioned argument on all sides. Also, you're losing me with respect to the actual changes you want made. Maybe someone could summarize for me? It would be helpful.

john
.

basically, this:

[attachment=0:342zdrwd]<!-- ia0 -->offset_desire.jpg<!-- ia0 -->[/attachment:342zdrwd]

(which would also apply to 3D offsets such as seen with the follow me tool)

Signed!

[jbacus]

I figured the main point was that you guys would like to have a true arc entity added to the object model from which can be generated arc-arc and arc-line intersections. And some new arc drawing tools to make them. You've seen me acknowledge that I'd like to have those, too— and also seen me explain why they aren't there today.

The Ruby API exposes almost all of SketchUp's internals for the use of 3rd party developers. While it does allow them to write new tools that operate on the SketchUp object model, it doesn't allow them to make fundamental changes to that object model.

Adding a a true arc entity would have to be done by us... and it isn't something that can happen quickly, easily or without risk. There is a feature request filed on the subject.

john
.

Jeff: I suspect that the changes you want to see could be implemented in the Ruby API- someone would have to write a new offset (and FollowMe) tool that reverses the direction of the geometric tradeoff we made when we wrote our tools.

[jeff hammond]

@jbacus said:

Jeff: I suspect that the changes you want to see could be implemented in the Ruby API- someone would have to write a new offset (and FollowMe) tool that reverses the direction of the geometric tradeoff we made when we wrote our tools.

i think it's probably possible too and have seen a few different offset tools created via ruby.
thing is, they've either been made as a variety of the current offset tool -or- only work on arcs..

but the real trick is to have it work properly when there's a straight line which is connected to an arc (the letter J was used as an example earlier in the thread).. and i haven't seen that happen in a ruby yet..

i personally don't know ruby and have no intentions of learning it.. TIG doesn't seem to think there's an issue and i can't demand better usability out of his plugins..

you guys though.. i give you guys money so i don't feel bad for yelling at you about it ..

[gilles]

@ john
and also a circle tool wich works like the rotate tool:

click for center, hold and choose an inference, release set the radius.

I hate this tool as it is today

[pbacot]

Does this mean if, for example, the follow-me tool is "coming along" an edge and suddenly there is an arc, the tool would say "Arc!" and look for it's center for lathing from that point, extending the edge offset to it's parallel endpoint. Of course it has to add or subtract from the arc length if it is not tangent to the edge, to create an offset intersection.

Wouldn't there be some problems because even if SU recognizes arcs, they tend to be exploded in the course of being incorporated in other geometry, so user's expectations may be confused.

[driven]

@pbacot said:

Of course it has to add or subtract from the arc length if it is not tangent to the edge, to create an offset intersection.

No... If it get clipped it's no longer an arc, it need to be re-spaced at the new length, i.e. if the original was a 12s Arc, then the 'offset with same centre point' Arc needs to re-calculate 12s at point of intersection.
The line need to extend to meet the end points of the new true arc.
john

[Alan Fraser]

This thread is well on the way to overtaking the 'Do we have a joke thread goin here?' started 5 years ago.
Next stop 'Some Funny Pics'

[jbacus]

@gilles said:

and also a circle tool wich works like the rotate tool

I'm not clear what you mean by referencing the Rotate tool. I think you mean you'd like a tool in SketchUp similar to LayOut's Arc tool— with which you set 'center point', 'arc start' then 'arc end'? Is that correct?

john
.

[jeff hammond]

@pbacot said:

Wouldn't there be some problems because even if SU recognizes arcs, they tend to be exploded in the course of being incorporated in other geometry, so user's expectations may be confused.

actually, they are only exploded when using the offset tool or follow me (which happen to be the two tools mostly being discussed) .. doing anything else to them won't make them lose their arc_ness.. **

but you can create new arcs and/or modify them with the rest of the tools (pushpull/move/rotate/scale/).. even cut arcs with an interesting line and the left over bits will still be arcs.. (even creating the ever-elusive 1 segment arc if you want )

[edit] obviously, using the scale tool can break an arc.. but if you scale it with a corner grip, it will remain an arc.

**[edit2] well… a lot of the plugins will also explode the arcs.. and this is one area where having this fix occur inside sketchup itself would be a huge advantage..

as is now, if we truly wanted consistency in this area, all plugin writers would need to individually code that an arc will be an arc upon being run through their tool.. but, if this was how sketchup itself acted, then all the plugins would inherit the behavior naturally (maybe)

[gilles]

@jbacus said:

@gilles said:

and also a circle tool wich works like the rotate tool

I'm not clear what you mean by referencing the Rotate tool. I think you mean you'd like a tool in SketchUp similar to LayOut's Arc tool— with which you set 'center point', 'arc start' then 'arc end'? Is that correct?

john
.

No what I we want for circle tool is chose center then pick any inference for axis then chose radius
the same way rotate tool and protractor tool work.

[Wo3Dan]

@desertraven said:

...
Edit: The result needs to be an offset copy of the original arch, with the same parameters, amount of segments, just bigger or smaller depending on the side of the offset......

There are quite a few situations (more than you would like to believe) where this is NOT possible at all when dealing with segmented arcs. Even if you want to take them all along the operation as true arcs. In the end you'll have to present the geometry as segmented.
(Reread my previous post)
Only, and I mean only when dealing with tangent at vertex all along the curve, SU can keep segmented arcs after the offset operation.
I've put two and two together in the next (attatched) file.
Lets say I'm one of the developers and I would like you and Jeff and others to come up with the best solution with how to solve the connection edge-arc-edge in presented situation.
Decide which location (F or G or H) and on the other side (K or L) would be acceptable for you. Whatever you think would be right, SketchUp has to compromise due to dealing with segments. The arc will be chopped off and in best cases you'll end up with an arc part with less segments.

The model on the right represents a curve with arcs (no matter how many sides, they vary).
They are all connected tangent at vertex.
Only in this situation you'll be able to get an offsetted curve consisting of arcs that are true offsets at vertex: they can be changed in number of segments, they are still connected tangent, the 'Follow Me' tool keeps the vertex cross sections predictable, a next offset would be possible, still keeping all arcs as arcs, though again segmented.
Even edges can be part of the curve, provided that they connect perpendicular to the local end radius of arc involved

In all other situations you can't get what you are after with segmented arcs.

---

Arc offset issues when dealing with segmented arcs

[DesertRaven]

@jbacus said:

@gilles said:

and also a circle tool wich works like the rotate tool

John, would it be possible to incorporate a "lath / revolve" function in to the existing "protractor tool"?
It would be done by adding an option triggered by holding down the "alt" key to create revolved shapes.

Like copying using the protractor tool, one could choose how many segments one wants to create by either typing in "x" followed by number or "/" followed by number?

Well a "compass tool" that acts like the "tape-measure" tool and creates "dash lined" true circles to find intersections would be very handy.

[pilou]

No image or V6 file about the Arc_offset_issues?
(think of old pro & free version users)

[DesertRaven]

@wo3dan said:

@desertraven said:

...
Edit: The result needs to be an offset copy of the original arch, with the same parameters, amount of segments, just bigger or smaller depending on the side of the offset......

There are quite a few situations (more than you would like to believe) where this is NOT possible at all when dealing with segmented arcs. ...... segmented arcs.

Looks like the arch at "A" isn't tangent to the wall? Judging from the pink circle.

[DesertRaven]

Wo3Dan brought up a valid point, as shown in the below diagram, if the offset curve needs to convert into a polygon, there is a problem.

[jeff hammond]

@wo3dan said:

Lets say I'm one of the developers and I would like you and Jeff and others to come up with the best solution with how to solve the connection edge-arc-edge in presented situation.

nice gerrit
yeah.. it's a weird one and at this point, i honestly can't see a simple solution to it.. i'll think about it some more and see if something appears..

for now, i think i've drawn the offset correctly in this .skp.. as in, i'm pretty sure this is how it should look.. but it's definitely not a case of "just move the arc vertices inward.. easy"

offset_issue_gerrit.skp

[EDIT]
here's an alternate solution which has the arc vertices in alignment towards the centerpoint then an oddball segment at the end.. (i talk about it some in the next post)

offset_issue_alternate.skp

[jeff hammond]

@Gerrit

i guess what would have to happen in that situation is that the arc is being viewed as a true arc in it's calculations..

so where ever the straight edge intersects with the true arc is where the new vertex is place..

of course, doing this misaligns the vertices between it and the arc it was offset from but i don't think that matters.. because that's whats going to happen anyway if you draw it manually..

it's a weird shape (a kink between an arc and a straight line..)..

another situation where you'll see this same behavior though even more mind boggling in a polymodeler would be two arcs mitered together.. imagine a V shape with the left and right half being drawn with different radius arcs..
it's going to get weird in there -- even trying to draw it manually.. which is all the more reason to have it automated

[EDIT] another option would be to have all the vertices line up towards the center point except that one last segment would be shorter… but i can see that as being mega odd to implement
fwiw, i do have a dynamic component that does this.. it divides an arc according to it's length (as opposed to segment length) then the last segment is more often than not, shorter than the rest.. but it's still on radius.
mess around with "Rib Spacing" in the component options dialog to see what i'm talking about..

[driven]

This is what I mean...

they come pretty dam close
john