@desertraven said:

It is completely illogical that the end of an offset arch would result in a cut short end segment or elongated end segment - just for the sake of keeping it square.

No, it's not illogical, it's just inconvenient for offsetting arcs. There ought to be another tool (or at east an option) for doing that, based on offsetting the end points, not the facets. Calling it illogical implies there's no logic. There is...like I said, it's just not a logic that a lot of people find particularly useful in many circumstances, me included. If there isn't already a Ruby for doing this, there ought to be.

More correctly, it's more than inconvenient, it's misleading. The reason being that it's not really an Offset Tool at all when it comes to offsetting arcs...it's a Joint Push/Pull Tool. In other words, it pulls out the facets, the resulting new endpoints are simply where those extruded facets happen to intersect. As such, it's no surprise that they don't conform exactly to any expected increase in radius.
In fact if you pull an arc upwards into 3D and JPP it, you'll find you get exactly the same new 'arc' as if you'd 'offset' it.

Gerrit, you're absolutely correct about the bulge/radius thing. I was having a senior moment.
There have been times when I simply can't persuade the Measurement box to say Radius instead of Bulge; I guess that's what prompted the remark. But of course I could always simply override that by typing value + r.

Gerrit, you can specify the number of decimal places in Model Info > Units.
You guys might find this handy.

Another of the quirks of the Arc tool...which is why I tend to use circles for laying out stuff like this. I reserve the Arc Tool for rounding corners, turning block ends into bullnose or rectangles into lozenges....or when 'looking good' is good enough.
The accuracy is actually pretty impressive, but I find it very odd that you get an utterly different result depending on whether you type the radius into the VCB (Measurements) or Entity Info. It would be really useful if you could inference off an established centre...something it seems to recognise if you go the Entity Info route.

That shouldn't be the case. If you choose to colour edges by material, then the only edges that change ought to be the ones you actually apply a specific colour to. All the others will remain the default black, exactly as they were before.

Now that really is weird. It must be a bug. Thanks Jim, I never thought of importing to Layer0...but see no logical reason why that should make any difference.

@thomthom said:

I think much of the tension in this thread comes down to people who accepts SketchUp as it currently works - and the ones that wants it to improve.

Almost correct, but not quite. I too would love to see the Offset tool perform the way that Jeff wants it to...treating arcs and straight lines differently. and producing a result like this.

All I'm saying is that this is not the one and only 'correct' way...just the way that most people would prefer and expect it to work...most of the time. It is fine and dandy if your prime concern is to maintain an equidistance across the arc nodes...and hence overall radius from centre. It's not so welcome if your work involves maintaining the same profile along each segment. As I already pointed out, the segmental width decreases as it goes around the arc. All kinds of people use SU for all kinds of purposes.

Also I'm no great coder, but I also suspect that such a change in behaviour might break every single Ruby concerned with offsetting, extruding, rounding corners and organic modelling in general (as well as not doing a thing for the current problems we have with internal offsetting...which I happen to think are far more serious and deserving of attention...we've all encountered the horrible bird's nest of intersecting planes that result not only from using the native tools, but also the scripts that have to conform to the coding that governs the behaviour of those tools).
I'm not advancing this as a reason not to change...I would welcome the change. I'm just pointing out that it might have serious consequences...at least for a while.

Jeff, there is absolutely no need for the patronising attitude...or the extrapolation to absurdity. You know as well as I do that no architect/designer worth a damn is going to use Follow Me to extrude critical parts of a building around a curve. That tool is quite obviously meant to be used on ducting, railings etc in which the intention is to keep the extruded shape a constant width...something your J example doesn't do...and which your Rhino example (which is supposed to prove God knows what) certainly doesn't do.

Anyone with any sense at all would lay out a radius-critical construction something like the diagram below before going vertical. This leads to no such contrived broadening at the base. Your solution of the radial splines is fine if your main concern is to maintain such a constraint of distance from centre; but (as my previous example of the arrayed components illustrates) it's not up to spec if your concern is more centred on maintaining a constant profile for the extrusion.
I will repeat it...even if you don't accept it...there are no 100% right and wrong solutions once you abandon true curves for segments.

