Sketchup is Inacurrate???

jeff hammond

@unknownuser said:

and before rich calls me a gob o' shite again over this, i would like to say that i fully understand these are first world problems.. i'm just being nerdy about it but in the actual big picture.. i don't care.. at all

Do care about the small picture as well as the big. I get very annoyed when someone mentions from out of the blue a third world problem to mute an otherwise sensible discussion. Or non-sensible for that matter. As if we should never be allowed to talk about anything else.

Btw - Luis CK FTW!

yeah.. he's the funniest guy of the past decade.. intelligence disguised by humor

what i'm getting at in that post is that i don't want to fight anybody over this.. in the bigger social picture, it's not worth it to me (or anyone else) to bring it to that level..

but on the flipside is that i'm pretty damn intimate with this app.. there will be times when i use sketchup more than i sleep in a day.. (and eat, and relax, and everything else that day).. so when you're that involved with something, you're equally involved with the downsides.. and in this instance, these downsides aren't natural.. they are man made and in this situation, definitely(!) fixable..

and i do understand that this isn't a simple fix.. on the surface it is but i think once you examine a bit further, many facets of the core app are linked in to this behavior.. not just the offset tool and follow me tool.. but the whole brain.. we just see it come out in certain tools but the behavior is underlying..

so considering that, i still believe it's worth pursuing.. and not in an 'oh, i wish they would do this..' manner..
it's a serious breakdown in the apps usage.*

