Vector texture width depends on direction (and latitude?)

[tml]

(Posted this also on avsim, sorry if you see this twice.)

It is somewhat disappointing to notice that despite the fact that FSX knows that the Earth is a sphere (or ellipsoid even) and properly handles this for many aspects, there are still obvious problems in other aspects.

Using some airplane as a yardstick (landing it on a road and driving around a bit), it is plain to see that at moderately extreme latitudes (like 60 deg N, where I live), the width of road segments depends very much on their orientation. The closer the road segment is to the N-S direction, the narrower it is.

(My first impression is that in the E-W direction does the road width actually match the StripLineWidth value in terrain.cfg. This would be kinda logical, I guess, as it's the surface size of longitude units that get narrower the closer to the pole one gets. Latitude units stay constant in size. So one can almost imagine the scenario behind this problem.)

So, when preparing some vector scenery, in order to get realistic and consistent road widths, one would have to use different terrain.cfg entries for road segments in different directions. The different entries would have different StripLineWidth values to compensate for this bug. Oh well, just a small matter of programming... Hopefully the number of entries in terrain.cfg doesn't have a large effect on performance, as long as the actual texture bitmaps used by such direction-specific entries are the same, with only the StripLineWidth varying.

Of course, this isn't really a such big deal. FSX is after all a Flight Simulator, not GIS software...

--tml

 

[Timmo]

Of course, this isn't really a such big deal. FSX is after all a Flight Simulator, not GIS software...

--tml

Indeed...although strictly speaking a line has no inherent width in a GIS anyway. Even when symbolised its 'width' is measured in screen pixels rather than real world units.....but yeah, it is important in FS as you are trying to display a feature that doesnt have 'width' as a feature that has to have consistent width (if that makes sense)

very interesting observation though. I wonder if it was an oversight on MS's part or more a case of 'yeah we know its there but dont have the resources to fix it?

 

[tml]

I did some more experimentation. I made a couple of exactly "horizontal" and "vertical" road segments at Helsinki Malmi airport in a CVX file, and then did measurements on screenshots. My initial vague ideas about the mechanism behind this effect are are probably wrong. At Helsinki's latitude (60.2 degrees North), a "horizontal" road is more or less exactly 1.5 times as wide as a "vertical" road (using the same texture). My first impression and expectation was that it would be more or less exactly 2x as wide, because cos(60deg)=0.5.

Hmm, so my next theory was that this 1.5 has to do with the fact that FSX's quads, as measured in units of latitude and longitude, are 1.5 times as wide as high? It does seem like a tempting explanation. Would this 1.5 vector texture width factor thus be the same all over the globe?

Nope. Doing the same experimentation close to Quito airport (which is very close to the Equator), shows that there the "horizontal" roads are narrower than "vertical" ones. Sigh. (The ratio is not really any "round" number, but abour 1.35.) Sigh...

So, what could be the mechnism? Are things just set up so that at the moderate latitudes where the major FSX markets are (the US, Western Europe), the ratio is closest to one, and as one moves closer to the Equator or the poles the ratio diverts more and more from one?

--tml

 

[lmoelleb]

It's all in the SDK, no need to experiment or dream up conspiracy theories on who FS is designed for.

The planet is devided into 768x512 areas each devided into 32x32 (but let's ignore the 32x32 as it will apply equally to latitude and longitude).

With approximately 40000km around the globe, this gives at the equator an area of 52km x 39km. As you head north or south, it will get close to square, and then start to be more narrow. At 60 degrees latitude it will be 26x39km, which match the factor 1.5 you noticed.

If they had split the world in 1024x512 the areas would have been 1:1 on the equator, but there would be a much larger average error across all cells on the planet.

If they had split it 512x512 it would have been OK at 60 degrees, but on average more of the planet is located south of 60 degress (and certainly more of the populated part even ignoring if it is a market or not), so again it would have given a worse result on average.

Sure they could have avoided the requirement to make it square, but computers really like square textures, and as they have to seemlesly blend form cell to cell showing a part of a texture isn't a good option.

They could have taken this into account when rendering vector lines on the ground texture, but apparently they considered there was other things with higher priority for the CPU and/or developers to do... and I guess they where right.

 

[tml]

The planet is devided into 768x512 areas each devided into 32x32 (but let's ignore the 32x32 as it will apply equally to latitude and longitude).

Yes, I know about the QMIDs. But I only now when I read your posting and thought freshly about this did I get how simple the relationship between vector texture widths in horizontal and vertical direction depending on latitude actually is... Isn't it like:

Wh = Wv * 3/4 * (1/cos(lat))

(Wv = width of vertical vector texture, Wh = width of horizontal vector texture)

Expanding this formula for obliquely oriented textures is left as an exercise to the reader.

The "lengthwise compression factor" is probably just the inverse of the "widening factor", hmm.

--tml

 

[rhumbaflappy]

Hi tml.

This characteristic is unchanged from as early as CFS2.

All terrain textures are at the mercy of their latitudinal location, regarding East-West dimentions. Widths are an expression of decimal degrees, not as a linear measurement. As you approach the poles, there is longitudinal compression. Approaching the equator, there is expansion.

LWM, VTP1, VTP2, and FSX vectors are all affected, as are landclass and photoreal textures.

Objects and aircraft, are not affected by this. Very near the poles, some odd things can occur with buildings and autogen, as they are dimensioned correctly in meters, whereas the terrain is not.

Dick

 

[12bPilot]

Hi all!

I have a similar problem. I had an idea for generating autogen files for a specific tile automatically. The source for the positioning of buildings or whatever comes from a orthophoto. With some image processing, I was able to extract the footprints of the buildings, which are then processed into a agn file. That's the procedure.
Now, for some reason the portion of the orthofoto which should match the appropriate FS photo scenery texture (i cut the orthofoto by coordinates of the LOD13 cell) does not align perfectly, meaning that the buildings would be placed wrongly. There's some odd transformation. Is this due the resample process? If so, how can I kind of "emulate" the resample transformation in order to process my orthophoto that it matches the FS texture?

Any pointers are highly welcome!

Cheers,
Jeff

 

[Timmo]

What program are you working in??

Are the buildings offset by a constant or does it appear that they get progressively further away from a central point?

It seems like a coordinate system issue but im not sure how agns work exactly...

What id love to be able to do is convert Shapefiles into agns.....that would be really handy