Automatic ASM creation

[Guest]

Wounderful,I can test it for you.I have ArcGIS 8.1//Anders

[Guest cwright]

Anders, thanks for the encouragement. As things turned out, there remained a lot of problems to solve but I'm well advanced. I think it will be working in another two or three days, though with some bugs still to resolve. Initially it creates flattened water that could be used for lakes or also for creating coastlines. Hopefully, when Dick releases the next tutorial, it will be extended to create coastlines and beaches, probably with waves. Right now the program creates the lat/long data from a mathematical formula for testing purposes. I will then add the capability to read a list of lat/long coords and also to read a hand-drawn .raw image file. It should then be easy to extend it to read other formats. With a bit of luck I'll be able to post a new screenshot of the circular lake - but this time completely filled with water! Best regards, Chris

[rhumbaflappy 113]

Hi Chris.I should release a new LWM ( Land/Water Mask ) tutorial in a week.Much of the material will be redundant to the first tutorial, but the terminology will be completely different, matching the naming conventions of the FS2002 Terrain SDK.It will include a new set of Macros named TDFMacros.inc, that will handle all the needs of BGLC programmers regarding terrain data file polys and lines. It also will contain TDFHeaders.inc, a macro to simplify the BGL and Terrain header creation. BGLHeader 64, 61, 7, 4, LWMHeader, TerrainHeaderStart...replaces all the code needed for the headers, and clarifies the coding. The numbers are integers to represent the bounds. Bob Bernstein pointed out that he routinely adds a degree or two to his scenery... so why do we need Minutes or Seconds or decimals at all? We don't. So that's why I simplified the code. Also, the TDFHeaders.inc eliminates the need for txt2asm... so BGLs can be produced by drag'n'dropping the TXT file directly onto the BGLC icon. The old way of writing the headers still works, in case someone needs to define the bounds more precisely.LWMHeader is the name of a label marking the location of the LWM header. TerrainHeaderStart is supposed to be a label marking the start of the VTP header, but as this example has no VTP data, I pointed the macro to itself! That places a zero in the Terrain Header in the neccessary spot to cancel out the VTPs.

include TDFMacros.incinclude TDFHeaders.inc; Flat WaterMask FillBGLHeader	64, 61, 7, 4, LWMHeader, TerrainHeaderStart 								LWMHeader	label	word; LWM_Header ID label	LWMFileHeader	513, LWMIndexStart, LWMStart, LWMEndLWMStart	label	word	data_start_0	label	word		LWMDataAreaFill16x16	0, 1, 0, 1, 0, 0, 0		LWMDataAreaHeight	-9999, 0		LWMDataAreaFill16x16	0, 1, 0, 1, 0, 0, 1		LWMDataAreaHeight	-9999, 0		LWMDataAreaFill16x16	0, 1, 0, 1, 1, 0, 1		LWMDataAreaHeight	-9999, 0		LWMDataAreaFill16x16	0, 1, 0, 1, 1, 0, 0		LWMDataAreaHeight	-9999, 0	data_end_0	label	word	data_start_1	label	word		LWMDataAreaFill16x16	0, 1, 0, 1, 0, 0, 0		LWMDataAreaHeight	-9999, 0		LWMDataAreaFill16x16	0, 1, 0, 1, 0, 0, 1		LWMDataAreaHeight	-9999, 0		LWMDataAreaFill16x16	0, 1, 0, 1, 1, 0, 1		LWMDataAreaHeight	-9999, 0		LWMDataAreaFill16x16	0, 1, 0, 1, 1, 0, 0		LWMDataAreaHeight	-9999, 0	data_end_1	label	word	Cell_396_78	EQU	LWMCellID 0, 0, 1, 396, 78	Cell_396_79	EQU	LWMCellID 0, 0, 1, 396, 79	LWMIndexStart	label	word		LWMIndexHeader	 2, LWMIndexData	LWMIndexData	label	word		LWMIndexEntry		 Cell_396_78, LWMStart, data_start_0, data_end_0		LWMIndexEntry		 Cell_396_79, LWMStart, data_start_1, data_end_1LWMEnd	label	word

This short BGLC code covers 2 entire LOD8 Cells with water. In fact, I believe there is a Cell fill technique that will make the code even "tighter". That's why I need a week or two for the tutorial.I think M$'s terminology is more descriptive, once you get used to it. And the new macro terms will ease the transition into C++ coding, if anyone wishes to go that route.Dick

[Guest]

Fantastic work fellas! I am so grateful for your efforts. Thanks to rhumba's tutorial and some other people, I have been able to make lakes. Can't wait for the next tutorial. Will be using that to modify Midway Island in CFS2 for the first job... then of course... back to Pearl.

[spotlope 0]

