Opened 5 weeks ago
Last modified 6 days ago
#155 new enhancement
Vertical support for extended elevation
| Reported by: | Andrew | Owned by: | Olly Betts |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | cavern | Version: | |
| Keywords: | vertical, extended | Cc: |
Description
Therion, Topodroid and now Sexytopo now supports vertical in extended elevation. This is only the height change is used and no lateral displacement. One example use is for legs that go directly across a passage, usually when first entering from a side passage.
Currently if people use this function in ST or topodroid a valid correct espec file cannot be exported
Attachments (2)
Change History (5)
comment:1 by , 4 weeks ago
comment:2 by , 4 weeks ago
Yes that is clearer, thank you. I did not really understand in the thread.
My choice to use the word vertical is that it makes the leg vertical in the extended elevation. Also it is what Theron uses. I think it is explicit to the user. Even when used on a horizontal piece of passage, the command would make the leg vertical. While happy to find a better word it would be nice to have some consistency across packages (I know I'm a dreamer)
Maybe a solution is *evertical 2 3 and the software does towards and away automatically. however an option is allowed of towards and away so that the user can override
*evertical 2 3 towards
*evertical 2 3 away
comment:3 by , 6 days ago
My choice to use the word vertical is that it makes the leg vertical in the extended elevation.
Currently extended elevations aren't completely 2D - passage tubes and splays are rotated with the passage such that they extend out into the unseen third dimension (the view is locked to not be rotatable by aven, so this third dimension is always in/out of the screen, but handling them this way means that passage tubes render as we want without extra work, and so should 3d passage models based on splays once we have those.
Given this approach, folding a passage to be "towards"/"away" (or maybe "in"/"out" is better - they're shorter words and more clearly a pair of opposites) would be naturally handled by rotating it about a vertical axis to lie in the plane formed by "up" and this third dimension, keeping its original length and inclination. Then the view down a side passage folded to lead off on the far side of the main passage should render sensibly without special handling.
We should also be able to render a cut-away just by setting the near clipping plane at Z=0 (this is the computer graphics "Z", which is aligned in/out of the screen and is used to decide which polygons drawn in front/behind). Drawing side passages leading off on the near side (which would be probably be dashed on a drawn up survey) might be a bit trickier, but we could try something like drawing the cave a second time with the far clipping plane at Z=0 and as a stencil or wireframe view or something.
So the underlying reality here is not that the leg becomes vertical. This is currently mostly a hidden implementation detail, but there will at least be clues that third dimension exists in how things render, and it might be helpful to allow the user to actually view this third dimension more directly - e.g. it could provide a visual overview if you have layers of extended passages cross-linked by passages folded "vertical"/towards/away/in/out, and want to adjust which are drawn in front of which, or to allow selecting which one to set Z at for cutaway rendering.
You can see the existing "2.5D"-ness if you nobble the 0x80 byte after the string timestamp to be 0x00 with a hex editor - I'll attach an example (1623/101 from CUCC's Austria data) which was splay surveyed both with and without this nobbling.
by , 6 days ago
| Attachment: | 101_extend_unlocked.3d added |
|---|
1623/101 extended elevation with extended elevation flag turned off
There was a thread about this: https://lists.survex.com/pipermail/survex/2026q2/002531.html
As I said there, I think "vertical" is not a helpful name for this. A use case for it may be to avoid folding legs in a predominantly vertical section of cave, but it has other uses and for some of those it's helpful to be able to control whether it's folded towards or away from the viewer. Both have the same effect on the centre-line leg itself, but opposite effects on how splays should be handled.
I feel I didn't manage to explain this satisfactorily on the list though, which makes me worry I won't be able to in documentation.
Imagine the main passage goes across your point of view, and is cut away on the side nearest you (like how a drawn-up extended elevation might be. If the side passage is on the cut-away side, it's folded "towards". If it's on the other side, it's folded "away". The cross-section of the passage moves with the centre line as it's folded, so ends up flipped for one compared to the other.
So that's why I was suggesting there should be "towards" and "away" rather than "vertical". Does that make sense?
As I said before, picking "towards" vs "away" automatically is probably possible in most cases, but would be frustrating when it gets it wrong if there isn't a way to specify this. So perhaps best to make the choice explicit to start with.