FSX earth curvation and ground polygons

[arno]

Hi,

While working the gPoly tool I am doing some experimentation with the code to make those ground polygons.

When I use one single reference point and make sure that the vertices are no more than 100 meter apart from each other everything shows fine.

But for bigger airports I usually used code in FS2004 that has multiple reference points. The code that worked fine for this in FS2004, gives small gaps between the polygons in FSX. I am suspecting this has something to do with the curvation of the earth and the way the FSX engine corrects the polygons for it.

Did anybody experience this issue before and maybe know a solution? I am trying to understand better what FSX is doing to fix the problem of the ground polygons and the curvation, so that I know how to adapt my code for it.

 

[LCSims]

Does this thread help?

http://www.fsdeveloper.com/forum/showthread.php?t=11726&highlight=halifax

 

[BASys]

Hi Folks

Arno -
I'm guessing you're aiming for polys with no/minimal overlap.

Don't know to what decimal place you're calculating to,
nor the QMID level you're working at,
nor how much relevance the following might have,
but your result might possibly vary,
dependant on the test airport's location.

Are you correcting for outwith the quadtree optimal Lat bands 45 N/S,
and potential distortion dependent on Lon.
Also for equatorial versus polar diameters ?



e.g.
What happens for an airport -
- central to the following areas
versus those
- airports adjacent their borders ?

i.e.
At 45 N/S, versus those near 0 N/S, and towards 90 N/S,
for each of Lats 0, 120, 240, versus Lats near 60, 180, 300 ?



See Adam's Global Terrain articles.

Maybe try contacting Adam ?



HTH
ATB
Paul

 

[Kack911]

I'm not sure if this answers anything for you, but here's what I noticed...

I created all of my runways and taxiways in 3ds Max 8. I created the entire airport with EXACT dimensions. Runway length, width, and centerline-to-centerline distances were modeled to the exact dimensions found on the surveyed Master Plan Study document. However, once I laid those polys down on my resampled GeoTIFF imagery, it was off by significant margin.

After much investigation, it was apparent that the correction applied by FSX for the "round-Earth" issue causes errors in the linear dimensions of exported objects. For instance, my 10,900ft Max 8 runway was only 10,885ft in FSX. I had to go back and artificially lengthen and adjust every single runway and taxiway to make everything match.

Near the scene origin, I didn't have to move anything, but the further away from the origin a vertex was, the more it had to be moved. At the edges of my scene, things had to be moved 15-20ft.

I checked my custom runway against an ADE (XML) created one, and found the same discrepancy.

This error is also apparent when trying to attach effects to objects like runway lights. I added runway lights every 200ft along the length of my runway. FSX automatically pulled the base of each runway light down to the surface, but the BGL_Lights began to "float" the further they were from the scene origin. In addition to floating, they were also displaced in the x/y axis proportionately as the distance increased.

So apparently the act of pulling the verts down to the mesh also displaces them slightly in a manner that you would expect when forcing a flat object to conform to a round one. It's the same distortions you'd find when comparing a map to a globe.

Regards,

Nick

 

[BASys]

Hi Folks

Arno -
Have you also tried turning off the round earth scaling ?
Do the ground polys now align correctly without gaps ?

In fsx.CFG [SCENERY] section -

// Objects on plane rather than earth
// 0==Flat, 1== Round
ScaleToRoundEarth=0

HTH
ATB
Paul

 

[arno]

Hi all,

@Paul, that CFG option is new to me. I'll try if that makes a difference. That will be a good indication if it is due to the curvation or not.

I have not made my polygons with the terrain SDK or so, they are FS2002 style polygons. For each vertex I know the lat/lon position and I am transforming that to a xy from a giving reference point. With exactly the same code these polygons would align perfect in FS2004, but in FSX they don't do so yet.

@Nick, your problem sounds related to mine. Although it could also be that you need to "reproject" your drawing from the units used by the official drawing to those used in FS. For a project I have used an official drawing giving distance in meters, but it was a in Dutch projection. I had to transform those to align perfectly with FS.

 

[arno]

Paul,

