> 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.
