-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Projected Profiles For Scrap Types #186
Comments
I've put some testing on the (partial?) implementation of this in 26b1b98 through 19db0c4. Thus far it seems to work well. however, 1) the UI is less-than-intuitive (I don't know how to fix that other than documentation; I figured it out eventually), and 2) it would be nice if it guessed projection plane based on shots. |
I'm currently working on a blog post and video now. The biggest issue is the the user currently has to select a valid azimuth for the profile. Do you remember what you tried first, because that's usually most intuitive approach. It's a good idea, if CaveWhere could automatically guess the profile plane's azimuth. |
I thought L->R or R->L would end up being the most sane, but quickly figured out it was easiest to just manipulate the 3d viewer to set view az to what I recalled the cross-section as being, and then plugging that in to "looking at"; starting from the shot azimuth may work just as well. It's also a little harder to get reasonable results, since guessing up and scale doesn't work as predictably as in profile or plan; it was mostly a matter of trial and error. |
I basically need to write an algorithm that quickly iterates through azimuths and choose the best azimuth by minimizing the error. The example above, the correct answer is azimuth 135 degrees. |
I think the only case, where this algorithm would fail, is if projected profile is UP or DOWN shot. Then the projection plan could be any azimuth. |
I gave it a quick spin with some data I had with 2-4 stations in the cross section: usually it ended up off by 40° (for all "orientations" of l-r, r-l, and "looking at"). This may be a consequence of the sketches not being accurately to scale; I'll give it a go with some constructed data. |
The algorithm tries to minimize the variance in the rotation, so the length
of the shots don't matter as much as the direction of the shots. I was
actually thinking about adding the per shot variances as an output so users
could see how sketched-to-scale the sketch is. Then CaveWhere could make a
database of good sketchers vs bad sketchers (hahaha).
…On Tue, Dec 8, 2020 at 3:19 PM echarlie ***@***.***> wrote:
I gave it a quick spin with some data I had with 2-4 stations in the cross
section: usually it ended up off by 40° (for all "orientations" of l-r,
r-l, and "looking at"). This may be a consequence of the sketches not being
accurately to scale; I'll give it a go with some constructed data.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#186 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKKDA3FC5ZUJZRHH4X2QXLST2C35ANCNFSM4R7V53EQ>
.
|
c.f. Bristol's comment about "prolific sketchers who don't use protractors"... This was mostly for near-horizontal shots and stations practically in-plane with each other: what should be almost perfect conditions. So I was surprised. |
Do you think it's better than not trying to find it the azimuth automatically? |
It would be nice to support Projected Profiles. This would enable cross-sections and other Projected Profiles in CaveWhere. This is the same warping algorithm as plan, but the view is different.
The text was updated successfully, but these errors were encountered: