Sketchup is Inacurrate???

thomthom · 17 Jan 2013, 08:53

The real question is why people like Tig, Thomthom, Fredo,and and and and ............... are able to create missing basic tools while Sketchup Team does not?
Aren't they paid for?

Remember that Google put quite some restraint on the development of SketchUp. Lets see where Trimble SketchUp goes.

thomthom · 17 Jan 2013, 09:02

@unknownuser said:

damn.. one more..

@desertraven said:

Maybe those SU dev's should consider hiring or at least inviting those "ruby wizzes" into their holy grounds along with some Pro Users that work for the money as a kind of conference. Closed doors for 2 weeks hard work to get this thing together.

yeah.. maybe..
but what really needs to happen.. if they want to get it on a more radical* approach.. is that in their office sit the ruby guy**.. shows up- rubies - goes home.. rubies some more..

he only has (or wants) his sub-project to mess with.. and his project isn't strictly within the main app.. sure, ruby will remain in the golden master but users can also download the module he's working with and install separately.. he has a lot more freedom on when he can release an update.. he'll have an official/possibly supported module that is released more infrequent but in between those releases a certain freedom/experimental/aggressive approach is allowed.. just from within my workflow, i know of rhino,indigo,grasshopper,&skindigo which do similar approaches (basically, open betas).. and it's great for the people(users) that choose to be involved + the official releases allow the less adventurous user to still gain the benefit of the module while not having to filter all the crap out of the inbetween phases themselves.. the official release has done the filtering for them..

that guy though isn't necessarily writing ruby all day long.. he's maintaining the environment & opening up new avenues in which the developers can function more freely in..

or something like that....

*this actually isn't very 'radical'..
** i don't feel sexist one bit for calling him a guy.. let's face it.. the dude is definitely going to be male..

Where do I apply?

@alan fraser said:

This thread seems to be getting a little lost.

We've turned pretty much all the stones, haven't we? Now we've moved on to the lounge area.

@unknownuser said:

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?

That is true - this goes back to the right tool for the right job. I guess why we keep getting back to these discussions is that we like SketchUp so much, have used it so much - so when it fails in one area we wish it was the right tool.

gilles · 17 Jan 2013, 09:33

@thomthom said:

we like SketchUp so much, have used it so much - so when it fails in one area we wish it was the right tool.

pilou · 17 Jan 2013, 10:19

SU is accurate for show an atomic plant!
SU is not yet accurate for calculate the reactor!

Alas temptation is inside!

Alan Fraser · 17 Jan 2013, 10:49

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.

Wo3Dan · 17 Jan 2013, 13:10

@alan fraser said:

........, all done in SU using only native tools. Do I get a cigar?
Alan, you won't be able to do this accurately with SU's native tools. Even increasing the number of segments to 1000 leaves a gap between two "circles"

You'll at least need trilateration.rb to get good results to do this.

Jeff, you may have misinterpreted my previous post, ("peace" stands).
I still think that the Offset tool does exactly what it is supposed to do, even with SU's arcs, (they are segmented) whether connected to edges or not. Changing the number of segments reproduces a different offset and a different mitter line at the end.

I'll go over your example once again (in this thread on page 6 or so).

noelwarr · 17 Jan 2013, 15:31

I wouldn't say SketchUp is a digital machine. Rather, it runs on one. Obviously floats and doubles have limited accuracy and indeed can cause all sorts of problems, especially in geometry. There are libraries that can work with arbitrary precision though. Checkout http://gmplib.org/ and its quotient class. It has no theoretical limit in accuracy.

Also, even though you can't create an infinitely long edge in SketchUp, Ruby does support the concept of infinity. Try 1/0.to_f

DesertRaven · 17 Jan 2013, 15:52

@alan fraser said:

This thread seems to be getting a little lost. .....he 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?

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.
As much as I appreciate your input I sure wish this thread could turn into something to access Sketchup's many shortcomings, elaborate on them and seek out how it could be done to the better.
Maybe, by chance this could be an inspiration for the developer and new owners of Sketchup.
If we, the users agree on certain issues, then maybe we are being taken serious and the Dev team sees it necessary to ally changes or improvements.
But as I said it is good to see issues from all sides.

Wo3Dan · 17 Jan 2013, 16:36

@noelwarr said:

... Obviously floats and doubles have limited accuracy and indeed can cause all sorts of problems, especially in geometry. .....
SU merges endpoints that are 0.0254mm (or less) apart. That is when within the same context.
I'm talking about a separation of about 0.167mm between circumferenses. It's no big deal when things (I mean buildings) get built. Far from that! But it's more than enough to cause errors in the model later on. You just need to know where to find them to fix them. Or much better, how to avoid them in the first place.

True construction circles wouldn't make this program that much heavier. They would not even make learning it any more difficult. But they will help quite a bit where it comes to accurate modeling.

Whereas true circles will make SketchUp an entirely different program.

jeff hammond · 17 Jan 2013, 16:55

@alan fraser said:

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

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.

yes alan, i see what you're saying.. but, it still offers nothing in the way of solving anything.. you can't use that midpoint of an arc's segment for any type of measuring and you can't place an extrusion profile there because it's no really on the arc.. the lines drawn between the arc's vertices have nothing to do with the actual arc other than visual reference..

@wo3dan said:

Jeff, you may have misinterpreted my previous post, ("peace" stands).
I still think that the Offset tool does exactly what it is supposed to do, even with SU's arcs, (they are segmented) whether connected to edges or not. Changing the number of segments reproduces a different offset and a different mitter line at the end.

I'll go over your example once again (in this thread on page 6 or so).

ok.. here is a different attempt at outlining the issue.. what i've done in this .skp, is manually draw a letter J (step-by-step.. real basic stuff and i know your skill level is way beyond this but i'm just trying to be clear in the example).. then, after i draw it manually, i do the same thing with the follow-me tool then show how the results are different..

draw_a_J.skp

the point of the drawing is that it shows two different results.. so either my manually drawn version is wrong -OR- the follow-me version is wrong.. they're not 'both wrong' and they're not 'both right'.. ONE is right - ONE is wrong.. you decide which one that is...

jeff hammond · 17 Jan 2013, 17:01

@noelwarr said:

I wouldn't say SketchUp is a digital machine. Rather, it runs on one. Obviously floats and doubles have limited accuracy and indeed can cause all sorts of problems, especially in geometry. There are libraries that can work with arbitrary precision though. Checkout http://gmplib.org/ and its quotient class. It has no theoretical limit in accuracy.

Also, even though you can't create an infinitely long edge in SketchUp, Ruby does support the concept of infinity. Try 1/0.to_f

see, i don't even care about any of that stuff (as in.. i don't even know what you're talking about )

i'm talking about what the user gets as a result from various tools... in the case of sketchup's accuracy, there are inaccuracies due to the way the geometry is being manipulated.. these aren't mathematical errors because "Ruby does support the concept of infinity" (or whatever).. they are programming errors..

if sketchup needs to round a vertex to one-billionth-of-a-hair in order for a face to form.. so be it.. that's fine..
but, that's not the problem here..

Alan Fraser · 17 Jan 2013, 17:02

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

jeff hammond · 17 Jan 2013, 17:06

@gilles said:

@thomthom said:

we like SketchUp so much, have used it so much - so when it fails in one area we wish it was the right tool.

Wo3Dan · 17 Jan 2013, 21:38

@unknownuser said:

ok.. ..... .. what i've done in this .skp, is manually draw a letter J (step-by-step.. real basic stuff and i know your skill level is way beyond this but i'm just trying to be clear in the example).. then, after i draw it manually, i do the same thing with the follow-me tool then show how the results are different..
....
the point of the drawing is that it shows two different results.. so either my manually drawn version is wrong -OR- the follow-me version is wrong.. they're not 'both wrong' and they're not 'both right'.. ONE is right - ONE is wrong.. you decide which one that is...

Thanks for making it so easy for me. Luckily I don't need decide anything. For your manually drawn J isn't according to what 'Offset' is about. The meaning of offset in SU (and in other programs that I know)is offsetting edges, not vertices. You offset to the point of where you offset infinitly short edges 0.0000000000000mm and "beyond" (true curves), but always edges. Now you introduce a totally different meaning of the operation, even unknown in other applications, for all I know.

Doing it manually means that you first decide the number of segments > the rotation angle per segment > construct the inner segmented line ("arc") > offset all segments outwards > extend the outer segments to intersect adjacent segments, all forming the outer "arc" > also intersection of first segment with the long edge > last segment has a perpendicular end (due to no connected edges)
If you fit this one on SU's offset, then it will fit.

Trogluddite · 17 Jan 2013, 22:22

@alan fraser said:

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

...but neither end point actually at the stated radius, only the middle ones.