(*ok.. i could have an entire drawing session and not encounter or be affected by these errors.. it depends on what you're drawing... but the minute you bring any sort of arc into the picture, you're gonna get stung.. and i honestly don't think using an arc should be viewed like "oh.. that's really pushing the limits of architecture and very few people need that capability.. etc.." this is an arc we're talking about.. a very basic and widely used building block in design.. and it should work right)

jeff hammond

@thomthom said:

Jeff, I wish you where a Ruby plugin developer - you sure have the drive for details and solutions to make great products. Can you not be teased into a new venture?

i don't think so.. i started getting into chess around 2000 or so.. in 2005, i quit.. i had to.. that's all i did or thought about or dreamed about.. it was weird.
ruby = chess

DesertRaven

@tig said:

The native 'Offset' works just fine - within its own limitations.

.....

okay here is another one, this time I'm using line segments that were drawn from scratch rotated about a center point, not an exploded arch.

So is it the arch that is causing this error or is it the offset tool? I think the later is the culprit.

As in the previous graphic, the middle line is the original the outer and inner line are the offset ones. They are not connected.

thomthom

@unknownuser said:

what i'm getting at in that post is that i don't want to fight anybody over this.. in the bigger social picture, it's not worth it to me (or anyone else) to bring it to that level..

I reckon this topic is worth a fight.

Alan Fraser

Chill out guys. I'm not defending the behaviour, merely explaining the logic behind it. As TIG says, the Offset Tool works accurately in it's own way. However, as far as I can see, that way isn't much use to most people most of the time...me included.
It seems that most of the problems arise from having the Arc and Circle tools being defined by distance to end points, while the offset Tool does exactly the opposite and works on the principle of offsetting the perpendicular distance from the edges between those end points.

TBH I can't really see how the Offset Tool can work any differently...especially when you consider offsetting rectilinear shapes. I guess what I'm trying to say is that the the fault doesn't necessarily lie with the offset Tool itself...more how SU handles arcs and elipses. If it was more aware of the true nature of any given curve, then perhaps we wouldn't see the problems we do when offsetting them.

For example, it would be useful to have the option of drawing arcs and circles defined by a radius from the centre to mid-facet...measuring the same way that the Offset Tool does. If an arc is drawn in this way, then Jeff's example of drawing such an arc of radius 10 units and offsetting by 1 unit yields a completely accurate offset. The radius of the offset is 11, not 11 1/16 or something equally weird.

DesertRaven

@alan fraser said:

Chill out guys. I'm not defending the behavior, merely explaining the logic behind it. As TIG says, the Offset Tool works accurately in it's own way. ......

I don't want to miss pointing out that I am, for my part, talking about SU "PRO";
Pro as in Professional. So I'm up for a fight and I will un cover more of SU's so called shortenings, at least that way I can say I did something instead of letting it just slip.
Anyone here who is serious about doing professional work here should join in to the fight for fixing SU.

There is also the promise of an easy to use easy to learn application, and until certain shortcomings are eventually fixed or at least recognized by the developers, this promise is not being met.

TIG

Olav

When you 'Offset' your example 'Arc'...
You completely missed the point.
The reason the offset's end segments are not the same length when the native tool Offsets an Arc, is that it does NOT offset the Arc at all, but it offsets its Segments.
The mid-segments are offset at the vertex bisector angles BUT the start/end segments are offset at a right-angle, just as you would expect it you exploded the Arc into separate Edges and Offset those...

If you want 'true' Arc offsets use my tool...
The native tool only Offsets Edges, Arc-ness is ignored and an Arc's segments are offset as edges...

To reply to earlier prods..

BUT...That is the way it is.
The Offset tool offsets Edges and it does not offset Arcs as anything but Edges...
It never has, it was never intended to, and it's unlikely it ever will.
I'm just telling it the way it is.
"For the avoidance of doubt."

That doesn't mean it shouldn't/couldn't be improved/changed, but then there's a long list of those waiting in the wings...

And... why would you [Jeff] use a 1" Offset on an Arc of radius 10" and expect the new 'Arc' to have a radius of 11" ?
You already know SketchUp Offsets the segments, so the segments are offset by 1", NOT the ARC [vertices] itself... so the new Arc's radius will actually depend on the original Arc's segmentation and only approximate to the 11" even with the most excessively segmented original Arc !

IF you want to do an 'Arc-Offset' then currently my tool Arc offsets truly by 1", so the new Arc's radius is indeed 11"... BUT these processes need to be done early days, otherwise the knock-on affects get very unpredictable/unmanageable... see below...

If the native tool did 'proper' Arc offsets it would be better, but it doesn't...

Remember that SketchUp [currently] doesn't pretend to Offset an "Arc" 'properly', it just Offsets some Edges that approximate to an "Arc"...

It's not a 'fault' with Sketchup, but rather it's a limitation - resulting from the way that SketchUp doesn't really have Arcs and Circles at all - it just pretends it does, by using segmented polygons...

When you have a raison d'être like SketchUp's, where a bound-set of edge-segments approximate to an "Arc", it will be very very difficult to 'add' a true Arc-centric solution, without recoding the very core of its being...

Imagine you have a 3d extruded form with its original faces bounded by Arcs...
Their form is now locked into the 3d object as 'facets' - each one having two edges that are two of the top/bottom "Arcs'" segment.
Now let's say that you want to add a new Line that arrives tangentially onto one of the existing "Arcs" [perhaps to add some linked geometry that you will subsequently extrude into an 'extension' of the original form...]... If you snap onto one of the "Arc's" segments or one of its vertices, then the chances are that the snapped point isn't going to be a true-tangent point on the Arc... thus the line isn't arriving tangentially... BUT if you were to determine the 'true-tangent' then that point is conversely very likely to be quite unconnected to the original "Arc's" geometry...
Let's now assume that this 'tangential' line is added... to make it properly tangential [so that it does now touch the "Arc" geometry] we now need to recast the "Arc" and recalculate an alternatively segmented "Arc" form that has vertices at all current 'nodes' forming 3d facets AND this new tangent-point... AND the connected 3d facets all need to adjust to match this, and of course their geometry might in turn be connected to other geometry that may well need to adjust to compensate too etc etc... So adding a tangential line to an "Arc" now ripples out affecting all connected geometry ! There would be significant 'ripples' as many vertices adjusted to accommodate the new form. This in turn might affect the Offsetting of some Edges elsewhere etc... Even worse... unconnected geometry [with say a group] that was once coincident with the former vertices is now out of step and needs adjusting to suit, and then groups abutting that etc etc... The "butterfly affect" of adding just one tangential line onto a "Arc" that is within established 3d forms could thereby have untold and unforeseeable consequences for other parts of the Model - this is not a sustainable fix for SketchUp as it is currently construed...

So... adding "true Arcs", and their related tools like drawing tangential lines, into SketchUp would mean it's then no longer the SketchUp we know and [often] love... and trying to shoehorn in anything much beyond where we already have, is likely to produce all sorts of unexpected 'ripples throughout the matrix', that you will later find you would probably have liked to have NOT done, and thereby you would have preferred the inadequacies of the current toolset...

If someone has a viable idea to fix this issue then please let us know... otherwise the half-baked version is better than none...

jeff hammond

I'll probably type more on this later but for now via phone...

@tig said:

The Offset tool offsets Edges and it does not offset Arcs as anything but Edges...
It never has, it was never intended to, and it's unlikely it ever will.

where are you getting this info? I mean, you may very well be right but I'd like to see your source if possible..

there are quite a few clues telling me otherwise.. maybe the most obvious being the offset tool's icon.. surely you've seen this before?

Alan Fraser

@desertraven said:

@alan fraser said:

Chill out guys. I'm not defending the behavior, merely explaining the logic behind it. As TIG says, the Offset Tool works accurately in it's own way. ......

I don't want to miss pointing out that I am, for my part, talking about SU "PRO";
Pro as in Professional. So I'm up for a fight and I will un cover more of SU's so called shortenings, at least that way I can say I did something instead of letting it just slip.
Anyone here who is serious about doing professional work here should join in to the fight for fixing SU.

There is also the promise of an easy to use easy to learn application, and until certain shortcomings are eventually fixed or at least recognized by the developers, this promise is not being met.

Before you start insinuating that I'm some kind of complacent, unprofessional dabbler, maybe I ought to point out that I've been beta testing this software for the best part of a decade...and that quite a number of basic taken-for-granted functions that are now part of the core program are there at my urging.
There are solutions to these kind of issues, as TIG points out...either by using plugins or a little common sense. personally, I'd rather go that route than have the program overly-complicated by attempting to second-guess what your intentions are.
You might regard that arc as a true arc with a centre, but as far as SU is concerned it's just a curved polyline...and it offsets it accordingly....and accurately in that context.
If you want it offset in the context of being a segment of a circle of known radius, then might I suggest you actually draw a circle of known radius and offset that...then delete what you don't need...or use TIG's script.
Either way, if you intend fighting for a better SU at my expence I'll fight right back.

TIG

@unknownuser said:

I'll probably type more on this later but for now via phone...

@tig said:

The Offset tool offsets Edges and it does not offset Arcs as anything but Edges...
It never has, it was never intended to, and it's unlikely it ever will.

where are you getting this info? I mean, you may very well be right but I'd like to see your source if possible..

there are quite a few clues telling me otherwise.. maybe the most obvious being the offset tool's icon.. surely you've seen this before?
My source is my thoughts and observation of freely available information...

Of course I have seen the icon...
What makes you think that a small icon drawing of some Offset Edges in the form of an Arc IS an Arc... OR that a small image like that somehow promises you something... ?
Where in any of SketchUp's documentation does it say that it makes True-Offsets of Arcs ?
It could perhaps better explain what it does, but for a long time now 'we' have all known more about the tool than the docs tell us...

YOU already know SketchUp's Offset tool has never offset an Arc in anything other than its segmented edges, and that its Arc is a mere representation of an Arc though segments and nothing more... so why suppose it was ever otherwise, or intended to be otherwise?

I'm quite sure the original coders would have loved 'true-arcs' and their related tools... BUT there are limitations to every approach, and trade-offs limiting some aspects have benefits elsewhere, so I'm sure that some years ago such an item on their 'wish-list' was quietly 'forgotten' as too problematical to realize...

IF you had read what I wrote...

SketchUp never has Offset Arcs 'as Arcs' [you brought this very 'fact' up ages ago !] - in fact Sketchup only has these pseudo-arcs anyway, made from edges - which it 'pretends' are Arcs !
SketchUp was never intended to Offset Arcs truly [that is abundantly clear from the way it functions and offsets them as if they were segments], if it intended to truly Offset Arcs it would do so - even if it sometimes failed - BUT it never even tries to do it... [but then the limitations of achieving this are expounded in other paragraphs...]
The enormous upheaval in the code that'd be needed to recast SketchUp into a something with 'real' Arcs and related tools was also covered in other paragraphs - and it is upon which I base my assertion that such a feature is unlikely to appear, at least in anything we would continue to recognize as SketchUp, simply because of the ramifications of such supposed tools on all connected faceted geometry...

There are obviously apps which give you true-arcs and related tools, but none that match SketchUp's simplicity and ease of use, so there's no such thing as a free-lunch... Use other software if you must have this functionality, because adding it to the native SketchUp would, in my humble opinion, make it a quite different thing from what we have now - "warts and all"...

jeff hammond

@alan fraser said:

personally, I'd rather go that route than have the program overly-complicated by attempting to second-guess what your intentions are.

You might regard that arc as a true arc with a centre, but as far as SU is concerned it's just a curved polyline...and it offsets it accordingly....and accurately in that context....

it's overly complicated now (at least the way it's presented to the user.. on the programming side of things, i believe the authors took the simpler, less complicated way)

