Hi guys, Lots of notes here on things I found and suggestions for improvements, but the important one first: I'm getting the hang of this and have drawn up some cave. It went OK until I got to a complicated section, with an underlying streamway adn overlying passages. The streamway needs to be a separate scrap. But I haven't got that far. One bit of wall wasn't shown. By adding a map-fg colour I could see that therion is very confused about what is the inside and what is the outside of the scrap. Here is the set of files needed to process this example: http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon.tgz including the offending background image. You can see from the included pdf (also here: http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon.pdf what the problem is. I;ve tried reversing some lines and reading the thbook, but I don;t know how to fix this. Does it in fact need to be split up into smaller, simpler scraps? why? I am hesitant to use smaller scraps on this drawing because none of the joins work when I just do join scrap1 scrap2 - it joins lines to the wrong places. I have to use explicit line ID's, which is really tedious - add line in map editor then add then to join command in text editor. Being able to graphically describe joins (at letsfor joins within one .th2 file) would be a really useful improvement. I'll send a separate mail for my other notes. 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/
I'm getting the hang of this and have drawn up some cave. It went OK until I got to a complicated section, with an underlying streamway adn overlying passages. The streamway needs to be a separate scrap. But I haven't got that far. One bit of wall wasn't shown. By adding a map-fg colour I could see that therion is very confused about what is the inside and what is the outside of the scrap.
Only minor improvements were required -- mostly to correct line types (the hidden wall was actually a border, the inner pillar should have -outline in option...). All my changes are marked red in the enclosed picture. The correct line types make correct scrap joins possible. Simple join s1 s2 worked fine with one exception, where the scrap ends are too far. There is perhaps a blunder in your data. Martin
+++ Martin Budaj [04-12-26 13:06 +0100]:
I'm getting the hang of this and have drawn up some cave. It went OK until I got to a complicated section, with an underlying streamway adn overlying passages. The streamway needs to be a separate scrap. But I haven't got that far. One bit of wall wasn't shown. By adding a map-fg colour I could see that therion is very confused about what is the inside and what is the outside of the scrap.
Only minor improvements were required -- mostly to correct line types (the hidden wall was actually a border, the inner pillar should have -outline in option...). All my changes are marked red in the enclosed picture.
Thanx for that, martin - that's great :-) I thin we need a better understanding of what makes a 'pillar'. I thought a pillar was a closed loop within a passage, but that is not a closed loop (a passage goes off underneath from the gap - see the scan to get the full idea). So when does therion need to be told that an outline is 'in'?
The correct line types make correct scrap joins possible. Simple join s1 s2 worked fine with one exception, where the scrap ends are too far. There is perhaps a blunder in your data.
OK. so there is some threshold of closeness that prevents a join happening automatically (to the right place). I think some form of feedback is needed that allows me to work out that the join has gone wrong due to excessive distortion. How did you work out what was wrong? Also a couple of new points - I added some areas and used 'Insert ID' in the area control. I assumed this just gave an ID to the area, but now having added 'bankatjoin' I get the error: object does not exist -- bankatjoin I'm a bit confused about this - does this area ID have some special significance and isn't just any old string I give to the area? Also what happens if an area crosses a scrap join? Presumably I have to draw an invisible borderline across the join in order to make a closed area (in both scraps)? Or is there some special way to indicate that it is one area? 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/
+++ Martin Budaj [04-12-26 13:06 +0100]:
I'm getting the hang of this and have drawn up some cave. It went OK until I got to a complicated section, with an underlying streamway adn overlying passages. The streamway needs to be a separate scrap. But I haven't got that far.
Sorry to keep asking the group questions but I'm stuck again. I've updated the files online. I've added the scrap containing the underlying streamway. As soon as I add the underlying scrap and process I get : therion: error -- metapost exit code -- 256 This appears to be due to "! Paths 4 and 3 don't intersect." But I have 5 aras in this scrap - how on earth do I work out which one is at fault? The area 'show' button doesn't seem to work - is that a clue? The odd thing is that that scrap did appearonce but I had a mislabelled station in it so it was tiny and in one corner. After I fixed that it seemed broken. Also I'm extrememly annoyed because I drew a load of another scrap but lost it somehow. It's the oldproblem of having files open in therion and another editor. But So far as I can tell I need to open it in another editor in order to edit the names of scraps. (as you say - calling them <filename>_sn is a good idea.) Having a .th2 file open in both the text and map editors seems to work OK, but I can't find any info on how to search in the text editor? So I use an editor i can search in. I tried to make sure I always closed a file in the map editor before editing it extrenally but something went wrong and a whole scrap disappeared :-( Given how long they take to draw in therion, we need to make sure this is not possible to do accidentally by checking timestamps. The 'command preview' window looks like it ought to let you edit commands, but it doesn't. It this worked and/or there was a 'search' option in the text editor then external editing would not be necessary. Ah - maybe I need to use the 'scrap control' section. On the good side I've discovered the 'move to' button which is brilliant. And the red entriesin the error window which takes you to the offending item in the mapeditor is really useful, although it doesn't work for metapost 'don't intersect' errors. where '(mptextmp.mp) [5]' is highlighted in red but clicking on it just gives an error saying it can't load it. I'm making a list of things I think we need to add shortcuts for. I'll post that soon. 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/
+++ Wookey [04-12-27 23:59 +0000]:
+++ Martin Budaj [04-12-26 13:06 +0100]:
I'm getting the hang of this and have drawn up some cave. It went OK until I got to a complicated section, with an underlying streamway adn overlying passages. The streamway needs to be a separate scrap. But I haven't got that far.
Sorry to keep asking the group questions but I'm stuck again.
I've updated the files online. I've added the scrap containing the underlying streamway. As soon as I add the underlying scrap and process I get : therion: error -- metapost exit code -- 256 This appears to be due to "! Paths 4 and 3 don't intersect." But I have 5 aras in this scrap - how on earth do I work out which one is at fault? The area 'show' button doesn't seem to work - is that a clue?
OK- I fixed this by comenting out areas until things worked again, but there does need to be a better way. That example (scrap bmb2_s3) has a streamway with sandbanks. Having got the large water area to work, I find that some of the sandbanks are sandy, but some are covered in water. What determines when an area follows the outer wall, or the sandbank border? IS the only way to be sure to get the right thing to split the wall at the sandbank? This gets back to the problem that making changes to line which surround areas is problematic - if you split a line that is part of an area then both lines losetheir IDs and the area breaks. This is a tricky problem, but what you really want is for the areas and lines to get re-written so they all still work. 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/
Wookey wrote:
I thin we need a better understanding of what makes a 'pillar'. I thought a pillar was a closed loop within a passage, but that is not a closed loop (a passage goes off underneath from the gap - see the scan to get the full idea). So when does therion need to be told that an outline is 'in'?
I agree that in the cave would nobody calls the massif between two passages 'pillar', but therion sees things purely geometrically -- doesn't matter if a closed loop within a passage is small or large, formed by a fallen block or two passages. So everything surrounded by a scrap border and not belonging to the scrap is a 'pillar' and need to have "-outline in" option specified.
OK. so there is some threshold of closeness that prevents a join happening automatically (to the right place). I think some form of feedback is needed that allows me to work out that the join has gone wrong due to excessive distortion. How did you work out what was wrong?
Yes, there should be a warning that therion couldn't find a join.
Also what happens if an area crosses a scrap join? Presumably I have to draw an invisible borderline across the join in order to make a closed area (in both scraps)? Or is there some special way to indicate that it is one area?
It would work, but areas (the pattern) wouldn't join smoothly :(( There is unfortunately no better solution now. Martin
Yes, there should be a warning that therion couldn't find a join.
Therion always joins something - there is no treshold for not joining. If join is not correct, usually scrap distortion is too big. If you will turn on debug mode in layout, you should see those distortions very easily.
Also what happens if an area crosses a scrap join? Presumably I have to draw an invisible borderline across the join in order to make a closed area (in both scraps)? Or is there some special way to indicate that it is one area?
It would work, but areas (the pattern) wouldn't join smoothly :(( There is unfortunately no better solution now.
At the scrap joins, you should try to avoid any symbols. If there are some, usually -clip off helps (if you do not need to clip them by scrap border). But in the case of area that exists between walls, it would probably not help. Regards, S.
Wookey wrote:
That example (scrap bmb2_s3) has a streamway with sandbanks. Having got the large water area to work, I find that some of the sandbanks are sandy, but some are covered in water. What determines when an area follows the outer wall, or the sandbank border? IS the only way to be sure to get the right thing to split the wall at the sandbank?
When I have to draw something like this, I draw one border curve that goes behind the wall on those places, where wall is areas active border. In the output, such border and area are clipped by walls.
This gets back to the problem that making changes to line which surround areas is problematic - if you split a line that is part of an area then both lines losetheir IDs and the area breaks. This is a tricky problem, but what you really want is for the areas and lines to get re-written so they all still work.
May be in the future it will be neccessary, but again - every time I draw area that should be surrounded by walls also, I just let it overlap walls and in the output this are will be clipped correctly. Regards, S.
This appears to be due to "! Paths 4 and 3 don't intersect." But I have 5 aras in this scrap - how on earth do I work out which one is at fault? The area 'show' button doesn't seem to work - is that a clue?
??? It should work, I will have a look at it. In any case, we should add source position to error report at least to areas.
Also I'm extrememly annoyed because I drew a load of another scrap but lost it somehow. It's the oldproblem of having files open in therion and another editor. But So far as I can tell I need to open it in another editor in order to edit the names of scraps. (as you say - calling them <filename>_sn is a good idea.) Having a .th2 file open in both the text and map editors seems to work OK, but I can't find any info on how to search in the text editor?
There is Search & Replace command bar, may be it is just hidden. But in any case - having file open both in map and text editor is not a good idea right now. Checking timestamps is in the TODO list, I can put it higher priority.
The 'command preview' window looks like it ought to let you edit commands, but it doesn't. It this worked and/or there was a 'search' option in the text editor then external editing would not be necessary.
Preview is just preview. It would be too difficult to edit command directly there. But there is Search & Select also in map editor, why don't you use it? Regards, S.
Wookey wrote:
But So far as I can tell I need to open it in another editor in order to edit the names of scraps. (as you say - calling them <filename>_sn is a good idea.)
You may edit scrap names directly in the map editor -- select the line with the scrap name in the 'File commands' menu and you may change the name in the 'Scrap control' menu. Martin
+++ Stacho Mudrak [04-12-28 08:44 +0100]:
Yes, there should be a warning that therion couldn't find a join.
Therion always joins something - there is no treshold for not joining. If join is not correct, usually scrap distortion is too big. If you will turn on debug mode in layout, you should see those distortions very easily.
OK - yes, I noticed that in the thbook. I must try it.
Also what happens if an area crosses a scrap join? Presumably I have to draw an invisible borderline across the join in order to make a closed area (in both scraps)? Or is there some special way to indicate that it is one area?
It would work, but areas (the pattern) wouldn't join smoothly :(( There is unfortunately no better solution now.
At the scrap joins, you should try to avoid any symbols. If there are some, usually -clip off helps (if you do not need to clip them by scrap border). But in the case of area that exists between walls, it would probably not help.
OK - this is a real problem for a cave containing a long streamway. There is a very long continuous 'water' area. This connot always be drawn as one scrap. As you say the pattern rather obviously doesn't match up at the join. I think we need to have some mechanism for making such smooth area joins in the medium term. 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/
It would work, but areas (the pattern) wouldn't join smoothly :(( There
is
unfortunately no better solution now.
At the scrap joins, you should try to avoid any symbols. If there are some, usually -clip off helps (if you do not need to clip them by scrap border). But in the case of area that exists between walls, it would probably not help.
OK - this is a real problem for a cave containing a long streamway. There is a very long continuous 'water' area. This connot always be drawn as one scrap. As you say the pattern rather obviously doesn't match up at the join. I think we need to have some mechanism for making such smooth area joins in the medium term.
I have tried this now and it works :-) It seemes that PDF viewers optimize filling of adjacent areas and join patterns smoothly. Martin
Ahoj! Kdyz jsme na Macose prohlizeli 3D pohled (.thm), orezavalo nam to nekdy predni a zadni rovinou. Ted jsem zjistil, ze se mi to objevuje pouze tehdy, kdyz je v exportu -disable cave-centreline. Kdyz to tam neni, tak to alespon u mne neorezava. A jeste mam jeden dotaz: mam zatim jen holy polygon, ve 3D se mi v internim prohlizeci zobrazi, ale kdyz ho vyexportuji do .wrl, tak tam nic neni (jen cerna plocha). Mam neco spatne nastaveno, nebo ten prohlizec .wrl neumi zobrazit cary? Diky za odpoved Ik S pranim ZARE SVETLA Ing. Jiri Novotny - JINOLI Tynska 7, 110 00 Praha 1 tel: 777 677 988, fax: 777 476 960 ICO: 48064149, DIC: CZ5404242239 e-mail: jinoli@centrum.cz http://jinoli.zde.cz - vse pro nezavisle sviceni a nejen to
+++ Martin Budaj [04-12-28 15:57 +0100]:
At the scrap joins, you should try to avoid any symbols. If there are some, usually -clip off helps (if you do not need to clip them by scrap border). But in the case of area that exists between walls, it would probably not help.
OK - this is a real problem for a cave containing a long streamway. There is a very long continuous 'water' area. This connot always be drawn as one scrap. As you say the pattern rather obviously doesn't match up at the join. I think we need to have some mechanism for making such smooth area joins in the medium term.
I have tried this now and it works :-) It seemes that PDF viewers optimize filling of adjacent areas and join patterns smoothly.
xpdf doesn't do this unfortunately. gpdf can't render my pdf file at all anymore :-( 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/
+++ Martin Budaj [04-12-26 13:06 +0100]:
I'm getting the hang of this and have drawn up some cave. It went OK until I got to a complicated section, with an underlying streamway adn overlying passages. The streamway needs to be a separate scrap. But I haven't got that far. One bit of wall wasn't shown. By adding a map-fg colour I could see that therion is very confused about what is the inside and what is the outside of the scrap.
Only minor improvements were required -- mostly to correct line types (the hidden wall was actually a border, the inner pillar should have -outline in option...). All my changes are marked red in the enclosed picture.
Now that I've drawn about 8km of survey the last scrap (top right hand corner - scrap bmb3_s3) has had 'pillar failure' again. There are 3 pillars which do not work (the insides are filled). They are all walls with -outline in and I've tried reversing them, but it seems to stay broken. What's going on? The files are are: Big version with the scans in (16Mb): http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon1.tgz Small version without the scans: http://trilogy-gw.aleph1.co.uk/~wookey/files/bluemoon.tgz 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/
Now that I've drawn about 8km of survey the last scrap (top right hand corner - scrap bmb3_s3) has had 'pillar failure' again.
There are 3 pillars which do not work (the insides are filled). They are all walls with -outline in and I've tried reversing them, but it seems to stay broken. What's going on?
There is another problem. Even if scrap boundary has correctly specified all -outline out/in/none options, there may be problem to determine which area is inside of the scrap if the outline crosses itself (like figure 8). In such a case you get a MetaPost warning Warning: scrap outline intersects itself in bmb3_s3@fake and it is than random if MetaPost determines the interior of scrap correctly. The solution is to 1) find where the loop occured -- this may be tricky, but start with the endpoints where scraps should join. The loop may be very small, even unnoticable. Even worse, it may not be visible at all, because it happens anly after the joining of scraps -- which is the case of your example :( 2) correct the position of the control points (see the second picture) I hope the enclosed pictures make it more clear. Regards Martin
+++ Martin Budaj [05-01-03 12:59 +0100]:
There is another problem. Even if scrap boundary has correctly specified all -outline out/in/none options, there may be problem to determine which area is inside of the scrap if the outline crosses itself (like figure 8). In such a case you get a MetaPost warning
Warning: scrap outline intersects itself in bmb3_s3@fake
OK. I have another big section of cave that is currently broken due to mysterious therion metapost errors. I've tried to track it down but I don't understand well enough to do it. I am getting this error: ! angle(0,0) is taken as zero. l_arrow->...d(angle(direction.infinity.of(EXPR0))- 90)shifted(point.infinity....l.5565 ),2); The angle' between two identical points is undefined. I'm zeroing this one. Proceed, with fingers crossed. I assume this means that I have two points on top of each other - but I don't know in which scrap, or which line, so it is not practical to find it. The offending files are at: http://trilogy-gw.aleph1.co.uk/~wookey/files/soundriver.tgz http://trilogy-gw.aleph1.co.uk/~wookey/files/soundriverpic.tgz (includes scans) It seems that if I include any of soundriver2_s1 soundriver3_s1 or soundrivercrab_s1 then it breaks. soundriver2_s1 is particularly perplexing as it is a straight bit of passage with no areas in it, 3 stations, and not much detail - seems to me there is very little to go wrong. I did have soundriver3_s1 working last night I thought, but not now... I am afraid I am going to keep sending you these until we work out some better debugging system :-( or I get a lot smarter. 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/
+++ Martin Budaj [05-01-03 12:59 +0100]:
Warning: scrap outline intersects itself in bmb3_s3@fake
and it is than random if MetaPost determines the interior of scrap correctly. The solution is to 2) correct the position of the control points (see the second picture)
I have a bit of a problem with your example fix. Now the wall does not follow the wall on my survey - I have had to distort it a little to solve this problem. This seems to me to be the wrong answer - the original version is a correct drawing of the cave, therion needs to be able to join (and distort if necessary) that drawing without telling me it it 'wrong' and I have to draw the cave a slightly different shape in order for it to be accepted. I realise this may not be easy, but I don't really think that telling the user their correct drawing causes an error is good enough. Perhaps when the outline intersection happens on a line that is a scrap end line (i.e one that therion invented, not one the user drew) then that should not be an error - and therion could adjust its own line to compensate? Is that practical? 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/
message re-sent as it seems to have got lost (same with the other two I sent just now). +++ Martin Budaj [05-01-03 12:59 +0100]:
Now that I've drawn about 8km of survey the last scrap (top right hand corner - scrap bmb3_s3) has had 'pillar failure' again.
There are 3 pillars which do not work (the insides are filled). They are all walls with -outline in and I've tried reversing them, but it seems to stay broken. What's going on?
There is another problem. Even if scrap boundary has correctly specified all -outline out/in/none options, there may be problem to determine which area is inside of the scrap if the outline crosses itself (like figure 8). In such a case you get a MetaPost warning
Warning: scrap outline intersects itself in bmb3_s3@fake
I have this warning in a few scrpas in that survey - I wondered how serious it was, and what I should do about it. But without more details of _where_ it intersects itself (and why this is a problem), I could not do anything but ignore it.
and it is than random if MetaPost determines the interior of scrap correctly. The solution is to 1) find where the loop occured -- this may be tricky, but start with the endpoints where scraps should join. The loop may be very small, even unnoticable. Even worse, it may not be visible at all, because it happens anly after the joining of scraps -- which is the case of your example :( 2) correct the position of the control points (see the second picture)
I hope the enclosed pictures make it more clear.
It does - thanks very much for taking the time to look at it. I have several more scraps which I cannot include in the overall survey at the moment because if I do I get cryptic metapost errors. We have to work out a way of getting better feedback to the user about _where_ the problem lies as it is currently extremely difficult to fix as you don't know which of many lines is at fault. How did you find the above problem. If I understood the process you used to find this it might help me next time. I'll add this answer to the FAQ too. 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/
Wookey wrote:
It seems that if I include any of soundriver2_s1 soundriver3_s1 or soundrivercrab_s1 then it breaks. soundriver2_s1 is particularly perplexing as it is a straight bit of passage with no areas in it, 3 stations, and not much detail - seems to me there is very little to go wrong.
I'll start with easier problems. The problem in soundriver3_s1 was really tricky. Step by step description: *** uncommented soundrivercrab_s1: I got an MetaPost error "! Paths 6 and 5 don't intersect." It's always related to areas so I used "search & select" in the map area to find all areas. There was only one area (line 6 in File commands). I looked to Command preview window to see the definition and tried to locate all area border lines in the scrap. There was one line too much (l26-1164-70), which I deleted in Area control. *** uncommented soundriver2_s1: I got an error: ----- l_flowstone->...as>dlzka+(mojkrok/3);t1:=t2;endfor ; l.5074 )) ; The `angle' between two identical points is undefined. I'm zeroing this one. Proceed, with fingers crossed. ----- The first error line gives the name of symbol in which the error ocured (l_flowstone) with a piece of its definition (which is not interesting now) and the second line gives a line number in the metapost file (created from all scraps) where the error ocurred and the text on that line. I knew that problem was in some line flowstone symbol so I used "search & select" to find all "line flowstone" occurences, and checked the definition in the "Command preview". Fortunately already the first flowstone line had duplicated point 703.0 793.0 703.0 793.0 I deleted it in Line control->Edit line->Delete point *** uncommented soundriver3_s1: Similar error ----- l_arrow->...d(angle(direction.infinity.of(EXPR0))- 90)shifted(point.infinity.... l.5728 ),2) ; The `angle' between two identical points is undefined. I'm zeroing this one. Proceed, with fingers crossed. ----- As before I searched for the given symbol (line arrow): search & select line arrow (Find first, Find next, ...) and watched the Command preview window to see the definition. I suspected that problematic is line 24 in the File commands window: 363.0 573.5 363.0 573.5 317.0 604.5 295.0 642.5 with the control point of bezier line equal to previous point. After playing a bit with control points and even deleting the line the problem remained. I couldn't imagine which arrow casues problems so I had to identify it acoording to the line number given in MP error. I run therion in debugging mode (-d argument), opened the file data.mp in the $TEMP/thTMPDIR directory and jumped to line 5728. The problem with the file data.mp is that it doesn't contain original coordinates from th2 files so I couldn't identify the arrow using coordinates. I counted how many arrows are in the scrap containing line 5728 before the arrow ending on line 5728. Our arrow was the second in this scrap. Metapost file has reverse order of symbols (in order to display first object in the th2 file on top) so the final result is that problematic arrow is last-but-one in the file, i.e. line 23 in the File commands window. There is actually nothing wrong with that arrow -- that is the reason why it took so long to find it :) It has the last control point identical with the last point, which is perfectly acceptable in metapost. Unfortunately there is some bug in the arrow definition, which doesn't allow this. I hope it will be possible to fix it. In the meantime you may change the line either to a straight segment (no control points) or add a control point different from the endpoint. Martin
Wookey wrote:
I have a bit of a problem with your example fix. Now the wall does not follow the wall on my survey - I have had to distort it a little to solve this problem. This seems to me to be the wrong answer - the original version is a correct drawing of the cave, therion needs to be able to join (and distort if necessary) that drawing without telling me it it 'wrong' and I have to draw the cave a slightly different shape in order for it to be accepted.
There is a problem that therion does some calculations itself and some lets to MetaPost. When the scraps are joined, therion has no idea if the border is intersecting itself. When MetaPost examines the border, it's too late for changing the scrap distortion -- it may only give a warning.
I realise this may not be easy, but I don't really think that telling the user their correct drawing causes an error is good enough. Perhaps when the outline intersection happens on a line that is a scrap end line (i.e one that therion invented, not one the user drew) then that should not be an error
It can't be just ignored, because metapost needs non-intersecting outline to determine the interior of scrap correctly.
and therion could adjust its own line to compensate? Is that practical?
It can't right now -- the intersection is detected only in metapost. We would have to implement the algorithm in therion, which would be not trivial. Martin
Wookey wrote:
Warning: scrap outline intersects itself in bmb3_s3@fake
I have this warning in a few scrpas in that survey - I wondered how serious it was, and what I should do about it. But without more details of _where_ it intersects itself (and why this is a problem), I could not do anything but ignore it.
The only information we can give here is the scrap name. There is no way how to find out in MetaPost where exactly the closed path intersects itself :-((
I have several more scraps which I cannot include in the overall survey at the moment because if I do I get cryptic metapost errors. We have to work out a way of getting better feedback to the user about _where_ the problem lies as it is currently extremely difficult to fix as you don't know which of many lines is at fault.
I think it's doable to give a line number in th2 file where the error occures. It would be perhaps possible to also identify area border lines which don't intersect.
How did you find the above problem. If I understood the process you used to find this it might help me next time.
I got this error (uncorrectly determined interior of the scrap) long time ago in Dead Bats Cave map. There was some strange clipping by the scrap border, which I could't explain. In that time there was no MP warning, no map colouring. I don't remember exactly but it took quite long till i identified that the problem is in the border and than what is wrong with the border. After reading thoroughly the apprpriate chapter of the Metafont book I knew that problem is in the loop -- but even than I couldn't find any -- so small it was, in fact very similar to yours. I added the MP warning to point to this problem. When I see it now, I first check scrap ends if something could cause the problem. The biggest problem is if the loop is introduced only after morphing the scrap ends before joining scraps. I can only recommend to move control point in the last bezier arc of wall just before the scrap end, run therion, undo the change by pressing Ctrl+Z and repeat with other walls until the problem remains. The loop may occur also in the middle of the wall, but it should be visible, at least in 400% zoom. I'm sorry that there is no cleverer algorithm to find the loop :( Martin
+++ Martin Budaj [05-01-05 23:42 +0100]:
Wookey wrote:
Warning: scrap outline intersects itself in bmb3_s3@fake
We have to work out a way of getting better feedback to the user about _where_ the problem lies as it is currently extremely difficult to fix as you don't know which of many lines is at fault.
I think it's doable to give a line number in th2 file where the error occures. It would be perhaps possible to also identify area border lines which don't intersect.
That would be a great improvement I think, although if it sometimes ends up suggesting the wrong line then that will cause some extra confusion.
I got this error (uncorrectly determined interior of the scrap) long time ago in Dead Bats Cave map.
I added the MP warning to point to this problem. When I see it now, I first check scrap ends if something could cause the problem.
OK. Having the metafont error suggest possible causes might be good (and probably removing some of the slovakian variable-names stuff which doesn't help anyone except maybe you), so that the error makes more sense to a normal user.
I'm sorry that there is no cleverer algorithm to find the loop :(
OK, well for now the best hing is to use these examples I have (unfortunately) produced to demonstrate likely problems and solution, and diagnostics. Your reply explaining how you found my errors is exactly what people need in order to learn therion-fu, so thanx very much for that. More for someone to put in the FAQ. MartinS can you do that again (with the pictures and everything) and I'll tidy it up? I'll get round to it eventually but I have survey-drawing and work deadlines this month _and_ my engine blew up on christmas day so I have to spend a lot of time under the car this month too, so time is limited. 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/
+++ Martin Budaj [05-01-05 22:31 +0100]:
I'll start with easier problems. The problem in soundriver3_s1 was really tricky. Step by step description:
*** uncommented soundrivercrab_s1:
I got an MetaPost error "! Paths 6 and 5 don't intersect."
It's always related to areas so I used "search & select" in the map area to find all areas. There was only one area (line 6 in File commands).
OK- at this point if I select the area then 3 of the lines surrounding the area are highlighted, but not the others? Why is this? Is it a clue to the problem or is the area highlighting just broken? Being able to click on the lines in the area control and have them highlighted would make it much quicker to check an area. (at the oment you have to search for their names, and after the first 3 you need to keep scrolling the preview window). Someone add this to the wishlist :-)
I looked to Command preview window to see the definition and tried to locate all area border lines in the scrap. There was one line too much (l26-1164-70), which I deleted in Area control.
OK - fixed :-) BTW when I view therion-produced pdf files in xpdf I get this a lot: Error (181503): Name token too long Error (181523): Dictionary key must be a name object The rendering looks OK so far as I can see, but maybe some element is missing. Is this an xpdf problem or something that should be fixed in therion? Do you need an example file? (this was the soundriver.pdf I sent with the above fix in)
*** uncommented soundriver2_s1:
I got an error:
----- l_flowstone->...as>dlzka+(mojkrok/3);t1:=t2;endfor
The first error line gives the name of symbol
aha - that's useful to know. fixed.
*** uncommented soundriver3_s1:
Similar error
----- l_arrow->...d(angle(direction.infinity.of(EXPR0))- 90)shifted(point.infinity.... l.5728 ),2) ; The `angle' between two identical points is undefined. I'm zeroing this one. Proceed, with fingers crossed. -----
As before I searched for the given symbol (line arrow): search & select line arrow (Find first, Find next, ...) and watched the Command preview window to see the definition. I suspected that problematic is line 24 in the File commands window: 363.0 573.5 363.0 573.5 317.0 604.5 295.0 642.5 with the control point of bezier line equal to previous point. After playing a bit with control points and even deleting the line the problem remained.
OK - in fact this line should be a contour not an arrow.
I couldn't imagine which arrow casues problems so I had to identify it acoording to the line number given in MP error.
<snip>
Unfortunately there is some bug in the arrow definition, which doesn't allow this. I hope it will be possible to fix it. In the meantime you may change the line either to a straight segment (no control points) or add a control point different from the endpoint.
OK thanx - I don't think I'd have worked that out myself in a month! So I've fixed all that and added some joins between the segments, and that all works reasonably well, but I have a few small problems remaining: Line 81 in soundriver.th2 is a pillar, but I can't get it to be empty. There is an 'outline crosses itself' error in soundriver_pooh which I thought might be affecting it, but removing that scrap makes no difference, and neither does reversing the line. Why is this pillar broken? Also there are a couple of places where there are 'gaps' in the grey background. The most obvious example is the large chamber in the middle is soundriver2_s2 (with lots of boulders). The main chamber has a RH wall which is in the 'middle' of 3 walls. The rightmost wall is the RH wall of a lower passage, formed by the large pile of rocks in the middle separating the upper and lower parts for 30m or so. What is the 'therion way' to draw something like this? Just use a border for the central line? Or split the lower portion into a very small scrap, I suppose? And there is a similar problem on the other side of the chamber (where a steep ramp goes up on the left) BTW - I hope you looked at the scale bar and were impressed with the size of the passage we found :-) All that was found on two pretty amazing trips! 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/
Wookey wrote:
It's always related to areas so I used "search & select" in the map area to find all areas. There was only one area (line 6 in File commands).
OK- at this point if I select the area then 3 of the lines surrounding the area are highlighted, but not the others? Why is this? Is it a clue to the problem or is the area highlighting just broken?
It's perhaps broken -- but that is a question for Stacho, who is on holidays now.
Being able to click on the lines in the area control and have them highlighted would make it much quicker to check an area. (at the oment you have to search for their names, and after the first 3 you need to keep scrolling the preview window). Someone add this to the wishlist :-)
Agree.
BTW when I view therion-produced pdf files in xpdf I get this a lot: Error (181503): Name token too long Error (181523): Dictionary key must be a name object
The rendering looks OK so far as I can see, but maybe some element is missing.
Is this an xpdf problem or something that should be fixed in therion? Do you need an example file? (this was the soundriver.pdf I sent with the above fix in)
I'll look at this. Recently we have had problems with Acrobat reader 7.0, which doesn't open files created on other platform (e.g. linux files on windows) and complains that file is dameged. There is no problem with 6.0 and older versions.
So I've fixed all that and added some joins between the segments, and that all works reasonably well, but I have a few small problems remaining:
Line 81 in soundriver.th2 is a pillar, but I can't get it to be empty. There is an 'outline crosses itself' error in soundriver_pooh which I thought might be affecting it, but removing that scrap makes no difference, and neither does reversing the line. Why is this pillar broken?
In my file is line 81 only a segment of the wall - I can't imagine where the pillar should be...
Also there are a couple of places where there are 'gaps' in the grey background. The most obvious example is the large chamber in the middle is soundriver2_s2 (with lots of boulders). The main chamber has a RH wall which is in the 'middle' of 3 walls. The rightmost wall is the RH wall of a lower passage, formed by the large pile of rocks in the middle separating the upper and lower parts for 30m or so. What is the 'therion way' to draw something like this? Just use a border for the central line? Or split the lower portion into a very small scrap, I suppose? And there is a similar problem on the other side of the chamber (where a steep ramp goes up on the left)
The separate scrap is the best solution. The other is to split the inner wall and set the 'outline in' option as displayed in the attached picture. The exact rule is that each line forming the outer border of the scrap has to have 'outline out' option (walls have this by default), each line forming inner pillars 'outline in' option, and all other lines (even walls lying inside of scrap) 'outline none' option. For all walls which shouldn't form the scrap border you have to set 'outline none' option. See the second attachment to see how to specify this.
BTW - I hope you looked at the scale bar and were impressed with the size of the passage we found :-) All that was found on two pretty amazing trips!
Of course we did :) it's really great. Martin
+++ Martin Budaj [05-01-06 11:19 +0100]: [I wrote this a day or two ago and forgot to send it.]
Wookey wrote:
Line 81 in soundriver.th2 is a pillar, but I can't get it to be empty. There is an 'outline crosses itself' error in soundriver_pooh which I thought might be affecting it, but removing that scrap makes no difference, and neither does reversing the line. Why is this pillar broken?
In my file is line 81 only a segment of the wall - I can't imagine where the pillar should be...
Sorry I don't mean line 81 I mean command list no 81 in map editor.
Also there are a couple of places where there are 'gaps' in the grey background. The most obvious example is the large chamber in the middle is soundriver2_s2 (with lots of boulders).
The separate scrap is the best solution. The other is to split the inner wall and set the 'outline in' option as displayed in the attached picture.
The exact rule is that each line forming the outer border of the scrap has to have 'outline out' option (walls have this by default), each line forming inner pillars 'outline in' option, and all other lines (even walls lying inside of scrap) 'outline none' option. For all walls which shouldn't form the scrap border you have to set 'outline none' option. See the second attachment to see how to specify this.
OK - another useful answer - that one might count as a 'tip and trick'. (we could write a lot of tips and tricks about scraps - where to split them, how big to make them, to do a check build after adding an area, not to make control points too close to the end lines and so on). 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/
Wookey wrote:
Line 81 in soundriver.th2 is a pillar, but I can't get it to be empty. There is an 'outline crosses itself' error in soundriver_pooh which I
thought
might be affecting it, but removing that scrap makes no difference,
and
neither does reversing the line. Why is this pillar broken?
In my file is line 81 only a segment of the wall - I can't imagine where the pillar should be...
Sorry I don't mean line 81 I mean command list no 81 in map editor.
I meant also line 81 in the command list of the map editor... Is the file the same? Martin
participants (4)
-
Ing. Jirí Novotný -
Martin Budaj -
Stacho Mudrak -
Wookey