Jump to content
Sign in to follow this  
Guest christian

A question for everyone...

Recommended Posts

Guest misho

Hello!I am working on some funky Flash teaching aids - it seems there is a lot of confusion about basic geographic principles and how they translate to FS World, and I thought that a well-illustrated teaching aid will greatly clear up confusion.The question is: what is the actual geometric shape of Earth in FS (as in, 3D model of it, not the conceptual)? Is it FLAT, and when you fly to the edges, you are transported ("wrapped around") to the other edge, or is it a true SPHERE?I would have to conclude that it is indeed flat, with a true lat-long grid superimposed to it so that it correlates to proper navigation. This would explain why we can't reach north or south poles (things get weird beyond +/- 87 deg latitude) because of the enormous distortions. Also, Flat system fits to the rectangular LOD model. But I am confused in what the SDK documentation says:"In Flight Simulator, the earth is defined as an

Share this post


Link to post
Share on other sites

Hi Misho.I would think that if the sim was a flat world, then lines of longitude would not narrow as we approach the poles, when in fact they do. If you've ever seen cellgrid used, you'll see that longitude does narrow towards the poles. Edgar Knobloch's GridGen, which displays lines of latitude and longitude in the sim shows this best.Another consideration, if the MS world was flat, then the 4.8 meter per pixel standard for TMF design would always be just that.. when in fact the longitudinal width of that standard is fatter at the equator and disappears at the poles.I found a good explanation of "oblate spheroid":http://regentsprep.org/Regents/earthsci/un...tion/oblate.cfmIn essence, I think the SDK was simply trying to be a little too accurate. :) In the sim, the earth is essentially round.For designers, however, the earth is flat. All design locations are based on a simple lat/long projection, that "maps" the earth as equiangular... all lines of latitude and longitude meet at 90 degree angles, and form perfect squares. Other names for this are Simple Cylinder or Platte-Carre projection.This is opposed to many maps, tiff images, and photos, that display the earth as equidistant. All measurements being of meters or feet and equally spaced NSEW.For small areas, this difference of projection is not pronounced, but as you go to latitudes near the poles, the effect can be great. A meter is still a meter, but one degree longitude is many meters less at N70* than it is at N0*. If your source data is projected as equidistant, then you'll have a lot of problems displaying that aerial photo or map data in more extreme northern or southern latitudes.For large areas of hundreds of meters, equidistant data, like joined aerial photos or maps from the internet, will usually be misalligned. They are usually using equidistant measurement, rather than equiangular.=================I recently started a project for CFS2. It is using Ground2K, by Christian Fumey. Ground2K uses a background map, upon which we can draw our TDF lines and polys. This map needs to be in equiangular projection... all lines of latitude and longitude meet at 90 degree angles.I have a map of my area of interest saved as a generated bitmap from MapPoint. MapPoint is equidistant in projection.. with so many pixels equalling so many meters.I used pushpins at the intersection of latitude and longitude to mark them. Then I saved a large bitmap. I trimmed the large bitmap in a paint program to as close to the pins as I could. Because the shot was pointing north, and it is in the northern hemisphere, I needed to use a perspective tilt function of the paint program to tip the top of the map towards me ( enlarge the top ) to square the angles of longitude. This distorts the equal measurements, but it now has equal angles of longitude as well as latitude.I then could use the map reliably in Ground2K, as I had visually reprojected the image from equidistant to equiangular. There are some commercial programs that will reproject georeferenced images, but they are quite expensive. I think GRASS, which is freeware, also has this capability... but I have never used that program.======================Users of LWMDraw know this process well. It recommends using topdown screenshots of the sim that has cellgrid displayed. Then the screenshot can be trimmed and warped to square the image of a single ( or few ) LOD13 Areas. All TDF design, and much traditional scenery design, is based on equiangular projection, which is then reprojected in the sim upon the spherical 3D FS world. This is easily seen with CUSTOM scenery. All bitmap slices are 256x256, but their projection at more extreme northern or southern latitudes show the spherical warping of their display... identical to the warping seen with cellgrid ( which marks the same LOD13 bounds that CUSTOM slices occupy ).======================Some sources of data are measured in angles, like DLG data or GIS line data, but this angular data is projected as a conic or other format which twists or tilts the angles to give a less distorted view. The problem is that a sphere isn't easily displayed on a flat surface. These angular data sources can easily be reprojected to simple lat-long projection by GIS programs. There are some free programs, like MapMaker ( gratis ) that will reproject GIS data on the fly, as long as the base projection is right ( simple lat/long ).Dick

Share this post


Link to post
Share on other sites
Guest christian

