An offset circle remains a circle. An arc scaled in both X and Y remains an arc. A split arc makes 2 arcs.
But the result of an offset applied to an arc converts to a curve. It will therefore not accept a radial dimension.
I call this a bug.
(For my extension I have to look at each curve, see if any are really an arc, delete it and recreate it as an arc.)
It is because the way the Offset tool works. If you look closely, what the tool creates is, in fact, not an arc, but a curve with the end segments shorter than the rest, as their endpoints are perpendicular to the endpoints of the original arc. So if you create construction lines that run through the endpoints of an arc and its offset descendant, the point where they intersect is not the centerpoint of the original arc. Here is a half circle (6 segments for clarity) and its offset.
Anssi
I understand, but that doesnāt excuse the weakness. If an arc can be split anywhere and regenerate as 2 arc, then offset should be able to reconstitute arcs.
I was going to protest but it seems you are right. Funny. When an arc is split at a point not on a vertex, it still records as an arc:
By changing the segment count and then deleting the cutting line I was able to create a totally impossible arc:
Anssi
fwiw, the new 3pt arc tool will draw arcs like that:
(which is a good thing since a user would expect all three points to correspond with a vertex)
The offset arc is worse than I thought. If you turn on endpoints in your current style the wrong points highlight. Here are dimensions when I created 50" radius with 20" offset. The offset does not conform to an arc shape, and the offset is not 20". What a mess!
I initially though I could write a script to correct this problem by deleting such curves and replacing them with arcs derived from curve geometry. But there are several reasons that this is not possible:
- the curve is not at the correct offset.
- the 2 end segments are not perpendicular to the radius at their midpoints.
- the end points of the two end segments are in the wrong place, which means that any connected lines that were part of the original offset operation also have endpoints in the wrong place. So I would have to correct them also.
Trimble will have to fix this bug.
While they are fixing that bug they should also allow offset of a single edge:
Currently you must pick at least 2 edges (ostensibly to establish a plane of reference for the offset) yet it will allow you to select 2 colinear lines for offset (???). Mouse cursor location can establish plane as it does in other operation.
Your dimension lines are not parallel. The offset is accurate. Note that the angle between an arc segment and a line drawn from a vertex to the arc centerpoint is not 90 degrees but less. In a true arc it is, of course, 90.
Anssi
donāt offset arcs in sketchupā¦ donāt use follow-me on arcs in sketchupā¦ donāt use any plugins on arcs in sketchup (shapebender, jointpushpull, etc)ā¦
itās not that offsetting an arc is ābadā in sketchupā¦ itās non-existentā¦ if you need to offset an arc, draw the new one manuallyā¦
offsetting/etc treats an arc as the individual segments itās composed ofā¦ in which case, it does that perfectly fine & accurately.
Yes at the end points. But the offset is not accurate. Al vertices on the original arc are exactly 50 from center. None of the offset vertices are.
" it does that perfectly fine & accurately."
Iām not drawing arcs, Iām working on a plugin that processes arcs and dimensions them.
Thousands of users expect and assume that offsetting an arc will result in an arc with a radius and centerpoint: look at the entity info window.
There is no reason Sketchup cannot be fixed to maintain true (albeit segmented) arcs from an offset applied to a Sketchup arc object. The resulting curves do not follow the same path as an arc drawn to the same offset and will not accept radial dimensions.
Thatās a bug.
1 Like
maybe so.
but i donāt think itās one which will be fixed.
this topic happened a few years ago in which su chief engaged and said proper offsetting/sweeping of arcs would need to be done with plugins.
That āsu chiefā may have different priorities about precision now that Trimble rather than Google (who cared only about Google Earth 3d models) is in charge.
Hereās a more definitive illustration comparing a 90 degree arc (green) with what offset produces (red).
rightā¦ sketchup doesnāt offset arcsā¦ it only offsets straight segments. (as in, the red offset is correct and accurate if your black curve is meant to be straight lines).
the real problem isnāt so much that the arc isnāt offset properly since itās easy/fast enough to draw a new one manuallyā¦ the problem is that this sickness(?) extends into more complex operations/plugins in which drawing manually can become much more cumbersome/time consumingā¦
simple examples:
my opinion wonāt be popular around here but really, if you need to model with arcs/curves beyond very basic shapes and they need to be accurate, use a different software.
iām pretty sure it will be much faster to learn another app which already has the capabilities than to wait for sketchup to gain them.
The Sketchup object model has a perfectly adequate arc definition that understands correct arc geometry and uses straight facets mostly only for display purposes. Arc geometry is correctly maintained even if arcs are scaled in both x and y, or are split at any point at intersections or for boolean results. But with the offset command the programmer just made a mistake. He could easily have retained arc geometry but just got lazy or didnāt notice.
I could easily write a plugin to do arc offsets one at a time. And users can draw them one at a time. But when using the offset command on a complex face with both straight and arc portions, concave and convex sections, and offset distances that can need some arcs to disappear. it gets a bit mode complicated. The good news is SketchUp already has written the code to do all this, so it should not be that difficult to fix the small part of the code where the mistake about arcs was made.
i think itās a lot more than an oversight or small part of code which needs fixed.
idk, i went the route of using other software and am currently able to not worry about this type of stuff in my modelsā¦ if i waited for sketchup to do what i needed, iād still be waitingā¦ maybe youāll have better luck with waiting for sketchup to deal with arcs (and more importantly, curves) properly.
good luck
You are correct for certain kinds of modelling. However my field is architecture. And except for certain rare designers, the parts of architecture that are dimensionally critical are mostly flat surfaces, with a few curved surfaces that are simple extrusions of circular arcs, perpendicular to the arc. If we are talking industrial design, SketchUp is a non starter.
But for architecture at $0 price (vs about $2000 for Rhino with architectural addins) and 100 times as many seats, I think SKetchup has a future.
so do iā¦ and itās fine/completely accurate for many many scenarios.
there arenāt a whole lot of people complaining about the offset behavior and i assume it would be quite a bit of work for the developers to fix while very very few users will actually notice a differenceā¦
i personally think it would be worth the effort to fix but iām pretty sure iām in a tiny minority so from a big-picture point-of-view, itās probably not worth itā¦ (as in- the developers are aware of this and have been for quite some time and nothing has changed so i can only assume they donāt think itās worth fixing eitherā¦ as you can see, itās not even worthy of discussion in the forum so youāre stuck talking about it to Anssi and me 
)
Iāve just been searching this Issue. Is there Plugins that do it well? Offsetting an 90Ā° Arc needs to create an 90Ā° Arc again. I agreeā¦with Berry from 2015. Its a Bug, and quite a cruel one 
I get arcs when I offset an arc. o need for a plugin.
