Problem with multiple LOD8 areas

[Guest cwright]

I've used my program to generate two test coastlines spanning two LOD8 areas (one above the other). One coastline works fine (see the screenshot - the beach is a generic texture, not a beach, that will come later). http://www.kline.demon.co.uk/coast.jpg But in the other similar area about a degree to the south, the water refuses to appear (it generates flattened water). The area consists of two LOD8 areas, one above the other. If I generate one LOD8 or the other, then it appears correctly. If I compile the two LOD8 areas into separate BGL's it also appears correctly. When using the older pre-SDK method I noticed precisely the same kind of problem. I then successively reduced the number of points, but no joy. With the last one there were just four small isolated polygons, two in each LOD8 area. I include the ASM text below. The location is E42 2.6, N1 0.6 If anyone can see why the polygons don't appear that'd be great. Many thanks. Best regards, Chris ************************************************************** include TDFMacros.inc include TDFHeaders.inc BGLHeader 3, 1, 43, 40, LWMHeader, TerrainHeaderStart LWMHeader label word LWMFileHeader 513, LWMIndexStart, LWMStart, LWMEnd LWMStart label word datamark_0 label word LWMDataAreaDrawPolygons 1, 3, 1, 29, 10 LWMPoly2 5, 0, 0, 0, 0 LWMPoint 151, 1 LWMPoint 151, 109 LWMPoint 2, 255 LWMPoint 1, 255 LWMPoint 1, 1 LWMDataAreaDrawPolygons 1, 3, 1, 26, 13 LWMPoly2 3, 0, 0, 0, 0 LWMPoint 254, 1 LWMPoint 16, 174 LWMPoint 254, 1 datamark_1 label word LWMDataAreaDrawPolygons 1, 3, 1, 29, 16 LWMPoly2 3, 0, 0, 0, 0 LWMPoint 2, 255 LWMPoint 151, 44 LWMPoint 151, 255 LWMDataAreaDrawPolygons 1, 3, 1, 18, 20 LWMPoly2 3, 0, 0, 0, 0 LWMPoint 1, 1 LWMPoint 100, 100 LWMPoint 1, 200 datamark_2 label word Cell_473_253 EQU LWMCellID 0, 0, 3, 473, 253 Cell_473_252 EQU LWMCellID 0, 0, 3, 473, 252 LWMIndexStart label word LWMIndexHeader 2, LWMIndexData LWMIndexData label word LWMIndexEntry Cell_473_253, LWMStart, datamark_0, datamark_1 LWMIndexEntry Cell_473_252, LWMStart, datamark_1, datamark_2 LWMEnd label word

[rhumbaflappy 113]

Hi Chris.Sorry about the late reply.You have discovered a 'feature' of the terrain engine. :)Reverse these lines:LWMIndexEntry Cell_473_253, LWMStart, datamark_0, datamark_1LWMIndexEntry Cell_473_252, LWMStart, datamark_1, datamark_2... so that they read:LWMIndexEntry Cell_473_252, LWMStart, datamark_1, datamark_2LWMIndexEntry Cell_473_253, LWMStart, datamark_0, datamark_1Apparently, the order of the LOD8 Cells in the LWMIndex makes a difference, due to the datastream... Once it renders Cell 473_253, it won't go back and render Cell 473_252! I'd never run across this before, and it never occured to me that the index order was important.Page 28 of the FS2002 Terrain SDK does indicate the datastream goes from Cell to Cell, but never specified Cell to the next Cell ( in order ). And what is the order? The SDK says on page 27, the LWMCellID structures can be sorted by treating them as unsigned Longs... that order would be column + row, from 0 to 767 column first( U value ), then consider the order of the rows 0 to 511 ( V value ). So CellID 0, 0 is numero uno in the index, while 767, 511 is the bottom of the barrel.The SDK says of the VTPIndexEntry order, that the entries are sorted by the cellid from lowest to highest... same thing!So the cell definition ( Cell_473_252 EQU LWMCellID 0, 0, 3, 473, 252 ) can be in any order, but the construction of the index itself ( LWMIndexEntry ) must be from low to high numerically.Somebody had to find this. :)Due to the concept of the datastream, this makes sense, as it would be a real time-waster for the rendering to have to backtrack to previous Cells. I don't know if the actual order of the LOD13 Areas ( 0-31, 0-31 ) makes a difference, but that might be interesting to research.Dick

[rhumbaflappy 113]