I think Dick pretty much hit the nail on the head.I think the complete earth in FS is indeed a spheroid in terms of referencing positions. You have to use the WGS84 projection for that...I terms of rendering I suspect it's 'flat' from a certain point of view. When you really zoom out, you can see how the textures are drawn, ie only huge '+' gets drawn (although behond there there still seems to land, but just not textured). Surely, FS can't draw the whole world, it probably only takes some portion and renders that and as you fly along other parts of the world get paged into memory.Now is that earth patch rendered flat or as a part of a spheroid? I don't know. To check that, I assume you have to fly really high over the ocean and see if you can see a bit of curvature. Would make sense to have a curved patch though.The poles are indeed a problem, one reason because it would be harder to get the right patch to display, and also because the textures aren't corrected for any geometric distortions. They act as a singularity which makes things a bit more compicated.Cheers, Christian

Share this post


Link to post
Share on other sites
Guest luissa

HiFor most FS purposes I assume the earth as one sphere and I use this equality:1 nautical mile = 1852 metersFollowing are some notes derived on this simple assumption.Distance between 2 points at the same longitude=====================================If 2 points P2 and P1 differ one MINUTE of latitude, the distancealong the meridian arc, in meters, will be:DY = 1852If 2 points P2 and P1 differ one DEGREE of latitude, the distancealong the meridian arc, in meters, will be:DY = 1852 * 60 = 111120If P2 is at latitude Lat2 and P1 is at latitude Lat1, the distancealong the meridian arc, in meters, will be:DY = 111120 * ( Lat2 - Lat1 )Distance between 2 points at the same latitude====================================At the equator one MINUTE of longitude is 1852 meters but, at the poles, itwill be zero. Assuming a sphere and 2 points, P2 and P1, at latitude equalto Lat and longitudes equal to Lon2 and to Lon1 respectively, the distancebetween the points along the parallel arc is:DX = 111120 * ( Lon2 - Lon1 ) * cos( Lat)Useful SCASM macro coding====================In order to evaluate delta_SN and delta_WE distances in RefPoint units between2 points of known latitudes and longitudes, the following code can be used:; Macro Parameters:; 1 = latitude; 2 = longitude; 3 = aux latitude; 4 = aux longitude; 5 = scaleUvar( $Lat0 %1 )Uvar( $Lon0 %2 )Uvar( $Lat1 %3 )Uvar( $Lon1 %4 )Uvar( $Scale %5 )UVar( $Lat [ [$Lat0 + $Lat1] / 2 ] )Uvar( $DX [111120 / $Scale * cos($Lat) * [$Lon1 - $Lon0] ] )Uvar( $DY [111120 / $Scale * [$Lat1 - $Lat0] ] )Another View to the "SDK LOD table"===========================In the SDK LOD table, a LOD_0 quadrant (not a square!) is said to span 10018863meters. This value is the "span along a meridian arc" and it is different from the "span along the equator". I get a different number using the above formulae. Since a LOD_0 spans 90 degreesof latitude, that translates to meters:90 * 60 * 1852 = 10000800Since a LOD_0 spans 120 degrees of longitude the "span along the equator" is:120 * 60 * 1852 = 13334400For other quadrants we can construct this table:http://www.ptsim.com/downloads/sdk_lod.htmAerial photos and custom textures=========================We can create photographic scenery from aerial photos very easily using the MS "resampletool". We only need to pass to the "resample tool" the coordinates of the NW corner andthe coordinates of the SE corner of the master bitmap. The tool will resample thebitmap and will produce 256 x 256 bitmaps which will fill LOD_13 quadrants.It has been said that better image quality can be achieved if the master bitmap is alreadysupplied to the resample tool in its final resolution. If so the resample tool justdivides the master in pieces without any resizing or scaling. At the equator oneLOD_13 measures 1221 x 1628 meters. At latitude of 41:24:00 it measures approximatelly1221 x 1221 meters. It is worth noting the LOD_13 size at different latitudes:Lat. Size00 1221 x 162810 1221 x 160320 1221 x 153030 1221 x 141040 1221 x 124750 1221 x 104660 1221 x 81470 1221 x 557If we have orto-rectified aerial photos we have to distort them if we want zero (or minimum)resizing by the "resample tool". At the equator one LOD_13 spans a rectangle of 1221 x 1628 meters so that the photograph should be compressed horizontally by 75% (1221/1628).This pre-distortion in photographs is also very important when we try to match a photowith a mesh. In this case we can take a snapshoot of the mesh in TMFViewer and use itas a template to position the photograph. In order to get good results the photographs shouldbe distorted horizontally (amplified at latitudes greater than 41 degrees and compressednear the equator).Kind Regards, Luis

Share this post


Link to post
Share on other sites

