An Island for FS2002

[Guest luissa]

Hello MartinYou say that the corner is at Lon = 24.960938 but it is really at Lon = 24.9609375 ! If you rounded it to Lon = 24.960937 then there would no problem as you were defining a boundary which was to the East of the meridional LOD10 line! By stating that you data starts at Lon = 24.960938 the resampler does not have altitudes to assign to left edge of your LOD10 square and it skips to the next LOD10. There is no data for it and no BGL is produced. I did not checked the Lat but the same problem could arise!Regards from Portugal (with snow! yes!)Luis

[Holger 0]

Hi all:if I may be so bold to jump in...I must admit I haven't read carefully each word of the above posts so some of this might be duplication ;-) but here are my thoughts why an island may not show an elevation:1. if the LWM land poly is NOT set to mesh-clinging (-9999)2. if the island sits where the default HYP file has declared a water LWM poly with sea-level elevation (default flattens can only be removed by editing or removing the HYP file)3. if the mesh itself is displaced relative to the island.Cheers, HolgerP.S. LWMViewer does display the declared elevation of LWM polys (NOT that of the mesh!) and a value of -1 indicates that that particular polygon is mesh-clinging (e.g., -9999 in Ground2K4 and .asm files).

[TheFiddler 5]

Thanks for further replies!> You could attach what you have ( BGLs, G2k4 files, ) > as a zipped file, and attach it to a post.Well, I would not have dared to terminally spoil your weekend, but since you're kind enough to ask... :-)Attached is a ZIP file with all you need:-- altMap.raw: the altitude map (needed only if you want to start from scratch, producing yourself the DEM file from this yourself)-- island.dem: the DEM file made from altmap above; to be used by resample.exe-- island.inf: using this with resample.exe produces the terrain for the "real" island at N60 E25 -- which then doesn't show up in FS2002, though.-- island2.inf: using this with resample.exe produces the terrain for the test island at N20 W20 -- this [em]does[/em] show up. Unfortunately it's the other one I really want...> When you make a mesh to exactly the dimensions of a source> file, sometimes the BGL doesn't get made, and sometimes it> just comes out wrong.> If your mesh source covered an area a bit larger than the> size you want to resample, then you can usually get the mesh> BGL.Now, this is getting interesting -- I read some doc.s which I (mis?)understood to say that you have to have precisely the coverage of one LOD square (in my case LOD10), and anything else wouldn't work. So far I have piously stuck to this "Law" -- which perhaps was not a good idea...And I was already wondering if giving explicit coord.s for NW and SE corner in the {Destination} chapter of the INF file, like you do, might not be a better idea than relying on NW corner plus square width/height or NumOfCellsPerLine/NumOfLines in the {Source} chapter.But I wasn't sure if I had understood how to do it. Thanks for the example! It also teaches me that apparently "NumOfCellsPerLine = 257" and "NumOfLines = 257" are not values written in stone, as I assumed.(Some of the scenery tools documentation is sometimes a bit confusing, IMO. But I have no wish to complain, as the tools themselves are so very good and useful. (I also know -- my job is in technical documentation -- that good developers are not always good documenters, too; and that they usually don't wish to waste their time on doc.s anyway... :-) )Cheers,Martinhttp://forums.avsim.net/user_files/65078.zip

[TheFiddler 5]

Hello Luis,(good thing you have snow, too -- so you have time to answer newbie questions! :-))> You say that the corner is at Lon = 24.960938 > but it is really at Lon = 24.9609375 ! Ahaa! That's one thing I don't like about the decimal degrees formats -- I can't get a "feel" for the figures... (and am always wondering if/when I might run into computer-internal rounding issues).Indeed, my Excel sheet (Richard Marklew's lodcalc.zip) has the correct value 24.9609375, but somehow it got rounded up during the copying -- and I didn't realize the difference is significant here.I also had a misconception (see message above) that the scenery boundaries must co-incide precisely with the LOD grid boundaries -- and this wrong idea makes the rounding issue worse, as then even a tiny deviation can bring you down "on the wrong side", just like you explain...> There is no data for it and no BGL is produced. And [em]that[/em] explains nicely why my non-working mesh BGL is only 1 kB, whereas the working one is 3 kB. The puzzle pieces are coming together...Happy skiing, Luis! (Give me a few more weeks, and I'll make you a nice slalom hill near Lisbo

[TheFiddler 5]

