Sketchup is Inacurrate???
-
@wo3dan said:
First of all I can't get Entity Info to show the (any) arc's length with that number of digits in decimals. Probably my fault, I was pretty sure it could be done.
strange find.. on mac, the length precision coincides with the model precision..
[edit-- checked it out in mm as well.. that works too on mac.. this is the R500mm @165º arc..
-
What is this prodigy ?
Unity in mm enable
On PC we have just ~1439.90mm even maxi precision decimal asked!
-
@desertraven said:
Well your logic explains what happens through SU, but that does not make the end result a logic conclusion. And if the Joint push pull does the same thing then it needs fixing too.
Edit: I'm glad you are agreeing on the misleading part. Here another example how misleading this tool is: The arch and the 2 lines were offset in one go so they were all 3 selected the result speaks for it's self.
I don't know how much more clearly I can put it; It's not my logic...it's just logic...the logical consequence of offsetting faces, not endpoints. The discrepancy shown in your illustration is the very logical consequence of offsetting a segment normal and not the end point. As long as arcs are measured based on centres and vertices, yet offsets are calculated from edge perpendiculars, that's going to be the result. They are fundamentally incompatible...which is why SU needs to treat arcs differently when offsetting.
It is misleading only in as much as many people might expect the rationale behind arc construction to be carried forward into offsetting...but it isn't.Fredo's JPP does not need fixing. It works exactly as any reasonable person would expect it to work. What do you propose Push/Pulling if not faces...remembering that there are only faces once you have entered 3D? My whole point in mentioning it was to illustrate that the Offset Tool, in it's present form, is actually an Extrude Tool...but working in 2D.
-
@unknownuser said:
@me said:
My $1 calculator(*) reveals 1439.98966329mm.
hum hum first number after the decimal point?
1439.8966322 mm mine ...You are right, my result has a typo
. (lack of coffee?)
It should have been typed as: 1439.8966329mm -
@Wo3Dan
Cool! Else that was meaning that the plugin should to be rewrited !
-
@unknownuser said:
Unity in mm enable
On PC we have just ~1439.90mm even maxi precision decimal asked!Seems to be more complex than that...
Precision of arcs entity info does not seem to change when edited in "model info" - lines etc. are OK, precision changes immediately, but for arcs you need to close and re-open the file. So maybe 0.00 precision is what is loaded into your default template - and gets 'stuck' until the file is saved.
This seems a very consistent and repeatable bug - I can easily make the opposite effect of arcs showing more precision than other entities by changing/saving/loading. -
@unknownuser said:
What is this prodigy ?
Unity in mm enable
On PC we have just ~1439.90mm even maxi precision decimal asked!Anyone with the PC version of SketchUp (whether free and pro) seeing arc lengths displayed in 'Entity Info' with more precision than one decimal digit?
In SU7 there's no problem: the decimals correspond the precision that is set. Not in SketchUp 8, neigther the Dutch free version (latest) nor the English pro version (8.011752)
-
@unknownuser said:
In SU7 there's no problem: the decimals correspond the precision that is set. Not in SketchUp 8, neigther the Dutch free version (latest) nor the English pro version (8.011752)
I am in free V7 or free V6 here
And that works with the trick of save / Exit / reload!
So for the V8 seems that is a bug ? -
@trogluddite said:
......Precision of arcs entity info does not seem to change when edited in "model info" - lines etc. are OK, precision changes immediately, but for arcs you need to close and re-open the file. ........
Thanks for clearing that up. I was almost certain that I'd seen more precision before. But couldn't seem to get it back.
In SU7 shown arc's length precision changes immediately after changing the settings!
Edit: In SU7 it's okay only starting from a loaded file with heighest precision. Just like you both explained. I didn't notice this before, since most of my saved (thus later loaded) files include the heighest settings to begin with. -
Win7 64bit
SU7: 1 decimal digit for Arc lengths.
SU8: 0 decimal digits for Arc lengths.I cannot seem to be able to change it. :s
-
Yep! That's the trick!
(So PC = MAC)
And I can change the number of segments!
Of course no more than 6 decimals so rounding result!
it's not so bad!
Here with free V7
-
@thomthom said:
Win7 64bit
SU7: 1 decimal digit for Arc lengths.
SU8: 0 decimal digits for Arc lengths.I cannot seem to be able to change it. :s
Not even when starting with a template that has set units precision to more digits?
Or (same thing) when loading a file saved with precision with more digits? -
@wo3dan said:
Or (same thing) when loading a file saved with precision with more digits?
Did this - set my model to maximum decimal digits, closed and reopened the model.
What template can I try?
-
@thomthom said:
@wo3dan said:
Or (same thing) when loading a file saved with precision with more digits?
Did this - set my model to maximum decimal digits, closed and reopened the model.
What template can I try?
The one that you (or better, SU) currently use(s). What if you re-new that template, but this time with precision set to max. Be sure to make it the default one. What happens then.
For me both methods (loading file including its saved precision / start with correct template) work for me in SU7. I still have to try in SU8, but I'm almost convinced that I have seen correct display of arc lengths in SU8 in the past. -
just chiming in to say that, on mac, there's no tricky steps to take to get those boxes to update.. change the units in model info and they update accordingly in entity info.. as you'd expect should happen.. so yeah, there's something wrong on the windows side of things pertaining to this.
and i fear, out of all of this discussion, this will be the only thing that gets fixed
-
I support improvements for arcs and circles, wholeheartedly, and thank Jeff for his diligent pursuit of enhancement.
On reading this entire thread, yet again, I believe there is a solution available.
Create a new tool by exposing, existing, functionality of arcs and circles and cardinal points.
Each know where there centre point lay, both know there own radius, and are capable of changing the number of sides after an initial commit. So, iff...
one: show the radial vectors and the centre point and use the end vectors as a handles for radial positioning (dividing the arc segments to fit between two, user selected, end points [with inference?])
two: when 'scaling' an arc from either end, allow a modifier key to scale from arc centre point (like a full circle does)
three: scale a copy from centre point, as a bonus modifier key...then we could at least draw them quicker.
leave the rest alone... for now!john
-
So here is another annoying short cumming of Sketchup.
I know the follow me tool is not supposed to be a real revolve tool, but why can't this be made to work to create a geometry one would expect?
result?!
To me this also defies any logic in an alleged simple to learn design software.
@unknownuser said:
@ Jeff, there's something wrong on the windows side of things pertaining to this.
No there isn't, on windows entity info shows the correct units and digits.
-
@desertraven said:
So here is another annoying short cumming of Sketchup.
that's the same error.. there are lots of ways to see it (though this way makes it pretty obvious
) -
The affects of an Arc path's segment's angle to the face to be extruded with native FollowMe have been discussed many times over...
Here are the three variants.
An Arc path that does not have its start segment perpendicular to the face: radius sized base, but odd start/end facets.
An Arc path that does have its start [half] segment perpendicular to the face: non-radius sized base, half start/end facets.
EEbyLathe, which produces the desired result: radius sized base, all full facets matching Arc's segmentation etc...
-
I'm not really understanding what the 'error' is in Olav's example. The path appears to be set up to produce two very short, on-axis side segments, joined by a 4 segment arc. Isn't this exactly what Follow Me has done?
I hate to sound like I'm defending SU yet again, but the quadrant below was produced in a single action (using Loft junctions along 2 paths).
You can't realistically expect SU to guess your intentions. If you want a quadrant with two end profiles sharing a common centre of rotation and at right angles to each other, then draw them that way; don't provide SU with a path with which it doesn't stand a cat-in-hells chance of achieving your aim and expect it to magically solve your geometry errors for you.
The same goes for drawing an extrude path using a simple arc...like when you round off the corner of a rectangle, In that situation, neither end segment will be on axis...so you can't realistically expect the resulting end profiles to be either.I'm not saying that the devs or a Ruby scripter couldn't produce a specific tool for producing such a quadrant (leaving the default extrude action exactly how it is...which works perfectly well in most cases) But there are plenty of ways of achieving the same result at present, including the plugin I used, which took little longer than using Follow me.
Advertisement