Hope this isn't too off-topic, but I was reading through the VTP macros you posted recently, Dick, and I have a question about coordinates. I noticed that there are only row/col coords for what look like the LOD13 areas defined in the macros, not the row/subrow/col trio I'm used to. This may be a basic newb question, but how to you go about getting those numbers? The LOD calculator in FSRegen does coord calcs the "old" way -- am I missing something obvious? Wouldn't surprise me if I am. I have a project that is missing only ground polys, and I'd love to get it finished and released into the wild. Any insight you can give us mortals?thanks,Bill Womack

[rhumbaflappy 113]

Hi Bill.You're not missing anything!The old "TMF" way of coordinates was defined by Christian Stock. He was working alone and totally in the dark. He spent months staring at hex numbers, and trying to make sense of this stuff. The coordinates, as well as the terminology were Christian's invention... and it worked pretty well!Now...With the release of the FS2002 Terrain SDKs, we need new terminology, and new macro structures to match the SDK. The new macro sets I use are TDFMacros.inc and TDFHeaders.inc TDFMacros.inc has about 500 lines of code, and I've tested it pretty well.TDF stands for Terrain Data File, and the macros include everything in order to make FS2002 and CFS2 terrain BGLs... both Land Water Masks ( LWMs )and Vectored Terrain Polygons/lines ( VTPs ).The coordinate system, and everything else, will be the same as the SDK info. No more column, subcolumn, row... just X,Y.The TDFHeaders.inc use one line of code to replace about a zillion lines of BGL and Terrain header info. This new macro used rounded integers to enclose the BGL ( Bounds ), instead of micro-defining the bounds with "degrees:minutes:seconds.decimalsforever". Bob Bernstein gets the credit for the idea, as he pointed out he generally adds a degree or two to the bounds to enclose the scenery. So why not use simple integers to define the header bounds? It works... and also eliminates the need for Christian's 'txt2asm'. Just drag the TXT file onto the BGLC icon, and you get your BGL!I've made a new 'TDFCalc' program to give us the info ( replacing fsregen's TMF calculator ), organized 11 different LWM BGL types with examples, and I've got about half of the new LWM tutorial done. So, about one more week and the tutorial will be posted, with the calculator and the macros.Here's an example of the new LWM area fill ( 16x16 Areas {LOD13} ):

include TDFMacros.incinclude TDFHeaders.inc; AreaFillWaterBGLHeader	34, 28, 30, 22, LWMHeader, TerrainHeaderStart 	LWMHeader	label	word					LWMFileHeader	513, LWMIndexStart, LWMStart, LWMEndLWMStart	label	word	datamark_0	label	word		LWMDataAreaFill16x16	0, 0, 0, 1, 0, 0, 1		LWMDataAreaHeight	-9999, 0	datamark_1	label	word	Cell_440_166	EQU	LWMCellID 0, 0, 3, 440, 166	LWMIndexStart	label	word		LWMIndexHeader	 1, LWMIndexData	LWMIndexData	label	word		LWMIndexEntry		 Cell_440_166, LWMStart, datamark_0, datamark_1LWMEnd	label	word

The code is a lot cleaner, and shorter. And it follows the SDK to the T.Dick

[Guest christian]

I can explain that. As Dick pointed out, I tried to beat sense into hex numbers. I saw a pair of bytes at the beginning, and then found that the second byte seemed to run from lowest to highest number in each bgl file. So I assumed that those 2 bytes were seperate.That was wrong. The row was in both bytes. Because I split it up into 2, I ended up with one part in the first byte , and the second one in the second part. Hence row and subrow.In hind sight it really makes sense just to glue both bytes together and just have a row, but afterwards one is over smarter...Cheers, Christian

[Guest cwright]

Dick, that's brilliant! By the time you release the tutorial my program should be fully functional. In fact there's a very good chance it'll be working this weekend, though probably with one or two minor bugs to fix. It should be pretty easy to convert it to the new format. By the way, will the tutorial include beaches? (and even waves?) An example of an island with beaches and waves that covers two LOD8 squares would be great (hint, hint....) Many thanks! Best regards, Chris

[rhumbaflappy 113]

Hi Chris.Shorelines are VTP Method 2 lines. The tutorial for all VTP polys/lines will be 6 weeks away. I have the macros, but I'll need to have code examples. I did post some info concerning shorelines and waves in a previous post. Those used Christian's TMFMacros.inc, and work well.Old shorelines can be excluded ( I believe from the entire LOD8 Cell only ), by adding 128 to the 'DECAL_GEOMETRY' macro's type number. That number is now called the 'VTPLayer'. Shorelines are layer 8 ( DECAL_HYDRO_LINE in Christian's TMFMacros.inc ). So a new line could start with 136 as the layer value ( 8 + 128 ).So old shorelines are removed once you add the new lines. You'd want to use the exclusion on the first VTP data area macro call only, as that will exclude that Cell's layer #8 first in the datastream. You don't want to keep excluding the layer, as it will erase your work as you go along!I haven't tested this completely, so there may be errors in my thinking. :-eekDatastream is a concept we all need to get used to. That's what allows you control over the layer, as each new instruction overworks the previous instruction for that layer. The strange-looking "Data Hierarchy" charts in the FS2002 Terrain SDK actually do show how the terrain is manipulated. :)Dick

