All that weird stuff is quite easy to explain.  The binary .btg scenery format uses 16 bit integers as indices for the vertex, normal, texture coordinate lists.  At one point we were using signed 16 bit integers, but I'm pretty sure we sneakily changed the flightgear btg loader to use unsigned 16 bit ints.  So this changed the original limitation of a max of 32,768 vertices/texture coords/normals, etc. up to 65,535.  However, I don't know if the terragear-cs tools ever got this fix on the scene generation side.  So if your scenery exceeds these limits, this is exactly what you will see.

The ultimate solution will be to expand the btg format to 3 or 4 byte integers -- but that will again require changes in the terragear-cs tools as well as changes in the flightgear btg loader.  Conveniently we have a versioning system in the btg format so we can extend the format and maintain backwards compatibility if we want.

The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files.

There may be other ways to tackle this problem too ... maybe the btg format emitter could detect if the size exceeds the threshold of the current format and output just the tiles that require the extended format in the extend format.  (Sorry it's late friday, I hope that makes sense.) :-)


On Fri, Sep 30, 2011 at 8:54 AM, James Turner <> wrote:

On 30 Sep 2011, at 11:56, Martin Spott wrote:

> Hah, I managed to find the web page I've been searching
> for weeks, Bruce did a pretty nice writeup of the problem:

A very useful description, yes!


All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
Flightgear-devel mailing list

Curtis Olson: - -