between geodetic and geocentric coordinates. So, we only need to
convert between geocentric and cartesian coordinates to complete the
picture. Converting from geocentric to cartesian coordinates is done
-by using the following formula: \\
-$x = cos(lon_\mathit{geocentric}) * cos(lat_\mathit{geocentric}) *
-radius_\mathit{geocentric}$ \\
-$y = sin(lon_\mathit{geocentric}) * cos(lat_\mathit{geocentric}) *
-radius_\mathit{geocentric}$ \\
-$z = sin(lat_\mathit{geocentric}) * radius_\mathit{geocentric}$
+by using the following formula:
-So far I haven't needed to convert from the cartesian coordinate
-system back into any of the polar representations so I haven't derived
-that part yet. However, it should be pretty straightforward.
-
-
-\section{Scenery Representation}
-
-This section is a work in progress. I am hashing out ideas as I
-write, so please feel free to send me your comments and suggestions.
-
-\subsection{External Scenery Representation}
-
-This section should deal with the external file format(s) that FG can
-use for input.
-
-\subsection{Internal Scenery Representation}
-
-This section describes how FG represents, manipulates, and
-transforms scenery internally.
-
-Internal, all FG scenery is defined using the coordinate system shown
-in figure \ref{fig:coords}. This means that regardless of the
-external scenery representation, FG will convert all object to it's
-internal coordinate system when it loads the external file. Note,
-when a default external FG scenery representation is created, its
-representation should probably parallel the internal FG representation
-as close as possible. This way, most necessary conversions can then
-be done offline in advance.
-
-\subsection{Scenery Partitioning}
-
-For a first stab, scenery will be partitioned along longitude and
-latitude lines. This will form trapezium shaped chunks. I'd like to
-shoot for 10km x 10km chunks. So, as we move towards the poles, the
-width in degrees of these areas will have to increase. Figure
-\ref{fig:trap} shows an exaggerated scenery area.
-
-\begin{figure}[hbt]
- \centerline{
- \psfig{file=trap.eps}
- }
- \caption{Scenery Partitioning Scheme}
- \label{fig:trap}
-\end{figure}
-
-\subsection{Reference Points}
-
-Each scenery area will have a reference point at the center of its
-area. This reference point (for purposes of avoiding floating point
-precision problems) defines the origin of a local coordinate system
-which is oriented the same as the global coordinate system. The only
-difference is the origin is translated from the center of the earth to
-the center of the individual areas. Figure \ref{fig:reference}
-demonstrates this.
-
-\begin{figure}[hbt]
- \centerline{
- \psfig{file=ref.eps}
- }
- \caption{Reference Points and Translations}
- \label{fig:reference}
-\end{figure}
-
-All the objects for a specific scenery area will be defined based on
-this local coordinate system. For each scenery area we define a
-vector $\vec{\mathbf{a}}$ which represents the distance from the
-center of the earth to the local coordinate system.
-
-
-\subsection{Putting the pieces of scenery together}
+\noindent
+\[ x = cos(lon_\mathit{geocentric}) * cos(lat_\mathit{geocentric}) *
+radius_\mathit{geocentric} \]
+\[ y = sin(lon_\mathit{geocentric}) * cos(lat_\mathit{geocentric}) *
+radius_\mathit{geocentric} \]
+\[ z = sin(lat_\mathit{geocentric}) * radius_\mathit{geocentric} \]
-To render a scene, the scenery manager will need to load all the
-nearby areas. Also, we define a vector $\vec{\mathbf{v}}$ which
-represents the distance from the center of the earth to the current
-view point. Before rendering each scenery area we translate it by
-$\vec{\mathbf{a}} - \vec{\mathbf{v}}$. This moves all the current
-scenery areas near the origin, while maintaining the relative
-positions and orientations. All these transformations are inexpensive
-to calculate and can be done easily with standard OpenGL calls.
+Here is the formula to convert from cartesian coordinates back into
+geocentric coordinates:
-It is straightforward to calculate the proper view point and up vector
-so that the scenery will appear right side up when it is rendered.
+\noindent
+\[ lon = atan2( y, x ) \]
+\[ lat = \frac{\pi}{2} - atan2( \sqrt{x*x + y*y}, z ) \]
+\[ radius = \sqrt{x*x + y*y + z*z} \]
+++ /dev/null
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter
-100.00
-Single
-0
-1200 2
-5 1 0 1 0 7 0 0 -1 0.000 0 1 0 0 6900.000 3304.688 5100 5700 6975 6300 8700 5700
-5 1 1 1 0 7 0 0 -1 4.000 0 0 0 0 6900.000 8100.000 5100 5700 6900 5100 8700 5700
-5 1 0 1 0 7 0 0 -1 4.000 0 0 0 0 6900.000 5175.000 5925 5100 6075 4650 6375 4350
-5 1 0 1 0 7 0 0 -1 4.000 0 0 0 0 8887.500 5062.500 6600 5325 6600 4800 6675 4425
-5 1 0 1 0 7 0 0 -1 4.000 0 1 0 0 6675.000 3975.000 5925 5100 6225 5250 6600 5325
-5 1 0 1 0 7 0 0 -1 4.000 0 1 0 0 6600.000 4087.500 6375 4350 6525 4425 6675 4425
-1 3 0 1 0 7 0 0 -1 0.000 1 0.0000 6900 5700 1802 1802 6900 5700 8700 5775
-2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 1.00 60.00 120.00
- 6300 4800 6300 3600
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 6900 5700 9300 5700
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 6900 5700 7800 4800
-2 1 0 2 0 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 2.00 120.00 240.00
- 6900 5700 6900 3300
-2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 1.00 60.00 120.00
- 6300 4800 7200 4800
-2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 0 2
- 2 1 1.00 60.00 120.00
- 6300 4800 6750 4350
-2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 0 2
- 0 0 1.00 60.00 120.00
- 6900 5700 6300 4800
-2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 0 2
- 0 0 1.00 60.00 120.00
- 6075 4950 6300 4950
-4 0 0 0 0 0 14 0.0000 4 150 120 6825 3150 Z\001
-4 0 0 0 0 0 14 0.0000 4 150 135 7875 4800 Y\001
-4 0 0 0 0 0 14 0.0000 4 150 150 9450 5775 X\001
-4 0 0 0 0 0 12 0.0000 4 135 135 7275 4875 X\001
-4 0 0 0 0 0 12 0.0000 4 135 135 6675 4275 Y\001
-4 0 0 0 0 0 12 0.0000 4 135 120 6300 3525 Z\001
-4 0 0 0 0 0 12 0.0000 4 90 90 6150 5100 a\001
projects / flightgear.git / commitdiff