VTP Polys

[Guest]

Hi everybody,looking to MS scenery files with VTP Polygons of non-line type I noticed, that they contain one point more than needed to draw the poly: the last point seems always to be identical with the first point. Does anyone know whether there is any advantage to that? I do not find anything about that in the SDK. Also interesting: the point sequence is either clockwise or anticlockwise, so that seems to make no difference.-osman

[rhumbaflappy 113]

Hi osman.This is from some documentation on TerraShape, by Colin Sare-Soar:"First, a word about Polygons, Polylines and shapefiles:A Polyline is a line with nodes or vertices joining the different sections.These are created in a CAD program using the polyline tool and not the line tool.A Polygon is simply a polyline defining an area with the first and last point joined. It can be any shape at all and obviously must be 3 sides or more.The line must be joined exactly or it will still be a Polyline and not the desired Polygon.Most CAD programs have a command to close the polygon, then you know that it is really closed."I don't know if this simply reveals the 'SHP2DXF' origins of the BGL data ( and it's processing by a CAD or database program ), or if there is a good reason for this format in the BGLs.I know our home-made VTP polys don't display properly in TMFViewer. One reason may be this redundant line to "close" the polygon, that we are ommiting. Another reason might be that the SDK tells us to leave the U and V parameters of the VTPDataArea as 0,0... but the default BGLs fill in those parameters ( Center Area of the poly? Start Area of the poly? ).A few examples you have given me, that you have decompiled from the originals, show properly in TMFViewer when recompiled. So it's not the macros at fault, but the info from the SDK that omits or misleads, concerning the polygons.I would recommend we also "close" the polys by repeating the startpoint. And we eventually need to discover the right way to list the U,V parameters of VTPDataArea. And then maybe our polys will be correctly located in TMFViewer.Dick

[Guest]

Hi Dick,I agree with you that at least it would do no harm if we close our polys that way. BTW, it seems not to be the same for LWM Polys. Another point that stunned me yesterday was when I discovered that in MS nph files there are polys in one cell that are completely outside the bounds of this cell, i.e. with one edge on a VTP value of 12240 and all other points with values above 12240. So it is not true that the parts of a poly outside these bounds are clipped on display (as the SDK states), for at least the TFMViewer displays these polys perfectly. Those polys are usually joined on the extreme side by a poly residing in the next cell. So the only reason I see why MS might have split those polys to two cells could reside in the way those files were generated from a GIS.BTW I fould that salt lakes like those in Southern Australia are rendered by polys in nph******.bgl files e.g. in Tunisia too, whereas the big Salt Lake in central Turkey (which resembles in my experience very much to those in Tunisia, i.e. changing from a water surface during the rainy season to almost complete dryness during summer)is given as LWM water polys (in real life, one should not dare to land on that surface with a water plane even in winter !!). I did not check for the Salt Lake in Utah, because I have never been there and thus I do not know how dry or wet it is thru the year). - osman