Sketchup is Inacurrate???
-
right rich.. the cardinal point scales an arc and that's all that needs to happen when offsetting one..
(the resulting geometry needs to remain an arc and the central angle needs to stay the same so basically, the only thing you can do to change it's size without breaking it's inherent properties is scale it)
[EDIT] but that does bring up a good example of what should be happening..
draw a 90º arc whose endpoints are on the red axis and the green one.. using the scale tool, grab the handle opposite of the arc's center point and scale it.. that's offsetting of an arc.[/edit][edit2] oops.. cardinal points change the bulge of an arc.. it's when you put the move tool on the ends of an arc which scales it..
-
@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. -
@alan fraser said:
@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.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.
-
@Wo3Dan
Rhino and its Length command and it gives a result of:Command: Length
Length = 1439.8966 millimetersSo that seems to agree with MoI.
The formula for the circumference of a circle is 2 * PI * radius = circumference.
The 2 * PI is for a full circle, for an arc you replace this with the angle of the arc in radians. 165 in radians is 165 * PI / 180.
So the full formula is: (165 * PI / 180) * 500 =
On my calculator here that yields: **1439.8**966328953219009620448840031 mm
@unknownuser said:
My $1 calculator(*) reveals 1439.**9**8966329mm.
So what has your calculator with the first number after the decimal point?
Or do we not calculate the same thing ?
-
@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
Advertisement