[Guest]

>>Datastream is a concept we all need to get used to. That's >what allows you control over the layer, as each new >instruction overworks the previous instruction for that >layer. The strange-looking "Data Hierarchy" charts in the >FS2002 Terrain SDK actually do show how the terrain is >manipulated. :) >I have to agree with you Dick. Those charts really tell you the whole picture. They are funny looking, but once you sit down and look at them and review the record structures, it all comes together. I have to say that the Terrain documentation is very well written and complete. Now if I could just figure out the elevation BGLs, I could probably come up with a better resampler that incorporates terrain decal data so that rivers, lakes and shoreline exactly match the BGL elevations. By using the resampler for the elevation data, I still see a bit of an offset (aka cliffs) with lakes in mountainous areas. I'm checking my data, but I think it may be due to the interpolation methods that the resampler uses.Christain, didn't you have some information on the elevation BGLs?Lee.

[Guest christian]

> I have to say that the Terrain >documentation is very well written and complete. Really? I still can't decompile VTPWidePoint entries (decal lines)! The 3 reserved bits seem to have some significance! Otherwise, I agree, its quite good...>Now if I could just figure out the elevation BGLs, I could >probably come up with a better resampler that incorporates >terrain decal data so that rivers, lakes and shoreline >exactly match the BGL elevations.you get that if your datasets don't match. If the dtm is built from the same vectordata you're using for rivers, etc, you won't have that problem...>Christain, didn't you have some information on the elevation >BGLs? Well, I still have to crack the compression algorithm. Without that we are stuck. And I don't think I can do that on my own, since I don't know enough about compressions algorithms. I suspect a lossless 2D compression, but that's not enough info...Cheers, Christian

[Guest cwright]

>Hi Chris. >>Shorelines are VTP Method 2 lines. The tutorial for all VTP >polys/lines will be 6 weeks away.... Hi, Dick Take your time, I'm sure it'll be worth it! I'll be busy working on my program for some time. It's fairly well advanced now. The screenshot shows the display. The map display was very useful as it allowed me to ado a *lot* of trouble shooting without having to run FS. You can clearly see the extra points added by the program to fill in the squares. The squares are the LOD13 squares and the line to the left is the edge of a LOD8 square. In the FS shot you can see several missing sections, so there's still work to do! I tried successively larger areas. There are problems, when the same LOD8 square appears at the beginning and end of the list it fails completely (nothing shows). This inevitably happens for a closed polygon. This could probably be fixed by re-arranging the list. It also looked as if it fails for multiple LOD8 squares, though it may be something to do with the above problem. I'll also need to test it with much more complex shapes. I suspect it could fail in many interesting ways! The last major addition is to fill in all the squares inside the polygon. That should be working today. As it turned out, this project was *much* bigger than I anticipated a week ago, but it's been fun! Best regards, Chrishttp://www.kline.demon.co.uk/circle_5.jpghttp://www.kline.demon.co.uk/circle_4.jpg

[Justin Toposim 16]

HI Lee,Make sure your two datasets (DEM & DLG) are in the same projection and Datum. WGS84 is different than, say, NAD27 or NAD83.Also, I suspect that something is lost in translation between between the source data coordinates and FS2002's coordinate system. A few meters is all it takes sometimes. (Not sure what data source MS used for Hawaii, but the shorelines are off by what seems several hundred meters in spots.)Perhaps a better tact would be to use the DEM itself to create the lakes and shorelines. Maybe an algorithm to detect perfectly flat areas in the DEM and turn those areas into water. ??JustinFSG

[rhumbaflappy 113]

Hi Lee.You'll probably adjust your program to take advantage of the LWMDataAreaFill?x? commands. This is new for us, as it was revealed in the Terrain SDK. It allows blockfilling of Areas ( LOD13 ) within Cells ( LOD8 ).Also Cellfilling is possible, and that uses no AreaData at all... just fills entire LOD8 Cells.I'm still hoping to post the LWM tutorial today ( 9/9/02 ), but I still need to include an example of "meshing-up" a re-masked coastal area, and do a final proofread.Dick

[Guest]

I've looked at using the dem for shorelines and lakes. It actually comes out about the same as if I use the DLG and DEM's together. This is why I believe there is some sort of error, probably a rounding error either on my part or the resamplers part. I'm looking into it to see if I can nail it down. That's why I would really like to know the layout of those elevation BGLs. Then I have the program allow the user to edit on or the other. And then compile both the elevation BGL and the flatten BGL for perfect fits. Right now it's as you say, only about a few meters off. And only with some vertices.Lee.