Thanks for the help, Holger!> 1. if the LWM land poly is NOT set to mesh-clinging (-9999)I checked, it is.> 2. if the island sits where the default HYP file has declared a > water LWM poly with sea-level elevation (default flattens can only > be removed by editing or removing the HYP file)Aha! Something else I didn't know and need to learn.(Psychologically amusing: I had heard of HYP files, but somehow -- and totally unwarranted -- I had formed the firm opinion that HYP files are some sort of devil's work to be found only in FS2004 -- so I happily ignored that whole issue. Now I actually [em]checked[/em], and lo and behold, FS2002 has them too, 1344 of them...! So much for my scientific mind. :-))> 3. if the mesh itself is displaced relative to the island.Yes, I thought of that, and tried to carefully co-align. But probably not good enough -- I'll have to re-check in the light of Luis's remarks about rounding.> LWMViewer does display the declared elevation of LWM polys > (NOT that of the mesh!) Ah -- that's important to know, thanks! The Readme (just to show I did read it ! :-)) says "the height of any LWM data under the mouse pointer", and I mistook that to mean terrain (mesh) altitudes.Cheers,Martin "The Mesher"

[TheFiddler 5]

Good morning everyone,anyone at all [em]still[/em] following this thread?(I noticed we even managed to turn it into a [em]flaming[/em] thread -- wow! Meaning the icon, not in the Austryelian sense of "flyming thread" :-))In the middle of the night (this is really getting to me... :-)), I realized that I forgot to include the LWM files in the ZIP I posted yesterday, which are of course the most important ones if anyone would really want to completely re-live my tribulations...So here is an updated version of that ZIP, including the LWMs; the other files are still the same, just re-included for completeness.Note that the so-called "topoMap", to be used as background map in Ground2k, looks much like the altitude map for grises50; but its only purpose here is to show the outlines of the island; the real topography (airport, roads, etc.) will come later (if I ever get that far).Dick, (if you are still reading this), one other straightforward (I hope) question about the INF example you posted yesterday.In the destination section, you are using

{Destination}...UseSourceDimensions = 0

and then give the four corner point coordinates (NorthLat etc.); that is clear.But in the source section, there is still also

{Source} ...Lon = 12.499003Lat = 35.540535...

What is the purpose of this Lat/Lon point? Is it there just because the entry is needed, without being actually used (since the actual area is defined in the {Destination} section); or does it still have a real function?Would it perhaps mean that the source area (= the altitude point grid) can come from other coordinates than the destination area (covering the scenery), and that the data will be "mapped", accordingly? E.g. I can take an altitude grid (DEM) from Finland (NW corner defined by entries Lon=25.0; Lat=60.0 or so), and "map" it to an area in Portugal* (with appropriate entries for NorthLat...etc)?*complete with the snow, of course, Luis :-) I re-read the SDK doc (Creating Terrain.doc) about INF files umpteen times, but it is rather vague as to the difference between UseSourceDimensions = 0 and 1, and the related other entries. They do talk about "over- and undersampling", which may mean this mapping of any source DEM area to any destination scenery BGL area, but I'm not sure if that's what they really mean.Anyhow, have a nice Sunday everyone!Cheers,Martin...and yes, I carefully closed all my opened tags, but the default message font doesn't return anyway...http://forums.avsim.net/user_files/65174.zip

[TheFiddler 5]