check an arc's entity info.. it's called an arc and being identified as one.. you can get it's correct length.. you can change it's radius (accurately) as well as the amount of segments (accurately)

change the arc to a 'curve' and it's treated differently.. length is now the sum of segments.. you no longer can get a centerpoint.. you can't change the segments

not to mention, arcs behave as true arcs in many other facets of sketchup (as outlined in the list i posted earlier)

therefore, at least to me, SU is aware there's a different type of geometry happening and it doesn't treat them the same.. unless of course, you try to offset it (or follow me it ..or any other type of operation along those lines)

so again.. that, from a user's point of view is overly complicated because it lacks consistency.. sometimes sketchup treats arcs like arcs and sometimes it doesn't..

@tig said:

My source is my thoughts and observation of freely available information...

seriously, i'd rather avoid getting finger pointy and all but.. earlier (in this thread and other places) you've said sketchup properly handles offsetting et.al of arcs..

now the tune has changed.. you're saying sketchup doesn't handle arcs properly but it was made this way.. and was never intended to properly offset arcs and insinuating that somehow the error is on my side because i wrongly assumed sketchup is supposed to be accurate in this regard..

it's too jumpy/politician like for me take to heart.. i don't care who comes out of these conversations with more saved face.. and you shouldn't either.. there is a flaw in the app that needs to be addressed.. that's that

