Sketchup is Inacurrate???
-
@unknownuser said:
@alan fraser said:
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?
i'll give you that
i mean, you're right, if the circles in your model are infact accurate (proper radius.. proper x/y centerpoint) then i t....seriously, if you guys (suteam) do not want to do the stuff requested in this thread to your app.. that's ok.. hook these boys up with some more ruby access.. set them up with a little vending machine.. there are obviously people that are willing and able to make workarounds.. as is now, it's often "whelp.. here goes another workaround".. but with the right developer access, and an ideal of more uniformity, they can make truly legit workarounds.. to where it doesn't feel the slightest bit workaroundy..
thank youMaybe 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.
-
something i started typing earlier.. i'll post it then maybe lay off this subject for a while.. at this point, it's just me
ing out thought trains at you poor guys 
i'm pretty sure i said all there is i have to say so now its just me trying to re-word the same stuff as if someone will magically appear with some answers... if i say it in the right way..
@unknownuser said:
in under 12 seconds..
@unknownuser said:
8 secondes with Moi but with a little training!
damn.. i have to keep practicing!
but this brings up a point as to why i'm even here participating in this thread or any sort of sketchup wish discussion..
if sketchup could draw those 4 circles like that, i could do it in 3 seconds... with my eyes closed.. (please let me exaggerate every now and then :wlnk: and no, not because su is so 'easy to use'.. it's because ive spent a helluvalotta time learning and using it..
i so want sketchup to be more [theres a word for this.. i just don't know what it is]
i know the damn app almost better than the back of my hand.. (but the reason i know the back of my hand so well is because all of the time they've spent on the keyboard/mouse using sketchup)
..and i know it can be more progressive.. not "oh, that would be cool if they..." ..more like "this is the exact right app in this world right now to really go for something".. and if you don't do that, it's done.. it is.. maybe not right this minute but...and there are other apps out there.. app~~-s-~~ that I'm getting proficient in.. so it's not like i'm sitting around bitching&moaning while not seeking out an actual solution.. i have a solution.. you know?
i guess it's more of a last ditch effort to get some real truth about the future of this app.. if it continues along the same path it's been going since su4 then
<puttered out around here...> good night
-
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.. -
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?
-
@gilles said:
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.
-
@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.
-
@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.
-
SU is accurate for show an atomic plant!
SU is not yet accurate for calculate the reactor!
Alas temptation is inside!
-
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. -
@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).
-
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 -
@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. -
@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.
-
@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..
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...
-
@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_fsee, 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.. -
@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.
-
-
@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. -
@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.
-
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!
Advertisement