New version of AutoAsm available

[Guest cwright]

Michel, yes, if you change the geographical coordinates or size, the relationship between the lines and the LOD13 squares (the squares on the map display) will change. As it's the relationship between the lines/points and the LOD13 squares that can cause problems, then the problems are likely to change. When I earlier tested your image I guessed a size of .15*.15 degrees and I placed it arbitrarily at N10 E40 (my usual testing area). Try it and see. With these settings there were no errors. Also, depending on the water height you use, you will get spectacular cliffs, due to the water flattening effect! The good news is, that my latest development version fixes those anomalies that appeared with the correct settings. It's getting there.... Best regards, Chris

[Guest cwright]

Hi, Dick, I looked into the anomalies shown on the screenshot. First, it looked to me like the asm data was correct, with one exception, the large chunk of land on the top of the bulge (24,17). The program had failed to add two fill points at the top of the LOD13. I have done several bug fixes the last couple of days, and the good news is that the latest dev version fixes it correctly. In fact virtually all the problems I encounter now are to do with adding the fill points (the extra points in the square corners). With a number of polygons waltzing through a single LOD13 it can get complicated! However, the other anomalies (below the airport) are more difficult to explain. It looked to me that the asm data was correct. Unfortunately, because I don't see the extra landclass I can't see the error first-hand, but I had the idea of simply increasing the LOD8 x value by one, which would shift the whole thing a fraction of a degree to the east. If those anomalies were normal geometrical effects caused by program errors (of which I have much experience now!) then they should still show when shifted to the east. But after shifting the anomalies did not appear. Just a shot in the dark - could there be a problem caused by the default scenery such as the VTP beaches etc? Or something to do with the default landclass that presumably extends a bit beyond the beaches? If this were so then shifting to the east would eliminate the problem - which is what happened.... Best regards, Chris

[Guest Richard Hill]

Cris;All I can say is you are the MAN! Although I was a loyal FS Simmer from FS2 up to FS2000 where I became unimpressed with it's features. I then went to fly and after TerraScene 2.0 was was released I was able to create rather good VFR scenery. Although the water nask and elevation task was beyond my aging mind. Will you be producing any step by step documentation on converting TerraScene to FS2002 or better yet a progran that will take the same data used in TerraScene and directly develope FS2002 VFR scenery. FS2002 is a fantastis simulator but after FS4 M$ has left us older and or less knowledgable users out of the process of designing home town scenery. From what I have read most SDK tools are not very user friendly.Again thanks for having such love for FS2002, and its users to develope user friendly progams.Richard L Hill;

[rhumbaflappy 113]

Hi Chris.Below the airport, the drawing was cutoff in the middle of the LOD13 Area... so the 'block' extencing into the ocean, was caused by my suggestion to "fill" the Areas with land first, then cut the water mask. If the picture is short of the entire LOD13 Area, you'll get the landfill... but the mask is too short ot trim it back. LWMDataAreaDrawPolygons 1,3,1,18,13 LWMPoly2 59,0,0,0,0 LWMPoint 1,42 LWMPoint 1,42 LWMPoint 4,42 LWMPoint 8,42 LWMPoint 14,42 LWMPoint 17,42 LWMPoint 23,42 LWMPoint 27,42 LWMPoint 33,42 LWMPoint 36,42 LWMPoint 42,42 LWMPoint 45,42 LWMPoint 52,42 LWMPoint 55,42 LWMPoint 61,42 LWMPoint 64,42 LWMPoint 71,42...............You get the point ( pun intended ). the y value is cut off at 42 ( the bottom of Michel's bitmap.To overcome this, you may need to force a cutoff at the LOD13 Area bounds, so partial masks are not included... or perhaps an option to do this.I also noted a lot of Area masks that Michel could cull out of his code... the type: LWMDataAreaDrawPolygons 1,3,1,18,14 LWMPoly2 4,0,0,0,0 LWMPoint 1,1 LWMPoint 255,1 LWMPoint 255,255 LWMPoint 1,255It is an entire LOD13 Area masked to water. There are lots of these polys. They are ocean and probably have no landclass under them, so they could be removed. I don't know if that's something you want to add to the progam, but it might be possible ot mark an Area as 'ignore', and the code won't be generated for that Area. It's easy to just delete the extra coding in a text editor. But I understand your intention is to avoid hand-coding with this program. The extra poly do no harm, but they do add flattening, and they must add to the CPU burden somehow.Dick

[Guest Claviateur]

Hi Chris and Dick Thanks allot for your continous help and experimentations with my coast project. Actualy I hope this exemple will help Chris to add to AutoAsm some options to make it better version after version. I am learning allot from this discussion!!CheersMichel

[Guest cwright]

