fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/Scenery/scenery.hxx

186 lines
6.4 KiB
C++
Raw Normal View History

C++-ifying.
1998-10-16 23:26:44 +00:00
// scenery.hxx -- data structures and routines for managing scenery.
//
// Written by Curtis Olson, started May 1997.
//
Fix my mailing address by replacing it with my web page.
2004-11-19 22:10:41 +00:00
// Copyright (C) 1997 Curtis L. Olson - http://www.flightgear.org/~curt
C++-ifying.
1998-10-16 23:26:44 +00:00
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
new FSF address
2006-02-21 01:16:04 +00:00
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
C++-ifying.
1998-10-16 23:26:44 +00:00
//
// $Id$
directory shuffling ...
1997-06-21 17:57:21 +00:00
Added a command line rendering option specify smooth/flat shading.
1998-04-30 12:35:26 +00:00
#ifndef _SCENERY_HXX
#define _SCENERY_HXX
directory shuffling ...
1997-06-21 17:57:21 +00:00
Added a command line rendering option specify smooth/flat shading.
1998-04-30 12:35:26 +00:00
#ifndef __cplusplus
# error This library requires C++
#endif
C++ - ifing the code a bit.
1998-04-22 13:21:26 +00:00
Mathias: I have done a patch to eliminate the jitter of 3D-objects near the viewpoint (for example 3D cockpit objects). The problem is the roundoff accuracy of the float values used in the scenegraph together with the transforms of the eyepoint relative to the scenery center. The solution will be to move the scenery center near the view point. This way floats relative accuracy is enough to show a stable picture. To get that right I have introduced a transform node for the scenegraph which is responsible for that shift and uses double values as long as possible. The scenery subsystem now has a list of all those transforms required to place objects in the world and will tell all those transforms that the scenery center has changed when the set_scenery_center() of the scenery subsystem is called. The problem was not solvable by SGModelPlacement and SGLocation, since not all objects, especially the scenery, are placed using these classes. The first approach was to have the scenery center exactly at the eyepoint. This works well for the cockpit. But then the ground jitters a bit below the aircraft. With our default views you can't see that, but that F-18 has a camera view below the left engine intake with the nose gear and the ground in its field of view, here I could see that. Having the scenery center constant will still have this roundoff problems, but like it is now too, the roundoff error here is exactly the same in each frame, so you will not notice any jitter. The real solution is now to keep the scenery center constant as long as it is in a ball of 30m radius around the view point. If the scenery center is outside this ball, just put it at the view point. As a sideeffect of now beeing able to switch the scenery center in the whole scenegraph with one function call, I was able to remove a one half of a problem when switching views, where the scenery center was far off for one or two frames past switching from one view to the next. Also included is a fix to the other half of this problem, where the view position was not yet copied into a view when it is switched (at least under glut). This was responsible for the 'Error: ...' messages of the cloud subsystem when views were switched.
2005-04-29 14:38:24 +00:00
#include <list>
Finish what was committed in a broken state yesterday. Split up main.cxx into a program manegement part (which remains in main.cxx) and a render part (the new renderer.?xx files). Also turn the renderer into a small class of it's own. At this time not really exctining because most of the stuff is still global, but it allows us to slowly migrate some of the global definitions into the new class. The FGRenderer class is now managed by globals, so to get the renderer just call gloabals->get_renderer() At some pijt it might be a good idea to also turn the remaining code in main into a class of it's own. With a bit of luck we end up with a more robust, and better maintainable code.
2004-09-20 13:21:51 +00:00
Updates, optimizations, and restructures from Norman Vine.
2000-06-15 22:32:26 +00:00
#include <plib/sg.h>
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
Mathias: I have done a patch to eliminate the jitter of 3D-objects near the viewpoint (for example 3D cockpit objects). The problem is the roundoff accuracy of the float values used in the scenegraph together with the transforms of the eyepoint relative to the scenery center. The solution will be to move the scenery center near the view point. This way floats relative accuracy is enough to show a stable picture. To get that right I have introduced a transform node for the scenegraph which is responsible for that shift and uses double values as long as possible. The scenery subsystem now has a list of all those transforms required to place objects in the world and will tell all those transforms that the scenery center has changed when the set_scenery_center() of the scenery subsystem is called. The problem was not solvable by SGModelPlacement and SGLocation, since not all objects, especially the scenery, are placed using these classes. The first approach was to have the scenery center exactly at the eyepoint. This works well for the cockpit. But then the ground jitters a bit below the aircraft. With our default views you can't see that, but that F-18 has a camera view below the left engine intake with the nose gear and the ground in its field of view, here I could see that. Having the scenery center constant will still have this roundoff problems, but like it is now too, the roundoff error here is exactly the same in each frame, so you will not notice any jitter. The real solution is now to keep the scenery center constant as long as it is in a ball of 30m radius around the view point. If the scenery center is outside this ball, just put it at the view point. As a sideeffect of now beeing able to switch the scenery center in the whole scenegraph with one function call, I was able to remove a one half of a problem when switching views, where the scenery center was far off for one or two frames past switching from one view to the next. Also included is a fix to the other half of this problem, where the view position was not yet copied into a view when it is switched (at least under glut). This was responsible for the 'Error: ...' messages of the cloud subsystem when views were switched.
2005-04-29 14:38:24 +00:00
#include <simgear/compiler.h>
Move FGEventMgr and FGSubsystemMgr over to SimGear, add SGEventMgr to FlightGear's globals structre and some small code cleanups
2003-09-24 17:20:55 +00:00
#include <simgear/structure/subsystem_mgr.hxx>
One more pass at a reorg.
2000-02-16 23:01:03 +00:00
#include <simgear/math/point3d.hxx>
Mathias Frhlich: Make use of the automatic reference counting class for ssg* data in flightgear.
2006-02-08 10:25:56 +00:00
#include <simgear/scene/model/placementtrans.hxx>
#include <simgear/structure/ssgSharedPtr.hxx>
Prepairing for C++ integration.
1998-04-21 17:02:27 +00:00
Mathias: I have done a patch to eliminate the jitter of 3D-objects near the viewpoint (for example 3D cockpit objects). The problem is the roundoff accuracy of the float values used in the scenegraph together with the transforms of the eyepoint relative to the scenery center. The solution will be to move the scenery center near the view point. This way floats relative accuracy is enough to show a stable picture. To get that right I have introduced a transform node for the scenegraph which is responsible for that shift and uses double values as long as possible. The scenery subsystem now has a list of all those transforms required to place objects in the world and will tell all those transforms that the scenery center has changed when the set_scenery_center() of the scenery subsystem is called. The problem was not solvable by SGModelPlacement and SGLocation, since not all objects, especially the scenery, are placed using these classes. The first approach was to have the scenery center exactly at the eyepoint. This works well for the cockpit. But then the ground jitters a bit below the aircraft. With our default views you can't see that, but that F-18 has a camera view below the left engine intake with the nose gear and the ground in its field of view, here I could see that. Having the scenery center constant will still have this roundoff problems, but like it is now too, the roundoff error here is exactly the same in each frame, so you will not notice any jitter. The real solution is now to keep the scenery center constant as long as it is in a ball of 30m radius around the view point. If the scenery center is outside this ball, just put it at the view point. As a sideeffect of now beeing able to switch the scenery center in the whole scenegraph with one function call, I was able to remove a one half of a problem when switching views, where the scenery center was far off for one or two frames past switching from one view to the next. Also included is a fix to the other half of this problem, where the view position was not yet copied into a view when it is switched (at least under glut). This was responsible for the 'Error: ...' messages of the cloud subsystem when views were switched.
2005-04-29 14:38:24 +00:00
SG_USING_STD(list);
Prepairing for C++ integration.
1998-04-21 17:02:27 +00:00
Make it compile, link and run again (pfew\!)
2004-09-19 18:34:47 +00:00
class ssgRoot;
class ssgBranch;
Finish what was committed in a broken state yesterday. Split up main.cxx into a program manegement part (which remains in main.cxx) and a render part (the new renderer.?xx files). Also turn the renderer into a small class of it's own. At this time not really exctining because most of the stuff is still global, but it allows us to slowly migrate some of the global definitions into the new class. The FGRenderer class is now managed by globals, so to get the renderer just call gloabals->get_renderer() At some pijt it might be a good idea to also turn the remaining code in main into a class of it's own. With a bit of luck we end up with a more robust, and better maintainable code.
2004-09-20 13:21:51 +00:00
C++-ifying.
1998-10-16 23:26:44 +00:00
// Define a structure containing global scenery parameters
Move FGEventMgr and FGSubsystemMgr over to SimGear, add SGEventMgr to FlightGear's globals structre and some small code cleanups
2003-09-24 17:20:55 +00:00
class FGScenery : public SGSubsystem {
C++-ifying.
1998-10-16 23:26:44 +00:00
// center of current scenery chunk
Converted to Point3D class.
1998-10-16 00:51:46 +00:00
Point3D center;
Shufflin' stuff.
1997-09-04 02:17:18 +00:00
C++-ifying.
1998-10-16 23:26:44 +00:00
// next center of current scenery chunk
Converted to Point3D class.
1998-10-16 00:51:46 +00:00
Point3D next_center;
Thursday's tweaks.
1998-02-20 00:16:14 +00:00
Mathias Frhlich: I have prepared a patch that: - Introduces a FGTileMgr::scenery_available method which asks the tilemanager if scenery for a given range around a lat/lon pair is already loaded and make use of that method at some -9999 meter checks. - Introduces a FGScenery::get_elevation_m method which queries the altitude at a given position. In constrast to the groundcache functions this is the best choice if you ask for one *single* altitude value. Make use of that thing in AI/ATC classes and for the current views ground level. At the current views part the groundcache is reused if possible. - The computation of the 'current groundlevel' is no longer done on the tilemanagers update since the required functions are now better seperated. Alltogether it eliminates somehow redundant terrain level computations which are now superseeded by that more finegrained functions and the existence of the groundcache. Additionally it introduces an api to commonly required functions which was very complex to do prevously.
2005-08-14 12:57:12 +00:00
// FIXME this should be a views property
C++-ifying.
1998-10-16 23:26:44 +00:00
// angle of sun relative to current local horizontal
Shufflin' stuff.
1997-09-04 02:17:18 +00:00
double sun_angle;
Added ground collision detection. This involved: - saving the entire vertex list for each tile with the tile records. - saving the face list for each fragment with the fragment records. - code to intersect the current vertical line with the proper face in an efficient manner as possible. Fixed a bug where the tiles weren't being shifted to "near" (0,0,0)
1998-07-12 03:18:27 +00:00
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
// SSG scene graph
Mathias Frhlich: Make use of the automatic reference counting class for ssg* data in flightgear.
2006-02-08 10:25:56 +00:00
ssgSharedPtr<ssgRoot> scene_graph;
ssgSharedPtr<ssgBranch> terrain_branch;
ssgSharedPtr<ssgRoot> gnd_lights_root;
ssgSharedPtr<ssgRoot> vasi_lights_root;
ssgSharedPtr<ssgRoot> rwy_lights_root;
ssgSharedPtr<ssgRoot> taxi_lights_root;
ssgSharedPtr<ssgBranch> models_branch;
ssgSharedPtr<ssgBranch> aircraft_branch;
Moved some scenery component initialization into FGScenery.
2002-05-14 06:08:28 +00:00
Mathias: I have done a patch to eliminate the jitter of 3D-objects near the viewpoint (for example 3D cockpit objects). The problem is the roundoff accuracy of the float values used in the scenegraph together with the transforms of the eyepoint relative to the scenery center. The solution will be to move the scenery center near the view point. This way floats relative accuracy is enough to show a stable picture. To get that right I have introduced a transform node for the scenegraph which is responsible for that shift and uses double values as long as possible. The scenery subsystem now has a list of all those transforms required to place objects in the world and will tell all those transforms that the scenery center has changed when the set_scenery_center() of the scenery subsystem is called. The problem was not solvable by SGModelPlacement and SGLocation, since not all objects, especially the scenery, are placed using these classes. The first approach was to have the scenery center exactly at the eyepoint. This works well for the cockpit. But then the ground jitters a bit below the aircraft. With our default views you can't see that, but that F-18 has a camera view below the left engine intake with the nose gear and the ground in its field of view, here I could see that. Having the scenery center constant will still have this roundoff problems, but like it is now too, the roundoff error here is exactly the same in each frame, so you will not notice any jitter. The real solution is now to keep the scenery center constant as long as it is in a ball of 30m radius around the view point. If the scenery center is outside this ball, just put it at the view point. As a sideeffect of now beeing able to switch the scenery center in the whole scenegraph with one function call, I was able to remove a one half of a problem when switching views, where the scenery center was far off for one or two frames past switching from one view to the next. Also included is a fix to the other half of this problem, where the view position was not yet copied into a view when it is switched (at least under glut). This was responsible for the 'Error: ...' messages of the cloud subsystem when views were switched.
2005-04-29 14:38:24 +00:00
// list of all placement transform, used to move the scenery center on the fly.
Mathias Frhlich: Make use of the automatic reference counting class for ssg* data in flightgear.
2006-02-08 10:25:56 +00:00
typedef list<ssgSharedPtr<ssgPlacementTransform> > placement_list_type;
Mathias: I have done a patch to eliminate the jitter of 3D-objects near the viewpoint (for example 3D cockpit objects). The problem is the roundoff accuracy of the float values used in the scenegraph together with the transforms of the eyepoint relative to the scenery center. The solution will be to move the scenery center near the view point. This way floats relative accuracy is enough to show a stable picture. To get that right I have introduced a transform node for the scenegraph which is responsible for that shift and uses double values as long as possible. The scenery subsystem now has a list of all those transforms required to place objects in the world and will tell all those transforms that the scenery center has changed when the set_scenery_center() of the scenery subsystem is called. The problem was not solvable by SGModelPlacement and SGLocation, since not all objects, especially the scenery, are placed using these classes. The first approach was to have the scenery center exactly at the eyepoint. This works well for the cockpit. But then the ground jitters a bit below the aircraft. With our default views you can't see that, but that F-18 has a camera view below the left engine intake with the nose gear and the ground in its field of view, here I could see that. Having the scenery center constant will still have this roundoff problems, but like it is now too, the roundoff error here is exactly the same in each frame, so you will not notice any jitter. The real solution is now to keep the scenery center constant as long as it is in a ball of 30m radius around the view point. If the scenery center is outside this ball, just put it at the view point. As a sideeffect of now beeing able to switch the scenery center in the whole scenegraph with one function call, I was able to remove a one half of a problem when switching views, where the scenery center was far off for one or two frames past switching from one view to the next. Also included is a fix to the other half of this problem, where the view position was not yet copied into a view when it is switched (at least under glut). This was responsible for the 'Error: ...' messages of the cloud subsystem when views were switched.
2005-04-29 14:38:24 +00:00
placement_list_type _placement_list;
This set of changes touches a *lot* of files. The main goal here is to fix startup sequence problems where we initialize the FDM before we know the desired starting altitude. These changes delay fdm initialization until the local tile has been loaded and we can do a real intersection and find the true ground elevation. In order to do this, I depend more on the property manager as glue, rather than the FGInterface. There are some glitches still when switching to a new airport or reseting the sim. I will work on addressing these, but I need to commit the changes so far to keep in sync with other developers.
2001-10-28 16:16:30 +00:00
public:
FGScenery();
~FGScenery();
Move FGEventMgr and FGSubsystemMgr over to SimGear, add SGEventMgr to FlightGear's globals structre and some small code cleanups
2003-09-24 17:20:55 +00:00
// Implementation of SGSubsystem.
This set of changes touches a *lot* of files. The main goal here is to fix startup sequence problems where we initialize the FDM before we know the desired starting altitude. These changes delay fdm initialization until the local tile has been loaded and we can do a real intersection and find the true ground elevation. In order to do this, I depend more on the property manager as glue, rather than the FGInterface. There are some glitches still when switching to a new airport or reseting the sim. I will work on addressing these, but I need to commit the changes so far to keep in sync with other developers.
2001-10-28 16:16:30 +00:00
void init ();
void bind ();
void unbind ();
Major overhaul: - changed FGSubsystem::update(int) to FGSubsystem::update(delta_time_sec); the argument is now delta time in seconds rather than milliseconds - added FGSubsystem::suspend(), FGSubsystem::suspend(bool), FGSubsystem::resume(), and FGSubsystem::is_suspended(), all with default implementations; is_suspended takes account of the master freeze as well as the subsystem's individual suspended state - the FDMs now use the delta time argument the same as the rest of FlightGear; formerly, main.cxx made a special case and passed a multiloop argument - FDMs now calculate multiloop internally instead of relying on main.cxx There are probably some problems -- I've done basic testing with the major FDMs and subsystems, but we'll probably need a few weeks to sniff out bugs.
2002-05-11 16:28:50 +00:00
void update (double dt);
This set of changes touches a *lot* of files. The main goal here is to fix startup sequence problems where we initialize the FDM before we know the desired starting altitude. These changes delay fdm initialization until the local tile has been loaded and we can do a real intersection and find the true ground elevation. In order to do this, I depend more on the property manager as glue, rather than the FGInterface. There are some glitches still when switching to a new airport or reseting the sim. I will work on addressing these, but I need to commit the changes so far to keep in sync with other developers.
2001-10-28 16:16:30 +00:00
Mathias Frhlich: I have prepared a patch that: - Introduces a FGTileMgr::scenery_available method which asks the tilemanager if scenery for a given range around a lat/lon pair is already loaded and make use of that method at some -9999 meter checks. - Introduces a FGScenery::get_elevation_m method which queries the altitude at a given position. In constrast to the groundcache functions this is the best choice if you ask for one *single* altitude value. Make use of that thing in AI/ATC classes and for the current views ground level. At the current views part the groundcache is reused if possible. - The computation of the 'current groundlevel' is no longer done on the tilemanagers update since the required functions are now better seperated. Alltogether it eliminates somehow redundant terrain level computations which are now superseeded by that more finegrained functions and the existence of the groundcache. Additionally it introduces an api to commonly required functions which was very complex to do prevously.
2005-08-14 12:57:12 +00:00
/// Compute the elevation of the scenery at geodetic latitude lat,
/// geodetic longitude lon and not higher than max_alt.
/// If the exact flag is set to true, the scenery center is moved to
/// gain a higher accuracy of that query. The center is restored past
/// that to the original value.
/// The altitude hit is returned in the alt argument.
/// The method returns true if the scenery is available for the given
/// lat/lon pair. If there is no scenery for that point, the altitude
/// value is undefined.
/// All values are meant to be in meters or degrees.
bool get_elevation_m(double lat, double lon, double max_alt,
double& alt, bool exact = false);
Make use of the ground material types
2006-06-08 05:58:36 +00:00
bool get_material_m(double lat, double lon, double max_alt,
double& alt, string & material, bool exact = false);
Mathias Frhlich: I have prepared a patch that: - Introduces a FGTileMgr::scenery_available method which asks the tilemanager if scenery for a given range around a lat/lon pair is already loaded and make use of that method at some -9999 meter checks. - Introduces a FGScenery::get_elevation_m method which queries the altitude at a given position. In constrast to the groundcache functions this is the best choice if you ask for one *single* altitude value. Make use of that thing in AI/ATC classes and for the current views ground level. At the current views part the groundcache is reused if possible. - The computation of the 'current groundlevel' is no longer done on the tilemanagers update since the required functions are now better seperated. Alltogether it eliminates somehow redundant terrain level computations which are now superseeded by that more finegrained functions and the existence of the groundcache. Additionally it introduces an api to commonly required functions which was very complex to do prevously.
2005-08-14 12:57:12 +00:00
/// Compute the elevation of the scenery beow the cartesian point pos.
/// you the returned scenery altitude is not higher than the position
/// pos plus an ofset given with max_altoff.
/// If the exact flag is set to true, the scenery center is moved to
/// gain a higher accuracy of that query. The center is restored past
/// that to the original value.
/// The altitude hit is returned in the alt argument.
/// The method returns true if the scenery is available for the given
/// lat/lon pair. If there is no scenery for that point, the altitude
/// value is undefined.
/// All values are meant to be in meters.
Alex Romosan: * Use "const string&" rather than "string" in function calls when appropriate. * Use "const Point3D&" instead of "Pint3D" in function calls when appropriate. * Improved course calculation in calc_gc_course_dist() * Safer thread handling code. Vassilii Khachaturov: Dont use "const Point3D&" for return types unless you're absolutely sure. Erik Hofman: * Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than calculating it by hand every time.
2005-10-25 13:49:55 +00:00
bool get_cart_elevation_m(const sgdVec3& pos, double max_altoff,
Mathias Frhlich: I have prepared a patch that: - Introduces a FGTileMgr::scenery_available method which asks the tilemanager if scenery for a given range around a lat/lon pair is already loaded and make use of that method at some -9999 meter checks. - Introduces a FGScenery::get_elevation_m method which queries the altitude at a given position. In constrast to the groundcache functions this is the best choice if you ask for one *single* altitude value. Make use of that thing in AI/ATC classes and for the current views ground level. At the current views part the groundcache is reused if possible. - The computation of the 'current groundlevel' is no longer done on the tilemanagers update since the required functions are now better seperated. Alltogether it eliminates somehow redundant terrain level computations which are now superseeded by that more finegrained functions and the existence of the groundcache. Additionally it introduces an api to commonly required functions which was very complex to do prevously.
2005-08-14 12:57:12 +00:00
double& radius, bool exact = false);
Make use of the ground material types
2006-06-08 05:58:36 +00:00
bool get_cart_material_m(const sgdVec3& pos, double max_altoff,
double& radius, string& material, bool exact = false);
This set of changes touches a *lot* of files. The main goal here is to fix startup sequence problems where we initialize the FDM before we know the desired starting altitude. These changes delay fdm initialization until the local tile has been loaded and we can do a real intersection and find the true ground elevation. In order to do this, I depend more on the property manager as glue, rather than the FGInterface. There are some glitches still when switching to a new airport or reseting the sim. I will work on addressing these, but I need to commit the changes so far to keep in sync with other developers.
2001-10-28 16:16:30 +00:00
Mathias Fröhlich: Take any arbitrary vector (not necessarily vertical) and intersect it with the current set of loaded terrain tiles. Returns lon, lat, elev. This could have a multitude of useful applications such as testing line of sight between two objects, faking a terrain following lookahead radar system, virtual georeferencing, etc.
2005-11-09 17:08:04 +00:00
/// Compute the nearest intersection point of the line starting from
/// start going in direction dir with the terrain.
/// The input and output values should be in cartesian coordinates in the
/// usual earth centered wgs84 coordiante system. Units are meters.
/// On success, true is returned.
bool get_cart_ground_intersection(const sgdVec3& start, const sgdVec3& dir,
sgdVec3& nearestHit, bool exact = false);
Alex Romosan: * Use "const string&" rather than "string" in function calls when appropriate. * Use "const Point3D&" instead of "Pint3D" in function calls when appropriate. * Improved course calculation in calc_gc_course_dist() * Safer thread handling code. Vassilii Khachaturov: Dont use "const Point3D&" for return types unless you're absolutely sure. Erik Hofman: * Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than calculating it by hand every time.
2005-10-25 13:49:55 +00:00
inline const Point3D& get_center() const { return center; }
void set_center( const Point3D& p );
This set of changes touches a *lot* of files. The main goal here is to fix startup sequence problems where we initialize the FDM before we know the desired starting altitude. These changes delay fdm initialization until the local tile has been loaded and we can do a real intersection and find the true ground elevation. In order to do this, I depend more on the property manager as glue, rather than the FGInterface. There are some glitches still when switching to a new airport or reseting the sim. I will work on addressing these, but I need to commit the changes so far to keep in sync with other developers.
2001-10-28 16:16:30 +00:00
Alex Romosan: * Use "const string&" rather than "string" in function calls when appropriate. * Use "const Point3D&" instead of "Pint3D" in function calls when appropriate. * Improved course calculation in calc_gc_course_dist() * Safer thread handling code. Vassilii Khachaturov: Dont use "const Point3D&" for return types unless you're absolutely sure. Erik Hofman: * Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than calculating it by hand every time.
2005-10-25 13:49:55 +00:00
inline const Point3D& get_next_center() const { return next_center; }
inline void set_next_center( const Point3D& p ) { next_center = p; }
This set of changes touches a *lot* of files. The main goal here is to fix startup sequence problems where we initialize the FDM before we know the desired starting altitude. These changes delay fdm initialization until the local tile has been loaded and we can do a real intersection and find the true ground elevation. In order to do this, I depend more on the property manager as glue, rather than the FGInterface. There are some glitches still when switching to a new airport or reseting the sim. I will work on addressing these, but I need to commit the changes so far to keep in sync with other developers.
2001-10-28 16:16:30 +00:00
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline ssgRoot *get_scene_graph () const { return scene_graph; }
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
inline void set_scene_graph (ssgRoot * s) { scene_graph = s; }
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline ssgBranch *get_terrain_branch () const { return terrain_branch; }
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
inline void set_terrain_branch (ssgBranch * t) { terrain_branch = t; }
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline ssgRoot *get_gnd_lights_root () const {
return gnd_lights_root;
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
}
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline void set_gnd_lights_root (ssgRoot *r) {
gnd_lights_root = r;
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
}
Fix a small mistake in the scene graph arrangement for vasi lights.
2004-01-11 19:45:29 +00:00
inline ssgRoot *get_vasi_lights_root () const {
return vasi_lights_root;
}
inline void set_vasi_lights_root (ssgRoot *r) {
vasi_lights_root = r;
}
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline ssgRoot *get_rwy_lights_root () const {
return rwy_lights_root;
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
}
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline void set_rwy_lights_root (ssgRoot *r) {
rwy_lights_root = r;
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
}
Put taxiway lights in their own scene graph so we can adjust their brightness (or fog punch through) independently from the ground or runway lighting.
2002-11-01 21:56:48 +00:00
inline ssgRoot *get_taxi_lights_root () const {
return taxi_lights_root;
}
inline void set_taxi_lights_root (ssgRoot *r) {
taxi_lights_root = r;
}
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline ssgBranch *get_models_branch () const {
return models_branch;
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
}
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline void set_models_branch (ssgBranch *t) {
models_branch = t;
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
}
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline ssgBranch *get_aircraft_branch () const {
return aircraft_branch;
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
}
Begin work on rendering runway lights using environment maps. The basics are now working. A runway light is defined by a point and a direction. The point and direction are combined with the local up vector to create a small triangle orthogonal to the direction. The two ficticous corners of the triangle are given an alpha value of zero, the orignal corner is given an alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT) mode which means only the corner points are drawn, and since two have alpha=0 only the original point is drawn. This is a long way to go to draw a point, but it ensures that the point is only visible within 90 degrees of the light direction, behind the light it is not visible. This is still a long way to get to drawing a point, but we use an environement map, with the direction vector as the normal to mimic a light that is brightest when viewed head on and dimmest when viewed perpendicularly or disappears when viewed from behind. - warning, there is a bug in how the current runway light direction vector is calculated which will adversely effect runway lighting. The airports should be regenerated in order to fix this problem.
2002-10-06 03:53:19 +00:00
inline void set_aircraft_branch (ssgBranch *t) {
aircraft_branch = t;
Consolodating scenery structures in scenery.hxx.
2002-05-14 05:49:47 +00:00
}
Mathias: I have done a patch to eliminate the jitter of 3D-objects near the viewpoint (for example 3D cockpit objects). The problem is the roundoff accuracy of the float values used in the scenegraph together with the transforms of the eyepoint relative to the scenery center. The solution will be to move the scenery center near the view point. This way floats relative accuracy is enough to show a stable picture. To get that right I have introduced a transform node for the scenegraph which is responsible for that shift and uses double values as long as possible. The scenery subsystem now has a list of all those transforms required to place objects in the world and will tell all those transforms that the scenery center has changed when the set_scenery_center() of the scenery subsystem is called. The problem was not solvable by SGModelPlacement and SGLocation, since not all objects, especially the scenery, are placed using these classes. The first approach was to have the scenery center exactly at the eyepoint. This works well for the cockpit. But then the ground jitters a bit below the aircraft. With our default views you can't see that, but that F-18 has a camera view below the left engine intake with the nose gear and the ground in its field of view, here I could see that. Having the scenery center constant will still have this roundoff problems, but like it is now too, the roundoff error here is exactly the same in each frame, so you will not notice any jitter. The real solution is now to keep the scenery center constant as long as it is in a ball of 30m radius around the view point. If the scenery center is outside this ball, just put it at the view point. As a sideeffect of now beeing able to switch the scenery center in the whole scenegraph with one function call, I was able to remove a one half of a problem when switching views, where the scenery center was far off for one or two frames past switching from one view to the next. Also included is a fix to the other half of this problem, where the view position was not yet copied into a view when it is switched (at least under glut). This was responsible for the 'Error: ...' messages of the cloud subsystem when views were switched.
2005-04-29 14:38:24 +00:00
void register_placement_transform(ssgPlacementTransform *trans);
void unregister_placement_transform(ssgPlacementTransform *trans);
More tweaking of terrian floor.
1997-07-11 01:29:58 +00:00
};
This set of changes touches a *lot* of files. The main goal here is to fix startup sequence problems where we initialize the FDM before we know the desired starting altitude. These changes delay fdm initialization until the local tile has been loaded and we can do a real intersection and find the true ground elevation. In order to do this, I depend more on the property manager as glue, rather than the FGInterface. There are some glitches still when switching to a new airport or reseting the sim. I will work on addressing these, but I need to commit the changes so far to keep in sync with other developers.
2001-10-28 16:16:30 +00:00
C++-ifying.
1998-10-16 23:26:44 +00:00
#endif // _SCENERY_HXX
Copy permalink