Hi Chris.I don't know if I made it clear enough.CellID 0,0 is first. CellID 0,511 is before CellID 1,0. Just read them like 6 digit numbers... 000511 is smaller than 001000. In fact, maybe we could adopt a naming convention for CellIDs that would be 6 digit numbers, with leading zeros if needed, just to help keep things straight.Your problem only tortured me for about 2 hours this time.Dick:-beerchug

[Guest cwright]

Many thanks, Dick, that fixed it. However.... I am now considerably more ambitious and I think I have encountered another small problemette. I have six LOD8 areas arranged like this: AD BE CF They are listed in the order ABCDEF as per the ordering rule. But areas D and E do not appear! After some tests it seems that any LOD8 that has one to its left and below does not appear. In this case square C stops E from appearing and B stops D from appearing. If I take out B and C then the others appear correctly. The solution would be to put each column into a separate bgl. I wonder if Microsoft does this? Very strange. Hope this doesn't torture you for too long! Fortunately doing these kinds of tests is very easy using my program. It's now well advanced. About the last issue to resolve is the problem of when the data stream visits a given LOD13 square more than once - the equivalent problem with LOD8 squares was easily fixed. This problem is particularly important when making rivers. In a day or so I'll give more details of the program and hopefully I'll make the first version available for download some time next week. Oh, yes, the other thing would be the ability to add beaches.... Once again, many thanks for your help. Best regards, Chris

[rhumbaflappy 113]

Hi Chris.I'll see if I can get time to check the Cell ordering like you have it... ABC in one column then DEF adjacent in the next column, and see what I find.Also, are you saying you found the LOD13 Areas must be ordered?I haven't tested that, and never ran into that either. I thought I could have any order to the Areas within the Cell, and revisit them as I wanted, in any order, as long as I stayed within the Cell, before moving on.Dick

[Guest cwright]

Hi Dick, I'll be interested to see what you find! As for LOD13's, I don't believe they need to be ordered. The problem is more specific to the way my program works. The points are processed serially as per the data stream. So when the first set of points in a LOD 13 is processed the program doesn't know that the stream returns later, and it will make incorrect decisions, particularly when it adds points to fill the polygon. It shouldn't be too difficult to fix, hopefully I'll do it this weekend. Best regards, Chris

[Guest cwright]

Dick, I've done some more tests, this time with a circular lake that spans 6 LOD8 areas, againADBECF With all six LOD8's only D fails to appear in FS, so my earlier theory isn't quite right (that a LOD8 kills the LOD8 to its right and one position up). I think there are two possibilities: 1. There is an interaction between LOD8 columns going from left to right - a bit unlikely? 2. There is a bug in my program - even more unlikely! (only joking....) But I can't see any error in the asm text. Anyway, if you're interested, you can download the asm file here: http://www.kline.demon.co.uk/ABCDEF.asm The geographical location is given at the top of the text. Many thanks. By the way, the artifacts (the empty bands and the square on the right) occur because there aren't enough points - at some places on the circle the LOD13 on the edge doesn't have any points, which causes the filling-in algorithm to fail. Best regards, Chris

[rhumbaflappy 113]

Hi Chris.I assembled the BGL and went to the area in the sim.I slewed to the east a bit ( while using 'topdown' view ). On slewing back, most of the water disappeared! I then used a cockpit view, and the elevations were right... but the water was still gone.So, right now I'm stumped. Apparently the terrain engine doesn't like what you're doing, but I don't know why not.I'll play with the code a bit and see.Dick

[Guest cwright]

Dick, that's interesting! On my system only D (top right) is missing but on yours both D and E are missing. Could it be a function of system memory? (mine has 256 Mb with a 32 Mb Geforce 1). However, I know that if I compile the two columns into two separate bgl's then everything is fine. I'll try again without the filled-in squares which will reduce the number of LOD13 squares by a lot. Meanwhile, more strange observations! I had the idea of manually editing the asm text to change the LOD8 numbers of ABC. With the standard ABCDEF configuration only D failed to appear. With ABC moved manually one position to the left then both D and E failed! This indicates it's not a bug in the program, as the data for E did not change. I was then amazed to find that if I shifted ABC further to the left D and E still failed, even when shifted ten positions. I then shifted ABC up and down with no sideways shift. When shifted up three positions everything was okay. But when I shifted ABC down three positions, DEF were okay - but ABC itself failed to appear! This is really weird. This indicates an effect moving from right to left (i.e. DEF affected ABC) - unless it was wrapped around the whole world! I'll test again without the filled squares and report back! Best regards, Chris

[Guest cwright]