Hi Misho, and all.Another point I'd like to make concerning Aerial photos:This is from Microsoft's TerraServer, a source many of us use for making CUSTOM bgls and slices:Image courtesy of the U.S. Geological Survey Info: Digital Ortho-Quadrangles (digitized and othro-rectified aerial photographs Provider: U.S. Geological Survey. To find out more about this image, visit the USGS's Digital Backyard. Image Size: 800 pixels wide by 600 pixels high. Resolution: Each pixel represents 4 meter resolution by 4 meter resolution of earth. Date: Photographed on 14 Apr 2000 digitized on 31 Oct 2001 Projection: The data below is projected in the Universal Transverse Mercator (UTM) Zone 16 projection using the North American datum of 1983. The decimal latitude and longitude in degrees and the UTM coordinates in meters are shown for each image tile. Source File: D.delavan_WI.ver_1.O4208819.SES received on tape/group 636 Load Date: 5/8/2002 3:09:09 PM via job DOQ-Tape-636 In this case, the datum wouldn't be a huge concern... but the projection in this case will give the image I looked at about a 1% twist oto the right ( The "i" button, near the top of the web page, reveals this info ).This twist is enough to sometimes skew the positioning of details around runways. If a large area of these photos are joined, the twist will now misposition the runway locations significantly. Roads, streams and towns are also mispositioned, but that usually isn't something we'd notice much.The attached jpeg shows this twist over my hometown.Dick

Share this post


Link to post
Share on other sites
Guest misho

Thanks everyone for some very insightful info. However, I haven't had my question answered. While it is apparent that FS World follows the physical characteristics of the real world, this can all be a fairly simple mathematical operation, i.e. application of polar coordinate grid (as opposed to Cartesian). However, this very approach exhibits most of the shortcomings that arise when you try to map the spherical surface to the FLAT plane, namely, the meridian convergence and distortions near the poles.So, let me ask the same question in a different form:If you COULD slew to, say, 300,000 feet altitude, would you see curvature of the Earth?(you can see this in Map View, but this doesn't apply - map view is faked beyond certain altitude. You can tell this by a "lovely" earth-wide photorealistic texture applied to globe beyond certain zoom level)

Share this post


Link to post
Share on other sites

Hi Misho.I think the sim allows us to slew to 30480 meters.At that height, with my screen resolution set to 1600x1200x16, heading 0*, at n0* and e0*, I can take a screenshot.Loading that screenshot into PaintShop Pro, and magnifying 5x, I can see FS does not represent the view as a flat horizon, but gives a one pixel bulge to the center area of the picture.That tells me that FS does render the 3D scene as a sphere... right up to those altitude extents.==========================By pointing the nose of the aircraft down while slewing, to get a good view of the earth, I can use cellgrid to display the extreme texture distortion near the poles. This is consistant with the concept of all LWM, VTP, and landclass ( as well as CUSTOM textures ) being mapped to the flat lat/long ( square ) projection during the design phase... then reprojected to a spherical 3D model in the sim. That is the reason for the elongation of these textures.========================If your CUSTOM source image is equidistant, instead of equiangular, it will suffer this distortion during runtime. If your image is equiangular, it will look very distorted during the design phase, but will be projected correctly onto the FS 3D world at runtime.These distortions are less noticable between latitudes 30* and 50* ( north and south ). So we can get away with using CUSTOM in that lat range, without our image sources being too stretched or squashed.=========================I have not tried to place a landclass with autogen buildings or CUSTOM near the poles. That might be interesting, as autogen are placed by lat/long, but are created as distance. That should "crowd" autogen longitudinally near the poles, and spread them ( EW ) near the equator.The attached screenshot tells the story of landclass or CUSTOM near the poles.Dickhttp://forums.avsim.com/user_files/2824.jpg

Share this post


Link to post
Share on other sites

Hi again Misho.I'm still thinking of your question, and I am haunted by a suspicion that MS has somehow faked the terrain curvature, as you have suggested.Perhaps MS has somehow created a mosaic of flat terrains to represent the globe It has elevation and perspective, and does reflect the narrowing of the individual LOD13 Areas, but there is no apparent curvature, in any one view.As we move, there is some "popping" of mesh, and textures. The slew mode shows a definite popping of the tiling format used in the display as we quickly move to new areas. An extreme altitude in the top-down view shows this.Mesh and landclass were added to the sim in FS2000. FS2000 shows a large rectangular pattern ( high altitude, top-down view ) when slewing. CFS2 and FS2002 show a "cross" shaped pattern. I think that cross may be the extent of the flat base terrain you may have been thinking about. The elevations and ground textures perhaps sit flatly on this base. As we slew to different areas, the cross moves as well. That might indicate the cross is computed at runtime, but is hardcoded to cover so many LOD13 Areas. I envision this cross pattern as a truncationg, or shaving of the round earth to a flat surface under the aircraft's position.The distance we can view landclass or CUSTOM textures in the sim is limited, as you have noted. Perhaps that corresponds to the extent of this cross.Is this what have been thinking of?Dickhttp://forums.avsim.com/user_files/2841.jpg