@unknownuser said:

Of course I have seen the icon...
What makes you think that a small icon drawing of some Offset Edges in the form of an Arc IS an Arc... OR that a small image like that somehow promises you something... ?

one thing that makes me think that is reiterated by apple here:
via OS X Human Interface Guidelines

The best toolbar icons use familiar visual metaphors that are directly related to the app commands they represent. When a toolbar icon depicts an identifiable, real-world object or recognizable UI element, it gives first-time users a clue to its function and helps experienced users remember it.
-or maybe-

Take advantage of people’s knowledge of the world by using metaphors to convey concepts and features of your app. Metaphors are the building blocks in the user’s mental model of a task. Use metaphors that represent concrete, familiar ideas, and make the metaphors obvious, so that users can apply a set of expectations to the computer environment.

@unknownuser said:

Where in any of SketchUp's documentation does it say that it makes True-Offsets of Arcs ?

or more importantly, where does it not say that... as it's presented now, it does..
you're human.. you know what it implies..
getting all nitpicky about what such-and-suchreally means etc is just getting further away from the fact that sketchup is flawed..

**[EDIT]**again, i think this side of things is far too nitpicky and off topic but i just googled "can you use the offset tool on arcs in sketchup" and the first listing that pops up is this:

http://support.google.com/sketchup/bin/answer.py?hl=en&answer=94871

with the first line of that link being:
"You can also select and offset connected, co-planar, lines (and arcs) for an offset."

and if i really felt it necessary to find more examples of this type of language in official docs, i don't think it would be too hard..
[/EDIT]

but i will say this.. i don't think you will find a single person using sketchup saying "oh.. i never assumed the offset tool was supposed to work on arcs as well as edges.. duh.."

@unknownuser said:

YOU already know SketchUp's Offset tool has never offset an Arc in anything other than its segmented edges, and that its Arc is a mere representation of an Arc though segments and nothing more... so why suppose it was ever otherwise, or intended to be otherwise?

