VTP alignment - 255 or 256??

[Guest]

Hi all,In designing my Coast-Line-Maker tool (see http://flightsim.computing.dundee.ac.uk/ for latest version), I came across an oddity with the VTP co-ordinates which I glossed over in the program, but a couple of users have spotted it and the reason for it is now puzzling me ...The LOD13 cells are 256 x 256, and I have based the VTP co-ordinates in my program on those dimensions too. However, when I originally produced VTP coasts and LWM polygons with an early version of the program, they DIDN'T align - the VTP segments were a little too far N and W ... I eventually realised that they were out by the values of the LOD13 cell co-ordinates e.g. if the cell was [ 20, 20 ] the VTP was out by 20 in both dimensions.To fix this in the program, I scaled the VTP co-ordinates to 255/256ths of their value on the screen, which worked very well in aligning the VTP and LWM ... though it means that the co-ordinates in the ASM file are not the same as those on-screen (this has not been a problem for me, but has caused headaches for some users).Can anyone explain how/why the LOD13 cells are 256 x 256, but the VTP co-ordinates that cover this area appear to be 255 x 255 ?!?!Yours somewhat puzzled ... :-hmmmIain.

[arno 1]

Isn't it because they run from 0 to 255, so that makes 256 of them in total?Arno

---

Member Netherlands 2000 Scenery Team[link:home.wanadoo.nl/arno.gerretsen]Arno's FlightSim World for scenery design hints, tips and other tricks...

[rhumbaflappy 113]

Hi Iain.The SDK is correct in that the VTP is based as 255x255 cell-like shapes. 255 x 32 = 8160.Discussions I've had concerning LWM lead me to believe we can number them as 1-255, rather than 0-255.Chris Wright has done some work with this, I think. I know Christian Stock has looked at it.It had never occured to me that we'd have programs that use data for both types ( LWM and VTP ).====================Our problem is that we are using raster data, and trying to convert it to vectors that can be used for both VTP and LWM in the same program.The total bounds of displayed VTP is 4080 - 12240, which is actually 1 more than it should be... perhaps it refers to verticies of a grid, much like landclass and mesh, where the verticies must always be 1 more than the cells they enclose? =======================The SDK states that LWM points are from 0,0 to 255,255 in span.256x256 points... but are these verticies, not cells? If so, then they are 255 cell-like shapes, enclosed by 256 verticies... just as VTPm2's ( cell size ) might be seen as 8160 cell-like shapes enclosed by 8161 vertices.Very similar to landclass.VTPPointXYUV ( VTPm1 points ) are described as 0,0 to 255,255. Again, possibly 256 verticies bounding 255 cell-like shapes.=======================So most probably, we are defining vertices, that the sim will use to paint tiny cell-like shapes at runtime.Unfortunately, TMFviewer won't let us look at our VTPs... But we can see LWMs. They are points, connected by lines, as shown by TMFViewer. But in the sim, at a high zoom level of view, we can see what is portrayed is not lines, but cell-like square shapes.===============================Does any of this help us? Not really, as we are making programs that use a raster interface to define vector points. A CAD program, would assume you draw any shaped-sized poly, then would use splitting routines to carve a shape into LWM Areas and Cells. These are vector. The edges of the carving, are shared with their neighbors. So your ( 0,255-255,255 ) bottom line is also the same top line ( 0,0-255,0 ) for the Area beneath it.Vector graphics are much different than the raster graphics we are used to... and we are using in the programs we have.This is still a problem for many of us to understand concerning Landclass INF files... and has been complicated by MS sometimes refering to vertices or enclosing vector lines as cells in the SDKs.In fact, the INF file itself contains a misnomer:[Destination]DestDir = "."DestBaseFileName = "HomeCustomLC257"; SampleIsCentered=1UseSourceDimensions = 1[source]Type = ClassU8SourceDir ="."SourceFile = "Home257.raw"Lon = -90Lat = 45NumOfCellsPerLine = 257 ; Should be "NumOfVerticiesPerLine" NumOfLines = 257 ; yes! 257 lines that enclose 256 cellsCellXdimensionDeg=0.0146484375 ; yes! 256 cell span... the actual width of a cell.CellYdimensionDeg=0.010986328125 ; yes! 256 cell span... the actual height of a cell.You can see how 1 misnamed term has caused years of confusion.I think we are seeing the same thing with VTPs and LWMs... and the easy solution is:if point = 0, then point = 1in our coding logic. Then we never have to deal with a zero valued point, in either VTP or LWM. I think, unless we commit to vector grahics, this will have to be "close enough".Dick

[Guest vlada stoje]

Dick,perhaps it is academic, but I suppose that while the VTP1 vertex (255,y) from the left area is identical with the VTP1 vertex (0,y) from the right area, the address (1,y) points to the next VTP1 vertex. So there is no need to round the 0 and 1 together, and the use of the zero is useful to join the LWM polygons absolutely exactly. But maybe nobody will notice visually the difference between the 0 and 1

[rhumbaflappy 113]

Hi Vlada.I think it was Chris Wright that found that 0 or 1 make no difference to LWM display. Or it may have been Ken Nelson. Perhaps they'll read this and comment.Dick

[Guest cwright]

Hi Dick! In your first tutorial, which by chance came out about the same time as the FS2002 SDK, you wrote:"The LOD13 area is further split into a 255x255 POINT grid ( numbered 1 to 255... 0 is accepted but may lead to "visual artifacts" in the decal )..." When I started work on AutoAsm I of course used this standard. In fact I used a zero coordinate to denote a special flag value. Then the SDK came out. It stated the coords were 0 to 255, as did your second tutorial. As I had used zero as a flag value, I realised I would have to change the code and add an extra array for the flag value. There was just one thing: 1 to 255 seemed to work perfectly well! Before making the change I looked into it. Entering a one or a zero made no visible difference. Also, if 0 to 255 was correct then there should have been lots of small gaps, but there were none. If I reduced 255 to 254, then gaps appeared just as expected. So most likely this is another error in the sdk, and your first tutorial was correct. Just as well, as I didn't have to change the code! Best regards, Chris

[Guest]

I disassembled today some of the the MS hyp****.bgl files which contain LWM poly's for the coast. MS seems never to use 0 for a LWM point but rather 1 ... 255, and the polys seem to be contiguous. So it looks as if an LWM area is indeed an 255x255 array of points.- osman

[Guest vlada stoje]

Hi Dick, Chris and all,Thanks for the explanation of this detail and also BIG THANKS for the lwm tutorial, utilities and all the knowledge on this super forum! Attached is my small experiment with the Slapy lake near to Praguehttp://www.volny.cz/stoje/slapy/z226sl_slapy.jpg (all 50 LWM polygons with the extent 0 - 255 without visual artifacts)

[rhumbaflappy 113]

Hi All.I think we can take Chris' word for it... the simple fix is the logic:if point = 0, then point = 1and just convert the zero value to 1, in every case... and treat this as 1-255 ( 255 total points ).This is probably what the sim is doing, anyways.Dick

[Guest vlada stoje]

Hi Dick,I tested this LWM pattern in the extent 0 - 255:LWMPoly2 21,0,1,280,0 LWMPoint 1, 1 LWMPoint 80, 1 LWMPoint 81, 0 LWMPoint 160, 0 LWMPoint 161, 1 LWMPoint 254, 1 LWMPoint 254, 80 LWMPoint 255, 81 LWMPoint 255, 160 LWMPoint 254, 161 LWMPoint 254, 254 LWMPoint 161, 254 LWMPoint 160, 255 LWMPoint 81, 255 LWMPoint 80, 254 LWMPoint 1, 254 LWMPoint 1, 161 LWMPoint 0, 160 LWMPoint 0, 81 LWMPoint 1, 80 LWMPoint 1, 1In the TMFViewer the difference between 0 and 1 is visible and is the same as the difference between 254 and 255, see the attached picture. In FS2002 I see only the simple "square", maybe in the extent 1 - 254. (The 0 and 255 rows and columns invisible? Both in the water and land mask variant.) Now I agree with you that there is perhaps no practical use of the zero points in the LWM patterns, but they can be in the bgl files and even the TMFViewer shows them (so it expects the 256 vertex concept, but who knows if the TMFViewer is correct) Best regards