[therion-users] Re: New version
Hi people, I've just joined up. I downloaded and compiled this OK on a debian woody box. I've got some small changes for you for the README and INSTALL docs as a result, which I'll mail as soon as I get the network card n my laptop working. The current build process assumes you have bin/therion on your PATH when you do make xtherion. I assume this needs to be the current version of therion, not just any old version. This is likely to cause trouble, as normally the ~home/therion/bin isn't going to be on the path but /usr/local/bin/therion will be and that'll be the old version. Will that break?
Of course, you're right ;-) The build process is now done a very dirty way and I'm very interested in, to make it GNU compatible (automake etc...), but we've a lot of other things on TODO list, that are too hot... If you're interested in, I can send you the map of our real (2 km) test cave (cca500kB in PDF, 40kB in therion format - if you're able to run therion - it would be a very nice test), that you will see, how the map of real cave processed by therion looks like. We can not put it on the web, as a motivation for other people, because it's very "sensitive" cave - in fact we have forbidden access to it (by ministry of environment) and we would have big problems, if some officer would know, that we're still doing explorations there... And we've no other cave maps, because until now we put 95% of our effort into programming. Now it's slightly changing, when we're able to put into maps all we need, we will probably be more editing maps than programming. In the very near future, we need to add to maps some basic things, that are still missing like graphical scale, north arrow, surveyors and dates and than generate automatically the map legeng - from the symbols that were used in a map. Then 2D output should be more or less finished (ha - it seems I'm still optimistic). But we urgently need some 3D passage model. It'll be a part of xtherion, because I've found one very nice parser of OpenGL into Tcl/Tk. Our goal is to minimize entering up-down-left-right data, but using map plan, extended profile and given sections (all parts of 2D input) generate a 3D passage wall model. I'm very keen on testing such an algorithms, because I've never seen something like this and I believe, it would save our time and improve the 3D model. Of course in parallel, we're planing to write some therion cookbook. README file now serves more like a reference guide, because sometimes I forget, how I've programmed something. That's all about the current state of therion project. Any help or comments are welcome. S. P.S. I'll change right now the Makefiles in a way, that only newly compiled therion will be used in xtherion compilation. I've been using symbolic links from /usr/bin, that pointed to therion, so I didn't recognize such a problems. P.S.2. Something went wrong with the setup of mailing list, so if you got this message twice, I'm sorry.
On Wed 06 Nov, Stacho Mudrak wrote:
Of course, you're right ;-) The build process is now done a very dirty way and I'm very interested in, to make it GNU compatible (automake etc...), but we've a lot of other things on TODO list, that are too hot...
OK - that's fine. If I'm going to package it for Debian then that will be a good excuse to work on the build system a little. You carry on with the good work on the application itself and I will try to improve the build environment. In consultation, of course - until I get a better feel for how it all fits together I might do unhelpful things if I don't check :-)
If you're interested in, I can send you the map of our real (2 km) test cave (cca500kB in PDF, 40kB in therion format - if you're able to run therion - it would be a very nice test), that you will see, how the map of real cave processed by therion looks like.
Please do - That would be brilliant. A real example is always very useful indeed in understanding things.
We can not put it on the web, as a motivation for other people, because it's very "sensitive" cave ...., when we're able to put into maps all we need, we will probably be more editing maps than programming.
Well I was intending to try it out on a short map as soon as I can. I'll make sure it is one we can distribute as an example.
Then 2D output should be more or less finished (ha - it seems I'm still optimistic). But we urgently need some 3D passage model. It'll be a part of xtherion, because I've found one very nice parser of OpenGL into Tcl/Tk.
You know that survex-aven now has an openGL version in alpha form (ie it works but isn't generally available) which doea nice 3D models based on LRUD. the missing part is reading in the LRUD info (it makes them up at the moment according to leg-length, which is remarkably effective as a hueristic). I thought therion was for drawing 2D maps and tools like aven were for 3D visualisation. Perhaps I am wrong, but it is good not to do the same work twice if it is not necessary...
Our goal is to minimize entering up-down-left-right data, but using map plan, extended profile and given sections (all parts of 2D input) generate a 3D passage wall model. I'm very keen on testing such an algorithms, because I've never seen something like this and I believe, it would save our time and improve the 3D model.
That is certainly a very good thing. In fact I have a need for somethng similar. I have just been given all the Mulu data for the last 20 years. Unfortunately most of the 1980s original centreline data has been lost - we only have the drawn-up surveys. Now that computer 3D visualisation is so important in caving it would be _really_ useful if there was some software that could let you regenerate the (approximate) centreline data from the plan and elevation. Doing this is quite similar to using the 2D drawings to add LRUD info. Can you make it do both of these things? The difference is the need to cross-reference the plan and elevation points, rather than reference the plan or elevation to the centreline independently. Does that make sense? Does it seem do-able?
Of course in parallel, we're planing to write some therion cookbook. README file now serves more like a reference guide, because sometimes I forget, how I've programmed something.
I should be able to help with docs. I did (most of) the original survex manual when it badly needed one. Time is always a problem of course but I'll see what I can do. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Please do - That would be brilliant. A real example is always very useful indeed in understanding things.
OK, I'll put it for a short time on the web and I'll send you the adress. I don't like sending large e-mails.
Well I was intending to try it out on a short map as soon as I can. I'll make sure it is one we can distribute as an example.
I think it's a question of 2 - 3 weeks, when we will also put some cave on the Web. MartinB has alredy started to write the therion book, where such real examples will be...
it makes them up at the moment according to leg-length, which is remarkably effective as a hueristic).
;-) This I know very well, we also have generated LRUD data this way...
I thought therion was for drawing 2D maps and tools like aven were for 3D visualisation. Perhaps I am wrong, but it is good not to do the same work twice if it is not necessary...
OK, the visualization. My experience is, that the visualization engine is not the problem in cave 3D models. Until now, we've been using VTK (probably also debian package), where the good visualization code was a question of 1kB script = half an hour and it was able to draw textured passage walls, polygon and semi-transparent surface with map texture (some examples were on old therion homepage). The only problem is, that it's quite large (OK, 5MB is now not so much) package. It has a nice tcl/tk interface so adding 3D viewer this way is in fact no real work. More important, I expect much more things from 3D viewer, than aven is now able to provide - and the main problem - I do not know, what I want exactly. But at least - also other data have to be insertable into 3D model - like geological structures (at least faults and underground water-levels), buildings, surface, labels - and everything with some textures and transparency specified... I also want to have more control of view-points (saving, opening, constructing a virtual flight path, combining 3D rendering with surface photo - i.e. entering camera position and optics parameters directly into viewer etc)... Off-screen rendering also... I have to experiment first and then I'll be able to say what is good and do-able.
That is certainly a very good thing. In fact I have a need for somethng similar. I have just been given all the Mulu data for the last 20 years. Unfortunately most of the 1980s original centreline data has been lost - we only have the drawn-up surveys. Now that computer 3D visualisation is so important in caving it would be _really_ useful if there was some software that could let you regenerate the (approximate) centreline data from the plan and elevation. Doing this is quite similar to using the 2D drawings to add LRUD info. Can you make it do both of these things? The difference is the need to cross-reference the plan and elevation points, rather than reference the plan or elevation to the centreline independently.
Does that make sense? Does it seem do-able?
I'm sorry - I do not understand this difference - or better say - I can not see it. Could you please draw some simple example? Because there is no need to reference plan or elevation to centerline in therion. You can draw maps without any survey data. And cross-reference these maps together looks quite simple to me. Example: in plan drawing you will specify: point 200 400 reference -name p1 point 400 400 reference -name p2 in elevation drawing: point 300 200 reference -name e1 point 400 500 reference -name e2 then you will specify centerline points like [p1 e1] [p2 e2]. The X Y coordinates will be read from p1 and Z from e1. I see no problem here... My experience is, that main problem in 3D cave modelling is LRUD approach. In fact, I've never been able to make nice model, without touching the survey data (inserting virtual points, zero length shots etc...), which I consider very dirty. Also orientation of these sections was allways a big problem (and with exception of TOPOROBOT I do not know any software, where this is possible). So my idea: I'll have plan and elevation 2D drawing. I'll specify some virtual centerline. The most simple way is to use survey stations, because there exist cross-references of these points between plan and elevation. But I can use also some other named points in these drawings - if I'll add these cross-references. Then I'll tell my therion worm - follow this centerline and every 1 m scan 2D drawings and find optimal cross section orientation, than read LRUD data in this orientation. And then I believe I'll have enought good data to generate a passage model - but may be I'm completely wrong, therefore I want to code and test it as soon as possible.
I should be able to help with docs. I did (most of) the original survex manual when it badly needed one. Time is always a problem of course but I'll see what I can do.
We would appreciate any help... Thanks, S.
participants (3)
-
Stacho Mudrak -
Stacho Mudrak -
Wookey