Here is something that could be very useful to SU users who have to set out structures on plan or produce site plans from site measurements.
The standard method to establish where a point is on plan is to triangulate from a line of known position and length. On a drawing board, you would use a compass to create two arcs and their intersection would give the point you want. Doing this in native SU is problematic because arcs are not true. This can be overcome to some extent by increasing the number of sides the arcs have, but it is still only an approximation.
I use @slbaumgartnerās extension SB Circle Intersect for better accuracy. That places construction points at the two intersections. However, they can be hard to see without zooming right in as they tend to be very close to the arcs themselves. So how about the following as a refinement?
Instead of drawing the arcs, you first invoke the extension. Then you select the centre-point of the first arc and input its radius. Then you do the same for the second arc. No arcs are actually drawn. Instead, a construction line with construction points at both ends is drawn between the two intersections. Now itās easy to see and you can easily start drawing from whichever end of the temporary construction line you need.
I realize that this only works for arcs and that it would be complicated if they werenāt on a flat plane. Circle Intersect allows more flexibility in that respect. However, I suspect that the situation of two arcs on a flat plane is by far the commonest.
@simoncbevans Iām a bit confused by your post. My uncertainty comes from your phrase
What extension?
I think you are proposing a new extension (or a modification of my SB Circle Intersect) that works as you describe? It wouldnāt be hard for me to add a cline between the points my extension finds. Would that provide enough to address your concern about visibility of the construction points?
I can see how not actually creating the arcs or circles would streamline the workflow, eliminating several extra steps when your goal is purely triangulation and the arcs/circles are ultimately irrelevant.
However, working from theoretical but non-drawn arcs or circles would be much more complex because the extension would have to reproduce much of the inference logic currently provided by the built-in circle and arc Tools - in particular figuring out what plane each arc/circle should use. It isnāt possible to deduce the plane from just a center point and radius. The existing Tools use inference in ways that might not be simple to reproduce using the Ruby API. Maybe just arrow-key based locks to primary axes?
As to non-coplanar arcs, I looked into that while writing my extension and concluded that the use case was unusual enough that it wasnāt worth the effort to cover the substantial increase in complexity of the 3D geometry vs 2D for coplanar. So far nobody has complained or requested the full 3D logic.
Yes, although visibility of intersection points is also part of the goal.
No, indeed, hence my point about complexity if arcs were not on a flat plane. But the majority of the time, they would be. My idea was that there would either be a new extension dedicated to 2D triangulation or your (very useful) Circle Intersect could have additional functionality to enable what I propose.
Of course, all this would be rendered obsolete if my other post today about selecting inferencing were taken up.
Yeah, if you could restrict inferencing to just cpoints it would be easier to use the existing Circle Intersect. However, since none of us know how complicated the inference engine code is or how far its tendrils extend into other parts of SketchUp, I wouldnāt hold my breath waiting for this feature. Plus, youād still need to draw and later erase the arcs or circles unless they were actually needed by your model.
Hereās an idea Iāve been pondering since my last post: what if the extension required the user to first select an existing face to provide the plane? The subsequent center points and (undrawn, theoretical) circles would then be required to lie on the selected plane. I think that wouldnāt be too hard to implement.
Brilliant! That would mean you donāt have to be tied to using a flat plane. Makes it more flexible at the small expense of having to select the relevant plane (or create one if it didnāt already exist).
True. This was one of the things I was hoping to avoid by my OP. Inputting cpoints and radii avoids the need for any arcs to show at all.
Iām tied up prepping to leave for vacation tomorrow, so time is tight - it may be a couple of days before I get time - but yes iāll take a run at it.
I have installed that extension and it does seem to work. In the test I did, it gave four options for the location of the intersection. I guess that is because it is faster and simpler than trying to narrow it down to the right one by having to input other data.
Trilateration uses only distances, triangulation uses distances and angles.
In trilateration, you only measure distances, no angles are measured. This is how GPS positioning works.
Iām not a surveyor but I suppose you could do a survey either way. Iād always assumed they did triangulation using the protractor on the base of a dumpy level to get the angles.
Thanks for clarifying that. As a surveyor, I probably should have known the distinction. However, I am a building surveyor not a land surveyor. Thatās my excuse and I am sticking to it!
I do use levels a step up form a dumpy but I have never used a theodolite. It would be difficult to use an ordinary level to measure angles with any great accuracy but I believe theodolites are another matter. They can measure points in 3D and presumably do that with a combination of horizontal angles, inclination angles, and distance measurement.
Most of what I do just involves distance measurement, so trilateration presumably describes that whereas a theodolite would be using triangulation. Mind you, I have never heard a surveyor here in the UK use the term trilateration - even land surveyors!
Another option is the āTrue Intersectionsā feature in TIGās TrueTangents v3.0
Native true arc intersections would be a worthwhile goal for SketchUp development.
It stands to reason 21st century software should be capable of a task accomplished for centuries with far simpler tools.
I couldnāt agree with you more. Itās such an obvious omission.
I have tried that out and it works very similarly to Circle Intersect. But it suffers from the same problem of having to start with geometry (that may only be temporary) and forcing you to zoom in to find the cpoint.
I wonder whether there could be another answer to this. I appreciate why circles and arcs in SU cannot be true, but what about construction lines? Would it be possible to have circular construction lines and then have true intersections to click on? This has come up before, such as here. Also @DanRathbun wrote in another post that they have been requested from SU before.
I think itās a matter of logical order.
The arc entities must exist before one can execute the math determining their point of intersection.
Iāve used Burās Trilateration for years, then TIGās True Tangents. Both can create a lot of extra guides. @slbaumgartnerās elegant Circle Intersect does the job quickly, without all the clutter.
The time it takes to navigate to the guide point depends upon technique.
Scroll wheel zooming is OK, but certainly not the fastest way to get from A to B and back.
Zoom Window, Zoom Selection, Zoom Extents and Previous position the camera instantaniously.
Creating easy to reach shortcuts for them speeds navigation.
And maybe some additional scenes of where to expect intersection(s).
Although I would prefer true guide circles and true guide arcs
They would be entities on on their own, not creating any new geometry. But ādue toā true intersections with same type or with real geometry it would solve many problems, eliminating all these workarounds with temporary intersection āPieā arcs and plugins on the subject.
In the meantime, while a useful ruby to do your trilateration surveying is being developed please give SolveSpace - Download a try.
-Start with drawing a single line, dimension it, change this dimension into the value you wont it to have.
The line will scale automatically
-now approximately sketch the rest of your floor plan to scale.
-Triangulate this face ( for accuracy) into as blund as possible triangles.
-Now dimension all remaining lines, change the dimension to the wright ones as you go.
-Export the file as DXF ,and import into Sketchup
For anyone following this topic who is interested, I have added a beta trilateration tool to my circle intersect extension. It does not require drawing circles or arcs and adds only guide points and guide lines to the model. If you are interested in testing it, please let me know.
Just to add to Steveās post, the new element in his extension works exactly as described in the OP. Itās really easy to use and will surely make drawing up surveys in SU a whole lot easier.
