Mini-challenge
-
The last Fredo method (some simple indeed) without plug gives with apparently no problem of top tangency vertices
1.3239127 Nurbs (height of brace cut vertically) Pilars are 1 * 1 * 10 , brace 1 * 1 * x : unity meter
1.323908 SU13.2391273 Nurbs (length of brace between the pilars)
13.239127 SU14.1421356 Nurbs diagonal
14.142136 Su
Does this acceptable ? Accurate or not?
PS
(i don't reload the Fredo's file due V8 against V6 So remake my own version of Fredo's Method! 
-
@unknownuser said:
[edit] and really? you're building ziplines that high? looks fun.
Jeff,
I composed a longer/detailed reply...........but? I got timed out I guess.So, in short........yes........towers for the ZL are high here (~90' AFG)..because the grade is relatively flat like pancake. (contours @ 1' intervals are typical).
Attached screenshot depicts my participation in the project. (plan/execute pre assembly components @ grade)...............hoist by crane to place.
Beast,
Charlie
-
@unknownuser said:
The last Fredo method (some simple indeed) without plug gives with apparently no problem of top tangency vertices
Unfortunately, although the method is mathematically correct, it suffers from the lack of precision of Sketchup for rotation and parallelism of guides (even with circles of 512 segments).
One way to check that is to split the right post and the board and check the intersectio. As shown in the video, it may not be clean in certain cases.
So you need an extra step, with the Move tool, to adjust the intersection. You can do this step accurately because the SU Move tools inferences differently the intersection points (cross) and the endpoints (circular dot).
Strangely, Ruby does not suffer this inaccuracy issue and gives a correct intersection, although the FredoScale Rotate script uses the same method (i.e. calculate the offset angle and substract it to the rotation angle).
Fredo
-
This mini challenge gave me an interesting idea. Thanks Jeff.
I will introduce an option in FredoScale for the tools using rotation, in particular the Free Rotate tool (but also Twist and Rotate in Box).
Basically, after you define the plan of rotation and base direction, you will click an extra target point anywhere in the model. This target point, and actually the parallel to the base direction passing through this point will be used as inference guide instead of the base direction.As I did not want to make a separate tool, the convention is that when you click the point for the base direction, you release after 1 second (kind of long click). Then you'll have the opportunity to click the target point as a red cross (in the Fee Rotate tool, you can also toggle this function via Ctrl Alone).
Indeed this is a plugin solution to the challenge, but I am not sure there is a pure geometrical solution with just the native standard SU Tools.
If you wish to try in advance of releasing, just drop the file Lib6Protractor.rb attached to this post into the LIBFREDO6_Dir_44 folder.
Fredo
-
For info, I just published the script updates for supporting the two problems featured in this mini challenge. See this post for detail and video.
This comes in FredoScale, but you just need to download LibFredo6 4.5a.
Fredo
-
You are a crazy man, Fredo!!!!!
-
Yep!
Classieux!
And no problem in the Big Zoom!1.3239127 Nurbs (height of brace cut vertically) Pilars are 1 * 1 * 10 , brace 1 * 1 * x : unity meter
1.323913m SU -
Bravo Fredo..............Bravo!
Thanks lots,
Charlie
-
.
2014 bump
.
-
-
-
Oh. By using the new Arc tool.
-
@dave r said:
Oh. By using the new Arc tool.
right. we finally have a way to natively get a rotated snap point.
next step, incorporate the same inferencing into the rotate tool
(but just having it in the arc tool is fine by me.. I've been wishing for it since maybe 2004 ) -
-
@jeff hammond said:
@dave r said:
Oh. By using the new Arc tool.
right. we finally have a way to natively get a rotated snap point. ...
Is it really that accurate? I can't get it to work. If I zoom in I can still see a new endpoint (second end of arc) not being on the edge inside a group I "rotated" to(=pulled the arc to.
-
@wo3dan said:
@jeff hammond said:
@dave r said:
Oh. By using the new Arc tool.
right. we finally have a way to natively get a rotated snap point. ...
Is it really that accurate? I can't get it to work. If I zoom in I can still see a new endpoint (second end of arc) not being on the edge inside a group I "rotated" to(=pulled the arc to).
-
@wo3dan said:
@jeff hammond said:
@dave r said:
Oh. By using the new Arc tool.
right. we finally have a way to natively get a rotated snap point. ...
Is it really that accurate? I can't get it to work. If I zoom in I can still see a new endpoint (second end of arc) not being on the edge inside a group I "rotated" to(=pulled the arc to.
as far as i can tell, it's completely accurate.. in this case, i tested it like this:
... then rotated the bottom board from the arc end point to the arc start point using the same center point..
everything appears to line up perfectly for me.. -
I am surprised because SU can't draw real arcs.
-
@pbacot said:
I am surprised because SU can't draw real arcs.
the arcs are the same as before. it's just that you can now get a snap at an intersection while creating the arc.
-
@jeff hammond said:
...
the arcs are the same as before. it's just that you can now get a snap at an intersection while creating the arc.The arc tool hasn't changed at all, it still doen't snap to edges, only to endpoints (say A), intersections (say A)etc. To indicate that the arc ends on a (virtual) line from certer to A.
The tool may indicate that you slide the cursor on an edge. But when zooming in, the resulting endpoint that the arc creates isn't on the edge that it is supposed to snap to. Unfortunately!
Advertisement