1
0
Fork 0
flightgear/src/Time/light.cxx

243 lines
7.2 KiB
C++
Raw Normal View History

//
// light.hxx -- lighting routines
//
// Written by Curtis Olson, started April 1998.
//
// Copyright (C) 1998 Curtis L. Olson - curt@me.umn.edu
//
// 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
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
//
// $Id$
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#ifdef HAVE_WINDOWS_H
# include <windows.h>
#endif
#include <GL/glut.h>
#include <GL/gl.h>
2000-02-15 03:30:01 +00:00
#include <simgear/compiler.h>
2001-03-23 22:42:49 +00:00
#ifdef SG_MATH_EXCEPTION_CLASH
1998-11-23 21:48:09 +00:00
# define exception c_exception
#endif
#ifdef SG_HAVE_STD_INCLUDES
# include <cmath>
#else
# include <math.h>
#endif
#include <string>
2001-03-23 22:59:18 +00:00
SG_USING_STD(string);
2000-02-15 03:30:01 +00:00
#include <simgear/constants.h>
2000-02-16 23:01:03 +00:00
#include <simgear/debug/logstream.hxx>
#include <simgear/math/interpolater.hxx>
#include <simgear/math/polar3d.hxx>
#include <simgear/misc/sg_path.hxx>
2000-02-15 03:30:01 +00:00
1998-10-17 01:33:52 +00:00
#include <Aircraft/aircraft.hxx>
#include <Main/globals.hxx>
#include <Main/viewer.hxx>
#include "light.hxx"
#include "sunpos.hxx"
fgLIGHT cur_light_params;
1998-05-20 20:54:16 +00:00
// Constructor
fgLIGHT::fgLIGHT( void ) {
}
// initialize lighting tables
1998-05-20 20:54:16 +00:00
void fgLIGHT::Init( void ) {
2001-03-24 06:03:11 +00:00
SG_LOG( SG_EVENT, SG_INFO,
"Initializing Lighting interpolation tables." );
// build the path name to the ambient lookup table
SGPath path( globals->get_fg_root() );
SGPath ambient = path;
ambient.append( "Lighting/ambient" );
SGPath diffuse = path;
diffuse.append( "Lighting/diffuse" );
SGPath sky = path;
sky.append( "Lighting/sky" );
// initialize ambient table
ambient_tbl = new SGInterpTable( ambient.str() );
// initialize diffuse table
diffuse_tbl = new SGInterpTable( diffuse.str() );
// initialize sky table
sky_tbl = new SGInterpTable( sky.str() );
}
// update lighting parameters based on current sun position
1998-05-20 20:54:16 +00:00
void fgLIGHT::Update( void ) {
FGInterface *f;
1998-05-20 20:54:16 +00:00
// if the 4th field is 0.0, this specifies a direction ...
GLfloat white[4] = { 1.0, 1.0, 1.0, 1.0 };
1998-05-20 20:54:16 +00:00
// base sky color
GLfloat base_sky_color[4] = {0.60, 0.60, 0.90, 1.0};
1998-05-20 20:54:16 +00:00
// base fog color
1998-05-11 18:18:51 +00:00
GLfloat base_fog_color[4] = {0.90, 0.90, 1.00, 1.0};
double deg, ambient, diffuse, sky_brightness;
f = current_aircraft.fdm_state;
2001-03-24 06:03:11 +00:00
SG_LOG( SG_EVENT, SG_INFO, "Updating light parameters." );
1998-05-20 20:54:16 +00:00
// calculate lighting parameters based on sun's relative angle to
// local up
2001-03-24 04:48:44 +00:00
deg = sun_angle * SGD_RADIANS_TO_DEGREES;
2001-03-24 06:03:11 +00:00
SG_LOG( SG_EVENT, SG_INFO, " Sun angle = " << deg );
ambient = ambient_tbl->interpolate( deg );
diffuse = diffuse_tbl->interpolate( deg );
sky_brightness = sky_tbl->interpolate( deg );
2001-03-24 06:03:11 +00:00
SG_LOG( SG_EVENT, SG_INFO,
" ambient = " << ambient << " diffuse = " << diffuse
<< " sky = " << sky_brightness );
// sky_brightness = 0.15; // used to force a dark sky (when testing)
// if ( ambient < 0.02 ) { ambient = 0.02; }
// if ( diffuse < 0.0 ) { diffuse = 0.0; }
// if ( sky_brightness < 0.1 ) { sky_brightness = 0.1; }
1998-05-20 20:54:16 +00:00
scene_ambient[0] = white[0] * ambient;
scene_ambient[1] = white[1] * ambient;
scene_ambient[2] = white[2] * ambient;
2000-05-27 06:40:55 +00:00
scene_ambient[3] = 1.0;
1998-05-20 20:54:16 +00:00
scene_diffuse[0] = white[0] * diffuse;
scene_diffuse[1] = white[1] * diffuse;
scene_diffuse[2] = white[2] * diffuse;
2000-05-27 06:40:55 +00:00
scene_diffuse[3] = 1.0;
1998-05-20 20:54:16 +00:00
// set sky color
sky_color[0] = base_sky_color[0] * sky_brightness;
sky_color[1] = base_sky_color[1] * sky_brightness;
sky_color[2] = base_sky_color[2] * sky_brightness;
sky_color[3] = base_sky_color[3];
1998-05-20 20:54:16 +00:00
// set fog color
fog_color[0] = base_fog_color[0] * sky_brightness;
fog_color[1] = base_fog_color[1] * sky_brightness;
fog_color[2] = base_fog_color[2] * sky_brightness;
fog_color[3] = base_fog_color[3];
}
1998-05-20 20:54:16 +00:00
// calculate fog color adjusted for sunrise/sunset effects
void fgLIGHT::UpdateAdjFog( void ) {
FGInterface *f;
double sun_angle_deg, rotation, param1[3], param2[3];
f = current_aircraft.fdm_state;
2001-03-24 06:03:11 +00:00
SG_LOG( SG_EVENT, SG_DEBUG, "Updating adjusted fog parameters." );
// set fog color (we'll try to match the sunset color in the
// direction we are looking
2002-01-22 15:38:02 +00:00
// Do some sanity checking ...
if ( sun_rotation < -2.0 * SGD_2PI || sun_rotation > 2.0 * SGD_2PI ) {
SG_LOG( SG_EVENT, SG_ALERT, "Sun rotation bad = " << sun_rotation );
exit(-1);
}
if ( f->get_Psi() < -2.0 * SGD_2PI || f->get_Psi() > 2.0 * SGD_2PI ) {
SG_LOG( SG_EVENT, SG_ALERT, "Psi rotation bad = " << f->get_Psi() );
exit(-1);
}
Major viewer-code overhaul from Jim Wilson: Description: This update includes the new viewer interface as proposed by David M. and a first pass at cleaning up the viewer/view manager code by Jim W. Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and modified the Makefile.am accordingly. Detail of work: Overall: The code reads a little easier. There are still some unnecessary bits in there and I'd like to supplement the comments in the viewer.hxx with a tiny bit on each interface group and what the groupings mean (similar but briefer than what you emailed me the other day). I tried not to mess up the style, but there is an occasional inconsistency. In general I wouldn't call it done (especially since there's no tower yet! :)), but I'd like to get this out there so others can comment, and test. In Viewer: The interface as you suggested has been implemented. Basically everything seems to work as it did visually. There is no difference that I can see in performance, although some things might be a tiny bit faster. I've merged the lookat and rph (pilot view) code into the recalc for the viewer. There is still some redundancy between the two, but a lot has been removed. In some cases I've taken some code that we'd likely want to inline anyway and left it in there in duplicate. You'll see that the code for both looks a little cleaner. I need to take a closer look at the rotations in particular. I've cleaned up a little there, but I suspect more can be done to streamline this. The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about to rip it out. It would seem that there more conventional ways to get spherical data that are just as fast. In any case all the viewer was pulling from the quat matrix was the pitch value so I modified mouse.cxx to output to our pitchOffset input and that works fine. I've changed the native values to degrees from radians where appropriate. This required a conversion from degrees to radians in a couple modules that access the interface. Perhaps we should add interface calls that do the conversion, e.g. a getHeadingOffset_rad() to go along with the getHeadingOffset_deg(). On the view_offset (now headingOffset) thing there are two entry points because of the ability to instantly switch views or to scroll to a new view angle (by hitting the numeric keys for example). This leaves an anomaly in the interface which should be resolved by adding "goal" settings to the interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc. Other than these two issues, the next step here will be to look at some further optimizations, and to write support code for a tower view. That should be fairly simple at this point. I was considering creating a "simulated tower view" or "pedestrian view" that defaulted to a position off to the right of whereever the plane is at the moment you switch to the tower view. This could be a fall back when we don't have an actual tower location at hand (as would be the case with rural airports). ViewManager: Basically all I did here was neaten things up by ripping out excess crap and made it compatible as is with the new interface. The result is that viewmanager is now ready to be developed. The two preexisting views are still hardcoded into the view manager. The next step would be to design configuration xml (eg /sim/view[x]/config/blahblah) that could be used to set up as many views as we want. If we want to take the easy way out, we might want to insist that view[0] be a pilot-view and have viewmanager check for that.
2002-03-20 17:43:28 +00:00
if ( globals->get_current_view()->getHeadingOffset_deg() * SGD_DEGREES_TO_RADIANS < -2.0 * SGD_2PI ||
globals->get_current_view()->getHeadingOffset_deg() * SGD_DEGREES_TO_RADIANS > 2.0 * SGD_2PI ) {
2002-01-22 15:39:51 +00:00
SG_LOG( SG_EVENT, SG_ALERT, "current view()->view offset bad = "
Major viewer-code overhaul from Jim Wilson: Description: This update includes the new viewer interface as proposed by David M. and a first pass at cleaning up the viewer/view manager code by Jim W. Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and modified the Makefile.am accordingly. Detail of work: Overall: The code reads a little easier. There are still some unnecessary bits in there and I'd like to supplement the comments in the viewer.hxx with a tiny bit on each interface group and what the groupings mean (similar but briefer than what you emailed me the other day). I tried not to mess up the style, but there is an occasional inconsistency. In general I wouldn't call it done (especially since there's no tower yet! :)), but I'd like to get this out there so others can comment, and test. In Viewer: The interface as you suggested has been implemented. Basically everything seems to work as it did visually. There is no difference that I can see in performance, although some things might be a tiny bit faster. I've merged the lookat and rph (pilot view) code into the recalc for the viewer. There is still some redundancy between the two, but a lot has been removed. In some cases I've taken some code that we'd likely want to inline anyway and left it in there in duplicate. You'll see that the code for both looks a little cleaner. I need to take a closer look at the rotations in particular. I've cleaned up a little there, but I suspect more can be done to streamline this. The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about to rip it out. It would seem that there more conventional ways to get spherical data that are just as fast. In any case all the viewer was pulling from the quat matrix was the pitch value so I modified mouse.cxx to output to our pitchOffset input and that works fine. I've changed the native values to degrees from radians where appropriate. This required a conversion from degrees to radians in a couple modules that access the interface. Perhaps we should add interface calls that do the conversion, e.g. a getHeadingOffset_rad() to go along with the getHeadingOffset_deg(). On the view_offset (now headingOffset) thing there are two entry points because of the ability to instantly switch views or to scroll to a new view angle (by hitting the numeric keys for example). This leaves an anomaly in the interface which should be resolved by adding "goal" settings to the interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc. Other than these two issues, the next step here will be to look at some further optimizations, and to write support code for a tower view. That should be fairly simple at this point. I was considering creating a "simulated tower view" or "pedestrian view" that defaulted to a position off to the right of whereever the plane is at the moment you switch to the tower view. This could be a fall back when we don't have an actual tower location at hand (as would be the case with rural airports). ViewManager: Basically all I did here was neaten things up by ripping out excess crap and made it compatible as is with the new interface. The result is that viewmanager is now ready to be developed. The two preexisting views are still hardcoded into the view manager. The next step would be to design configuration xml (eg /sim/view[x]/config/blahblah) that could be used to set up as many views as we want. If we want to take the easy way out, we might want to insist that view[0] be a pilot-view and have viewmanager check for that.
2002-03-20 17:43:28 +00:00
<< globals->get_current_view()->getHeadingOffset_deg() * SGD_DEGREES_TO_RADIANS );
2002-01-22 15:38:02 +00:00
exit(-1);
}
// first determine the difference between our view angle and local
// direction to the sun
2001-03-24 02:36:45 +00:00
rotation = -(sun_rotation + SGD_PI)
Major viewer-code overhaul from Jim Wilson: Description: This update includes the new viewer interface as proposed by David M. and a first pass at cleaning up the viewer/view manager code by Jim W. Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and modified the Makefile.am accordingly. Detail of work: Overall: The code reads a little easier. There are still some unnecessary bits in there and I'd like to supplement the comments in the viewer.hxx with a tiny bit on each interface group and what the groupings mean (similar but briefer than what you emailed me the other day). I tried not to mess up the style, but there is an occasional inconsistency. In general I wouldn't call it done (especially since there's no tower yet! :)), but I'd like to get this out there so others can comment, and test. In Viewer: The interface as you suggested has been implemented. Basically everything seems to work as it did visually. There is no difference that I can see in performance, although some things might be a tiny bit faster. I've merged the lookat and rph (pilot view) code into the recalc for the viewer. There is still some redundancy between the two, but a lot has been removed. In some cases I've taken some code that we'd likely want to inline anyway and left it in there in duplicate. You'll see that the code for both looks a little cleaner. I need to take a closer look at the rotations in particular. I've cleaned up a little there, but I suspect more can be done to streamline this. The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about to rip it out. It would seem that there more conventional ways to get spherical data that are just as fast. In any case all the viewer was pulling from the quat matrix was the pitch value so I modified mouse.cxx to output to our pitchOffset input and that works fine. I've changed the native values to degrees from radians where appropriate. This required a conversion from degrees to radians in a couple modules that access the interface. Perhaps we should add interface calls that do the conversion, e.g. a getHeadingOffset_rad() to go along with the getHeadingOffset_deg(). On the view_offset (now headingOffset) thing there are two entry points because of the ability to instantly switch views or to scroll to a new view angle (by hitting the numeric keys for example). This leaves an anomaly in the interface which should be resolved by adding "goal" settings to the interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc. Other than these two issues, the next step here will be to look at some further optimizations, and to write support code for a tower view. That should be fairly simple at this point. I was considering creating a "simulated tower view" or "pedestrian view" that defaulted to a position off to the right of whereever the plane is at the moment you switch to the tower view. This could be a fall back when we don't have an actual tower location at hand (as would be the case with rural airports). ViewManager: Basically all I did here was neaten things up by ripping out excess crap and made it compatible as is with the new interface. The result is that viewmanager is now ready to be developed. The two preexisting views are still hardcoded into the view manager. The next step would be to design configuration xml (eg /sim/view[x]/config/blahblah) that could be used to set up as many views as we want. If we want to take the easy way out, we might want to insist that view[0] be a pilot-view and have viewmanager check for that.
2002-03-20 17:43:28 +00:00
- (f->get_Psi() - globals->get_current_view()->getHeadingOffset_deg() * SGD_DEGREES_TO_RADIANS);
while ( rotation < 0 ) {
2001-03-24 03:10:40 +00:00
rotation += SGD_2PI;
}
2001-03-24 03:10:40 +00:00
while ( rotation > SGD_2PI ) {
rotation -= SGD_2PI;
}
2001-03-24 04:48:44 +00:00
rotation *= SGD_RADIANS_TO_DEGREES;
2001-03-24 06:03:11 +00:00
// fgPrintf( SG_EVENT, SG_INFO,
1998-07-24 21:42:25 +00:00
// " View to sun difference in degrees = %.2f\n", rotation);
// next check if we are in a sunset/sunrise situation
2001-03-24 04:48:44 +00:00
sun_angle_deg = sun_angle * SGD_RADIANS_TO_DEGREES;
if ( (sun_angle_deg > 80.0) && (sun_angle_deg < 100.0) ) {
1998-08-06 12:47:22 +00:00
/* 0.0 - 0.6 */
1998-10-20 18:41:53 +00:00
param1[0] = (10.0 - fabs(90.0 - sun_angle_deg)) / 20.0;
param1[1] = (10.0 - fabs(90.0 - sun_angle_deg)) / 40.0;
1999-04-05 02:14:40 +00:00
param1[2] = (10.0 - fabs(90.0 - sun_angle_deg)) / 30.0;
// param2[2] = -(10.0 - fabs(90.0 - sun_angle)) / 30.0;
} else {
param1[0] = param1[1] = param1[2] = 0.0;
}
if ( rotation - 180.0 <= 0.0 ) {
param2[0] = param1[0] * (180.0 - rotation) / 180.0;
param2[1] = param1[1] * (180.0 - rotation) / 180.0;
param2[2] = param1[2] * (180.0 - rotation) / 180.0;
1998-07-24 21:42:25 +00:00
// printf("param1[0] = %.2f param2[0] = %.2f\n", param1[0], param2[0]);
} else {
param2[0] = param1[0] * (rotation - 180.0) / 180.0;
param2[1] = param1[1] * (rotation - 180.0) / 180.0;
param2[2] = param1[2] * (rotation - 180.0) / 180.0;
1998-07-24 21:42:25 +00:00
// printf("param1[0] = %.2f param2[0] = %.2f\n", param1[0], param2[0]);
}
adj_fog_color[0] = fog_color[0] + param2[0];
if ( adj_fog_color[0] > 1.0 ) { adj_fog_color[0] = 1.0; }
adj_fog_color[1] = fog_color[1] + param2[1];
if ( adj_fog_color[1] > 1.0 ) { adj_fog_color[1] = 1.0; }
adj_fog_color[2] = fog_color[2] + param2[2];
if ( adj_fog_color[2] > 1.0 ) { adj_fog_color[2] = 1.0; }
adj_fog_color[3] = fog_color[3];
1998-05-20 20:54:16 +00:00
}
// Destructor
fgLIGHT::~fgLIGHT( void ) {
}
Major viewer-code overhaul from Jim Wilson: Description: This update includes the new viewer interface as proposed by David M. and a first pass at cleaning up the viewer/view manager code by Jim W. Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and modified the Makefile.am accordingly. Detail of work: Overall: The code reads a little easier. There are still some unnecessary bits in there and I'd like to supplement the comments in the viewer.hxx with a tiny bit on each interface group and what the groupings mean (similar but briefer than what you emailed me the other day). I tried not to mess up the style, but there is an occasional inconsistency. In general I wouldn't call it done (especially since there's no tower yet! :)), but I'd like to get this out there so others can comment, and test. In Viewer: The interface as you suggested has been implemented. Basically everything seems to work as it did visually. There is no difference that I can see in performance, although some things might be a tiny bit faster. I've merged the lookat and rph (pilot view) code into the recalc for the viewer. There is still some redundancy between the two, but a lot has been removed. In some cases I've taken some code that we'd likely want to inline anyway and left it in there in duplicate. You'll see that the code for both looks a little cleaner. I need to take a closer look at the rotations in particular. I've cleaned up a little there, but I suspect more can be done to streamline this. The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about to rip it out. It would seem that there more conventional ways to get spherical data that are just as fast. In any case all the viewer was pulling from the quat matrix was the pitch value so I modified mouse.cxx to output to our pitchOffset input and that works fine. I've changed the native values to degrees from radians where appropriate. This required a conversion from degrees to radians in a couple modules that access the interface. Perhaps we should add interface calls that do the conversion, e.g. a getHeadingOffset_rad() to go along with the getHeadingOffset_deg(). On the view_offset (now headingOffset) thing there are two entry points because of the ability to instantly switch views or to scroll to a new view angle (by hitting the numeric keys for example). This leaves an anomaly in the interface which should be resolved by adding "goal" settings to the interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc. Other than these two issues, the next step here will be to look at some further optimizations, and to write support code for a tower view. That should be fairly simple at this point. I was considering creating a "simulated tower view" or "pedestrian view" that defaulted to a position off to the right of whereever the plane is at the moment you switch to the tower view. This could be a fall back when we don't have an actual tower location at hand (as would be the case with rural airports). ViewManager: Basically all I did here was neaten things up by ripping out excess crap and made it compatible as is with the new interface. The result is that viewmanager is now ready to be developed. The two preexisting views are still hardcoded into the view manager. The next step would be to design configuration xml (eg /sim/view[x]/config/blahblah) that could be used to set up as many views as we want. If we want to take the easy way out, we might want to insist that view[0] be a pilot-view and have viewmanager check for that.
2002-03-20 17:43:28 +00:00