Re: [Flightgear-devel] FG git (was Sport Model)
On 07/06/2007 01:12 AM, Pigeon wrote: For quite a while I've been using git to keep track of FlightGear files. Using git instead of CVS is like having a sports car instead of a skateboard. All good :) :-) I notice you're hosting git over http, which is usually much slower than using git-daemon. Yes, git-daemon has many advantages. I went with http strictly as a stopgap. The http price is very low for me, and the folks who sell this http service don't sell git-daemon service. I have mine setup at: git://pigeond.net/flightgear/flightgear.source.git/ Would you be interested in pulling the sport branch into that repository? For those interested I also have gitweb at http://pigeond.net/git/ Ah, very useful. (I have a private gitweb, but I'm not in a position to export it to the world.) Last month there were a lot of people asking questions about the CVS logs. I reckon many of those questions could have been answered very conveniently via a look at the gitweb. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to, the terrain mesh? (addressing especially Tim Moore)
Hello Sebastian! Sebastian Bechtold wrote: Tim Moore wrote: So, I don't mean to be discouraging because I think this is ultimately the right approach in terms of bumping up terrain detail and implementing terrain and texture LOD, but you have a lot of hacking ahead of you. Then it should be so. I'd really like to help making FlightGear better, and of course I want to improve the things which, in my option, need it most. Great to hear that you're so motivated. I hope it stays that way once you have started! ;-) I have to admit that at the moment, I have not the slightest idea about any coordinates and stuff, but I'm willed to learn :). Although I'm a bit skeptical about whether I like the concept at all or not, there's no better way of finding out than trying. ;-) I can assure you that I will provide support to you with everything I learned about scenery design, file formats and coordinate systems in the FlightGear world. I will not be able to assist you much in coding, and specifically not in the area of 3D programming, but I will try to do my very best to help you being successful in the areas I can help with. Sebastian Bechtold wrote: The plan would be to include the raw (meaning not compiled/digested into the .btg files) vector data into a scenery file and auto-generate the textures using this data. The .btg-file-format is not well extensible (and probably will not be needed anymore anyway with your approach), so I wouldn't integrate this data into the btg or stg files. You don't seem to be thinking about something like that anyway, so this is merely a note from my side. Cheers, Ralf - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh?
Sebastian Bechtold wrote: Your thread title is misleading, Sorry, but I don't think so. The title describes my intentions pretty well. what you really want to do is to add layers, so to add some geometry drapped around the terrain. No, I don't I want to do that. I want to do what I've been talking about in my posting. Best regards, Sebastian Ok, I was reading a bit fast and saw rounded curve and you'll never get that with textures. The texture mapping we are using today is done with the function in simgear/texcoord.cxx. I supposed you've read the explanation of how it's done in msfs on the fsinsider site, the problem I see here is that we do not have a regular mesh grid so we will have the boundary triangles that will span on several textures. In msfs they have a regular grid (it's just a height map) so the mapping is direct. HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fancy lvalues in c++
Hi, I didn't intend to take part in more threads with you that could (and most likely would) turn out to be yet another flame war. The following is really meant to be the opposite, but I assume that it will fail poorly. * John Denker -- Friday 06 July 2007: I'm sure some people will take this as evidence of my perversely incompetent programming technique ... Nobody said that. And I for one didn't even mean to imply it. I saw your c++ code and it did look quite skilled (though it was about topics where I can't contribute much -- aviation/instrument/weather stuff). But I'm afraid you aren't judged like others, simply because of your fgfs history. From the first day on you had permanent teacher mode turned on. About everything that you said and did seemed to say I'm the greatest, and I'll teach you now how to do even trivial things. And at the same time you were several times (though not more often than others) proven wrong in various questions. Nothing wrong with that, but it took lengthy threads for you to admit your mistakes. You seem to consider your contributions perfect and finished, and don't accept criticism. (Snipers everywhere.) You haven't adapted and re-submitted your code even *once* (IIRC) after issues were pointed out. (Your current work on the dialog layout seems to be the first time.) If you'd try more to serve the project than your ego, then it would be much easier to work with you. (And don't underestimate the egos of the other developers! :-) This didn't really belong to the list, but the flames were also here, and some newcomers might just not understand why people quickly become annoyed, sometimes mean in their responses to you. Maybe you should stop by in our IRC channel at some time. It's usually much more relaxed and friendly there, and it's easier to clear matters. m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to, the terrain mesh? (addressing especially Tim Moore)
Hi once more! Ralf Gerlich wrote: I can assure you that I will provide support to you with everything I learned about scenery design, file formats and coordinate systems in the FlightGear world. I will not be able to assist you much in coding, and specifically not in the area of 3D programming, but I will try to do my very best to help you being successful in the areas I can help with. So why not start right now? (forgive me if you already know a lot of the following). So what we have in the database is a logical setup of the terrain data in terms of polygons describing aerial features (forest, town, cities, etc.) in terms of polylines describing linear features (roads, railroads, small streams, etc.) Logical setup means that the data is not yet directly associated with a texture or in case of linear features also with a width, but this is typically done when extracting the data from the database and converting it to a TerraGear-friendly format in the TerraGear working directory. So the actual association of type of landcover and a texture is established by the script that does the conversion. Instead of converting the data to a TerraGear working directory it would be possible to convert it to a file format useable by your scenery engine, in which the polygons and lines would be associated with a display type defining texture and markings, and in case of the lines also with a width. The positions in the database are in WGS84 format, i.e. in geodesic coordinates according to the WGS84 ellipsoid approximation of the earth's surface. You can use the functions in simgear/math/SGGeodesy.hxx to convert these to cartesian coordinates. These functions are, however, a bit computationally expensive - at least when used hundreds or thousands of times per frame - so a pre-calculation of the actual cartesian coordinates used for display would be a good idea. The cartesian coordinates are used to actually model the earth as a round shape instead of a flat shape in display space, which makes things a lot easier (latitude-longitude wrap-around) and also more realistic (ever seen the curvature of the earth from high above?) The other data you will probably need is the elevation data. Most of the elevation data we have is from SRTM, the Shuttle Radar Topography Mission. The data consists of raster files in different formats, a non-standard format named HGT and as GeoTIFF. We can of course make this available in a suitable raw binary format. As I have some experience in working with all that data and the formats, I could write the conversion tools. We'd just have to agree on a format for the files. Cheers, Ralf - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fancy lvalues in c++
Am Freitag 06 Juli 2007 10:19 schrieb Melchior FRANZ: ... Maybe you should stop by in our IRC channel at some time. It's usually much more relaxed and friendly there, and it's easier to clear matters. I second that. I was quite surprised yesterday :-) Thx OTOH sometimes it's not an option (being at work etc.) Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Harald JOHNSEN schrieb: Sebastian Bechtold wrote: Your thread title is misleading, Sorry, but I don't think so. The title describes my intentions pretty well. what you really want to do is to add layers, so to add some geometry drapped around the terrain. No, I don't I want to do that. I want to do what I've been talking about in my posting. Best regards, Sebastian Ok, I was reading a bit fast and saw rounded curve and you'll never get that with textures. The texture mapping we are using today is done with the function in simgear/texcoord.cxx. I supposed you've read the explanation of how it's done in msfs on the fsinsider site, the problem I see here is that we do not have a regular mesh grid so we will have the boundary triangles that will span on several textures. In msfs they have a regular grid (it's just a height map) so the mapping is direct. Yes, that's true. This might really be something that makes the implementation a bit more complicated. Currently, I have two ideas to solve this problem: 1.) Apply the textures on tile-level. The tiles have a regular rectangular shape, so you could map one texture on one tile, without any overlapping. A problem with this could be the dimensions. You'd need quite large textures to get an acceptable low value of square-meters per pixel. I don't yet know enough about 3D programming to judge if this is feasible or not (hardware-limited maximum texture size, OSG / FlightGear performance with handling such huge textures and so on), but at least we could try it. 2.) Use smaller textures (for example 2x2 or 4x4 per tile) and draw overlapping redundant borders to their neighbor textures. Mhh...I have problems to write a good explaination of this in english...I mean...near the borders of each texture (for example a 100 Pixel wide frame), you draw exactly the same pixels as you draw on the corresponding frame of the neighbor texture in each direction. You would then apply the textures so that they overlap and decide with triangle in the border area is filled with which one of four adjacent textures. When the frames are wide enough to cover every irregular shape that could occur, it should be possible to handle the problem this way. A clear disadvantage of this approach is, of course, the additional graphics memory requirement, and it's perhaps a bit harder to implement. I don't know what's better or if there are other, better ways to solve this. Feel free to help finding a solution! :) Cheers, Sebastian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (addressing especially Ralf)
Heiko Schulz schrieb: Hi, the graphic at the end of your steps should be no or very small problems. To make pseudo aerial photographs can be done very easy. Your idea sounds good now - but one curious question I have: when it really works at runtime, we could do something like the livery-changing for the textures? As an example, when we have rain - the runway will look wet? When it's snowing, the landscape will be white? I think this would involve basically the same things as it would now. You switch textures depending on specific environment properties. Shouldn't be that hard to do, no matter by which rules the textures are selected and applied. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Sebastian Bechtold wrote: Yes, that's true. This might really be something that makes the implementation a bit more complicated. Currently, I have two ideas to solve this problem: 1.) Apply the textures on tile-level. The tiles have a regular rectangular shape, so you could map one texture on one tile, without any overlapping. A problem with this could be the dimensions. You'd need quite large textures to get an acceptable low value of square-meters per pixel. I don't yet know enough about 3D programming to judge if this is feasible or not (hardware-limited maximum texture size, OSG / FlightGear performance with handling such huge textures and so on), but at least we could try it. 2.) Use smaller textures (for example 2x2 or 4x4 per tile) and draw overlapping redundant borders to their neighbor textures. Mhh...I have problems to write a good explaination of this in english...I mean...near the borders of each texture (for example a 100 Pixel wide frame), you draw exactly the same pixels as you draw on the corresponding frame of the neighbor texture in each direction. You would then apply the textures so that they overlap and decide with triangle in the border area is filled with which one of four adjacent textures. When the frames are wide enough to cover every irregular shape that could occur, it should be possible to handle the problem this way. A clear disadvantage of this approach is, of course, the additional graphics memory requirement, and it's perhaps a bit harder to implement. I don't know what's better or if there are other, better ways to solve this. Feel free to help finding a solution! :) Cheers, Sebastian The point 1) will give worse ground texture than today if we set the texture size at 4090^2. The point 2) is better except that this 100 pixel border is arbitrary. Sometimes it will be ok but i'm afraid there is some triangles that will go very far inside adjacent texture (some sea triangles inside the bay are very long for example). But if the the real problem is those anoying triangle why not simply delete them ? Frankly we don't care about the geometry in the btg file, we just need a height field, let just built this grid and voila (this is for the display, the btg is still used for agl computation, intersection, etc or not because finding a height in a grid is instant, no more sequential scan of a soup of triangles). HJ. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Today's CVS
Hi all, Today's cvs seems to have solved thru problem of crashes with traffic-manager when compiled with MSVC8, at least for short runs. My testing is incomplete, since I have not been able to test for extended periods, so the longer term memory leak that has been reported may still be present. That is the good news. The bad news is that the ac taxiing towards KSFO 28L disappear just as they arrive at the threshold. Reagan Thomas has already reported seeing this. So far as I can see, the ac are teleported to 28L, where they take off and carry on normally. I have tracked this visually and on radar, and it is repeatable. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Hi! Harald JOHNSEN wrote: The point 1) will give worse ground texture than today if we set the texture size at 4090^2. Not necessarily. Currently we have the same basic texture resolution everywhere. With the approach Sebastian wants to try one could use tiles of different sizes depending on the distance from the viewer. Which may or may not be a good thing but we won't know until somebody tries. The point 2) is better except that this 100 pixel border is arbitrary. Sometimes it will be ok but i'm afraid there is some triangles that will go very far inside adjacent texture (some sea triangles inside the bay are very long for example). There won't be triangles oriented along the bay. If I understood Stefan right, there will be a regular triangle grid depicting the elevation structure and the borders between different regions will be depicted by a change in the master texture. But if the the real problem is those anoying triangle why not simply delete them ? Frankly we don't care about the geometry in the btg file, we just need a height field, let just built this grid and voila (this is for the display, the btg is still used for agl computation, intersection, etc or not because finding a height in a grid is instant, no more sequential scan of a soup of triangles). Exactly. The question that comes to mind is whether OpenSceneGraph does not already have support for such a thing. The applications of OSG I have seen seem all to use this concept so maybe it is reasonable to believe s.th. like that has been included in OSG? Mathias? As I said I'm skeptical about the outcome, but I would say it's worth a try. Sebastian seems to be committed, so why not? Cheers, Ralf - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Gerlich wrote: Hi! Harald JOHNSEN wrote: But if the the real problem is those anoying triangle why not simply delete them ? Frankly we don't care about the geometry in the btg file, we just need a height field, let just built this grid and voila (this is for the display, the btg is still used for agl computation, intersection, etc or not because finding a height in a grid is instant, no more sequential scan of a soup of triangles). Exactly. The question that comes to mind is whether OpenSceneGraph does not already have support for such a thing. The applications of OSG I have seen seem all to use this concept so maybe it is reasonable to believe s.th. like that has been included in OSG? Mathias? OSG has primitive support for rendering heightfields, but it has good support for producing geocentric (even whole earth), paged databases with overlay textures and Level-Of-Detail from DEMs... the same sources that FlightGear uses. The polygons are not a grid but a TIN. So if you really want to depart from the btg format, there you go. See http://www.openscenegraph.com/projects/VirtualPlanetBuilder. I don't think this scheme is the best possible, and you'd still need to support the surface properties somehow, but it gets a lot of use from the OSG community. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGjk6deDhWHdXrDRURAqLJAJ9IUCqQ6ADdPsPsPIeKVKI59PxakACdGXbZ qFb72DUrZlT2XdWj/HjXIb0= =MkkV -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
On Friday 06 July 2007 18:03, John Denker wrote: 1) Where I'm coming from: Different people are interested in different parts of FlightGear. I consider it a strength of the project that it can be put to disparate purposes. I'm sure we all agree about that, anyway. 1a) As for me personally, and for more than a few others, there is interest in using it as a complex-aircraft procedures trainer, and as an IFR procedures trainer. I'm sure virtually all of us want FG to be suitable for that purpose. YMMV, but for my purposes the whole Doppler-shift thing is unhelpful. But there's no reason whatsoever for it to be so, that I can imagine; it's in everyone's interest that it works properly. The cases where the existing Doppler model works are features I don't use, while features I do use are cases where the existing Doppler modle fails. For example: -- It is comical that the ILS middle marker is strongly shifted. -- It is not so comical that the ATIS broadast is redshifted into unintelligibility. These bugs actually have been worked out already. The necessary fixes have been made and with Maik's last patch (which was posted to the dev list, I'm pretty sure) I'm not aware of any significant problems. Maybe you could try that? I expect it will be committed soon, anyway. Cheers, AJ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
On 07/06/2007 01:08 PM, AJ MacLeod wrote: These bugs actually have been worked out already. Excellent! The necessary fixes have been made and with Maik's last patch (which was posted to the dev list, I'm pretty sure) I'm not aware of any significant problems. Maybe you could try that? I expect it will be committed soon, anyway. It's been ten days now with no CVS-commit nor even any discussion of a CVS-commit AFAICT. If you send me the appropriate patch [off list or otherwise] I'll be happy to try it. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
1) Where I'm coming from: Different people are interested in different parts of FlightGear. I consider it a strength of the project that it can be put to disparate purposes. 1a) As for me personally, and for more than a few others, there is interest in using it as a complex-aircraft procedures trainer, and as an IFR procedures trainer. 1b) If you want to use it for other things, that's fine. 2) Back on 06/26/2007 03:06 PM, Jon Stockill wrote: With a cvs build checked out about half an hour ago I've just noticed something very strange - with external views the doppler shift appears to be related to the view angle rather than the approach speed. If you select the chase view then you'll find that the sound is extremely slow from behind the aircraft, and ridiculously fast from in front. This also still seems to affect the radio chatter, resulting in some highly comical, but not too realistic radio messages. I did not participate in the previous discussion of this topic. The thread died ten days ago in a pillar of flame. The program bugs, however, have lived on. YMMV, but for my purposes the whole Doppler-shift thing is unhelpful. The cases where the existing Doppler model works are features I don't use, while features I do use are cases where the existing Doppler modle fails. For example: -- It is comical that the ILS middle marker is strongly shifted. -- It is not so comical that the ATIS broadast is redshifted into unintelligibility. Therefore I ask: Is there a nice way for the pilot, if he chooses, to disable Doppler effects, at least until the bugs are worked out? Perhaps a property that can be set? I grepped through the current property tree and didn't notice such a thing. 3) See item 1. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument-altimeter unable to indicate altitude above 61831 feet
On Fri 6 July 2007 01:41, John Denker wrote:
On 07/05/2007 06:57 PM, gh.robin wrote:
When i opened that topic , it was to know if we could hope any FG update
to get an altitude instrument which can be able to indicate more than
61000 ft.
We have had a lot of discussion on it , but nothing which could give the
right answer.
Do we have to stay with that limitation = 61000 ft ?
No, we do not.
Back on 06/19/2007 03:20 PM, I sent a message Gérard off list, including
a patch to fix this, extending the existing model to over 100,000 feet.
Apparently the message got lost somehow.
As I explained on-list, there is nothing wrong with the altimeter.
I fixed the altimeter months ago.
The problem is in the model of the atmosphere, in environment.cxx,
where it computes the ambient pressure.
I will have more to say about this anon, but for now, here is
the patch again. It applies to today's CVS (offset one line).
Well your patch is right, i have tested it with Blackbird up to 9 ft
does anybody who has access to CVS source could commit it , both branch ?
here again is the John Denker Patch.
Thanks
--
Gérard
--- src/Environment/environment.cxx 2007/06/19 18:58:22 1.1
+++ src/Environment/environment.cxx 2007/06/19 19:03:22
@@ -48,43 +48,50 @@
// Atmosphere model.
-// Copied from YASim Atmosphere.cxx, with m converted to ft, degK
-// converted to degC, Pa converted to inHG, and kg/m^3 converted to
-// slug/ft^3; they were then converted to deltas from the sea-level
-// defaults (approx. 15degC, 29.92inHG, and 0.00237slugs/ft^3).
-
-// Original comment from YASim:
-
-// Copied from McCormick, who got it from The ARDC Model Atmosphere
-// Note that there's an error in the text in the first entry,
-// McCormick lists 299.16/101325/1.22500, but those don't agree with
-// R=287. I chose to correct the temperature to 288.20, since 79F is
-// pretty hot for a standard atmosphere.
+// Calculated based on the ISA standard day, as found at e.g.
+// http://www.av8n.com/physics/altimetry.htm
-// Elevation (ft), temperature factor (degK), pressure factor (inHG)
+// Each line of data has 3 elements:
+// Elevation (ft),
+// temperature factor (dimensionless ratio of absolute temp),
+// pressure factor (dimensionless ratio)
static double atmosphere_data[][3] = {
- { 0.00, 1.00, 1.000 },
- { 2952.76, 0.98, 0.898 },
- { 5905.51, 0.96, 0.804 },
- { 8858.27, 0.94, 0.719 },
- { 11811.02, 0.92, 0.641 },
- { 14763.78, 0.90, 0.570 },
- { 17716.54, 0.88, 0.506 },
- { 20669.29, 0.86, 0.447 },
- { 23622.05, 0.84, 0.394 },
- { 26574.80, 0.82, 0.347 },
- { 29527.56, 0.80, 0.304 },
- { 32480.31, 0.78, 0.266 },
- { 35433.07, 0.76, 0.231 },
- { 38385.83, 0.75, 0.201 },
- { 41338.58, 0.75, 0.174 },
- { 44291.34, 0.75, 0.151 },
- { 47244.09, 0.75, 0.131 },
- { 50196.85, 0.75, 0.114 },
- { 53149.61, 0.75, 0.099 },
- { 56102.36, 0.75, 0.086 },
- { 59055.12, 0.75, 0.075 },
- { 62007.87, 0.75, 0.065 },
+ { -3000.00, 1.021, 1.1133 },
+ { 0.00, 1.000, 1. },
+ { 2952.76, 0.980, 0.8978 },
+ { 5905.51, 0.959, 0.8042 },
+ { 8858.27, 0.939, 0.7187 },
+ { 11811.02, 0.919, 0.6407 },
+ { 14763.78, 0.898, 0.5697 },
+ { 17716.54, 0.878, 0.5052 },
+ { 20669.29, 0.858, 0.4468 },
+ { 23622.05, 0.838, 0.3940 },
+ { 26574.80, 0.817, 0.3463 },
+ { 29527.56, 0.797, 0.3034 },
+ { 32480.31, 0.777, 0.2649 },
+ { 35433.07, 0.756, 0.2305 },
+ { 38385.83, 0.752, 0.2000 },
+ { 41338.58, 0.752, 0.1736 },
+ { 44291.34, 0.752, 0.1506 },
+ { 47244.09, 0.752, 0.1307 },
+ { 50196.85, 0.752, 0.1134 },
+ { 53149.61, 0.752, 0.0984 },
+ { 56102.36, 0.752, 0.0854 },
+ { 59055.12, 0.752, 0.0741 },
+ { 62007.87, 0.752, 0.0643 },
+ { 65000.00, 0.752, 0.0557 },
+ { 68000.00, 0.754, 0.0482 },
+ { 71000.00, 0.758, 0.0418 },
+ { 74000.00, 0.761, 0.0362 },
+ { 77000.00, 0.764, 0.0314 },
+ { 8.00, 0.767, 0.0273 },
+ { 83000.00, 0.770, 0.0237 },
+ { 86000.00, 0.773, 0.0206 },
+ { 89000.00, 0.777, 0.0179 },
+ { 92000.00, 0.780, 0.0156 },
+ { 95000.00, 0.783, 0.0135 },
+ { 98000.00, 0.786, 0.0118 },
+ { 101000.00, 0.789, 0.0103 },
{ -1, -1, -1 }
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
Am Freitag 06 Juli 2007 19:27 schrieb John Denker: It's been ten days now with no CVS-commit nor even any discussion of a CVS-commit AFAICT. That's definitely not true (generally spoken). Which branch are you using? Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Harald JOHNSEN schrieb: Sebastian Bechtold wrote: Yes, that's true. This might really be something that makes the implementation a bit more complicated. Currently, I have two ideas to solve this problem: 1.) Apply the textures on tile-level. The tiles have a regular rectangular shape, so you could map one texture on one tile, without any overlapping. A problem with this could be the dimensions. You'd need quite large textures to get an acceptable low value of square-meters per pixel. I don't yet know enough about 3D programming to judge if this is feasible or not (hardware-limited maximum texture size, OSG / FlightGear performance with handling such huge textures and so on), but at least we could try it. 2.) Use smaller textures (for example 2x2 or 4x4 per tile) and draw overlapping redundant borders to their neighbor textures. Mhh...I have problems to write a good explaination of this in english...I mean...near the borders of each texture (for example a 100 Pixel wide frame), you draw exactly the same pixels as you draw on the corresponding frame of the neighbor texture in each direction. You would then apply the textures so that they overlap and decide with triangle in the border area is filled with which one of four adjacent textures. When the frames are wide enough to cover every irregular shape that could occur, it should be possible to handle the problem this way. A clear disadvantage of this approach is, of course, the additional graphics memory requirement, and it's perhaps a bit harder to implement. I don't know what's better or if there are other, better ways to solve this. Feel free to help finding a solution! :) Cheers, Sebastian The point 1) will give worse ground texture than today if we set the texture size at 4090^2. The point 2) is better except that this 100 pixel border is arbitrary. Sometimes it will be ok but i'm afraid there is some triangles that will go very far inside adjacent texture (some sea triangles inside the bay are very long for example). But if the the real problem is those anoying triangle why not simply delete them ? Frankly we don't care about the geometry in the btg file, we just need a height field, let just built this grid and voila (this is for the display, the btg is still used for agl computation, intersection, etc or not because finding a height in a grid is instant, no more sequential scan of a soup of triangles). Mh...I have to admit that I can't completely follow your words here. You talk about deleting the problematic triangles. Do you mean deleting at runtime or by rebuilding the scenery file? If possible, I'd like to try to do this without doing such further changes. I'd like to avoid a plan where one feature requires another, and this one requires another again, and so on. The more you change, the higher is the risk of unplanned side effects and work to adapt other things to the changes. As I've already said: For myself, some kind of golden rule here is to change as little of the existing concepts and code as possible. This may rise problems which require some odd and maybe suboptimal solutions, but I think that's still better than running into a situation where the list of things which have to be changed is growing longer and longer. Not to mention the inacceptable problems related to project coordination and the different opinions everyone has. I also think that the ground texture resolution you'd get with one big texture per tile won't be that good. Especially not when your original intention to do this was to make things like road markings(!) possible. In the end, the ground might look worse than before. But anyway - I'm convinced that this is in principle an important feature which opens the door to a lot of visual improvements, given that texture resolution and performance are fine. So I think it's absolutely worth working on it. If the first version won't pay off, there will surely be ways to improve it. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
On 07/06/2007 01:50 PM, Thomas Förster wrote: That's definitely not true (generally spoken). Which branch are you using? CVS OSG, up to date as of late yesterday (the 5th). Has something happened since then? With this version I observe: -- Middle marker audio is strongly shifted. -- ATIS audio is strongly shifted. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
Am Freitag 06 Juli 2007 20:33 schrieb John Denker: On 07/06/2007 01:50 PM, Thomas Förster wrote: That's definitely not true (generally spoken). Which branch are you using? CVS OSG, up to date as of late yesterday (the 5th). Has something happened since then? Hmm, rereading your post this probably was a misunderstanding. You were referring to doppler effect related commits, weren't you? Thomas -- PhD Student, Dept. Animal Physiology, HU Berlin Tel +49 30 2093 6173, Fax +49 30 2093 6375 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
On Friday 06 July 2007 18:27, John Denker wrote:
It's been ten days now with no CVS-commit nor even any
discussion of a CVS-commit AFAICT.
That's probably about right. I and a few others on IRC were testing various
patches for Maik for a while... I thought that the results of that made it to
the devel list, but to remove any doubt about, I'll attach (what I think is)
the last one here.
If you send me the appropriate patch [off list or otherwise]
I'll be happy to try it.
If I'm not mistaken, attached is the patch I'm currently using and I haven't
noticed any problems with other than the slightly odd (but expected, and no
doubt correct) effect one gets if one moves the view really quickly when in
external view.
Let us know if you find otherwise...
Cheers,
AJ
Index: sound/sample_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/sample_openal.cxx,v
retrieving revision 1.27
diff -u -p -r1.27 sample_openal.cxx
--- sound/sample_openal.cxx 21 Jun 2007 21:46:21 - 1.27
+++ sound/sample_openal.cxx 28 Jun 2007 19:22:14 -
@@ -75,12 +75,17 @@ SGSoundSample::SGSoundSample() :
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(true)
{
}
// constructor
-SGSoundSample::SGSoundSample( const char *path, const char *file) :
+SGSoundSample::SGSoundSample( const char *path, const char *file , bool _no_Doppler_effect ) :
buffer(0),
source(0),
pitch(1.0),
@@ -88,8 +93,13 @@ SGSoundSample::SGSoundSample( const char
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
-{
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(_no_Doppler_effect)
+{
SGPath samplepath( path );
if ( strlen(file) ) {
samplepath.append( file );
@@ -145,7 +155,7 @@ SGSoundSample::SGSoundSample( const char
}
// constructor
-SGSoundSample::SGSoundSample( unsigned char *_data, int len, int _freq ) :
+SGSoundSample::SGSoundSample( unsigned char *_data, int len, int _freq , bool _no_Doppler_effect ) :
buffer(0),
source(0),
pitch(1.0),
@@ -153,7 +163,12 @@ SGSoundSample::SGSoundSample( unsigned c
reference_dist(500.0),
max_dist(3000.),
loop(AL_FALSE),
-playing(false)
+#ifdef USE_SOFTWARE_DOPPLER
+doppler_pitch_factor(1),
+doppler_volume_factor(1),
+#endif
+playing(false),
+no_Doppler_effect(_no_Doppler_effect)
{
SG_LOG( SG_GENERAL, SG_DEBUG, In memory sounds sample );
@@ -247,14 +262,23 @@ SGSoundSample::bind_source() {
}
alSourcei( source, AL_BUFFER, buffer );
+#ifndef USE_SOFTWARE_DOPPLER
alSourcef( source, AL_PITCH, pitch );
alSourcef( source, AL_GAIN, volume );
+#else
+print_openal_error(bind_sources return);
+alSourcef( source, AL_PITCH, pitch *doppler_pitch_factor );
+alGetError(); //ignore if the pitch is clamped by the driver
+alSourcef( source, AL_GAIN, volume *doppler_volume_factor );
+#endif
alSourcefv( source, AL_POSITION, source_pos );
alSourcefv( source, AL_DIRECTION, direction );
alSourcef( source, AL_CONE_INNER_ANGLE, inner );
alSourcef( source, AL_CONE_OUTER_ANGLE, outer );
alSourcef( source, AL_CONE_OUTER_GAIN, outergain);
+#ifdef USE_OPEN_AL_DOPPLER
alSourcefv( source, AL_VELOCITY, source_vel );
+#endif
alSourcei( source, AL_LOOPING, loop );
alSourcei( source, AL_SOURCE_RELATIVE, AL_TRUE );
@@ -273,8 +297,13 @@ SGSoundSample::set_pitch( double p ) {
if ( p 2.0 ) { p = 2.0; }
pitch = p;
if (playing) {
+#ifndef USE_SOFTWARE_DOPPLER
alSourcef( source, AL_PITCH, pitch );
print_openal_error(set_pitch);
+#else
+alSourcef( source, AL_PITCH, pitch * doppler_pitch_factor );
+alGetError(); //ignore if the pitch is clamped by the driver
+#endif
}
}
@@ -282,7 +311,11 @@ void
SGSoundSample::set_volume( double v ) {
volume = v;
if (playing) {
+#ifndef USE_SOFTWARE_DOPPLER
alSourcef( source, AL_GAIN, volume );
+#else
+alSourcef( source, AL_GAIN, volume * doppler_volume_factor );
+#endif
print_openal_error(set_volume);
}
}
@@ -313,6 +346,7 @@ SGSoundSample::set_source_pos( ALfloat *
sgAddVec3( final_pos, source_pos, offset_pos );
alSourcefv( source, AL_POSITION, final_pos );
+print_openal_error(set_source_pos);
}
}
@@ -327,6 +361,7 @@ SGSoundSample::set_offset_pos( ALfloat *
sgAddVec3( final_pos, source_pos, offset_pos );
alSourcefv( source, AL_POSITION, final_pos );
+print_openal_error(set_offset_pos);
}
}
@@ -350,13 +385,88 @@ SGSoundSample::set_orientation( ALfloat
}
void
Re: [Flightgear-devel] Doppler oddness
On 07/06/2007 02:56 PM, Thomas Förster wrote: Hmm, rereading your post this probably was a misunderstanding. You were referring to doppler effect related commits, weren't you? Yes. Perhaps I clipped too much context; I thought the Subject: line would be sufficient contex. Sorry. To repeat: I am using CVS OSG, up to date as of late yesterday (the 5th). With this version I observe: -- Middle marker audio is strongly shifted. -- ATIS audio is strongly shifted. Please tell me where to find whatever patches are needed to deal with these bugs. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
Hi John, I posted the patch which should fix your problem on June 1st, 22:16 (German time). (If you do not have archived this EMail: just drop me a note, I will email it to you). I think the patch will be commited soon. But I am modifying files, which are not mine, therefore it is ok, to give the file-owner some time. On IRC we discussed to commit it tomorrow if nobody complains up to then. Maik P.S.: for plib-branch-users: June 3rd, 23:21 John Denker schrieb am 06.07.2007 21:04: On 07/06/2007 02:56 PM, Thomas Förster wrote: Hmm, rereading your post this probably was a misunderstanding. You were referring to doppler effect related commits, weren't you? Yes. Perhaps I clipped too much context; I thought the Subject: line would be sufficient contex. Sorry. To repeat: I am using CVS OSG, up to date as of late yesterday (the 5th). With this version I observe: -- Middle marker audio is strongly shifted. -- ATIS audio is strongly shifted. Please tell me where to find whatever patches are needed to deal with these bugs. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to apply different texturing to the terrain mesh? (especially addressing Harald Johnsen)
Sebastian Bechtold schrieb: .. If possible, I'd like to try to do this without doing such further changes. I'd like to avoid a plan where one feature requires another, and this one requires another again, and so on. The more you change, the higher is the risk of unplanned side effects and work to adapt other things to the changes. As I've already said: For myself, some kind of golden rule here is to change as little of the existing concepts and code as possible. This may rise problems which require some odd and maybe suboptimal solutions, but I think that's still better than running into a situation where the list of things which have to be changed is growing longer and longer. ... Hi Sebastian, once again my suggestion would be in accordance to your point of view a) to _minimize all changes to the actual given code _b) doing all work and calculation *off* runtime . Then it should be possible to 1. have the lat/lon coordinates calculated for all 4 corners of the used _new texture_ of any size 2. calculate the lat/lon coordinates of every corner of every _triangle_ out of the *.btg file and sort the tiles (the fileformat is sure documented anywhere, I looked for it but did not find any documentation) 3. split the new texture into the sizes of all given triangles using the precalculated triangles area/lat-lat-corners 3.a uncomplicated for all triangles fully located within the new texture area = only new texture is used 3.b more problematic for boarder triangles only partly located within the new texture area = merging of old ground texture for the outside part and new texture for the inside part has to be done. 4. this results in a special ground-texture for every given triangle 5. there must be already a marker in the actual *.btg format for every ground-triangle which ground-texture to use. But there is only a limited number of ground-textures and therefore the marker might not have the data-format for a *big* number of different ground-textures (what would be necessary if we split bigger textures and create a lot of different new ground-textures). So a slight change of the *.btg format might be necessary. 6. With this the actual display-routines for OSG and PLIB should work principally, only the new *.btg data-format (for the really bigger number of available ground-textures) must be handled _I know, this solution is suboptimal but can be made with a overviewable amount of coding_ (and therefore the chance to have very little negative sideeffects) but makes a big ground-texture improvement possible. And I know that this can really get more complicated if the new ground-texture-area uses partly 2 or more *.btg files. Once working pretty well, this changes could be improved more and more in little further steps - that is what everyone likes to avoid big coding-problems. Some years ago I did this for X-Plane with own new groundtextures from Landsat 7 . This was a lot easier as a) the used data-format was well documented b) there where only little squares with regular size to split the big texture to (very easy to handle, OLD X-Plane elevation data format, has changed since then). But I think it was _generally_ the same process to improve the ground-view as I suggested from 1 to 6 and should therefore work for FlightGear as well. Just my thoughts :-) Regards Georg EDDW - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
Hi, ups. Is it really July? Please replace June by July in my last post. Thanks to John. Maik Maik Justus schrieb am 06.07.2007 21:23: Hi John, I posted the patch which should fix your problem on June 1st, 22:16 (German time). (If you do not have archived this EMail: just drop me a note, I will email it to you). I think the patch will be commited soon. But I am modifying files, which are not mine, therefore it is ok, to give the file-owner some time. On IRC we discussed to commit it tomorrow if nobody complains up to then. Maik P.S.: for plib-branch-users: June 3rd, 23:21 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
I wrote Sent: 06 July 2007 12:56 To: 'FlightGear developers discussions' Subject: [Flightgear-devel] Today's CVS Hi all, Today's cvs seems to have solved thru problem of crashes with traffic-manager when compiled with MSVC8, at least for short runs. My testing is incomplete, since I have not been able to test for extended periods, so the longer term memory leak that has been reported may still be present. That is the good news. The bad news is that the ac taxiing towards KSFO 28L disappear just as they arrive at the threshold. Reagan Thomas has already reported seeing this. So far as I can see, the ac are teleported to 28L, where they take off and carry on normally. I have tracked this visually and on radar, and it is repeatable. After further testing I can confirm that the disappearance is readily repeatable. If you position your ac on the threshold of 28R at KSFO, as the AI aircraft are about to trample all over you they obligingly commit suicide. The first then reappears well down runway 28L taking off, the second just disappears. On second thoughts this isn't perhaps such a bad idea after all, perhaps it's a feature not a bug. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Doppler oddness
I got the .diff from Maik Justus. I merged it into the _Sport Model_. It works fine; ATIS and marker beacons are no longer Doppler shifted. In addition to the two files patched by the .diff, I had to make some trivial and obvious edits in two other files, to bring them into compliance with the new interface. If anybody wants to see the details they can pull the _Sport Model_ and do a git-diff. For details on that, see http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11530.html - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] randomized ceiling
Hi -- I just added a feature to the _Sport Model_. This has been on my wish list for a long, long time. I implemented it this morning, and I've been having quite a lot of fun trying it out. Here's the scenario: Suppose you are on an instrument approach. You know the weather is marginal, but you can't be sure whether it is slightly above minimums or slightly below. This motivates you to a) Fly the approach very precisely, because if you're even a little bit off, you won't be able to land, and b) Be prepared for the miss. Remember, if you're not prepared for the miss, you're not prepared for the approach. It's hard to simulate that scenario in a self-instruction simulator situation ... unless there is some randomization. So that's what I did. In the clouds popup, there is a new Plus/Minus field that the pilot can use to create a ceiling with some uncertainty. If the Plus/Minus field is set to x, the cloud base is perturbed by a random amount uniformly distributed on the interval [-x, x]. The randomness is applied when you hit the Apply button or the OK button; there is no time-dependence. Screen shot: http://www.av8n.com/fly/fgfs/random-ceiling.jpg IFR checkride standards call for maintaining the MDA plus 50, minus 0 feet. So, we say there is a band from MDA-0 to MDA+50 for maneuvering in. Therefore, in preparation for a non-precision approach, it makes sense to set the nominal cloud base field (on the Clouds popup) to MDA+50 and set the Plus/Minus field to 100 or thereabouts. That way there will be a 50% chance of having clouds intruding below the top of the allowed maneuvering band, and a 25% chance that clouds extend even below the MDA. You'll never know whether the approach will terminate in a landing or in a miss. This is very good practice for real-world IFR operations. Similar ideas apply to precision approaches. Set the nominal cloud base to DH+50 and set the Plus/Minus field to 100 or therabouts. After landing, it pays to check the Clouds popup again. If there is an overcast cloud base below the MDA, you shouldn't have landed. There are more than a few folks who think this sort of feature (and the similar features in gremlins.nas) are the greatest part of the raison d'etre of simulators. -- You can practice more cheaply than in a real aircraft; -- You can practice almost as well; and -- In some ways you can practice better, because there are some emergency situations that you would like to practice, but can't be safely practiced in the real aircraft. For details on how to get yourself a copy of the sport model, see http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11530.html - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument-altimeter unable to indicate altitude above 61831 feet
On Fri 6 July 2007 01:41, John Denker wrote: On 07/05/2007 06:57 PM, gh.robin wrote: When i opened that topic , it was to know if we could hope any FG update to get an altitude instrument which can be able to indicate more than 61000 ft. We have had a lot of discussion on it , but nothing which could give the right answer. Do we have to stay with that limitation = 61000 ft ? No, we do not. Back on 06/19/2007 03:20 PM, I sent a message Gérard off list, including a patch to fix this, extending the existing model to over 100,000 feet. Apparently the message got lost somehow. Do we have to conclude that FG altitude instruments is unable to give the right value? As I explained on-list, there is nothing wrong with the altimeter. I fixed the altimeter months ago. The problem is in the model of the atmosphere, in environment.cxx, where it computes the ambient pressure. I will have more to say about this anon, but for now, here is the patch again. It applies to today's CVS (offset one line). Thanks Jon, Yes the patch has vanished , probably in the vacuum space :) Because your patch is only a simple extension of the existing table it could be commit without any risk. Regards -- Gérard - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: Apply throttle axis changes only to selected engines
Hi all!
Currently the joystick throttle axis and the mouse throttle control apply
any throttle change to all engines. In my work on LZ-129 Hindenburg I
discovered that I need to be able to quickly control the engines
individually or in (sub)groups - and I think this ability would be useful
also for other multi-engine aircraft.
I propose the following changes to controls.nas:
1. throttleMouse(), throttleAxis() and incThrottle() only change the
throttle setting for the selected engines, i.e. those that have
/sim/input/selected/engine[i] == true
2. A new function controls.selectEngineToo(e_no) adds engine number e_no
to the set of active engines. The existing selectEngine() is mutually
exclusive - it deselects all other engines. (I hope somebody can come
up with a better name than selectEngineToo..)
3. Mixture and propeller controls seem to honour engine selection already.
On my system I have mapped controls.selectEngineToo(number) to
shift+ctrl+number, which I find convenient and easy to work with.
E.g. shift+1 and then shift+ctrl+2 selects engine 1 and 2.
Aircraft like Dornier Do X or Convair B-36 could add their own
keyboard shortcuts to select engine groups.. :)
Here is a patch for Nasal/controls.nas that implements the changes:
http://www.gidenstam.org/FlightGear/misc/controls.nas_individual_throttles.diff
Suggestions and comments are welcome!
Cheers,
Anders
--
---
Anders Gidenstam
mail: anders(at)gidenstam.org
WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/Index: Nasal/controls.nas
===
RCS file: /var/cvs/FlightGear-0.9/data/Nasal/controls.nas,v
retrieving revision 1.21
diff -u -p -u -r1.21 controls.nas
--- Nasal/controls.nas 22 Jun 2007 18:49:38 - 1.21
+++ Nasal/controls.nas 6 Jul 2007 22:31:28 -
@@ -27,6 +27,10 @@ selectEngine = func {
foreach(node; sel) { node.setBoolValue(node.getIndex() == arg[0]); }
}
+selectEngineToo = func {
+setprop(/sim/input/selected/engine[~arg[0]~], 1);
+}
+
selectAllEngines = func {
sel = props.globals.getNode(/sim/input/selected).getChildren(engine);
foreach(node; sel) { node.setBoolValue(1); }
@@ -53,10 +57,16 @@ centerFlightControls = func {
throttleMouse = func {
if(!getprop(/devices/status/mice/mouse[0]/button[1])) { return; }
-val = (cmdarg().getNode(offset).getValue() * -4
- + getprop(/controls/engines/engine/throttle));
-if(size(arg) 0) { val = -val; }
-props.setAll(/controls/engines/engine, throttle, val);
+sel = props.globals.getNode(/sim/input/selected).getChildren(engine);
+foreach(node; sel) {
+ if (node.getValue()) {
+val = (cmdarg().getNode(offset).getValue() * -4 +
+ getprop(/controls/engines/engine[~node.getIndex()~]/throttle));
+if(size(arg) 0) { val = -val; }
+setprop(/controls/engines/engine[~node.getIndex()~]/throttle,
+val);
+ }
+}
}
# Joystick axis handlers (uses cmdarg). Shouldn't be called from
@@ -64,7 +74,13 @@ throttleMouse = func {
throttleAxis = func {
val = cmdarg().getNode(setting).getValue();
if(size(arg) 0) { val = -val; }
-props.setAll(/controls/engines/engine, throttle, (1 - val)/2);
+sel = props.globals.getNode(/sim/input/selected).getChildren(engine);
+foreach(node; sel) {
+if (node.getValue()) {
+setprop(/controls/engines/engine[~node.getIndex()~]/throttle,
+(1 - val)/2);
+}
+}
}
mixtureAxis = func {
val = cmdarg().getNode(setting).getValue();
@@ -218,16 +234,19 @@ adjEngControl = func {
# arg[1] is the auto-throttle target speed increment
incThrottle = func {
auto = props.globals.getNode(/autopilot/locks/speed, 1);
+selected = props.globals.getNode(/sim/input/selected);
if ( !auto.getValue() ) {
engs = props.globals.getNode(/controls/engines).getChildren(engine);
foreach(e; engs) {
-node = e.getNode(throttle, 1);
-node.setValue(node.getValue() + arg[0]);
-if ( node.getValue() -1.0 ) {
- node.setValue( -1.0 );
-}
-if ( node.getValue() 1.0 ) {
- node.setValue( 1.0 );
+if(selected.getChild(engine, e.getIndex(), 1).getBoolValue()) {
+ node = e.getNode(throttle, 1);
+ node.setValue(node.getValue() + arg[0]);
+ if ( node.getValue() -1.0 ) {
+node.setValue( -1.0 );
+ }
+ if ( node.getValue() 1.0 ) {
+node.setValue( 1.0 );
+ }
}
}
} else {
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
[Flightgear-devel] making 25-kHz frequencies work
In several places in the code, a conversion is made from double frequency in MHz to int frequency in tens-of-kHz. The conversion was done unwisely, i.e. in a way that is incompatible with the way 25-kHz frequencies are rounded in near-universal aviation practice ... and, in particular, as done in the apt.dat file. This is particularly noticeable in the case of ATIS and AWOS frequencies, which commonly use 25-kHz frequencies. 1) I created a structured reference, and 2) I made it work. The upgrade has been incorporated in the _Sport Model_. For details on the _Sport Model_, see http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11530.html === For those of you who are still using the boring old CVS model, here's a patch for you. http://www.av8n.com/fly/fgfs/kHz10.diff - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
