Re: [Flightgear-devel] collision avoidance
On Monday 12 June 2006 07:15, Mick - wrote: > Through observation, I found that my calculated agl value (as discussed in > my > previous post) was close to that of "/position/ground-elev-ft" when using > the > current lat/lon values instead of those from > Point3D calc_gc_lon_lat( const Point3D& orig, double course, double dist ). > I did this in an attempt to compare against the /position/ground-elev-ft > value. > The resulting value was close but not the same. Having > converted between feet and meters, and degrees and radians for the purpose > of the calculations, would this have resulted in the slight difference in > value? Ok, what is 'slight' in that case? > With my limited avionics knowledge, I assumed that: > (altitude-ft - ground-elev-ft) = altitude-agl-ft. Again, this is something > I want to verify > instead of assuming. So is it (somewhat) correct to assume that subtracting > the > current altitude from my "calculated agl" would give me the the > altitude-agl-ft? That should be ok. Anyway, I have attached the quick hack that I used to test that and the past material changes. That might serve as a starting point for you. It takes the aircraft's position (not the view position!) does an additional ground query at that location and computes an additional location 10 meters away in the direction of your view. There is also an additional ground query. Both are printed to stdout ... Hope that helps Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ? src/FDM/OpenFDM Index: configure.ac === RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v retrieving revision 1.116 diff -u -r1.116 configure.ac --- configure.ac 5 Apr 2006 19:52:52 - 1.116 +++ configure.ac 12 Jun 2006 06:13:18 - @@ -439,6 +439,14 @@ fi AM_CONDITIONAL(ENABLE_JPEG_SERVER, test "x$ac_cv_header_simgear_screen_jpgfactory_hxx" = "xyes") +dnl Check for installed OpenFDM +AC_CHECK_HEADER(OpenFDM/OpenFDMConfig.h) +AM_CONDITIONAL(ENABLE_OpenFDM_FDM, \ + [ test "x$ac_cv_header_OpenFDM_OpenFDMConfig_h" = "xyes" ] ) +if test "x$ac_cv_header_OpenFDM_OpenFDMConfig_h" = "xyes" ; then +AC_DEFINE([FG_ENABLE_OPENFDM_FDM], 1, [Define for no logging output]) +fi + AC_LANG_POP dnl Check for system installed zlib @@ -519,6 +527,7 @@ src/FDM/JSBSim/models/atmosphere/Makefile \ src/FDM/JSBSim/models/propulsion/Makefile \ src/FDM/LaRCsim/Makefile \ + src/FDM/OpenFDM/Makefile \ src/FDM/SP/Makefile \ src/FDM/UIUCModel/Makefile \ src/FDM/YASim/Makefile \ Index: src/FDM/Makefile.am === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/Makefile.am,v retrieving revision 1.7 diff -u -r1.7 Makefile.am --- src/FDM/Makefile.am 22 Nov 2004 10:10:33 - 1.7 +++ src/FDM/Makefile.am 12 Jun 2006 06:13:18 - @@ -4,8 +4,14 @@ SP_DIR = endif +if ENABLE_OpenFDM_FDM +OpenFDM_DIR = OpenFDM +else +OpenFDM_DIR = +endif + SUBDIRS = Balloon JSBSim LaRCsim UIUCModel YASim \ - $(SP_DIR) ExternalNet ExternalPipe + $(SP_DIR) $(OpenFDM_DIR) ExternalNet ExternalPipe noinst_LIBRARIES = libFlight.a Index: src/FDM/flight.hxx === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/flight.hxx,v retrieving revision 1.13 diff -u -r1.13 flight.hxx --- src/FDM/flight.hxx 11 Jun 2006 13:34:19 - 1.13 +++ src/FDM/flight.hxx 12 Jun 2006 06:13:20 - @@ -433,7 +433,10 @@ FG_PARACHUTE = 9, // Driven externally via a serial port, net, file, etc. - FG_EXTERNAL = 10 + FG_EXTERNAL = 10, + + // OpenFDM. Reads JSBSim legacy and new files. + FG_OPENFDM = 11 }; // initialization Index: src/Main/Makefile.am === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/Makefile.am,v retrieving revision 1.68 diff -u -r1.68 Makefile.am --- src/Main/Makefile.am 14 May 2006 12:22:53 - 1.68 +++ src/Main/Makefile.am 12 Jun 2006 06:13:20 - @@ -9,6 +9,13 @@ SP_FDM_LIBS = endif +if ENABLE_OpenFDM_FDM +OpenFDM_LIBS = $(top_builddir)/src/FDM/OpenFDM/libFGOpenFDM.a \ + -lOpenFDMJSBReader -lOpenFDMeasyxmlXML -lOpenFDMXML -lOpenFDM +else +OpenFDM_LIBS = +endif + if WITH_THREADS THREAD_LIBS = -lsgthreads $(thread_LIBS) else @@ -74,6 +81,7 @@ $(top_builddir)/src/FDM/LaRCsim/libLaRCsim.a \ $(top_builddir)/src/FDM/UIUCModel/libUIUCModel.a \ $(SP_FDM_LIBS) \ + $(OpenFDM_LIBS) \ $(top_builddir)/src/GUI/libGUI.a \ $(top_builddir)/src/Autopilot/libAutopilot.a \ $(top_builddir)/src/Input/libInput.a \ Index: src/Main/fg_init.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v retrieving revision 1.165 diff -u -r1.165 fg_init.cxx --- src/Main/fg_init.cxx 10 Jun 2006 22:24:05 - 1.165 +++ src/Main/fg_init.cxx 12 Jun 2006
Re: [Flightgear-devel] collision avoidance
Before continuing, I thought I'd verify a few points with those in the know. Through observation, I found that my calculated agl value (as discussed in my previous post) was close to that of "/position/ground-elev-ft" when using the current lat/lon values instead of those from Point3D calc_gc_lon_lat( const Point3D& orig, double course, double dist ). I did this in an attempt to compare against the /position/ground-elev-ft value. The resulting value was close but not the same. Having converted between feet and meters, and degrees and radians for the purpose of the calculations, would this have resulted in the slight difference in value? With my limited avionics knowledge, I assumed that: (altitude-ft - ground-elev-ft) = altitude-agl-ft. Again, this is something I want to verify instead of assuming. So is it (somewhat) correct to assume that subtracting the current altitude from my "calculated agl" would give me the the altitude-agl-ft? thanks, Michael. From: Mathias Fröhlich <[EMAIL PROTECTED]> Reply-To: FlightGear developers discussions To: FlightGear developers discussions Subject: Re: [Flightgear-devel] collision avoidance Date: Sun, 11 Jun 2006 12:21:23 +0200 Hi, On Sunday 11 June 2006 06:53, Mick - wrote: > I've managed to get Mathias' suggestion of using get_elevation_m but with > strange AGL values. > I used calc_gc_lon_lat from simgear/math/polar3d.hxx for getting the > latitude/longitude from > x-meters away, then feeding the resulting lat/lon values into > get_elevation_m, but it seems this might not be correct (result is not > wgs84?). When flying over the ocean, I get an varying AGL value of 10-20ft. > With this said, could you suggest an alternative? I have tried that out. That what you describe works here. The ocean surface is not exactly at 0m elevation. It varies between 0m elevation and about -1m. That is normal since the vertices are at exactly 0m, the triangle surfaces must be beond that somewhere in the middle. May be our maximum altitude value bites you. You may need to set that to something similar than the aircrafts altitude. The problem is that the down direction for the lookup is not perpandicular to the geodetic earths surface but directed towards the earths center ... > Additionally, could you please suggest how I could use the bounding box > method? Well, that depends on what you need. Hierarchical bounding boxes is something different than I suggest. It helps for a different problem. If you need that, I have not understood what you need. Collision avoidance can be meant with not hitting the ground. I expect that you need that. Collisions can also happen with other aircraft/whatever in 3D. If this is what you need than, the elevation value is not aprioriate for you. For that problem it is best to use hierarchical bounding boxes. The scenegraph already has some (poor) hierarchical bounding box structure in it. If you need that it might be a good starting point to reuse that. If you have further problems, feel free to ask. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New JSBSim document posted
I have posted an initial (but still useful) article I am writing on the process of creating a JSBSim aircraft model. You can read it here: http://jsbsim.sourceforge.net/CreatingJSBSimAircraft.pdf If you have any comments on what is unclear, or where more detail needs to be added, please let me know. This is an ongoing process, and obviously more still needs to be done. Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Saturday 10 June 2006 13:15, Tony Pelton wrote: > heck, even taking the records, and stuffing those records, as they are > now, into XML would be a start. Already in XML format... http://www.cs.yorku.ca/~cs233144/export_cyyz.svg http://www.cs.yorku.ca/~cs233144/export_eddf.svg http://www.cs.yorku.ca/~cs233144/export_eddh.svg http://www.cs.yorku.ca/~cs233144/export_etou.svg http://www.cs.yorku.ca/~cs233144/export_ksfo.svg Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New apt.dat format, X-Plane and Flight Gear
Hi Y'all,
I hope you'll forgive my crashing the FG-dev list...I work with Austin
on X-Plane and am working closely with Robin on the new apt.dat
revisions ("version 850") for X-Plane.
I just wanted to make a few comments on how this format has evolved that
might be of bearing to future FG development:
- After going in circles quite a few times, we've ended up with an
apt.dat that remains relatively high-level. There is almost no
customization allowed in the apt.dat 850 (which is similar to past
apt.dat files). If you say you want "taxi lights", the sim decides what
they look like.
I think that this will turn out to be a good thing for FG and for any
hope of data sharing between flight sims; it leaves you guys with a lot
of latitude to decide how to implement the various features and to
optimize the results in ways appropriate to your own technology. For
example, you aren't stuck with a requirement to allow certain parameters
just because it seemed like a good idea in X-Plane.
For X-plane we expect our authors to make truly detailed custom airports
using our regular scenery-modeling facilities, which allow for lower
level customization and tweaking. It seems to me that the success of
the apt.dat files (in that users submit layouts and they get distributed
to everyone) is partly because they are simple and high level.
- Our new unit for taxiways is a "bezier polygon" - that is a simple
polygon with holes where each segment may be a bezier curve. We chose
this because it is again high level - the number of triangles will be up
to the sim (because you can choose your level of tesolation of curves)
rather than up to the author. Looking through existing layers there is
a huge amount of inefficient overlapping pavement as authors try to
simulate curves - my previous attempts to mathematically analyze such
layouts has been a real PITA.
X-Plane currently uses the glu polygon tessolator to convert polygons
with holes into triangles, and a very simple function to turn the bezier
curves into line segments. If it turns out to be useful off to you
guys, email me off list and I can provide any needed info on doing this,
although it's pretty much a straight use of glu. (My point here is just
that hopefully the bezier polygon with holes spec isn't too hard to
implement because glu can do most of the work.)
The layout does not provide ordering for pavement. I will admit that
this is very much driven by X-plane...we found that the need to draw
layouts in the order of the apt.dat really kills framerate. So the idea
of allowing holes in pavement but not guaranteeing draw order is to
encourage authors to put down taxiway pavement just once (cutting a hole
in the "bottom" layer so it doesn't overlap the top). This should also
reduce the total amount of overlapping polygons.
From a conceptual perspective, I would argue that surfaces in an
airport do not truly overlap (or if they do, it's not something that
would affect a flight sim). For our purposes, the surface of an airport
could be thought of as a planar map, where the plane is subdivided into
polygons that are homogenous...a given point is either concrete or
asphalt, not both. So any overlapping layout should be reducable to a
non-overlapping one by subtracting the "top" polygons out of the bottom
ones via holes. So I feel safe with a non-overlapping pavement model.
By comparison, the runway model _does_ overlap and runways are ordered,
because in real life we need to put the dominating runway on top of the
non-dominating one - see KBOS 4R and 9 on google maps. :-)
- I am a big believer in not putting features into the apt.dat format
that can't be visualized...my fear is that authors wouldn't be able to
validate their work and we'd end up with junk in the database. But
there's no reason why the domain of implemented features would have to
be implemented by X-Plane alone. So I would say that if you guys want
an enum code for a new type of pavement or marking or light string other
than the initial set we're spec'ing out, talk to Robin and perhaps it
can go into his database for FG first and X-Plane could catch up.
Uh, that's all I can think of for now...feedback or flames, please email
me off list. I'd like to just end by saying that LR is not a terribly
secretive company and I think that exchange of ideas between FG and
X-Plane is positive for both sims. :-)
*cheers*
Ben
--
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://xplanescenery.blogspot.com/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
Scenery mailing list: [EMAIL PROTECTED]
Developer mailing list: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UAV Heli and Matlab
Correu PelDavid wrote: > Hello, > > After lots of exams, and almost infinite tasks at university, and before > some more to come, I'd like to ask for a few things I'd like to do in > the quiet sunny summer days. > > I'd like to mix FlightGear with Matlab through the aerospace toolbox. > Weeks ago I asked for the 0.9.8a versions, which was kindly linked so I > could download, but I could work on it, and I have some questions. > > So, Question #1: To practice with the helicopter, what key do I have to > press to activate the engine? I've tried anything I found on the help > without success. > Question #2: How can I setup the joystick? I'd like to exchange some of > the axis function. > Question #3: Does anybody have a 3D model for a R/C-like helicopter? > Something like a 1 meter thing. > Question #4: Has anybody tried the Matlab-FlightGear connection without > perishing on the try? If so, is there any documentation? > > Your 'question #1' might be: Is that fool a newbee? > My answer: absolutely. > > Thanks for your help. Any advice will be gratefully accepted. > > David > > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel The helicopter simulation that YASim does is very primitive. Really the only working model is of the bo105, and is suffers from the lack of fidelity in the FDM. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] UAV Heli and Matlab
Hi >Hello, > >After lots of exams, and almost infinite tasks at university, and before >some more to come, I'd like to ask for a few things I'd like to do in the >quiet sunny summer days. > >I'd like to mix FlightGear with Matlab through the aerospace toolbox. >Weeks ago I asked for the 0.9.8a versions, which was kindly linked so I >could download, but I could work on it, and I have some questions. > >So, Question #1: To practice with the helicopter, what key do I have to >press to activate the engine? I've tried anything I found on the help >without success. What helicopter are you using? my experience with a helicopter (Bo105 Rule #1 Turn autocoordination OFF Rule #2 see rule #1 ;-) Rule #3 The throttle works reverse to fixed wing aircraft. Rule #4 Using the keyboard rudder (tail rotor) control is almost impossible. Rule #5 Until you can hover indefinitely over the same point on the ground and and climb and descend without moving from that point, don't try anything fancier...ie practice hovering. Rule #6 When you can hover, practice pulling up from level flight to a stationary hover. Rule #7 When you can hover and pull up to a hover with 100% success try other things. >Question #2: How can I setup the joystick? I'd like to exchange some of the >axis function. See above rules .. they may help >Question #3: Does anybody have a 3D model for a R/C-like helicopter? >Something like a 1 meter thing. >Question #4: Has anybody tried the Matlab-FlightGear connection without >perishing on the try? If so, is there any documentation? > >Your 'question #1' might be: Is that fool a newbee? >My answer: absolutely. > >Thanks for your help. Any advice will be gratefully accepted. > >David :-D ene >___ >Flightgear-devel mailing list >Flightgear-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Looking for love? Check out XtraMSN Personals http://xtramsn.match.com/match/mt.cfm?pg=channel&tcid=200731 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] UAV Heli and Matlab
Hello,After lots of exams, and almost infinite tasks at university, and before some more to come, I'd like to ask for a few things I'd like to do in the quiet sunny summer days.I'd like to mix FlightGear with Matlab through the aerospace toolbox. Weeks ago I asked for the 0.9.8a versions, which was kindly linked so I could download, but I could work on it, and I have some questions.So, Question #1: To practice with the helicopter, what key do I have to press to activate the engine? I've tried anything I found on the help without success. Question #2: How can I setup the joystick? I'd like to exchange some of the axis function.Question #3: Does anybody have a 3D model for a R/C-like helicopter? Something like a 1 meter thing. Question #4: Has anybody tried the Matlab-FlightGear connection without perishing on the try? If so, is there any documentation? Your 'question #1' might be: Is that fool a newbee?My answer: absolutely.Thanks for your help. Any advice will be gratefully accepted.David ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tower patch
On Sunday 11 June 2006 21:36, Melchior FRANZ wrote: > He said so. We just need to release 1.0 next week, and ... :-) > > * David Luff -- Thursday 20 April 2006 00:04: > | But tower.cxx is the only thing I'm working on at the moment - I want > | it fixed and stable before 1.0 as much as you guys, because otherwise in > | retropect there wouldn't have been much point in writing it to start > | with. Ah, ok. Thanks ... Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tower patch
* Mathias Fröhlich -- Sunday 11 June 2006 21:31: > On Sunday 11 June 2006 21:09, Melchior FRANZ wrote: > > I thought Dave would soon come up with a fixed/rewritten version, anyway. > > :-) > True? > Is he working on that? He said so. We just need to release 1.0 next week, and ... :-) * David Luff -- Thursday 20 April 2006 00:04: | But tower.cxx is the only thing I'm working on at the moment - I want | it fixed and stable before 1.0 as much as you guys, because otherwise in | retropect there wouldn't have been much point in writing it to start with. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tower patch
On Sunday 11 June 2006 21:09, Melchior FRANZ wrote: > Yes. And there was no commit since this crash happened, so the line > can't have moved. Sorry, I didn't investigate, because I have ATC always > turned off because of the flakiness, and I just returned to that mode. > I thought Dave would soon come up with a fixed/rewritten version, anyway. > :-) True? Is he working on that? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tower patch
* Olaf Flebbe -- Sunday 11 June 2006 21:03: > Is tower.cxx:905 in your source code this line? > > t->landingType = t->planePtr->GetLandingOption(); Yes. And there was no commit since this crash happened, so the line can't have moved. Sorry, I didn't investigate, because I have ATC always turned off because of the flakiness, and I just returned to that mode. I thought Dave would soon come up with a fixed/rewritten version, anyway. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tower patch
2006/6/10, Melchior FRANZ <[EMAIL PROTECTED]>: > * Olaf Flebbe -- Monday 29 May 2006 23:14: > > latest workarounds in tower are not quite correct. Please apply. > > And what about the new ones ...? > > #1 0x080c4ada in FGTower::CheckCircuitList (this=0xed37920, > dt=0.30004) at src/ATC/tower.cxx:905 Is tower.cxx:905 in your source code this line? t->landingType = t->planePtr->GetLandingOption(); That's crazy, since the line before is t->pos = t->planePtr->GetPos(); I am asking myself what can crash in line 905 since t->planePtr is dereferenced in 904, too. landingType is a simple enum and GetLandingOption is not too complicated. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Impact of texturing objects on performance?
On Friday 09 June 2006 21:50, Arnt Karlsen wrote: > ..Roberto _ is_ stretching understatement as concept, last years > AirVenture put over 10 000 planes on KOSH. My initial idea > was "paint parked planes" with copies of one texture. Textures is > what we "see out the window" in FG and it works on my old junk. > > ..you're saying "using 20 different a few hundred times each > is gonna work better than textures??? "Bring it on!" 8o) Textures would work if all those planes are of one type and have the same livery, which is an unrealistic scenario. A more realistic scene that a user would see (hopefully) in FG is a dozen different types of planes belonging to a dozen different airlines. Using textures for details would require huge textures per aircraft-type per airline, and would result in performance cost going through the roof; and that's excluding the textures that would be already presented in the airports. Performance would still degrade if all those aircraft and buildings have high geometric details, but geometries wouldn't eat up memory as quick as textures would. Beside, one could always turn off a portion of the geometries when they aren't needed. Anyway, I think we are getting a bit ahead of ourselves here. FlightGear starts to struggle/struggles with merely 10 aircraft on the scene. I don't think users would be able to see 100 planes in the same scene anytime soon. :P Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] collision avoidance
Mick - wrote: > When flying over the ocean, I get an varying AGL value of 10-20ft. > With this said, could you suggest an alternative? The AGL value is the height above the polygon surface of the ocean. Polygons are flat so if all the vertices are at sea level, the center of the triangles will dip below sea level. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] collision avoidance
Hi, On Sunday 11 June 2006 06:53, Mick - wrote: > I've managed to get Mathias' suggestion of using get_elevation_m but with > strange AGL values. > I used calc_gc_lon_lat from simgear/math/polar3d.hxx for getting the > latitude/longitude from > x-meters away, then feeding the resulting lat/lon values into > get_elevation_m, but it seems this might not be correct (result is not > wgs84?). When flying over the ocean, I get an varying AGL value of 10-20ft. > With this said, could you suggest an alternative? I have tried that out. That what you describe works here. The ocean surface is not exactly at 0m elevation. It varies between 0m elevation and about -1m. That is normal since the vertices are at exactly 0m, the triangle surfaces must be beond that somewhere in the middle. May be our maximum altitude value bites you. You may need to set that to something similar than the aircrafts altitude. The problem is that the down direction for the lookup is not perpandicular to the geodetic earths surface but directed towards the earths center ... > Additionally, could you please suggest how I could use the bounding box > method? Well, that depends on what you need. Hierarchical bounding boxes is something different than I suggest. It helps for a different problem. If you need that, I have not understood what you need. Collision avoidance can be meant with not hitting the ground. I expect that you need that. Collisions can also happen with other aircraft/whatever in 3D. If this is what you need than, the elevation value is not aprioriate for you. For that problem it is best to use hierarchical bounding boxes. The scenegraph already has some (poor) hierarchical bounding box structure in it. If you need that it might be a good starting point to reuse that. If you have further problems, feel free to ask. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-06-04_15:47:21 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/CanberraBI8/thumbnail.jpg Add a pict for the web site. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-06-04_18:00:51 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Attic/OV10.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Attic/OV10_USAFE-set.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Attic/submodels.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Attic/thumbnail.jpg /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Engines/Attic/T76.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Engines/Attic/direct.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/OV10.xml Dave CULP, Jean PIERRU, Ron JENSEN: merged into OV10/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-06-04_18:00:52 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/OV10_NATO.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/ov10_0.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/ov10_1.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/ov10_2.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/ov10_3.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/ov10_4.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/ov10_5.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/ov10_6.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/ov10_8.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/panel-hotspots.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Attic/transparent.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/AI/Attic/AI.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/AI/Attic/AI.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/AI/Attic/ai_face.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/AI/Attic/ball.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/AS/Attic/AS.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/AS/Attic/airspeed.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/AS/Attic/airspeed.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Alt/Attic/Altimeter.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Alt/Attic/altimeter.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Alt/Attic/altimeter.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/EGT/Attic/EGT.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/EGT/Attic/EGT_1.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/EGT/Attic/EGT_2.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/EGT/Attic/egt.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Flaps/Attic/flaps.ac Dave CULP, Jean PIERRU, Ron JENSEN: merged into OV10/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-06-04_18:00:53 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Flaps/Attic/flaps.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Flaps/Attic/flaps.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Fuel/Attic/fuel.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Fuel/Attic/fuel.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Fuel/Attic/fuel.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/GMeter/Attic/gmeter.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/GMeter/Attic/gmeter.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/GMeter/Attic/gmeter.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Gunsight/Attic/gunsight.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Gunsight/Attic/gunsight.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Gunsight/Attic/piper.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Gunsight/Attic/power.rgb /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Gunsight/Attic/switch.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/Gunsight/Attic/switch.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/IVSI/Attic/IVSI.ac /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/IVSI/Attic/IVSI.xml /var/cvs/FlightGear-0.9/data/Aircraft/OV10_USAFE/Models/USAFE/Instruments/IVSI/Attic
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-04_17:18:05 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Main/splash.cxx
fix the splash background color property path
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_13:45:59 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Input/input.cxx
make modifier keys accessible via /devices/status/keyboard/{shift,ctrl,alt}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_16:19:50 (fredb)
/var/cvs/FlightGear-0.9/source/src/Input/input.hxx
Declare new member functions
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_16:28:20 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Input/input.hxx
whoops, sorry, I forgot to commit that. (Thanks, Fred, for fixing).
Belongs to the SGSubsystem interface functions.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_20:21:45 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Main/globals.cxx
/var/cvs/FlightGear-0.9/source/src/Main/globals.hxx
make fontcache globally available
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_20:23:56 (mfranz)
/var/cvs/FlightGear-0.9/source/src/GUI/new_gui.cxx
/var/cvs/FlightGear-0.9/source/src/GUI/new_gui.hxx
make FGFontCache independent of NewGUI and allow early construction in
FGGlobals
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_20:25:43 (mfranz)
/var/cvs/FlightGear-0.9/source/src/GUI/dialog.cxx
use global fontcache
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_20:49:35 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Main/splash.cxx
use the global fontcache; this has the nice side-effect that the font is
now settable via /sim/gui/style/fonts/splash/{name,size,slant}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_21:55:18 (mfranz)
/var/cvs/FlightGear-0.9/source/src/GUI/new_gui.cxx
don't choke on invalid nodes
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-05_22:03:23 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Main/splash.cxx
read font and colors from the selected style, not always from /sim/gui/style[0]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-06_12:49:42 (mfranz)
/var/cvs/FlightGear-0.9/source/src/GUI/new_gui.cxx
/var/cvs/FlightGear-0.9/source/src/GUI/new_gui.hxx
FGFontCache: add getter for the fntTexFont component of a cached font
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-06_12:52:45 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Cockpit/panel.cxx
use global fontcache. This hast the nice side effect that panels can now
use *any* texture (*.txf) font, not just "typewriter" and "led".
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-06_15:34:18 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Cockpit/hud.cxx
/var/cvs/FlightGear-0.9/source/src/Cockpit/hud.hxx
- use global fontcache
- make font/size configurable
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-06_16:33:38 (mfranz)
/var/cvs/FlightGear-0.9/source/src/GUI/gui.cxx
use global fontcache ... this is mostly cosmetic, as the whole file will
probably die a soon as the old property picker was removed
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-06_17:30:49 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Main/splash.cxx
better always use style[0] (again). Otherise *-set.xml can't easily change
background/font
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-06_18:36:34 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Cockpit/panel.cxx
/var/cvs/FlightGear-0.9/source/src/Cockpit/panel_io.cxx
restore old default; this should probably be configurable ...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-06_19:25:33 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Cockpit/hud.cxx
bark if the requested font isn't a texture font. A more graceful recovery
doesn't buy us much, as the font is only set at initialization time and not
changeable later. Better tell the user immediately that he goofed.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-07_17:59:28 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Main/fg_commands.cxx
remove obsolete HUD fgcommands
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-07_18:01:19 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Cockpit/hud.cxx
/var/cvs/FlightGear-0.9/source/src/Cockpit/hud.hxx
- drop hardcoded color/brightness values
- let listener class watch and maintain HUD color properties, which is
more effective and more flexible.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-07_21:09:38 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Cockpit/hud.hxx
remove obsolete constants
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2006-06-07_21:28:33 (mfranz)
/var/cvs/FlightGear-0.9/source/src/Cockpit/hud.hxx
whoops ... compile (thi
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2006-06-08_05:54:23 (frohlich) /var/cvs/SimGear-0.3/source/simgear/scene/material/matlib.cxx /var/cvs/SimGear-0.3/source/simgear/scene/material/matlib.hxx Preliminary material lookup hooks - still unoptimized. 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Softpedia
How do you want to do interactive placement without interaction? ;-)I think there's no way other than gimp, if the placement of the watermark must be adjusted for every single image...ThomasThere is PHP library GD which is used to to all kind of stuff with images.If is someone interested to do such a script in PHP for FG site there is a tutorial: http://www.sitepoint.com/article/watermark-images-php.If no one will do it. I'l try it, but it depends on my verry limited free time. IS ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