Thanks for the tip. With that setting to 0 the problem does not show, while with the setting to 1 it does. So now I know that it is caused by the correction for the curvation.

All I have to do now is try to understand what they are doing as a correction, so that I can automatically compensate for it .

 

[BASys]

Hi Folks

Arno -
EDIT - Crossing posts

Good result.



In your OP you mentioned the multiple reference points.
Are those a ref point per poly ?
Or a ref point for a cluster of polys ?

Try per poly.

PS
If I've understood Adam's notes correctly
they say 64 bit precision is required for correction.



EDIT 2 -
PPS
With ScaleToRoundEarth=0
is there any poly overlap ?

Maybe check with gridded textured polys ?



HTH
ATB
Paul

 

[arno]

Hi Paul,

In your OP you mentioned the multiple reference points.
Are those a ref point per poly ?
Or a ref point for a cluster of polys ?

Try per poly.

Now I have multiple polygons per reference point. But big polygons can be split over different reference points for better performance control.

Since the problems occur between the different reference points and not between polygons of the same reference point, I think using a single reference point per polygon does not help. It would only kill performance on big airports .

If I've understood Adam's notes correctly
they say 64 bit precision is required for correction.

Yes, but that is something internally in the engine. With single precision you can indeed get jittering, I have seen that in other systems as well. I don't think we can do much about that though.

With ScaleToRoundEarth=0
is there any poly overlap ?

Maybe check with gridded textured polys ?

I will try with another texture, but at the moment I see no flickering or other problems. It seems like a perfect match again (like I was used to before in FS2004).

 

[BASys]

Hi Folks

Since the problems occur between the different reference points
and not between polygons of the same reference point,
I think using a single reference point per polygon does not help.

Arno -
That's exactly my point, (if I've understood you).

Using a single point for a cluster of 100x100m polys
is creating too big a difference at the edges.

Is the gap visible in top down,
or just from oblique angle viewpoints ?

HTH
ATB
Paul

 

[arno]

Hi Paul,

Using a single point for a cluster of 100x100m polys is creating too big a difference at the edges.

Not sure if I understand you there.

Is the gap visible in top down,
or just from oblique angle viewpoints ?

It is visible from all sides. So to me it seems both polygons are properly on the ground, but there is just a gap. It does not seem one of them is floating a bit.

 

[arno]

Hi Paul,

I will try with another texture, but at the moment I see no flickering or other problems. It seems like a perfect match again (like I was used to before in FS2004).

I just tried with a checkerboard texture and the edge between the different polygons is not visible when I use ScaleToRoundEarth=0. So it seems that in that case they connect perfect again (like they should).

 

[rhumbaflappy]

Hi arno.

With the round earth in FSX, the distances are not planar, but geodetic... that is they follow the curve, making them shorter than planar distance.

You would think the scaling option would make objects larger, to compensate for the curve... but the opposite seems true.

During the FSX beta, I noted that 10000m long objects made with the FSX gmax pack were of a different length than FS2004 objects. This would be the same issue.

Dick

 

[BASys]

Hi Folks

Arno -
Talking about tessellation AIUI



100m is a poly's max side length,
per 'earth-attached' plane.



Creating a cluster of 100x100m polys
all referencing a single earth-attach,
will behave as if a single 'earth-attached' plane,
as it exceeds that 100m limit.



It's 1 poly, 1 earth attach.



i.e.
Correct -
100x100m poly, 1 earth attach.

Incorrect -
9 off 100x100m polys, (3x3 grid),
with 1 earth attach, is a 300m sided plane.



re: Coordinates, Offsets, & Scaling Conversion
From Adam's notes on conversion elsewhere -

make sure you use
64 bit double precision floating point math
or you won't get accurate results.

re: Length of very large objects
Shrunken versus expected larger objects,
sounds as if FSX -
- takes your planar object (gmax length x)
- projects your planar object onto the 'earth model' surface (as length x)
- takes the chord length (y) spanned by your planar object
- scales your planar object to length (y)
- displays your rescaled object as length (y) onto a planar surface



Interested to hear how people are
accurately measuring the distances in game.



HTH
ATB
Paul

 