because there are many other areas where sketchup does in fact treat an arc in a proper fashion.. arcs aren't impossible in a polygon modeler.. and in many ways, sketchup shows us this.. but in some ways, it shows us that it wants to just brush it under the rug..

@unknownuser said:

I'm quite sure the original coders would have loved 'true-arcs' and their related tools... BUT there are limitations to every approach, and trade-offs limiting some aspects have benefits elsewhere, so I'm sure that some years ago such an item on their 'wish-list' was quietly 'forgotten' as too problematical to realize...

you could very well be right.. but if long time users want them to unforget it and discuss it openly, i don't feel like it's too much to ask.. i wouldn't quite say i or we deserve an answer but i sure would appreciate some sort of official dialog on the matter..

@unknownuser said:

Use other software if you must have this functionality, because adding it to the native SketchUp would, in my humble opinion, make it a quite different thing from what we have now - "warts and all"...

yes and no.. an adjustment/reworking of the app might have many users not even noticing anything.. (unfortunately.. but at least their drawings will be more accurate - unbeknownst to them (offtopic_ish -- i'm willing to bet there are thousands if not millions of sketchup created drawings floating around which are in fact inaccurate directly related to this issue))

i understand also that when you start tinkering that deep into the core in order to address this, that other issues may arise which are in themselves undesired.. this, i feel, is where a developer with access to the core could be discussing this with us.. make me understand that somehow fixing the arcs are going to be detrimental to sketchup as a whole.. because right now, i don't see that one bit...

andybot

Hate to weigh in on this, but I can't resist piling it on. I totally agree with you Jeff, the way SU half-handles arcs as sort-of-polylines is really limiting. Very early on in using Sketchup I realized just what a limited ability there is to do 2D drafting with SU. I personally have stuck with ACAD for anything complex in 2D because it doesn't get stuck on these goofy half-solutions, it just works.

thomthom

@alan fraser said:

TBH I can't really see how the Offset Tool can work any differently...especially when you consider offsetting rectilinear shapes. I guess what I'm trying to say is that the the fault doesn't necessarily lie with the offset Tool itself...more how SU handles arcs and elipses. If it was more aware of the true nature of any given curve, then perhaps we wouldn't see the problems we do when offsetting them.

But it is though. It has information of the arcs beyond just the segments, it has centre, radius, start and end angle. The information is there.

Alan Fraser

But Thomas, that doesn't alter the basic problem of the arc not actually being and arc but a series of segments. Saying that SU knows the radius is pretty meaningless when you get different measurements for such a radius depending on whether you are measuring from the centre to a point or to an edge.
SU has no option but to offer offsets from the edges, not the points. Think of the confusion that would arise if you were to offset 1m from a rectilinear shape...only to find that the resulting 'path' was only 1m wide as measured by the diagonal from the corner.

Surely it would make much more sense to be demanding this kind of 2D operability within Layout, not the modeller? LO deals in true bezier curves; and would therefore offer true, accurate offsets... the results of which could be carried into SU. In fact you could not only have a decent Offset tool in layout, but a decent, parametric Contour tool also...one in which you could specify how many offsets you wanted, at what distance; and whether they were to be exterior or interior to the original curve.
All this could be then worked up in 3D in SU (with the necessary faceting compromise) while still remaining gemetrically accurate in Layout.
If they could figure some way of further increasing the communication between LO and SU so that LO acted as a geometrically accurate proxy for SU, even better.

I'm not saying that the Arc and Offset tools don't need more work in SU...they do...lots of it...especially when interior offsets (of rounded corners, for instance) turn themselves inside-out instead of just shrinking sensibly. However, that very feature requires SU to second-guess what your intentions are...and therefore become necessarily more complex. It is only in a very rare and specific instance that such interior offsets would be geometrically accurate and remain concentric. So actually demanding that such offsets do not turn themselves inside-out is asking SU to be geometrically inaccurate...exactly the opposite of what is being demanded in this thread. Things get complicated.

thomthom

@alan fraser said:

But Thomas, that doesn't alter the basic problem of the arc not actually being and arc but a series of segments. Saying that SU knows the radius is pretty meaningless when you get different measurements for such a radius depending on whether you are measuring from the centre to a point or to an edge.
SU has no option but to offer offsets from the edges, not the points. Think of the confusion that would arise if you were to offset 1m from a rectilinear shape...only to find that the resulting 'path' was only 1m wide as measured by the diagonal from the corner.

I fail to see why the arc can't be treated as the arc it represent - ignoring it's segmented presentation in SketchUp.

An 500mm radius arc is offset by 100, the result can easily be computed to an 600mm arc. Use the meta data of the arc entity to calculate the true geometric offset - then transform that result into the segmented representation SketchUp uses.

Alan Fraser

But as I said in an early post, there is a fundamental mismatch between the way SU draws arcs and circles and the way it draws offsets. It can only sensibly draw offsets perpendicularly edge to edge; but it calculates arcs and circles point to point or centre to point. If the Arc Tool could be persuaded to construct arcs with the measuremnt being made from a segment mid-point instead of an end point, then the problems associated with offset largely disappear...as in the diagram. Those are real offsets, not doctored concentric circles.
It does, however require that an arc begins and ends with a half-segment.

thomthom

What I had in mind was that SketchUp reconstruct the original arc instead of offsetting it's edges or points. Make ArcCurve entities special cases in the offsetting process. And that prevents any half length segments.

The problem as, as you say that things go wrong when the offset bases itself of the segmented abstraction of the arc. What I'm trying to get to is that offsetting the arc based on it's geometric properties (the metadata which SketchUp holds of the arc) then you get a correct offset.

Alan Fraser

Yes, I definitely think that copying the original is probably the easiest way to go. I think that's how TIG's script works also.
On the problem of interior offsets, I long ago gave up using the Offset Tool or even Follow Me (most of the time). The shape below was constructed by positioning a scaled copy of the outside shape then using Curviloft and tweaking the individual contours to give a rounded profile rather than the straight truncated pyramid. A workaround, I admit...but a heck of a lot quicker than using SU's standard tools, then having to clear up all the mess.
(Yes, I know there's Rounded Corners in 3D, but it's not always appropriate...and it too can give some nasty intersections)

thomthom

@alan fraser said:

Yes, I definitely think that copying the original is probably the easiest way to go. I think that's how TIG's script works also.

If it does -then Jeff, you mentioned not even that worked 100%?

However, the general consensus appear that both Offset and Follow Me can benefit from changes which would greatly improve our workflow.

SketchUp is inaccurate when it comes to Curves, due to it's nature of segmenting - but there should be room for improvement if it treated Arc and Circle entities are their true geometric origin instead of their segmented representation.

jeff hammond

re: a solution

i suppose the offset tool itself could be 'fixed' fairly easily..
as now, su appears to explode an arc prior to offsetting it therefore losing its inherent arc-like properties.. so they'd just have to stop that behavior and instead, when offsetting an arc, treat it more like the way we can move the bulge (a vertex) around when drawing an arc..

but-- that's a band aid and doesn't address the entire problem.. throughout this thread, i've been using the offset tool as an example because it's easier to talk about.. but things start getting really bad with the follow-me tool and other operations that create faces during offset like operations..

if you use follow me on a 24-segment-circle profile then a path with an arc in it and turn on hidden geometry… you'll see that you've effectively offset the profile path, incorrectly, 22 times (the top and bottom of the tube are correct.. they're the same as the path moved vertically with no offset)

and in that case, i don't think it's such an easy fix a only changing the offset tool..
(not sure if i'm making sense here.. didn't sleep much )

i imagine the devs know exactly the deal here and wouldn't need multi-page forum threads to point out the error.. they get it already.. they have to..

but when it comes down to an actual solution to the issue, i think it's on them to figure out the best way to solve the problem.. i think all we really need to do as users is try to get them to address and/or fix this behavior but when it comes to the actual programming and methods used to overcome this limitation, that's all on them.. keep it behind closed doors if they must.. i'd be totally ok with that.

i just wish the door wasn't closed at this point (i.e.- the 'what & why' stage.. the point prior to any sort of 'how' stage..) and they were willing to discuss with us publicly..