Dick, I just tried compiling it without filling in the squares, which vastly reduces the number of points/polygons. No difference - D still refuses to appear. I'm intrigued to know why both D and E failed on your system - and why you actually saw some water disappear! It does suggest there is a system factor. Very strange.... If there is a fundamantal problem then the solution will probably be to compile each LOD8 column into a separate bgl.... Best regards, Chris

[rhumbaflappy 113]

Hi Chris.To further confound you, I compiled the 6 Cells as 16x16 area fills... completely filling ABCDEF with water... and had the same problem.Now, after loosing a little more hair, I believe I found the fix.We are required to pad each column in the cell index with null entries, both North and South...Here's the end of your ASM file, changed to add Cells before A, after C, before D, and after F: Cell_472_248 EQU LWMCellID 0, 0, 3, 472, 248 Cell_472_249 EQU LWMCellID 0, 0, 3, 472, 249 Cell_472_250 EQU LWMCellID 0, 0, 3, 472, 250 Cell_472_251 EQU LWMCellID 0, 0, 3, 472, 251 Cell_472_252 EQU LWMCellID 0, 0, 3, 472, 252 Cell_473_248 EQU LWMCellID 0, 0, 3, 473, 248 Cell_473_249 EQU LWMCellID 0, 0, 3, 473, 249 Cell_473_250 EQU LWMCellID 0, 0, 3, 473, 250 Cell_473_251 EQU LWMCellID 0, 0, 3, 473, 251 Cell_473_252 EQU LWMCellID 0, 0, 3, 473, 252 LWMIndexStart label word LWMIndexHeader 10, LWMIndexData LWMIndexData label word LWMIndexEntry Cell_472_248, LWMStart, datamark_0, datamark_0 LWMIndexEntry Cell_472_249, LWMStart, datamark_0, datamark_1 LWMIndexEntry Cell_472_250, LWMStart, datamark_1, datamark_2 LWMIndexEntry Cell_472_251, LWMStart, datamark_2, datamark_3 LWMIndexEntry Cell_472_252, LWMStart, datamark_3, datamark_3 LWMIndexEntry Cell_473_248, LWMStart, datamark_3, datamark_3 LWMIndexEntry Cell_473_249, LWMStart, datamark_3, datamark_4 LWMIndexEntry Cell_473_250, LWMStart, datamark_4, datamark_5 LWMIndexEntry Cell_473_251, LWMStart, datamark_5, datamark_6 LWMIndexEntry Cell_473_252, LWMStart, datamark_6, datamark_6 LWMEnd label wordNote how I craftily forced the bogus Cells to use datamarks that point to themselves, in order to fool the terrain engine. *:-* Anyways, I think this will solve the problem with Cells... just pad the index with 'do-nothing' Cells, before and after the real deal, North and South, for each column.I think I actually saw this in the default BGLs... Christian Stock might clarify that, as he's spent more time peeking at the default code with a hex editor.Try it out and see what you get.DickP.S.I think the LOD13 Area order can be anything, and you should be able to revisit an Area as much as you want.

[Guest christian]

Hmm, I haven't noticed this myself, but never played with it either.The M$ default bgls have this structure though, Chris:ABCDEFI suspect D and E fail to show, because it's not in the right order...Cheers, Christian

[rhumbaflappy 113]

Hi Christian.Good to hear from you, as always.I'll play with the Cell ordering as you suggest. If that works, it's much better than having to pad the index with dummy Cells ( although that does work, it may rob some processing time ). Hopefully I'll have time tomorrow.Apparently the spanning of LOD13 Areas is not a problem... just the transition from one LOD8 Cell to the next. The SDK mentioned the ordering in passing, but it is critical, as Chris found out for us.Dick

[Guest cwright]

Christian, many thanks. It worked a treat! Best regards, Chris

[Guest cwright]

Dick, I tried Christian's suggestion and it worked perfectly. Here's a pic of Lake Circle in all its glory! http://www.kline.demon.co.uk/circle.jpg Hope you didn't tear out too much hair! Anyway, we got there in the end. Many thanks for your help - and thanks to Christian, too. I removed the obvious artifacts by increasing the number of points around the circumference. Currently, if the datastream passes through a LOD13 but there is no point there, the square filling routine will fail. As I said, the problem that occurs with multiple visits to a LOD13 square is purely a problem with the program. I've worked out how to fix that. Thanks a lot guys! Now I suggest you have a long, cool beer, relax and enjoy the rest of the weekend.... Best regards, Chris