[GHD]

when I use ScaleToRoundEarth=0. So it seems that in that case they connect perfect again (like they should).

But ScaleToRoundEarth=0 is a fudge that every user would need to add to their fsx.cfg.

 

[BASys]

Hi Folks

George -
I'm assuming,
that Arno was referring to how gpolys behave in FS9 FlatWorld.



The switch was an interim aid
for MS to port FS9 content to FSX.

It was supposed to have been removed in RTM.



It is not intended/suitable
for users to apply to their fsx.

The FSX earth is still round
and all content is rendered
on the plane of the user's immediate locale.

i.e.
All outwith,
will be floating at increasing elevation.



HTH
ATB
Paul

 

[arno]

Hi George,

But ScaleToRoundEarth=0 is a fudge that every user would need to add to their fsx.cfg.

True, it is not a final solution. But it helps me to narrow down where the error is introduced. I now know quite sure it is due to the curve of the earth, so I can focus my attention on that.

 

[arno]

Hi Dick,

With the round earth in FSX, the distances are not planar, but geodetic... that is they follow the curve, making them shorter than planar distance.

You would think the scaling option would make objects larger, to compensate for the curve... but the opposite seems true.

During the FSX beta, I noted that 10000m long objects made with the FSX gmax pack were of a different length than FS2004 objects. This would be the same issue.

That's indeed what I am thinking now. I am trying to understand what happens to the flat polygons when it is adjusted to the shape of the earth. If I understand what happens there, I hope I can compensate for it, so that the polygons fit as before again.

I guess I will take a look at the formula's for geocentric coordinates next and see if that helps me...

 

[arno]

Hi Paul,

100m is a poly's max side length,
per 'earth-attached' plane.

Creating a cluster of 100x100m polys
all referencing a single earth-attach,
will behave as if a single 'earth-attached' plane,
as it exceeds that 100m limit.

It's 1 poly, 1 earth attach.

i.e.
Correct -
100x100m poly, 1 earth attach.

Incorrect -
9 off 100x100m polys, (3x3 grid),
with 1 earth attach, is a 300m sided plane.

I am not sure about it. As long as you make sure that the distance between vertices is maximum 100 meter, it seems the ground polygons follow the terrain. If the distance is bigger the planes will be floating and you get trouble. But within one reference point it seems you can have a much bigger plane, as long as the segments are maximum 100 meter.

But for my tests I currently use polygons that are within 100 meter, so that's not the issue.

re: Length of very large objects
Shrunken versus expected larger objects,
sounds as if FSX -
- takes your planar object (gmax length x)
- projects your planar object onto the 'earth model' surface (as length x)
- takes the chord length (y) spanned by your planar object
- scales your planar object to length (y)
- displays your rescaled object as length (y) onto a planar surface

Could be. I have been trying to estimate how big that scaling would be, but for ground polygons of the size I am working with now that should be very small. The gaps I am getting are bigger.

Interested to hear how people are
accurately measuring the distances in game.

Yes, that's a whole challenge already . It can become very confusing when you realize that 1 meter in one projection is not 1 meter in another .

 

[BASys]

Hi Folks.

Arno -

But within one reference point
it seems you can have a much bigger plane,
as long as the segments are maximum 100 meter.

AIUI, that is not the case,
(from reading Adam's doc).

But for my tests
I currently use polygons that are within 100 meter,
so that's not the issue.

Are you saying -
- The total size of any cluster does not exceed 100m ?
Or -
- Your individual polygons don't exceed 100m,
but the cluster does ?

Former required, (AIUI).



1 metre is still 1 metre.

It's just your large flat object that's been reprojected,
so no longer meets your expectations.



Just to be clear -

Are your 100m polys -
- still flat planes ?
- round-earth projected, (i.e. domed) ?

Latter required, (AIUI).

See Adam's post at the other place.
Re: RoundEarth again (Fri, 15 Dec 2006 14:04:33 -0800)



EDIT -
Just reread the thread
and IIUC you're still working with two dimensional planes.

Also reread Adam's post
and not 100% sure about domed poly aspect.



HTH
ATB
Paul