You can play with this to get some interesting insights into the way that SU deals with curves. Afraid I'm not on my work machine, so no pics - but here's a little run-down of an experiment you might like to try.

Draw an arc with a nice grand curve - a half circle, say, with 12 segments.
Bisect one of the segments near the middle - chop it right in half at the point where the 'radius' is smallest.
Select one half of the chopped arc, and choose a small number of segments
And a large number for the other half.
Erase the stumps of the line that you used to chop the arc.
You now have a single arc with very uneven segments.
Look closely at the bit where the two sections join - eeek.
See how far you can shrink it with the offset tool before it gets, err, odd.

Similarly, you can show that if you change the segment count to even up the segment length after chopping a curve mid-segment, you'll still have 'off-radius' end points - and if you explode the arc and measure, you'll find that the end segment is not quite the same length as all the others

Just a rather contrived illustration that the lines are being offset, not the arc's 'parameters', of course - I offer it more as a curiosity than a judgement of SU.

I do think, though, that Jeff made a good point about this being a problem of expectations. We may know that it is the lines that get offset, but once you decide to call something an 'arc' or a 'circle', it is not surprising that users expect them to exhibit the behaviour associated with those categories of objects.

The "line offset" tool is a very good, and accurate, "line offset" tool - what is really being requested is a different tool, not a more accurate one.

Wo3Dan · 17 Jan 2013, 22:22

And Jeff, even the 'Follow Me' tool is consistant when applied on a series of connected coplanar edges. It's just a different, now 3D way of creating an offset. If you delete the third dimension's geometry, it will fit on what the offset does.

b.t.w. You could do your J with the arc tool in a few seconds.
The arc tool acceps (during the operation) changing the number of segments (s), the chord length ((units)) and the bulge ((units)) or the radius ((units)r). (Units) is optional, needed when not according to current settings.
So what IS the problem.
You want a tool that lets you "offset" a series of edges and "arcs" (in one go) where edges and "arcs" act differently in the same operation. This requires a different tool that spits the entities by property. It could be integrated but IS a special, not according to offset's rules, operation. I remember your previous example with the first "curve"-stud parallel to the last "edge"-stud and a consistant shell width of the bottom plate. Special cases!

jeff hammond · 17 Jan 2013, 22:27

@wo3dan said:

For your manually drawn J isn't according to what 'Offset' is about. The meaning of offset in SU (and in other programs that I know)is offsetting edges, not vertices.

gerrit
it sounds as if you've learned geometry from sketchup... instead of in school (or where_ever) then bringing that knowledge into sketchup..

(on a side note, this is a point where i really (really) wish jbacus or another su official* would comment on the topic.. like i've been implying, he knows exactly what i'm talking about.. he absolutely has to.. much of the thread is simply trying to point out that there is an error occurring and i think if someone more official than me gave a statement, then more people (everybody?) would be less likely to defend the app and re_go through some of the example files with a fresh mind to see and understand the error themselves..) (*or some other definitive source where this part of the discussion can be cleared up)

regarding "The meaning of offset in SU is offsetting edges, not vertices."..... i'm no programer but there are some in this thread (tt?) that could clear this up.. when moving geometry around etc, i'm willing to bet at the root, sketchup actually never moves edges around.. it moves vertices.. if it moves an line, it's in fact moving the two end points of that line..

if you draw an edge, you click on the start and endpoints of that line.. it's ALL about the vertices.. when sketchup offsets a square, it boils down to moving the cornerpoints around.. (maybe not the case with guidelines which are infinitive? but even then, points and not lines are being used to define it's placement)

and, believe it or not, the math behind measuring/transforming/etc the points defining an arc are different than the points defining straight edges.. in many ways, sketchup recognizes the real math of an arc (bullet list a few pages back outlining some of these ways).. it's not totally dumb and it doesn't always treat the points defining an arc in the same manner it treats the points defining a collection of edges.. but, sometimes, it does.. which is a pretty major error..

Wo3Dan · 17 Jan 2013, 22:33

Jeff, I'll get back to you tomorrow. Disagreeing with you.

Alan Fraser · 17 Jan 2013, 22:37

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.

jeff hammond · 17 Jan 2013, 22:54

@wo3dan said:

So what IS the problem.

for absolute starters.. i can't even do this in sketchup:

and that's a super basic example.. there are potentially hundreds of other things that need to happen after a step like this but this step breaks any possibility of doing much more afterwards.. it's crap geometry..