Share this post


Link to post
Share on other sites
Guest misho

Hi Dick,I am also haunted by this, and more I think about it, the inevitable becomes obvious: FS World is flat.The fact that we are limited to 30,000 meters altitude ceiling, plus the fact that we are "not allowed" to reach the poles make me think these are the consequences of having the flat world. Moving towards the poles, we hit an invisible barrier and we cannot get past it. Why would this be a limitation if the world was a sphere?However, If the world was modelled flat, reaching a Pole would mean reaching a top/bottom edge of the flat earth, where the Pole is indeed a LINE, instead of a point. How would you handle that? Well, use a dirty trick - don't LET user reach the pole.Think about it - data sets, be it bitmaps or DEM elevation data, are inherently rectangular organized matrix - that's the way the computer's binary system likes it. This does not map well onto a curvature, and using it on a sphere would introduce persistent gaps.I think the cross pattern is simply a progression from the rectangular pattern - it better represents a circle, which would be the range of "detail" around the observer, where things (mesh and textures) kick in.

Share this post


Link to post
Share on other sites

Hi Misho.I think the only area of disagreement between us is that I'm thinking the flat plane we see in the sim is recomputed dependant on our lat/long position. That would determine the look of the LOD shape and spacing of points, which does change as we move from area to area ( narrow near the poles, wider at the equator ).That would also mean mesh point spacing, as well as textures, have different longitudinal spacing ( or widths ), depending on the aircraft global position. This gets updated or refreshed as we enter new areas.I agree the world we see in the sim is flat, but this flatness is probably computed at runtime and is not a constant... or else we would see no LOD distortion near the poles. I think MS is trying to display an equidistant-flat display on an equiangular-round world. The flattening of mean sea level under the aircraft's position, and extending beyond the distance at which landclass is visible would be a good illusion, and would speed up the display of textures and mesh, as the LOD spacing and elevations would be set in size and point-spacing, and not forced to constantly recompute for a curved surface. At certain global points, the MSL base flattening, and LOD point-spacing would have to be recomputed to new "constants", as the aircraft moves into those areas. The only puzzle would be how big is the area before a recomputation of MSL and LOD shape. That cross pattern jpeg I posted, could actually be the area of the computation.. a cross made up of several squares of an LOD size.. and gets recomputed as we move to a new center, I don't know what the LOD size is of the squares that comprise that cross area, but I could experiment to find it. I don't know what good that would do. This visual cross pattern also becomes elongated near the poles, so it is tied to longitude, not distance. That also seems a clue that it may actually represent the flat plane you have noticed... where elevation "0" is flat as a pancake, and all mesh rises from. The disparity between textures represented as LOD's longitude ( angular measurement ), and the necessity of distance always being equal ( 1 meter must be 1 meter in all directions and angles ), would mean that MS did take a shortcut and made the poles like some kind of Bermuda Triangle. They had to, as the textures and meshpoints could no longer be narrowed without gross distortion. A large building near the poles could span several degrees of longitude, and the mesh and ground textures near it would be severely compressed longitudinally. ( Not as real as it gets anymore ). :)So I do agreee MS cheated and displays the sim as flat, and equidistant in measurement around the aircraft. But as we move the aircraft's position, certain bounds will trigger a recomputation of this flatness and the distance-spacing of mesh/landclass verticies, dependant on Latitude. That's a theory, and I don't know how to prove it.. but it seems to fit what we see in the sim.Dick

Share this post


Link to post
Share on other sites
Guest christian

Misho, I still don't understand what you are trying to get at.In terms of rendering, as I explained, yes Microsoft only renders a patch, but that's a good thing, because loading the whole world as a full sphere would use up too much memory resources.Everything else follows from that, it doesn't really matter if there is a curvature or not. Let me explain:The big cross is made up of squares (LOD quads). The important one (ie the one you only really see, when we have say LOD5 or bigger) is the one you are in. In that regards having a flat earth is quite a good approximation of the curvature, because in your immediate surrounding the curvature is so small that it doesn't matter.I'm not saying that it is indeed flat, because I don't know. It shouldn't really be hard to draw a curved patch.Now as you fly along, FS updates the patch, so everything around you stays correct, ie LOD quads at the equators are indeed bigger than they are on the poles.The poles are a problem with this approach. You are just drawing a patch, but there are 2 problems at the poles:1 - The poles are a singularity, so you would have to do some tricky projection to draw the patch (curved or not).2 - Microsoft has a standard size texture for a LOD quad. This means they should get really squished at the poles.Cheers, Christian

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...