Today I have been experimenting with updating the ground polygon wizard of ModelConverterX to also export P3D v2 MDL files for ground polygons. Given the recent announcement by Lockheed Martin that the FS2002 style polygons will be dropped in the future, it became time to update the GPW.

The good news is that it was quite easy for me to ouput the ground polygons as P3D v2 MDL files. The layering information is stored in the material zbias property now, but for the rest it works similar to the FS2002 style polygons approach.

But I also found a problem. It seems the positional accuracy of BGLComp compiled scenery is much lower than that of SCASM based scenery. As a result of that, gaps will appear between the polygons when they are split up in different groups. I usually do this in the GPW to increase performance. So in the old FS2002 style code there would be multiple reference points, each containing the the polygons closest to that point.

I need to do a bit more thinking on how to handle this. Either  I will drop the option to group polygons for P3D v2 output or I need somehow use the same reference point for all groups. So there is some more experimenting to do before I can finish the GPW update.

And for those of your interested in the math of the positional accuracy. In the BGLComp BGL format the latitude and longitude are stored as 32 bit integer values. This means that an increase of the lat/lon value by 1 corresponds to 3.3528e-7 degrees for latitude and 4.4703e-7 degrees for longitude (at the equator). That roughly corresponds to 4 to 5 centimetre accuracy.

In the old FS2002 style scenery the latitude and longitude are stored as a 32 bit integer plus a 16 bit integer. This means that an increase of the 1 corresponds to 1.3731e-10 deg degrees for latitude and 1.2790e-12 degrees for longitude (again at the equator). This corresponds to an accuracy of around 0.015 millimetre.

I never realised before that the accuracy of placing objects was so different between both methods. The accuracy of the old method is probably a bit over the top, as you won’t see that difference. But for the BGLComp approach I would have expected a little more accuracy actually.