>..................>You get the point ( pun intended ). the y value is cut off >at 42 ( the bottom of Michel's bitmap. Hi, Dick, yes, I understand....>I also noted a lot of Area masks that Michel could cull out >of his code... the type: .............. Of course these are the squares the program adds to fill in the polygon. If you were creating a lake you'd certainly want the polygon to be fully filled! In Michel's screenshot you can see the white drawn polygon extends all the way over to the left. It could be easily modified so the LH of the polygon runs a lot closer to the coast and so would generate a lot less redundant squares. By the way, do you have any ideas on the problem I mentioned? I tried both your examples to add the squares above the bulge - but I see nothing at all! It means I'm unable to test this new method because I don't seem to see any land beyond the default coast. Very strange.... Best regards, Chris

[Guest cwright]

Richard, thanks for the kind words! Unfortunately I don't use TerraScene so I can't be of much help. However, Dick (rhumbaflappy) has been using it and it was at his suggestion that I added the TerraScene water mask import feature. I know Dick is very interested in the use of TerraScene for FS, so I'm sure he'll be able to help you. Best regards, Chris

[Guest cwright]

Dick, many thanks for the email. Now I can see it clearly! I modified AutoAsm to generate the 1,1,1 option to show the land class. With this version there are no anomalies caused by the program. Here's a screenshot: http://www.kline.demon.co.uk/coast.jpg Most of the remaining anomalies occur because the default land class does not extend far enough out to sea. Actually, there are two distinct cases.1. Where the coast is inclined at, say, 45 degrees, for a small stretch of coast, there are actually two LOD13 squares with land class extending to the west of the beach. If the data stream passes through the LOD13 on the extreme left, then that square will be correct - but as the data stream does not pass through its brother to the right, it will show a triangle of water. Without a diagram this probably sounds meaningless. Anyway, that was easily corrected. At two places where this occurred I added an entry like this for the square with a triangle of water: LWMDataAreaDrawPolygons 1,1,1,30,14 LWMPoly2 0,0,0,0,0 It wakes up the land class but adds no polygons. This works fine. 2. The anomaly just below the airport occurs because the datastream is too far to the west of the LOD13 through which the default coast passes. By using the same method as above I could extend the land to the western edge of the land fill LOD13. You can see in the screenshot that the water 'hole' is now smaller. But there is still a gap between the data stream and the western edge of the land class. I guess the only solution is to add more land class to guarantee the water polygons have enough to bite on. With the anomaly at the bottom, I cheated. I simply filled the LOD13 with water. The best solution would be to make the edges of the water polygon exactly match a LOD13 square. This could be done by choosing the image size to exactly fit the LOD13 squares. Anyway, if adding additional landclass fixes the problem, then we're home and dry! (pun intended). Michel, I believe you said you had added additional land class data. Does that cure the water gaps when using the modified bgl? I've emailed a bgl made with the latest version of Autoasm. If the extra land class does the trick then the problems will be nearly over! Best regards, Chris

[Guest Claviateur]

Hi Chris :)Here is the jpg I sent you by email. Big Success!! Here I put it on the forum so Dick can see it too. I see no anomalies myslef exept the land stripes on the left side of the screenshot and on the top as well (they are croped in this image). They are a square portions that the coast did not bite. Actually as you notice my Landclass is different and the difference is the fact I changed it with FSLandClass and I made the landclass extend inside the see. Might this be the cause? I can try with the default one.If those are the details that are to be solved then I think the whole problem is fixed. Now what will remain for me to do is the adjustement of the Long and Lat to position the coastline in a way to match the white line I pasted over the screenshotCheers! :)Michel

[Guest cwright]

Michel, that's looking great! Your additional landclass has done the trick. As you say, there is still more to do but it looks like the fundamental problems are solved. You should be able to get rid of the land stripes on the left etc by adjusting the landclass. I suppose the drawback of this is that you may have to design the landclass for quite a large area, maybe one whole LOD8 area....but then I'm sure the default landclass could be improved a lot! Best regards, Chris

[Guest fumey]

HelloI read in your messages that you have problems with complex polygones.Could you be more precise : concave or convex, how many points is the maximum for you ?Thanks for all of you.Christian

[Guest cwright]

Christian, it's not so much a function of the actual shape (i.e. convex or concave) as far as AutoAsm is concerned. If there is one large polygon the program has to split it into smaller polygons, each one fitting into one LOD13 square. If the polygon is fairly simple then it may only enter a given square once; but if the shape is more convoluted it may re-enter the same square several times, which makes things a lot more complicated. And then, of course, *other* polygons may enter the same square as well! There's no limit on the number of polygons as such, but there is a limit currently of about 250,000 points - it's set by the size of the program's arrays. Best regards, Chris

[Guest]

Hi chrisI don't know that happening, so, I put all in order (coordinates, xy, raw file...), compiled correctly and nothing appears, NOTHING.., I'm tired, and I have got a headache... :-swordHelp please!Pablo

[Guest cwright]

Pablo, I'd need more information to know what the problem is. Are you saying that you generated the asm file but you couldn't compile it with bglc? Or did you load the image into AutoAsm but it didn't generate an asm file when you pressed the ASM button? Let me know and I'll see what I can do.... Best regards, Chris

[Guest]

Hi ChrisThe Autoasm can generate the file and compile correctly, but when I run to the fs2002 i don't see nothing, nothing was changed. PabloHere a few screenshots of gcla (La Palma, Canary Islands)project: