Re: [Therion] Loch giving strange artifacts
I managed to compile myself[*] but still get the same results. If you don't get such errors i strongly presume that this is a problem either in the underlying libs but i think more probable an issue with my graphics card and/or linux driver. Currently i run the following setup: - Linux phobos 4.9.0-2-686-pae #1 SMP Debian 4.9.13-1 (2017-02-27) i686 GNU/Linux - Debian GNU/Linux 9 (debian stretch / testing) - lxde/openbox on Xorg - Therion from GIT (commit ca1aa8f1b7b4760b9; Fri Mar 31 21:06:03); compiled against VTK 6.3.0 - old Fjitsu-Siemens Amilo Xa2528 - with an GeForce 8600M GS viedo card - running on noveau drivers On my stationary PC i cannot test this as loch hangs up itself (probably an issue with the proprietary nvidia drivers i run there) [*] @wookey: at debian jessie i had some strange dependency problem with some dependant libs of other libs, probably caused by some older mixing of stable/testing; just wanted you to know in case you want to dig into it. I upgraded to debian stretch, where i could install all libs and compile without trouble) Am 2017-03-31 22:46, schrieb Benedikt Hallinger: Hello, sorry for not responding a while, i tried to debug this myself. Unfortunately i was not able to detect an error in my data. The compile gives no warning at all and also the pdf map output looks like expected. Fortunately i was able to reproduce it in a very simple dataset (with therion 5.3.15 on debian). Please see the attached archive. It does even happen when: - the data is contained in one single centerline only - the break in the map is commented out - no map definition is present at all - all in parallel Is this a bug with loch? With best regards, Beni Am 2017-03-27 10:55, schrieb Footleg: Possibly your walls are inside out. Do the walls appear and vanish as you rotate the model? That is a sure sign some of your scrap boundaries are not right. Common causes are the insides of loops not flagged as outline in, or walls which cross other walls. Footleg On Fri, Mar 24, 2017 at 3:34 PM Benedikt Hallinger via Therion wrote: Hello, in my loch model i get some strange artefacts. It seems that the further-away objects are rendered in front of the nearer-in-front objects. I would expect that the passages far away would be covered by those in the front of the camera (as is the case where i did not yet have scraps and only the centerline is present... look at the screenshot) What am i doing wrong?___ Therion mailing list Therion@speleo.sk [1] https://mailman.speleo.sk/listinfo/therion [2] Links: -- [1] mailto:Therion@speleo.sk [2] https://mailman.speleo.sk/listinfo/therion [3] mailto:therion@speleo.sk <> ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] cavern exit code 256
Hello, when compiling my project, i get an cavern error: therion: warning -- cavern exit code -- 256 Everything seems to be fine in the map, but what does this exit code mean? ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] cavern exit code 256
I found it, the following error is reported by cavern: ### cavern log file 1> Survex 1.2.30 2> Copyright © 1990-2016 Olly Betts 3> /tmp/th24737/data.svx:113:47: Fehler: Standardabweichung muss positiv sein 4> *fix 1 --.-- --.-- ---.-- 0.00 0.00 0.00 5> ^~~~ The source giving causing it is: fix 1.0 x y z 0 0 0 If i remove the standard-deviation zeros, cavern stops to complain. The reason was that the entrance location was measured by public service against official grid by theodolite and as such is "perfectly correct". How can i give this information? Am i forced to use some minimal positive fraction? (eg. "0.1"?) If yes, could this be an cavern bug? Am 2017-04-02 12:53, schrieb Benedikt Hallinger: Hello, when compiling my project, i get an cavern error: therion: warning -- cavern exit code -- 256 Everything seems to be fine in the map, but what does this exit code mean? ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Aven colour by loop error
On Sat, Apr 01, 2017 at 09:10:02PM +1300, Bruce Mutton via Therion wrote: > The new capability of exporting loop closure information to 3d format is > helping to identify the bad loops on our surveys. > > Very nice. > > However the scalebar at the top right seems to be locked into a range of 0.0 > to 12.0 (%) error. Aven's error scale isn't in %, but rather in "sigmas" - i.e. it's how many times the expected error the observed error is. Assuming normal distribution of errors (which sums of random errors will tend towards) anything more than 3 is only 0.3% likely by random errors, so highly suspect: https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule If what Stacho said back in February is still true, therion outputs the wrong data in this field in the 3d file, so you actually see "2 * relative error of a loop" there, by which I think he means percentage misclosure. But as I said at the time, percentage misclosure isn't really a useful measure of loop quality because the threshold of what is reasonable varies with the length of the loop: https://mailman.speleo.sk/pipermail/therion/2017-February/006300.html > This is OK for our really nasty loop closures; the maps look suitably > colourful, but some of our more recent cave surveys don't have error much > more than 1.5%, so the picture is kind of shades of blue, as below. It > doesn't help with visualising the relative quality of the loops. Unless Stacho has since fixed this, you're actually seeing 0-6% there currently. > Would it be possible to change the default scalebar to something like 0.0 to > 2.0, with the upper limit stepping upwards to suit the data, if there are > larger loop errors? I'd much rather we fixed therion to export the correct error information. Trying to colour based on percentage error just seems to be fundamentally a less helpful approach. Also, not varying the colours for a particular number of sigmas depending on how bad the data is was a deliberate choice. 2 sigmas is no better or worse just because someone blundered a survey elsewhere. And if data is surveyed to a lower quality the grades should be set appropriately to reflect that. Cheers, Olly ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