Progress!After modifying the coordinates in the INF file (according to Luis's advice), and also following Dick's example about UseSourceDimensions = 0 etc., I have finally succeeded to generate a mesh BGL file which is valid, and shows up correctly (with regard to terrain and location) in TMFviewer and LMWviewer. Hurra!Unfortunately, in FS2002, the island is still flat.So, looking into HYP files (as per Holger's pointer) will be next, I guess...Cheers,Martin

[TheFiddler 5]

..yep, definitely the HYP files.From a nice web site (John Woodside's notes on scenery design, http://www.homepages.mcb.net/bones/04FS/sc...esign/CLM2.htm), I learnt the trick of experimentally de-activating the NW Europe (eurnw) scenery.Now my island has the terrain, and it's correct! Of course, this is no solution, as now the island coastlines (in fact all coasts of NW Europe :-)) are lost, but we're getting there...Now to decipher HY*.bgl naming conventions, and finding the specific one around my island...(BTW: These progress (or otherwise) reports are intended to perhaps help some poor souls after me. If someone thinks this is spamming, let me know, and I'll cease and desist...)Cheers,Martin(who BTW knew who the Luis'es are, but only now realized who Dick/rhumbaflappy actually is. Wow - talk about help from the giants...! :-))

[rhumbaflappy 113]

Hi Martin.LWMViewer can load the correct files if you give it co-ordinates... so you should be able to find the HP file quickly.Edgar Knobloch has invented an LWM converter:http://library.avsim.net/esearch.php?CatID...Scen&DLID=43104This will take an LWM source file ( HP ) and change all the water to CFS2-style mesh-clinging.So you can export the HP code from LWMViewer, convert it to mesh-clinging, recompile it, replace the default HP, and your island will be fine. Or you could find the LWM code specific to your island's area in the originals, and hack the code for the LOD8cell involved. Again, LWMViewer will help, and again, you'll need to replace the default HP.I started a diet about a week ago, so I won't be a giant anymore. :)Dick

[TheFiddler 5]

Hello again,and thanks again!>LWMViewer can load the correct files if you give it>co-ordinates... Not for me, unfortunately, it keeps looking (in the Registry) for FS9 entries; and I don't know (yet, have contacted the author, though) how to point it to my FS2002.No big deal, however -- I (mis)used FlightManager which, as a utility function, has a nice BGL coverage display.And I had already decompiled the HYPnnnnn.bgl (with BGLanalyze -- LMWviewer is probably better), and did find the LOD8 Cell in question.Still shying away from ASM fiddling, though, so was glad about your next tip, thanks: >This will take an LWM source file ( HP ) and change all the>water to CFS2-style mesh-clinging.>>So you can export the HP code from LWMViewer, convert it to>mesh-clinging, recompile it, replace the default HP, and your>island will be fine. Wahh, that sounds reckless :-) But I faithfully tried it, and decompiling (with LWMviewer this time), running through cfs2conv, and re-compiling all went well.However, I'm sorry to report that the resulting BGL, when replacing the original HYPnnnnnn.BGL, crashes FS2002 (in module terrain.dll, with code 0x00000e18). The BGL does display correctly (and identical to the original HYP) in LMWviewer, though, so it's not totally broken.(The cfs2conv doc.s recommend a BGLC version dated 4/3/2002, while mine is 4.June 2002 -- could that make a difference?)So it seems, it's now time for your next suggestion:>Or you could find the LWM code specific to your island's area>in the originals, and hack the code for the LOD8cell involved.>Again, LWMViewer will help, and again, you'll need to replace>the default HP.And [em]that[/em] means, now I have to come to grips with ASM code (as described in your "TMF-BGLC Design")... :-)But why not, now I've come so long a way already...Cheers,Martin

[LuisFelizTirado 33]

Boy, this is really getting complicated.It has not snowed here in over 5 million years, but I shall make bold enough to also make some comments.First, Martin the mesher, the "flaming" icon means that this thread has been viewed over 1 gazillion times so far (beats MacDonald's). How about that? This is a "hot" topic. Your question has been of great interest to everyone here. Congratulations! Keep them coming.Second, why have you made a fictitious island? Is it because you want to practice before you make modifications to a real island? If this is the case, there is no need to practice on a make-believe island - just practice on the real thing. Or perhaps you really want to make this island. There have been instances of people making fantasy scenery - surprisingly, this has often been very popular.Third, here is the problem with your altitude mesh. You have drawn the island over water where there was no previous Land Mask. Unfortunately, in Flight Simulator, the altitude of the sea is always set to... sea level! Or rather, to an altitude of 0 m.To make matters worse, we do not have any straightforward means of overriding this altitude. An altitude mesh placed over "Flat Water" will not affect it and the island will always remain at an altitude of 0 m.(Note to our friends at Microsoft: Water flattens must be deleted. Please provide us means of either excluding or superseding water flattens.)There are ways to get around this.First method: Using Ground2K4, use the Re-mesh function to raise elevation points on your island. This is rather a delicate operation and not always very easy. Or you could draw Land Masks within your island and assign a different altitude to them. Good luck.Second method: requires LWMViewer by Jim Keir and Edgar Knobloch's CFS2Conv, in the AvSim library (many thanks to them both). With this method, you take the default hyp bgl for the area of your island, convert the altitude of the water to a mesh-clinging value (-9999), and then re-compile it. This replaces the default water flattens, your island will no longer be flat, and the altitude mesh will now be effective. Here is the procedure to follow: - 1. Find the relevant hyp bgl with LWMViewer. With FS2002, you will have to look at each one to find the correct bgl, as we never figured out the naming convention, but this should not be too hard; - 2. Using LWMViewer, export the source file; - 3. Using Edgar's program, convert the source file. This will automatically remove that 0 m. altitude and replace it with a mesh-clinging value; - 4. Compile this modified source file using BGLC.exe, and replece the deault bgl with this one; - 5. Your fantasy island and its altitude mesh will now work.Good luck.Best regards.Luis

[TheFiddler 5]

Thanks, Luis.Dick gave the same advice, and I have already gone through the cycle twice, exactly as you suggest (details above in the thread). The first time I just de-compiled, ran cfs2conv, then re-compiled, but the resulting BGL crashed FS2002. (Perhaps because the LWMFileHeader now had the CFS2 version code 0x100, instead of FS2002 0x201? As I found out after looking at the macros a bit closer).Anyhow, in the second round I did some manual adjustments (e.g. left that LWMFileHeader alone), and this resulted in a BGL with the correct size (same as original HYP file), and it does not crash FS2002 any more. Good!But the island coast is still not OK. On the other hand, I got highly interesting new seascape features:

[rhumbaflappy 113]

Hi Martin."But I faithfully tried it, and decompiling (with LWMviewer this time), running through cfs2conv, and re-compiling all went well.However, I'm sorry to report that the resulting BGL, when replacing the original HYPnnnnnn.BGL, crashes FS2002 (in module terrain.dll, with code 0x00000e18). The BGL does display correctly (and identical to the original HYP) in LMWviewer, though, so it's not totally broken."You've stumbled onto something I hadn't seen before. CFS2 style LWM polys do work in FS2002, but this one does crash the sim. I had noticed the default HP files in FS2002 overlap the same LOD8 cells. So perhaps the presence of both types in the same cell is a problem.The CFS2-style water works fine in FS9 and in CFS2.If you still want to hack the asm of the unconverted original, you could change the instances of "height, fraction" to "-9999,0", and recompile. In FS2002, "-9999,0" is mesh-clinging.You'd need to identify the LOD8cell and LOD13 areas involved.Wouldn't it just be easier to try a remesh with Ground2K?Dick

[TheFiddler 5]

YEEEHAAH!!!(to put it mildly...)

The Isle of Plight

[p class=dcmessage]Got it!!! Thanks for that final piece of advice, Dick -- the island now is where it should be, coastline correct, terrain correct, landable, and there's not even any damage to the other coastlines in the LOD8 cell...What a tour that was -- great that it gets a happy end, after all :-sun1And it pleases me almost as much as the result that none of the many problems apparently were caused by (overly :-)) stupid mistakes on my part -- that risk was the [em]real[/em] stress...As it turns out, I had to absorb, and could put to good use, really each and every single bit of advice received from you, Luis, Luis, and Holger. Thanks for all your time, patience, and helpfulness (and while on diet, too... :-)) -- to get this kind of support is truly a great experience.>You've stumbled onto something I hadn't seen before.Hehe, I'm good at that -- the born beta tester, always apt to quite unintentionally break something in ways innovative even to the experts :-)Not so good a talent if you're after results, though...>If you still want to hack the asm of the unconverted original,>you could change the instances of "height, fraction" to>"-9999,0", and recompile. In FS2002, "-9999,0" is>mesh-clinging.Yes, thanks, that is what I did, and it did the trick.>You'd need to identify the LOD8cell and LOD13 areas involved.Hmm -- ok the LOD8 cell is easy, but about the LOD13 Areas: Are you saying I should have to analyse in detail every LWMDataAreaFill and LWMPoly2 to find out which LOD13 Area they might affect? I did figure out the grid indices (x, sub-x, and y) of all Areas involving the island. But it is still not easy to find them in the ASM source, as the various LWMDataAreaFill variants (1x1 to 16x16) cover different ranges, and the polys are usually irregular (non-square).In the end, I just set all -1 height values to -9999, for the whole LOD8 Cell, and that seems to work (unless I broke something somewhere which I haven't yet found).>Wouldn't it just be easier to try a remesh with Ground2K?In fact, that's what I had tested before even looking at grises50. However, I wasn't quite satisfied with the re-meshing procedure (may be I need more practice): for one thing I find it rather painful to do manually, even for such a relatively small area; and it is also difficult to achieve the intended results -- one must have a very clear idea of which altitudes to set where, how to get the transitions right, etc. But more important, the purpose of this whole exercise (beside the birthday) was to learn the techniques, and on the whole, grises50 seems the more versatile method: it can with equal ease be applied to areas of any size, and can use "hand-painted" as well as real world altitude data; whereas (I think) re-meshing in Ground2k will in practice be limited to smaller corrections.So, thanks again for all the support! :-beerchug (caloriless!)I hope the other guys will read this, too.Cheers,Martinfrom the Isle of Flight[/p]

Mt.Richard (backgr.), Vista de Los Dos Luises (centre, with plane),and Holger's Beach (lower right)

[LuisFelizTirado 33]

Congtatulations, Martin. Looks very, very good! Your friend will surely be happy with his island.And, many thanks for the honor - never had a vista named for me before!Best regards.Luis