I agree completely with your point about treating curves and straight lines differently; which is why I have been arguing all along for more than a one hit solution for these functions. Offsetting along radial splines along an arc, but a straight linear offset along lines would result in the either of the two versions below. I'm quite certain the non-filetted one would be the most useful and the one that most closely resembles such an offset performed in a bezier environment.
But even here it has to be recognised that this is also a compromise. The offset at the base of that semicircular model is precisely 3"...the offset, similarly edge to edge, along the arc is 1/32" less. True, this will become more accurate if you increase the number of segments in the curve...but by the same token, so does Follow Me. If you increase the number of segments on the base of your J to 36, the discrepancy in the exterior radius shrinks to less than 1/100 mm

Following that logic. You are saying that the Follow Me version is wrong and the Hammond version is right. Well, how about you apply that to another object that doesn't have regular curves? In this example, the Hammond version is on the left...with a consistent width only at the vertices; and the Follow Me version is on the right...with a consistent width to each side.
Dunno about you, but I know which one I prefer. Yours looks plain ugly.

Or putting it another way; here is your J with identical components arranged along its length. Down the stem, they fit perfectly edge to edge...but by the time you get to the bottom of the curve they're hanging over. Isn't that inaccurate too? It doesn't happen with the Follow Me version. You seem to be very partial as to which features you find fault with.
As I said before...both versions are compromises, because of the segmentation of the curve. They are both right and they are both wrong. It depends what your priorites are.

Here you go, Jeff. I think this is what you asked for, As you can see, the two Js superimpose almost exactly. I say 'almost' because the Follow me version is ever-so-slightly broader at the extremity of the curve.
It would be difficult to say either version is wrong...because what is being exhibited are the compromises made when a curve is approximated by straight-line segments. Your version maintains a 1cm thickness at the vertices, the Follow Me version maintains a 1cm thickness perpendicularly, edge to edge (which is how it starts out, after all)
This means that it's slightly wider at each vertex...which explains the broader curve. Your J, however, gets slightly thinner along each segment (0,991445cm it would seem)...thinner than the 1cm it is down the stem. Like I said. It's hard to say either is wrong. It depends what your priorities are.

Jays.skp

