fly/flightgear
1
0
Fork 0
Code Activity
flightgear/src/AIModel/AIThermal.hxx

66 lines
1.9 KiB
C++
Raw Normal View History

Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
// FGAIThermal - AIBase derived class creates an AI thunderstorm
//
// Written by David Culp, started Feb 2004.
//
// Copyright (C) 2004 David P. Culp - davidculp2@comcast.net
//
// 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.
#ifndef _FG_AIThermal_HXX
#define _FG_AIThermal_HXX
#include "AIManager.hxx"
#include "AIBase.hxx"
#include <string>
SG_USING_STD(string);
class FGAIThermal : public FGAIBase {
public:
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
FGAIThermal();
Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
~FGAIThermal();
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
void readFromScenario(SGPropertyNode* scFileNode);
virtual bool init();
Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
virtual void bind();
virtual void unbind();
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
virtual void update(double dt);
Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
David Culp: I added some things to the AI stuff to improve the AIThermal processing. Before, all the thermals were processed in order, and the last one overwrote the prior one. Now, only the data from the nearest thermal is kept. This way a tile can be populated with many thermals, and (as long as they have the same diameter) the one nearest the airplane correctly takes effect. This will make us ready for the next step, "auto-thermaling", where FlightGear's tile manager can cover a tile with thermals, and set the thermal strength based on land-use type. I moved the enumerated object_type to the base class. When an AI object is created it now sets the _otype variable in the base class. This lets the AI manager find out what kind of AI object it is dealing with, using the base pointer. I also added a function isa() to the base class, so the manager can process objects differently based on their type. The AI manager now sends AIThermal processing to a different function, where only the data from the nearest thermal is kept. After the manager processes all the AI objects, then the results from the nearest thermal are applied to wind-from-down.
2004-03-07 12:08:46 +00:00
inline void setMaxStrength( double s ) { max_strength = s; };
Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
inline void setDiameter( double d ) { diameter = d; };
David Culp: Here are files to get automated contrails working. I've set up contrails for the 737, using my simple, untextured contrail model. Vivian has made another contrail model, but I'm still trying to get his to work. I'm hoping others will try to make contrail models also. Here's some code that defines a top to thermals. When the top of a thermal is reached the strength is phased-out linearly over the next 100 feet of altitude. At first I tried just capping the thermal at the top, but the change in thermal strength was too fast for the FDM to handle well. Included is a new version of the thermal scenario that includes a top (height-msl) to the thermal. The default value is 5000 feet.
2004-11-07 14:46:21 +00:00
inline void setHeight( double h ) { height = h; };
David Culp: I added some things to the AI stuff to improve the AIThermal processing. Before, all the thermals were processed in order, and the last one overwrote the prior one. Now, only the data from the nearest thermal is kept. This way a tile can be populated with many thermals, and (as long as they have the same diameter) the one nearest the airplane correctly takes effect. This will make us ready for the next step, "auto-thermaling", where FlightGear's tile manager can cover a tile with thermals, and set the thermal strength based on land-use type. I moved the enumerated object_type to the base class. When an AI object is created it now sets the _otype variable in the base class. This lets the AI manager find out what kind of AI object it is dealing with, using the base pointer. I also added a function isa() to the base class, so the manager can process objects differently based on their type. The AI manager now sends AIThermal processing to a different function, where only the data from the nearest thermal is kept. After the manager processes all the AI objects, then the results from the nearest thermal are applied to wind-from-down.
2004-03-07 12:08:46 +00:00
inline double getStrength() const { return strength; };
inline double getDiameter() const { return diameter; };
David Culp: Here are files to get automated contrails working. I've set up contrails for the 737, using my simple, untextured contrail model. Vivian has made another contrail model, but I'm still trying to get his to work. I'm hoping others will try to make contrail models also. Here's some code that defines a top to thermals. When the top of a thermal is reached the strength is phased-out linearly over the next 100 feet of altitude. At first I tried just capping the thermal at the top, but the change in thermal strength was too fast for the FDM to handle well. Included is a new version of the thermal scenario that includes a top (height-msl) to the thermal. The default value is 5000 feet.
2004-11-07 14:46:21 +00:00
inline double getHeight() const { return height; };
Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
Mathias Froehlich: This patch removes some useless indirection when creating AIModels. It obsolets AIScenario*. AIEntities are just an intermediate copy of an other intermediate copy of an xml file on the way from the ai scenario configuration file to the AIModels. As such the AImodels can now be created directly from the property tree read from the scenario file. This reduces the amount of work needed to add an other AIModel and reduces the amount of copy operations done during initialization. It also moves internal knowledge of special AI models into these special AI models class instead of spreading that into the whole AIModel subdirectory which in turn enables to use carrier internal data structures for carrier internal data ... Also some unused variables are removed from the AIModel classes. I believe that there are still more of them, but that is what I stumbled accross ... Tested, like the other splitouts these days in a seperate tree and using the autopilot for some time, and in this case with a carrier start ...
2006-02-11 13:16:56 +00:00
virtual const char* getTypeString(void) const { return "thermal"; }
Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
private:
void Run(double dt);
David Culp: I added some things to the AI stuff to improve the AIThermal processing. Before, all the thermals were processed in order, and the last one overwrote the prior one. Now, only the data from the nearest thermal is kept. This way a tile can be populated with many thermals, and (as long as they have the same diameter) the one nearest the airplane correctly takes effect. This will make us ready for the next step, "auto-thermaling", where FlightGear's tile manager can cover a tile with thermals, and set the thermal strength based on land-use type. I moved the enumerated object_type to the base class. When an AI object is created it now sets the _otype variable in the base class. This lets the AI manager find out what kind of AI object it is dealing with, using the base pointer. I also added a function isa() to the base class, so the manager can process objects differently based on their type. The AI manager now sends AIThermal processing to a different function, where only the data from the nearest thermal is kept. After the manager processes all the AI objects, then the results from the nearest thermal are applied to wind-from-down.
2004-03-07 12:08:46 +00:00
double max_strength;
Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
double strength;
double diameter;
David Culp: Here are files to get automated contrails working. I've set up contrails for the 737, using my simple, untextured contrail model. Vivian has made another contrail model, but I'm still trying to get his to work. I'm hoping others will try to make contrail models also. Here's some code that defines a top to thermals. When the top of a thermal is reached the strength is phased-out linearly over the next 100 feet of altitude. At first I tried just capping the thermal at the top, but the change in thermal strength was too fast for the FDM to handle well. Included is a new version of the thermal scenario that includes a top (height-msl) to the thermal. The default value is 5000 feet.
2004-11-07 14:46:21 +00:00
double height;
David Culp: I added some things to the AI stuff to improve the AIThermal processing. Before, all the thermals were processed in order, and the last one overwrote the prior one. Now, only the data from the nearest thermal is kept. This way a tile can be populated with many thermals, and (as long as they have the same diameter) the one nearest the airplane correctly takes effect. This will make us ready for the next step, "auto-thermaling", where FlightGear's tile manager can cover a tile with thermals, and set the thermal strength based on land-use type. I moved the enumerated object_type to the base class. When an AI object is created it now sets the _otype variable in the base class. This lets the AI manager find out what kind of AI object it is dealing with, using the base pointer. I also added a function isa() to the base class, so the manager can process objects differently based on their type. The AI manager now sends AIThermal processing to a different function, where only the data from the nearest thermal is kept. After the manager processes all the AI objects, then the results from the nearest thermal are applied to wind-from-down.
2004-03-07 12:08:46 +00:00
double factor;
Put the AIStorm and AIThermal classes back in
2004-03-03 20:26:06 +00:00
};
#endif // _FG_AIThermal_HXX
Copy permalink