Arc offset bug (It converts to a curve)


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.)

Help needed on countersinking holes

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.



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:



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.



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.


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 :wink: )