Gerrit is correct, Jeff...you haven't given SU a fair crack of the whip. In your hand-drawn version you have the final radial section running horizontally along the red axis. Yet in the prepared path for Follow Me, the final segment of the path is still at a slight angle. You can't possibly expect Follow Me to produce a squared-off final cross section under those circumstances.
In situations like that (or in more practical circumstances like a pipe bending through 90 degrees before disappearing into a wall) you have to add a final 'follow-through' segment to get Follow Me to terminate properly. In the case of the pipe and wall, that would be a segment perpendicular to the wall (which a 90 degree arc doesn't give you). In the case of the J, it's a final segment running along the Green axis. The length doesn't matter...because after you've extruded, you just Push/Pull it back to the intended end point. If you do it that way, the two versions seem to match exactly. I tried it...they do.

Any Brits or Irish got any decent supermarket horsemeat jokes, or have they run their course? What's next, I wonder...my Lidl Pony...UniQuorn in the veggie burgers?

A duck walks into a post office and asks the man behind the counter: 'Do you have any corn?' The man answers politely: 'No, we don't have any corn here.' The next day, the duck enters again and asks: 'Do you have any corn?' Annoyed, the man answers: 'No! We don't have any corn.' This goes on for a couple of days until finally, when the duck asks 'Do you have any corn?', the man gets so upset he yells: 'NO! For the last time we don't have any corn, and if you ask again I'll nail your beak to the counter!' The next day, the duck returns and asks: 'Do you have any nails?' The man answers: 'No.' Then the duck asks: 'Do you have any corn?'

A man goes to the doctor and says: 'Doctor, there's a piece of lettuce sticking out of my backside.' The doctor asks him to drop his trousers and examines him.
The man asks: 'Is it serious, doctor?' and the doctor replies: 'I'm sorry to tell you, but this is just the tip of the iceberg.'

A magician was working on a cruise ship in the Caribbean. The audience was different each week so he did same tricks over and over.
The problem was, the captain's parrot saw all the shows and began to understand how the magician did every trick.
He started shouting in the middle of the show: 'Look, it's not the same hat. Look, he's hiding the flowers under the table. Hey, why are all the cards the ace of spades?' The magician was furious but, as it was the captain's parrot, he could do nothing. Then one day the ship sank and the magician found himself floating on a piece of wood with the parrot.
They glared at each other but said nothing. Finally, after a week, the parrot said: 'OK, I give up. Where's the boat?'

@unknownuser said:

"DesertRaven"Alan, this thread is going exactly where it needs to go. If we keep saying we'll settle for "good enough", nothing will ever be gained to the better.

Where have I ever indicated that I'd settle for 'good enough'? I have pointed out several times now the shortcomings of the Offset Tool...in both exterior and more especially on interior offsets. I have also mentioned that Follow Me leaves much to be desired. If it didn't, we wouldn't need rubies like Follow Me and keep to perform simple tasks. I've also said...several times...that the arc and circle tools need many more options other than (in the case of the circle) simple Circle from Center. The arc tool is reasonably decent in Layout. I see no reason why it can't operate the same way in SU.
As Wo3Dan points out (and TIG before him), the operation of Offset tool is not necessarily an inaccuracy (which is what this thread is about). It is, in fact entirely logical...it's just not a logic that we find particularly useful most of the time. Again, another mode of operation would be very welcome. I and others have also been long pressing for true construction curves (as opposed to true curves in the geometry) I believe that is also achievable.

All these are reasonable and achievable requests for improvement. You, on the other hand seem to be basing almost all of your criticism on the fact that SU does not display true geometry curves. This isn't a matter of not being good enough, it's simply the nature of the beast. SketchUp is a polygon modeller; it's currency is straight lines. You can campaign for true curves from now till eternity...but you won't get them.

What I mean is that even though the two versions look different when viewed separately, if you import them both into a new file the Material and Components browsers will tell you you have imported two different models with two different materials (as expected...you can even see the difference in the thumbnails in the Component browser)...yet the second model to be imported will always come in looking identical to the first one.

A slight little factoid, stemming from my earlier comments about arcs beginning and ending with only half-segments:

If you draw a default arc then chop a little off each end segment, it's still obviously a 12 segment arc...but with two of those segments shorter than the others. Now use Entity Info to change the resolution to...say...24 segments, then back again to 12.
You find that what you have now is a redrawn 12 segment arc with all its segments now all the same length.

No great surprise there, as SU seems to recognise arcs based on their end points and centre...neither of which has changed.
I just thought it might be a useful little trick if you needed to butcher or intersect an arc for various reasons, yet still wanted whatever remained to comprise equal segments.

This thread seems to be getting a little lost. Yes, there are annoyances in SU...like the way that Offset (or Follow me, for that matter) doesn't currently play nicely with curves. I also can't see any reason why SU can't have circle and arc tools based on 2 points + centre etc. like other apps do. However, these things are not necessarily reflections on SU's accuracy. Like I said above, those 3 circles I drew earlier are dimensionally and positionally accurate. It's utterly irrelevant that their low-res polygonal representations don't quite touch. If what you demand is true curves from beginning to end, one has to question why you are using SU at all; it is not a NURBS modeller, was never developed as one, has no intention of ever becoming one.

I like Jeff's idea of having a construction point mark the true tangential point of two curves. I'd even go further and suggest that it would be really cool if we could have an option (on the context menu maybe) to temporarily show a true curve 'ghost' of a polyline curve. As Thom has already said, SU knows what these polylines actually are; and it will make them progressively more accurate as you increase the number of polys. If this 'ghost' could be inferenced off, even better. Linked to better options for drawing arcs, you could then construct one arc directly off another with pin-point accuracy.
If this can't be done in the modeller itself without screwing-up the code, then have it available in Layout...which uses true curves already. Then have the resulting plan exportable directly to SU in the resolution of your choice...and with the arcs still showing up as such.

This thread started off with everyone more or less in agreement the SU is very accurate and the many reports of it being inaccurate were from people who didn't know how to use it properly. We all recognise that there is still much room for improvement...especially in the area of curves and arcs...and their further extrapolation. However, the last few pages seem to be little more than bitching about the fact that it's not a NURBS modeller. Absolutely correct....it's not...so what?

@desertraven said:

@alan fraser said:

Well of course they don't touch...they're not bezier curves, they are polygon approximations of circles. SU still understands them as circles with those properties...and if you increase the number of segments (to say 120) to get rid of the facets, then the edges will touch.
Criticizing SU for not displaying true curves is like criticizing and Abrams tank for not being able to do aerobatics. The right tool for the right job.

But that was the premise here. In Architecture we like circles; So are you saying sketchup not the right tool for the job?
I'll tell you with a we bit more sophisticated options it absolutely would be.
As I said before some issues just need to be fixed. And there is no reason why not.

But you said those circles weren't accurate...and they are. They are circles of an established radius and they are the correct distance apart for their circumferences to touch tangentially. Whether they actually touch visually is entirely dependent on how many segments you care to assign to them. Did you increase the number and see that they do, in fact, touch?
SketchUp could certainly do with more options to construct circles and arcs starting from various points along the curve. I believe ther is a plugin that will do that (which I don't possess)...but that is a question of usability, not accuracy.

I'm not an architect, but there appear to be an ever-growing number that believe it is the right tool for the job. Maybe not the only one, but certainly one that has radically affected their workflow.

As for your question of whether it is still easy once you get beyond rectilinear shapes; well, as I routinely use it for modelling eveything from tufted sofas, through all manner of organically shaped furnishings to entire human figures and trees, I guess I'd have to say "Yes it is."
That's not to say it can't be frustrating at times; and there are certainly some processes that are much easier in other programs. But taking the broad view, it is still much faster and easier than anything else out there. If it wasn't, I wouldn't be using it.

Well of course they don't touch...they're not bezier curves, they are polygon approximations of circles. SU still understands them as circles with those properties...and if you increase the number of segments (to say 120) to get rid of the facets, then the edges will touch.
Criticizing SU for not displaying true curves is like criticizing and Abrams tank for not being able to do aerobatics. The right tool for the right job.

Three different sized circles touching tangentially. Radii of 12', 9' and 6', giving center to center distances of 21', 18' and 15', all done in SU using only native tools. Do I get a cigar?

CIRCLES.skp

Here's an interesting phenomenon that I came across some years ago. It seems that SU sometimes needs a good kick up the butt to get it to update properties.
At FormFonts, we are forever creating different configurations of the same component...maybe a sofa or shelf in different finishes.
To save remapping every variant separately, it makes sense to map just one then specify a different image map for the other variants. If you want to use more than a single variant in the same model, you need to do more than simply specify a different texture. That alone is not sufficient to create a separate unique component.

I have attached two very basic shelves...one in dark wood, one in light wood. I made the dark shelf first. I then swapped the dark wood for a lighter one in the Materials Edit tab. I also changed the name of the material so it wouldn't conflict with the original, before saving to a different file. I then even created different internal components within the two files...one light, one dark.

You can see all this if you download the two files to your desktop. Open each one separately and study the info in the materials and components browsers. Everything looks exactly as you would expect it to. They are clearly different components. Now try opening a new file and importing them both...then open another new file and import them in reverse order. In both cases SU will tell you you have two different components with two different materials

Luckily, there is a solution...the proverbial kick up the butt.

shelf dark.skp

shelf light.skp

Strange! I just did it again in a fresh file and now I get a circle...but still with the correct entity info. Maybe the FormFonts layer is the magic ingredient.
I am on V. 8.0.16846. I assume you two are as well.

circle.skp