Re: [Flightgear-devel] Next world scenery build
On Tuesday 20 December 2005 18:17, Dave Culp wrote: I'm still itching to get the approach light structures working at KSFO, and I think Curt's improvements will allow accurate modeling of unusual airports, like KLGA, where both runways are extended out over the water on decks. We're still stuck not being able to model airports properly. TaxiDraw is a great tool but I really don't like being limited to rectangular taxiway sections - they look awful. I started playing with the idea of modeling them as a 3D model in Blender and sticking that into the terrain instead. Yes it's a lot slower but you can get things spot on like the real thing. A few decent, well known airports would be nice in FG. I'm sure Curt would love to include a few dozen of them everytime he does a scenery rebuild. :P What would be really helpful though is a way to snap the vertices of the terrain in fgsd to the vertices of a placed model to eliminate seams or a way of converting a 3D model to one of those special binary model files that the airports are in. (*.btg.gz) In the long term an automatic airport slicer/cutter would be the best option. Pre-generate or generate an airport on the fly and cut and stitch it into the underlying terrain at run time. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Options saving patches
On Saturday 17 December 2005 16:10, Curtis L. Olson wrote: Maybe we should drop the arbitrary version numbering scheme (and I do see the version numbers as 99.9.9% arbitrary) and go with code names for our releases. Would that make people happier? Curt. No what would make us more happy is to know why there is such an urgency to have two FG releases in the space of a couple of months when up till now we've been releasing about once per year. What has prompted this change? This decision didn't involve the developers at all. Not even a guys what do you think about having another release in January that just contains bug fixes? Are we changing to a frequent release cycle or what? When will the next release be after 1.0? March or April? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plugins, Was: KLN89 GPS added
On Thursday 01 December 2005 11:12, Erik Hofman wrote: Joacim Persson wrote: On Thu, 1 Dec 2005, David Luff wrote: I have no experience of plugin architectures, and don't feel competent to attempt it at the moment. First of all: there's obviously no panic. (If there were fifty-seven hard-linked GPS models, AP's etc it would be a problem, ;) Personally I'd much rather see the rest of FlightGear advance in a direction that this kind of stuff can be done using Nasal (ultimately). The bonus is that others gain from those additions too. Erik I'd hate to see full blown graphical GPS units like the Garmin GNS430 running purely in Nasal unless there are lots of generic C/C++ functions that are being called to do the hard work in the background. In MSFS the GPS units and complex instruments are coded in C and you should see how many CPU cycles they require to update. It would only be a lot worse in Nasal. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added
On Wednesday 30 November 2005 16:50, Melchior FRANZ wrote: * Curtis L. Olson -- Wednesday 30 November 2005 15:19: You may want to attack this in small steps ... for instance start out with just getting save/load of aircraft position working. As demonstrated before [1], this is quite easy to do even with Nasal[2]. The only thing that needs to be implemented in fgfs is a way to tell it where to store the files. Something like FG_HOME/--fg-home. Paul was already working on that for exactly this purpose[3], but somehow he felt discouraged and stopped (IIRC). m. [1] http://mail.flightgear.org/pipermail/flightgear-users/2005-November/012871. html [2] http://members.aon.at/mfranz/flightgear/ac_state.nas [3] http://mail.flightgear.org/pipermail/flightgear-devel/2004-December/032641. html From the thread : http://mail.flightgear.org/pipermail/flightgear-devel/2004-December/032651.html Curt said it was something we should discuss. So I laid out my ideas and the reasons for those ideas and that was the end of it. Zero feedback. :( I'm not the sort of person who persistently badgers someone to give me their input. If people aren't bothered to reply to my thoughts and ideas then I'm not going to be bothered to contribute any code. Someone else can do it now. :) And this whole let's push 1.0 out thing is annoying me too. It's like someone has a secret agenda for getting a 1.0 release out. We sit on a single version for nearly an entire year and then suddenly we have to push out two consecutive releases within a couple of months. There was *ZERO* discussion about the decision and now it seems everyone must halt their contributions and fix bugs instead? I don't mind leadership but I hate dictatorship. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On Thursday 24 November 2005 20:18, Josh Babcock wrote: Stefan Seifert wrote: Mathias Fröhlich wrote: On Donnerstag 24 November 2005 04:44, Ampere K. Hardraade wrote: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 30 Current serial number in output stream: 31 Well, as far as I can see and remember: The client libraries send a request to the 'display system' and the 'display system' bails out with an 'unsupported request'. The error message is somehow misslieading, since the problem happens when communicating with dri/drm instead of the X server - the reason I called it 'display system' above. I just wanted to note, that when it is clear, that it's a bug in ATI's drivers, someone should post a bugreport in the ATI driver Bugzilla: http://ati.cchtml.com/ This is actually a place where driver developers are watching and a good chance that such bugs get fixed. Before posting, you should read the instructions at: http://www.rage3d.com/board/showthread.php?t=33799828 which is btw. a thread in _the_ most useful forum for Linux using ATI card owners: http://www.rage3d.com/board/forumdisplay.php?f=88 Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I'm not sure if it's the same one, but I have been following this one: http://ati.cchtml.com/show_bug.cgi?id=232 Doesn't seem to be any progress yet though. Josh Ampere says that they are not the same bug. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 0.9.9 scenery?
On Friday 11 November 2005 17:14, Curtis L. Olson wrote: The new world will be based on SRTM v2 data supplimented with USGS DEM data to fill in the voids where possible, i.e. in the usa. The grand canyon and rhode island will be much better. These places glitched out in SRTM and portions never got properly mapped. There is 100% void free SRTM data here : http://srtm.csi.cgiar.org/ Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 0.9.9 scenery?
On Friday 11 November 2005 22:27, Oliver C. wrote: Isn't SRTM data version 2 allready corrected manually? That's what i thought, when i heard sth. about SRTM v2. Best Regards, Oliver C. Well yes SRTM version 2 has had some corrections made to it including flattening the areas covered by water but it's still FULL of voids. For some other flight sim scenery I use SRTM version 2 and fall back to the CGIAR when voids are encountered. So far so good. Of course the USA has complete coverage in NED1 (30m) which should rather be used in my opinion. 90 meter DEMs are pretty coarse. Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] San Jose
On Saturday 05 November 2005 07:57, Shelton D'Cruz wrote: Hi Guys Just to let you all know I am populating San Jose airport with buildings, tower etc, I am trying to make it as real as possible (from airport charts) - using existing objects. I have just added the tower. When I am complete, how do I send it for submittal to be included in the next release? Since it's in the default San Francisco area you can submit it to Erik or Curt or you could sumbit it to the FlightGear scenery database. http://fgfsdb.stockill.org/ I'm just not sure if Curt will include objects from the FG scenery db into the default scenery area. Curt what's the plan with regards to models and the next scenery build? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Adding a Hanger
On Saturday 05 November 2005 10:09, Shelton D'Cruz wrote: However, FGFS says: WARNING: ssgLoadAC: Failed to open '/usr/share/games/FlightGear/data/Models/Airport/hanger2.ac' for reading Looks like you haven't added your hangar2.ac model to the /usr/share/games/FlightGear/data/Models/Airport/ directory or it's a file permissions problem. My guess is it's the former. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Friday 04 November 2005 23:23, Durk Talsma wrote: I've been playing a bit with loading different aircraft and different paint schemes. To get AI traffic going in the forseeable future, we could use quite a few low-polygon count aircraft models in various paint schemes. So, I'd be interested to know if anybody with reasonable 3d modeling skills would be interested in contributing in this field. Although the traffic system shouldn't be limited to commercial airliners, this is probably the area I'd be working on mostly initially. So, for starters, I would like to explore some models of the more popular airliners series, i,e., the Boeing 7[0-8]7, Airbus A3[0-8]0, and any [McDonnel] Douglas aircraft (and Fokkers of course :-)). I'd build them myself If I had shown any signs of talent in the field of 3D modeling :-(. It's a pity we can't use something like the Project AI aircraft packages. It's a lot of work modeling dozens of aircraft types and liveries. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Carrier Taking Off Landing Customization
On Tuesday 18 October 2005 12:26, Dai Qiang wrote: Hi folks, I have chosen FGFS as the tool to finish my master thesis. I hope to realize a carrier taking off and landing simulation program. Here is my question: Is it possible to make my own plane and carrier in FGFS? If so, what are the specific steps? Thanks for your help. - Qiang There are already working carrier ops in FlightGear. There is the Nimitz carrier just off the West coast of San Francisco and several aircraft are carrier ops equipped. The carrier moves all the time in a box pattern but can be told to head into the wind for launches and landings. This all works perfectly in the CVS version so if you're interested in developing other aircraft carriers and/or aircraft I suggest you grab a copy of the CVS code and take a look at what we already have. Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On Monday 17 October 2005 19:50, Martin Spott wrote: Well, points and lines and taxiway width is what we have now and people claim that the result looks terribly :-) Finally with points and lines you won't be able to describe the _shape_ of a junction - as I understood exactly this is what people like to improve. You won't be able to reverse-engineer the shape of such a junction because in real live they don't follow geometric perfection. Sometimes you have an offset between the upper and the lower junction, one is more situated to the right whilts the other to the left, one taxiway gets a bit wider on one side and so on. We should take this into account once we get serious about a new taxiway format. We're digging a big hole here and we should avoid spending all this effort for a solution that doesn't satisfy. Regards, Martin. Thanks Martin, you say things much better than I can. :) What I was trying to say is that taxiway layouts should be a COMBINATION of polylines and hand drawn polygons. Polylines will allow all the perfectly parallel taxiways to be drawn quickly and easily and raw polygons will allow for customized areas. We need a combination solution not a polyline only or raw polygon only solution. I while back I actually started coding an app to do this but didn't get very far. However I did get to the point where I could draw polylines and set their properties like bend radius and width. Unfortunately my coding skills are not very good and I ended up with a pile of spaghetti code. :) I was also going to use a lego approach where predefined taxiway junctions could be joined to taxiway segments just by snapping them together. Here is the functional spec I did : http://surgdom.hollosite.com/flightgear/fg_airport_maker/functional_specs.html Here are some of the reasons why I believe we need BOTH polyline and raw polygon editing : http://surgdom.hollosite.com/flightgear/fg_airport_maker/terrain_approaches.html Here are some screenshots of a taxiway polylines with configurable radius, width and max kink angle (smoothing of radius) : http://surgdom.hollosite.com/flightgear/fg_airport_maker/screens.html Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On Saturday 15 October 2005 23:44, Ralf Gerlich wrote: Hi, I hope I don't say too much if I say that there is work planned on defining taxiways by means of polylines in TaxiDraw. That's still very restrictive. It's a step in the right direction but is still far from what is needed. We need polygon editing and not just polylines. Taxiways are unfortunately too full of non-parallel sides for polylines to work properly everywhere. How would you draw these taxiways with polylines? http://surgdom.hollosite.com/flightgear/fg_airport_maker/images/terrain_approaches/katl_breakdown2.png http://surgdom.hollosite.com/flightgear/fg_airport_maker/images/terrain_approaches/katl_breakdown3.png http://surgdom.hollosite.com/flightgear/fg_airport_maker/images/terrain_approaches/katl_breakdown4.png However I don't mean to be discouraging. Polylines will be a lot better than what we currently have but would still frustrate people like me who want to be able to model all the minor details such as the common overtaking/passing sections at the end of taxiways or the shoulders that allow large aircraft to turn on a taxiway without running off it. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On Saturday 15 October 2005 20:54, [EMAIL PROTECTED] wrote: You know, I'd be happy to help do some of the taxiway work if a new format becomes available. I've been trying to work with Taxidraw, but it's kind of difficult to work in because of the underlying format (I have no problems with Taxidraw itself.) I find I spend a lot of time making sure the areas are in the correct place, all to make a curve that could've been described more easily with multiple points. I know there was some talk of extracting taxiways from the FAA's PDFs, but until that becomes available, a 'starter set' of airports in the new format might be a good idea. I thought about the taxiway structure/format a while back. I came to the conclusion that a raw polygon editor is about the only way you're going to be able to create taxiways properly. One can use rectangular or bent taxiway sections but when you get to all the weird and wonderful taxiway layouts it's impossible to do with a generic taxiway structure. This is very apparent where taxiways intersect other taxiways, runways or aprons. The only thing that made sense to me was a 2D CAD type app like TaxiDraw which can draw polygons of any shape and size. The tessellation stage can be done when building the scenery. The only major problem I ran into was how does one handle markings and lines? Having offset or floating polygon lines is a major trick with regards to z-buffer fighting. Texture based lines that are part of the taxiway textures need to be generated on the fly and consume huge amounts of VRAM due to their uniqueness so that's not a very good solution either. Also cutting the lines into the taxiway polygons pushes the polygon count up horrendously. I think we need to pick a solution that is going to work in the sim before we try to figure out what storage mechanism or format we are going to use. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Determining range?
On Saturday 17 September 2005 23:48, Mike Kopack wrote: Hey gang, As part of my simulated UAV control system project, I needed to augment the built in Autopilot system in FG with a module in my own system (which is written in java) that takes the aircraft's current position, and a desired position (lat/long/altitude/desired arrival time) and figures out the proper autopilot heading to lock to and altitude locks etc. Now, I'd like to figure out how to handle that last variable: Arrival time. To do it, I need to know how far I have left to travel, and how long I have to get there. The time isn't a problem, but how do I get the distance from my current Lat/Long to another Lat/Long? My investigations online show that there's no real way to directly convert from Lat/Long to meters. I know that the GPS system in FG calculates this distance. I just need to know what the formulas are that are used to arrive at this distance. Hi Mike Take a look at Aviation Formulary V1.42 http://williams.best.vwh.net/avform.htm It has everything you'll ever need formula wise for great circle navigation. Distance, initial course, cross track error, working out an enroute point at x distance from the origin along the route, etc It uses a spherical earth model which means there is a maximum error of about 0.2% which should be acceptable if I'm not mistaken. There is a worked examples section. Distance between points d=2*asin(sqrt((sin((lat1-lat2)/2))^2 + cos(lat1)*cos(lat2)*(sin((lon1-lon2)/2))^2)) The distance from LAX to JFK is === d = 2*asin(sqrt((sin((lat1-lat2)/2))^2+ cos(lat1)*cos(lat2)*(sin((lon1-lon2)/2)^2)) = 2*asin(sqrt((sin(0.592539-0.709186)/2))^2+ cos(0.592539)*cos(0.709186)*(sin((2.066470-1.287762)/2)^2)) = 2*asin(sqrt((-0.05829)^2 +0.829525*0.758893*0.379591^2)) = 2*asin(0.306765) = 0.623585 radians = 0.623585*180*60/pi=2144nm or d = acos(sin(lat1)*sin(lat2)+cos(lat1)*cos(lat2)*cos(lon1-lon2)) = acos(sin(0.592539)*sin(0.709186)+ cos(0.592539)*cos(0.709186)*cos(0.778708)) = acos(0.811790) = 0.623585 radians = 0.623585*180*60/pi=2144nm The initial true course out of LAX is: == sin(-0.778708)=-0.7020 so tc1 = acos((sin(lat2)-sin(lat1)*cos(d))/(sin(d)*cos(lat1))) = acos((sin(0.709186)-sin(0.592539)*cos(0.623585))/ (sin(0.623585)*cos(0.592535)) = acos(0.408455) = 1.150035 radians = 66 degrees Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the texture-path tags in XML.
On Sunday 11 September 2005 23:15, Erik Hofman wrote: Yes, correct. The texture positioning is done in the 3d model. So there's nothing we can do other than duplicating the model. Erik But if a model is UV mapped shouldn't it still work? With UV mapping the texture co-ords are normalized to 1 if I'm not mistaken so doubling the texture size for instance shouldn't cause any problems. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On Saturday 10 September 2005 13:19, Dave Martin wrote: I have a feeling as we get more road data, we're going to be seeing slight placement errors at the airports. Currently EGBB is placed over the A45 on the 0.9.8 scenery. If I can get that road mapped by GPS and a few others around it, we can probably move the airport to its correct location. I noticed that a lot of airports in the X-Plane DB are quite far out. Even some major airports like Sion were out by ~ 3 km. What I do find interesting is that the quality of the data seems to change for every country. South Eastern France's data was horrid, so was Switzerland's however Italy's data was almost spot on more than 90% of the time. Maybe someone corrected the data for Italy already or maybe it came from a different source. Also it appears that a lot of the data was pure guess work in a lot of cases. I saw plenty of runways that were more than 20 degrees out, runways that were more than 50% too short, wrong runway id's, wrong surface types, etc. Ever seen a military airport with a single 500m long grass runway that they use for F18's, Mirages, etc? :) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On Saturday 10 September 2005 15:28, Curtis L. Olson wrote: My understanding is that for the USA, the X-Plane data for runways comes primarily from DAFIF. Taxiways are all hand drawn and placed. Outside the USA the runway data is manually generated by anyone who wants to submit new airports, so quality and accuracy is all over the map. Oh! I never knew that. I thought DAFIF was a global database. That explains it then. Hehe ... I like your pun. (accuracy is all over the map) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DHC-6 progress
On Saturday 10 September 2005 18:42, Andy Ross wrote: It's hard to fix. When you mirror a mesh, the winding order of all the polygons gets reversed, which means their normals change direction. If the mesh is stored in an optimized format (strips, fans, etc...) then it needs to be broken down and re-optimized. Big mess. It's not something that blender can't or shouldn't handle, but it *does* interact in weird ways with the geometry representation. I sympathize. Isn't that where the flip normals feature comes in handy? I don't remember having any problems when I mirrored meshes in Blender for use in FG but it was a while ago. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On Saturday 10 September 2005 19:03, Ralf Gerlich wrote: However, I'm still searching for free detailed aerial photos for other areas of the world such as Germany. Here the government wants you to pay twice for the photos: Once via tax and once when you want to use the photos. The license under which you get those photos here is quite limited as well. That's a normal practice outside of North America. Don't you just love government surveyors. :-\ Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Tuesday, 2 August 2005 21:25, AJ MacLeod wrote: I'm using nvidia's headers all right... From /usr/include/GL/gl.h A while back I found that when the nVidia installer did its nut I had two versions of GL files. One set in /usr/include/GL and one in /usr/X11R6/include. One was nVidia and the other was the original (Mesa ?) headers. Now I symlink /usr/include/GL to /usr/X11R6/includeGL so that I only have one copy on my system. It caused me much compilation grief before until I did this. Maybe it was just a bad installer and has since been fixed. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Saturday, 30 July 2005 23:57, Paul Surgeon wrote: There is still a problem. If I roll back extensions.hxx and RenderTexture.cpp then I can compile SimGear. I'll try figure out what's causing it but I'm not very strong at C or C++ Paul GLXPbufferSGIX and GLXPbuffer are not defined anywhere in my nVidia GL headers although they are used throughout the GL headers! I've checked Mesa - same thing. The following lines in extensions.hxx cause a problem because GLXPbufferSGIX is not defined. #ifndef GLXPbuffer #define GLXPbuffer GLXPbufferSGIX #endif That is why I get a : ../../simgear/screen/extensions.hxx:441: error: ISO C++ forbids declaration of `GLXPbufferSGIX' with no type This is confusing. Are GLXPbuffer and GLXPbufferSGIX both supposed to be programmer defined? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Sunday, 31 July 2005 10:50, Erik Hofman wrote: Ok, this is be fixed in CVS now. Well almost fixed :-) Using a clean SG checkout (extensions.hxx version 1.24) : In file included from ../../simgear/scene/sky/bbcache.hxx:29, from ../../simgear/scene/sky/newcloud.hxx:31, from visual_enviro.cxx:35: ../../simgear/screen/extensions.hxx:449: error: `GLXPbufferSGIX' has not been declared ../../simgear/screen/extensions.hxx:449: error: ISO C++ forbids declaration of `parameter' with no type Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Sunday, 31 July 2005 11:19, Richard Harke wrote: On my system, I find that both are defined in GL/glxproto.h I have a Debian testing system and I run Nvidia. I don't think this file is from Nvidia, however, but I don't know the exact package. Apparently belongs to some part of glx Richard Harke If you scroll down to about line 1700 you'll find : #undef GLXPbuffer #undef GLXPbufferSGIX They are just temporarily defined as something and then undefined again. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
Problem fixed! SimGear WILL NOT compile with nVidia 6629 headers (like it used to). I updated to 7667 OpenGL headers and it compiles now. What I should do is do a diff between the 6629 and 7667 headers to find the problem but I'm too tired and lazy and am happy that things now work. ;) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SimGear RenderTexture changes causing compile problems
The updates (RenderTexture.cpp RenderTexture.h extensions.cxx extensions.hxx)
committed to SimGear on the 13th July don't compile on my system.
Error messages :
../../simgear/screen/extensions.hxx:438: error: ISO C++ forbids declaration of
`GLXPbufferSGIX' with no type
../../simgear/screen/extensions.hxx:438: error: typedef `GLXPbufferSGIX' is
initialized (use __typeof__ instead)
../../simgear/screen/extensions.hxx:438: error: `glXCreateGLXPbufferProc' was
not declared in this scope
../../simgear/screen/extensions.hxx:438: error: expected `,' or `;' before '('
token
GLXPbufferSGIX is definately defined in my glx.h/glext.h files.
If I roll back to 12th July I have no problems.
Any ideas?
Paul
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
On Saturday, 30 July 2005 18:27, Paul Surgeon wrote:
The updates (RenderTexture.cpp RenderTexture.h extensions.cxx
extensions.hxx) committed to SimGear on the 13th July don't compile on my
system.
Error messages :
../../simgear/screen/extensions.hxx:438: error: ISO C++ forbids declaration
of `GLXPbufferSGIX' with no type
../../simgear/screen/extensions.hxx:438: error: typedef `GLXPbufferSGIX' is
initialized (use __typeof__ instead)
../../simgear/screen/extensions.hxx:438: error: `glXCreateGLXPbufferProc'
was not declared in this scope
../../simgear/screen/extensions.hxx:438: error: expected `,' or `;' before
'(' token
GLXPbufferSGIX is definately defined in my glx.h/glext.h files.
If I roll back to 12th July I have no problems.
Any ideas?
Paul
Please disregard.
I don't understand why it didn't compile before even after 2 clean checkouts
but now it's happy.
Seems like I confused it enough with the rolling backwards and forwards to
make it happy.
Paul
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
There is still a problem. If I roll back extensions.hxx and RenderTexture.cpp then I can compile SimGear. I'll try figure out what's causing it but I'm not very strong at C or C++ Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns in Viewport
On Saturday, 23 July 2005 14:04, Paul Kahler wrote: All this multiplayer chat stuff has me thinking game. It would probably be more in line with simulation if chatting took place on a simulated radio. You'd not only have to be close enough to someone, but you'd have to be on the same frequency in order to talk to them. The idea of having little on-screen identifiers might be OK as long as it can be turned off. I really like that FGFS focuses on simulation and not game play. If you want to be highly realistic, mutiplayer voice chat with proper radio frequencies would be ideal. Bandwidth might be a problem for large groups, but small ones should be no problem. Of course it's much more complicated too ;-) I was going to comment on this earlier but decided not too since I may step on someone's toes. However since we are now on the topic ... :) The FS2004/IVAO network have voice comms working quite nicely. If you tune your radio in FS2004 to an active frequency (within range) TeamSpeak automatically connects to the server the frequency is hosted on and joins the channel. This happens in the background and is totally seamless. All you do is, tune to an ATC frequency and use the PTT key to make radio contact. Just like one would in real life. TeamSpeak doesn't use huge amounts of bandwidth and on the client side will happily run on a 56K dialup with multiplayer running. Chat windows are fine for development purposes but are totally evil and 1980's technology when it comes to ATC. :P In the early days of SATCO (pre VATSIM, IVAO) it was all text and it was a major pain to fly and try to type at the same time. Even shortcut keys used to build text messages were a pain. Getting a late landing clearance due to another aircraft clearing the active runway invariably meant an aerobatics display on short finals while trying to type a reply and configure for landing. One doesn't have to jump in the deep end by trying to implement all the features in one go. Someone can simply host a TeamSpeak server and create a KSFO_TWR channel which the pilots can join. Then when things get more busy we can add KSFO_APP, KSFO_CTR, UNICOM, etc. Getting TeamSpeak to switch servers and channels by tuning the radios can come at a later stage. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns inViewport
On Saturday, 23 July 2005 16:08, Vivian Meazza wrote: This has already been discussed. Teamspeak in not GPL'd. I think the licensing arrangements would give us problems. That would be a pity, because on the face of it, it's pretty much what we want. Certainly it's the right way to go though. Vivian TeamSpeak doesn't have to be part of the FG package. It's a separate program that has an API you can interface to. People run FlightGear on MS operating systems which are not GPL either so I don't see what the issue is. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns inViewport
On Saturday, 23 July 2005 17:34, Andy Ross wrote: Writing code that runs in the fgfs binary to interface to an API is generally considered to be making a derivative work, for fairly obvious reasons. ...whereas the simple act of running a program is not the creation of a derivative work. I know it's frustrating, but unfortunately the you can use this software for free culture isn't really compatible with the GNU notion of free software, or with the open source definition. This is a pretty fundamental thing, and it's not likely to be fixed any time soon. Most of us, I suspect, simply aren't interested in hooking someone else's proprietary stuff into FlightGear. Andy What a pity as I don't know of any good replacements and writing VOIP software is not a trivial task. So the only way it could work is if the creators of TeamSpeak released a GPL interface to their software? I guess text will just have to suffice. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns inViewport
On Saturday, 23 July 2005 20:55, Jon Stockill wrote: Paul Surgeon wrote: That's the beauty of an app like TeamSpeak. You just download it, install it and it works. No mess, no fuss, no sleepless nights trying to code or debug something. :) What about the server? Looking at the site it seems that you need a license to run it. I'd investigate more, but the link to the FAQ from the page discussing the costs doesn't go anywhere. Jon I didn't realise the server side was so sticky. :( The licenses are free for non-profit organisations as long as you don't exceed 100 slots for all instances of Teamspeak running on a server. If you do then you get billed $0.14 per slot. Well that's what I can make of it. TS is starting to look less and less attractive. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
On Monday, 4 July 2005 15:04, Jon Stockill wrote: I converted a chunk of SRTM data to 10m interval contours, and overlaid this on an ordnance survey map (using mapserver) - the results are actually incredibly close - the 0 point of the two datasets is obviously slightly different, but the two datasets fit together remarkably well - Obviously I have no idea how good the data is for the rest of the world, but the UK data seems surprisingly accurate, which leads me to my question - is there really such a huge problem with our source data, or do we just need to be generating scenery with more polygons? SRTM3 is very coarse. What I had problems with were airports that are on hill tops or steep terrrain. One example being KAVX. One would need a DEM with a = 5m sample spacing and about 1 meter vertical accuracy around such airports. SRTM's vertical accuracy is only guaranteed to be within 16 meters! It's usually within 10 meters but that is still a large error when dealing on a micro scale. Also what about custom mods like Alcatraz? There is going to be a need to custom tweak scenery with regards to both the DEM and the vector overlays (roads, rivers, railroads, powerlines, etc). Having everything in one DB with a single TG exporter interface is going to make life a lot easier in the long run in my opinion and there are numerous advantages which haven't been discussed yet. Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
On Sunday, 12 June 2005 09:22, Erik Hofman wrote: Ampere K. Hardraade wrote: I like that idea. It would be nice to fly along the coast of a tropical island, look down and be able to see the white sand under the water... or flying above a coral reef and see the corals on the sea floor. =) Seperating land and water will also allow tidal effects to be modelled. As for underwater exploration, I for one wouldn't mind taking the UFO down and see some underwater landmarks such as the Titanic. hehe. I think we're all getting carried away a bit. We are aiming at a professional *flightsimulator* to be used as a training aid, not for Hollywood film making. Erik Personally I don't care much for submarines and sealife in a flight sim. What Flight Unlimited did was when you crashed in water the screen went a murky water color and your altitude starts heading for negative figures. No fish, no sharks and no coral but you get the point that you just crashed into water and that should be sufficient in my opinion. If someone wants to make a submarine simulator then they are welcome to make a fork of FlightGear and name it SubGear but I'm interested in aerodynamics and not aquadynamics. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building joystick hardware
On Monday, 6 June 2005 20:46, Andy Ross wrote: Torsten Dreyer wrote: Well - it's not really a serial driver, the interface connects thru the handshake lines rts/cts and dtr with rxd and txd left unconnected since the LTC1090 speaks a synchronous protocol. Oh, heh. Well, if the hardware is non-standard, then one hack is as good as another. Never mind what I said, this is actually pretty elegant. Short of putting a microcontroller on your board, I have no suggestions. :) What would be really great is if there was an *easy* DIY USB-HID interface. I've been hunting all over for an simple solution but have found none. I know CH Products sell a USB-HID joystick module that comes in various preprogrammed options or that they will customize for you if you want but I don't know the price and I'm even less sure that I want to know how much it costs. All the other USB-HID interfaces require some fairly in depth knowledge of microprocessors, ASM and USB protocol specs which is not for the faint hearted. Programming the USB-HID protocols in ASM is the really difficult part - the hardware is simple. However the advantages of USB-HID are tremendous since there is no need to write drivers for MS OS's or Linux as they are already included in the OS's. No worrying about kernel space or user space drivers which probably halves the work involved. I'm not sure how the Linux USB-HID stuff works but I know MS Windows actually compiles and installs a new driver in the background after querying an HID device and finding out what features the device contains. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building joystick hardware
That's a really nice setup. I'd be interested in seeing how the device driver code works. I've been thinking about building a decent rudder setup and using a USB HID interface but the software side of USB protocols is really daunting to a below average programmer like me. Paul On Thursday, 2 June 2005 13:18, Torsten Dreyer wrote: Hi everybody. Some weeks ago, I dug thru my spare-parts-box and found a small assembly of an 8 channel 10 bit A/D converter using a LTC1090 and a few other parts. I dug a bit further and out came some pots, knobs, switches, some pieces of wood, a few screews and a bit of wire. I glued it all together, wrote a device driver for linux, hacked a xml file and suddenly had a neat power quadrant to use with flightgear's piston twins connected to the unused serial port. It has: 6 levers (axis?): 2 black for throttle, 2 blue for prop, 2 red for mixture 2 wheels for elevator and rudder trim 1 switch for gear up/down 2 switches for flaps down/up js_demo sees it like this: ~~ Joystick 0: LTC1090 Joystick Joystick 1 not detected Joystick 2 not detected Joystick 3 not detected Joystick 4 not detected Joystick 5 not detected Joystick 6 not detected Joystick 7 not detected +JS.0--+ | Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 Ax:5 Ax:6 Ax:7 | +--+ | 0004 +0.2 +0.2 -0.6 +0.3 -0.1 -0.6 -0.0 -0.1 | If anyone here on the list (or is there a hardware-builder list?) is interested in rebuilding this little toy, I am happy to put all I know to a little web site. One should be able to purchase all parts for around 40 EUR. Oh - by the way: Thanks everybody for making FlightGear! I use it a lot to keep current in flying ifr procedures... Cheers, Torsten ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] batteries, alternators, volts, amps - electrical system
Just some general info that may or may not be useful. General aviation batteries : Typically lead acid Commercial and military : Typically Ni-Cad (nickel cadmium) Alternators are far more efficient at *low* RPM than generators but are still terrible energy converters (unless you really need heat). The average general aviation alternator takes a little over two watts of energy (from the engine) to produce one watt of electrical power. Automotive alternators are usually of the Lundell type but there are newer types being used now. I should imagine light aircraft also use the Lundell type. The power output versus speed (RPM) for an alternator is almost perfectly linear so that should make things a little easier to model. What's not so easy to figure out is how much power is delivered at engine idle as this varies widely from one alternator to the next. I've seen anything from 25% to 80% on automobiles. On the battery side of things the discharge and charge rates are not going to be easy to model. Maybe a simple approximation using a lookup table will do as an interim measure. Paul On Wednesday, 1 June 2005 00:06, Curtis L. Olson wrote: I need to do some work beefing up our electrical system model a bit. I'd like to add a simple model for a battery where output varies with time and a simple alternator model where output varies with rpm. I'm a complete moron when it comes to electrical stuff so I'm not even sure I'm asking a sensable question. Does anyone know of a good online reference(s) or even just send me some reasonable info. In the end I'd like to be able to be able to output bus voltage (downstream of the battery + alternator) and also model an ammeter. I already have a way to back propogate the total current draw on the system, where the individual electrical system outputs can be marked with some current draw when they are on, however, I need to work on the input side of the equation. Again, I want to start pretty simple and not get drug down with too fancy of an implimentation. Thanks, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Tuesday, 17 May 2005 06:01, Ampere K. Hardraade wrote: For those who are currious: http://www.a1.nl/~ehofman/fgfs/gallery/fgfs-screen-016.jpg Erik It looks good, although usually there's only one bolt. Ampere Usually there is one main main strike called the leader and multiple step leaders connected to the leader that made it to the target. The step leaders are however not as visible as the leader and may go unnoticed. Only 20% of strikes consist of one stroke (pulse along the same path) while the other 80% are two or more strokes. The mean stroke occurrence is five to six and the maximum has been measured at twenty-five. Strikes can last up to 1 second in duration and I saw such a lighting storm a couple of months ago. It's amazing stuff - it even vaporized a 10 meter section of my fencing. (10 meters of 2.5mm high tensile fencing wire vanished) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Tuesday, 17 May 2005 22:46, Paul Furber wrote: On Tue, 2005-05-17 at 19:54 +0200, Paul Surgeon wrote: It's amazing stuff - it even vaporized a 10 meter section of my fencing. (10 meters of 2.5mm high tensile fencing wire vanished) Do you also live on the Highveld? :) Hehe, yes. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] City signs
On Saturday, 14 May 2005 12:50, Jon Stockill wrote: It's easy enough to do using the date from GNS (http://earth-info.nga.mil/gns/html/) the biggest quiestion is how to generate the signs - imagemagick could be used to generate a texture to add to a standard model (and an appropriate xml file could be created at the same time to select it) but that would result in insane texture usage. A better way may be to generate the letters seperately, and add those to the scenery (not unlike a variation on the hollywood sign). A better way would be to generate the textures dynamically at runtime. Dynamic scenery in FG ... I must be smoking grass seeing as we can't even do multitexturing yet. My useless contribution for the day Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
On my system the new 3D clouds only appear when I look directly at them. I have to move the pan cursor over them to see them. Paul On Sunday, 24 April 2005 13:35, Erik Hofman wrote: Hi, I have added the new 3d clouds code from Harald Johnson to CVS. The code is not yet perfect (the movements to the viewer needs some tweaking) but the effects are really nice. I hope we can figure out the problems and eliminate them because the results are even better than I had expected! Another thing is that it seems to depend on glut functions which need to be resolved for SDL users also. A third problem is that it uses the RenderTexture class which hasn't been implemented for MacOS-X yet. Anyway, en ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Building airports
On Wednesday, 20 April 2005 15:51, Corrubia, Stacie K wrote: Hi --- I am having a problem generating airports within TerraGear. I have been following the recipe from the TerraGear.README file and downloaded Robin Peel's database of airports and managed to create the basic.dat and the runways.dat file. Why not just use the airport database files that come with FlightGear? You can check them out of CVS without downloading the entire data package if you like. When I tried to use the genapt utility first I had to create a directory poly_counter and now I am getting an error: Unknown line in file: A E46 3799 CNN 02 Ranch This is the first line in the runways.dat file. Is there an issue with the file format? I downloaded source for TerraGear 9.8 I've seen that one before and in my case it was a UNIX vs MS line termination problem. Both Unix and Windows make use of ASCII encoded files; however, the standard used for line termination is slightly different. For Unix, lines are terminated with a single line feed (0Ah) code. For MS-DOS (and Windows), lines are terminated with a carriage return (0Dh) and line feed (0Ah) pair of codes. Use unix2dos or dos2unix to fix the end of line termination problem. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] realistic scenery
On Tuesday, 19 April 2005 08:21, eagle monart wrote: i tried to used fgsd but terrains are made in triangles not in squares an it looks impossible to tile what you want . a It's impossible to tile textures properly in FG. FG uses an irregular triangle mesh and not square tiles like MSFS. Even if you managed to tile a texture across the mesh you would still end up with a mess around the edges of the texture where the triangles don't end on the edge of the textures. You would need to clip a texture into the mesh for it to work properly and in the process you end up with a grid or semi tile based system. :) nowi am looking for information on importing bgl sceneries from msfs. Build terraintiling in msfs terrain generators and convertimport scenery in fgfs (sure i have to import tiles) and then add static objects in fgsd. Currently there are no tools to do what you want to do and you would have to do some serious work on the FG scenery code to support what you want to do. any idea? You have a few options 1. Learn to live with the FG scenery 2. Code a new or highly modified FG scenery engine 3. Go back to MSFS and pretend you never saw FG Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Van's RV-7 Model
On Sunday, 3 April 2005 23:22, Matthew Law wrote: I might be ordering the first part of the kit later this year even though my fiance tells me she will kill me if I do - and if I survive that, I'd better learn to fly tailwheel pretty quick too! Why not just get the tricycle version of the kit? (The RV-*A kits) You sacrifice less than 2 knots in speed and have much better visibilty while taxying not to mention better ground handling too. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Van's RV-7 Model
On Friday, 1 April 2005 12:12, Matthew Law wrote: I've been learning Blender and trying my hand at modelling an RV-7. Progress has been slow due to work, family and the learning curve but here are the results so far: http://www.matthewlaw.plus.com/RV-7.jpg Looks quite nice. An RV would be a nice addition to FG. A chap I know just finished building himself an RV-6 and it moves! About 145 knots at 50% power with a 160hp O320. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] xml sound : Does negative pitch work?
On Saturday, 26 February 2005 10:51, Erik Hofman wrote: The annoying click is because the audio file is not edited correctly. This one has me a bit stumped. It loops without clicks in Audacity and I've check the individual samples and the start/end joint is perfect. Do samples have to start and end with a sample value of zero in order to not click? I'll try to figure this one out. Also, you are aware that a sound played with a pitch offset of 1.0 is played twice the original speed (pitch always start at 1.0). I just checked this and a pitch offset of 1.0 definately reproduces the original speed. I don't have a frequency analyser available but my ears aren't that bad. :) With an offset of 0.5 the frequency is definately about half of the original pitch. Negative values for the properties should be no problem at all. They certainly are! :) I just did a bug test. Here is the config : audiocue namesinkcue/name modelooped/mode pathAircraft/LAK-19/Instruments/ILEC_SC-7/sink-tone.wav/path property/instrumentation/vertical-speed-indicator/indicated-speed-fpm/property volume min0.3/min max0.3/max /volume pitch property/instrumentation/vertical-speed-indicator/indicated-speed-fpm/property factor0.001/factor offset1.0/offset /pitch /audiocue For positive values the tone increases. For negative values the tone just loops with no pitch change. It's definately broken but this is one of those bugs that has not popped up in the past because no one has tried driving the pitch with a negative value yet. :) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] xml sound : Does negative pitch work?
On Saturday, 26 February 2005 13:07, Paul Surgeon wrote: On Saturday, 26 February 2005 10:51, Erik Hofman wrote: The annoying click is because the audio file is not edited correctly. This one has me a bit stumped. It loops without clicks in Audacity and I've check the individual samples and the start/end joint is perfect. Do samples have to start and end with a sample value of zero in order to not click? I'll try to figure this one out. This looks like an OpenAL problem or maybe a problem with the FG implementation. All the looping sounds in FG click however they are barely noticable because the sounds that are played are very noisy for lack of a better description. If you use a clean signal such as a sine wave with no other ambient sounds you immediately hear the clicking. It has nothing to do with the audio file as far as I can see. Here is my audio file : http://surgdom.hollosite.com/flightgear/tmp/sink-tone.wav Here is what the join looks like when I copy the beginning of the sample and paste it on the end : http://surgdom.hollosite.com/flightgear/tmp/wavmatch.png If someone can point out where the click is coming from I'd appreciate it but as I said in my previous e-mail the sound loops perfectly in Audacity with zero clicks. Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] xml sound : Does negative pitch work?
On Saturday, 26 February 2005 14:22, Erik Hofman wrote: There is one special condition, min is set to 0.0 as it's lowest value, so the only reason pitch can be clamped at the lower end is because it is really 0.0. Aha! That cured it - thanks Eric. Everything works perfectly now except the clicking of the looping tone. The clicking is not of a constant volume either, sometimes it's hard and sometimes soft. An ugly way of reducing it's annoyance factor is to just make the sample a lot longer - like a couple of minutes. :) Anyway I won't worry about it at the moment. Thanks Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] xml sound : Does negative pitch work?
I'm busy hooking up the sounds for a vario but can't get the sink tone to work. I'm using the vertical speed property to test against. Here is the my xml sound config for the sinking tone : audiocue namesinkcue/name modelooped/mode pathAircraft/LAK-19/Instruments/ILEC_SC-7/sink-tone.wav/path condition less-than property/instrumentation/vertical-speed-indicator/indicated-speed-fpm/property value-50/value /less-than /condition volume min0.3/min max0.3/max /volume pitch property/instrumentation/vertical-speed-indicator/indicated-speed-fpm/property factor0.001/factor offset1.0/offset /pitch /audiocue As you can see I've configured the tone to start playing when the vertical speed drops below -50 fpm. That works perfectly. However the pitch doesn't change - it loops (with an annoying click) and stays at a constant pitch regardless of what I throw at the pitch config. According to the docs the pitch is calculated like this when the factor is positive : value += factor[n] * function(property[n]) So if the indicated-speed-fpm = -300 and the factor = 0.001 the intermediate value for pitch should be equal to -0.3 (the default function is linear) The final calculation is value = offs + value With the offset = 1.0 the final value of the pitch should be 1.0 + (-0.3) = 0.7 This is not happening. BTW : There is a typo in the README.xmlsound doc. volume = offs + value; should read value = offs + value; since it's the same logic for both volume and pitch according to the doc. I also tried changing the factor to -1.0 which mathematically isn't what I want but it has no effect either! Am I doing something wrong or is something broken? Thanks Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Total Energy instrument
On Thursday, 24 February 2005 18:49, Alex Perry wrote: The easy non-software thing to do is to hook up a second VSI simulation to the pitot simulation instead of the static simulation. Then, take the VSI instrument and change the artwork to look like a vario and add a second rotation layer. The first rotation layer watches the normal VSI simulation, the second rotation layer watches the new pitot VSI except that it is cumulative to the first and in the other direction. Well I already have most of the artwork done - I just need a valid TE variable to plug into my needle animation. In the C++, I'd simply copy the altimeter code (which has both data sources) and the VSI code (which has the low pass filter and the like) and merge them into a new function. Other than that, there isn't much coding needed. Ok that sounds easy enough. I'll look into that when I reach that stage. Do you have all the information you need, or should I ask for help ? I'll yell for help when I get to the maths part. :) Thanks Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument headaches
On Wednesday, 23 February 2005 02:08, Roy Vegard Ovesen wrote: I would like to suggest a different approach. 1. Create a new Variometer instrument module i C++. Actually you might want to create a more generic Total Energy Tube module to add to the systems modules (static, pitot, vacuum, etc.). I urge you to try to model the Total Energy Tube principles as closely as possible. I found a basic description from a variometer manufacturer: If I was able to create a Total Energy Tube module it still leaves me without a way to perform calculations and logic that are vario specific. 2. The sound bit can be coded in C++ into the variometer instrument module. Are you now talking about a separate C++ instrument? I assume you are not referring to the Total Energy Tube module which can be generic in nature. So the way I see it is I need two C++ modules that need to be created and hooked into FG. How does one do that? Can I write shared libraries with a defined interface and get FG to load it when the panel references it? If there is a defined API for this stuff I'll manage but if it requires designing software architectures then I'm stuck. I think I'll rather fiddle around with the existing mess and leave the serious stuff up to the guys who have brains. I'm happy with the technology we use at the moment like the XML animations, sounds, nasal, etc. I just wish that the way things were hooked together was a bit more logical and cleaner. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument headaches
On Wednesday, 23 February 2005 00:07, Berndt, Jon S wrote: This is exactly the reason for one of the features being added for JSBSim in the next release: the ability to calculate arbitrary values based on parameters know within the FDM - especially things like you have described here: total energy. Flight management systems and displays are getting increasingly sophisticated. The next release of JSBSim includes the ability to specify functions using XML markup very similar to MathML. The result of the function would be available as a property to the instrument subsystem. Believe me, this approach that FlightGear uses - however complicated it may seem - is so much better than other approaches I have seen in flight simulation code. Like comparing night and day. That's good news. However I thought JSBSim was just a flight dynamics engine? Even if these features were added to an aircraft config file FG would still have to be modified so that instruments can also have their own separate config files otherwise you end up coding the instrument maths/logic into the aircraft config files all over again. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Total Energy instrument - Was Instrument headaches
On Wednesday, 23 February 2005 20:07, Alex Perry wrote: 1. Create a new Variometer instrument module i C++. If I was able to create a Total Energy Tube module it still leaves me without a way to perform calculations and logic that are vario specific. I'm an ASEL pilot (without glider training) but I was of the impression that the variometer was a slightly modified pitot tube connected to a VSI. That sounds about right. As far as I know one can hook up most variometers to any TE probe. However some electronic varios don't use a TE probe but rather a set of pressure transducers. What also differs between some designs which use a TE probe is the inclusion or exclusion of a flask that is used to average the reading out. Are you trying to simulate the aircraft instrument or are you trying to provide the same value as an expensive air data computer would yield ? I'm trying to simulate an aircraft instrument. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Instrument headaches
Hi guys I'm busy creating a variometer for FlightGear. My instrument needs to be able to : 1. Display total energy (using some maths I haven't figured out yet) 2. Play sounds (audio cue) 3. Accept user input to its 2 knobs and 3 toggle switches. From what I've seen in FG I would have to generate the total energy property from a nasal script, play the sounds from the aircraft XML file and accept the user input through the panel hot spot (actions) config file. I have one short word to describe this affair : Mess! :) Most of the instrument has to be coded into the aircraft config files (although none of it is aircraft model specific) and for every aircraft that I want to install the instrument in I would have to duplicate the sound, hot spots and nasal code. Is there not a better way of doing it? Also is there not a way to accept user input on a 3D instrument? I don't see the logic behind specifying hot spots using 2D panel *pixel* locations for a 3D model which is placed using 3D coordinates. Not to mention that as soon as I move my 3D instrument around in the cockpit the input is lost. Surely the input should be part and parcel of the instrument? The way I see it is an instrument should be able to have it's own set of animation, input and sound config files as well as nasal scripts. Then only a single include has to be done in an aircraft config file to load the instrument at the right location. Thanks Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172 C182 in CVS
Thanks - I was wading through that mess yesterday trying to figure out how it was all hanging together with its spaghetti of aliases and includes. Paul On Tuesday, 22 February 2005 21:00, Erik Hofman wrote: Erik Hofman wrote: The question is whether we want to keep all versions of the C172 or just a few (and if so, which could be removed)? Ok, nobody bothered so I made the decision: C172P/JSBSim 3d cockpit and JSBSim 2d panel versions C172R/JSBSim 3d cockpit C172-610/NULL highres panel All other versions have been removed (LaRCsim/YASim included). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear version 9.2 Help Request
On Wednesday, 16 February 2005 20:05, Geoffrey Frost wrote: Can I just replace the radio-medium.xml file with a .3ds model and get the same results? Geoffrey Frost No, the xml files are used to change attributes of models (animations, visual range, scale, etc) Here is a quick rundown on how to add a shared model to the current version of FlightGear - I'm not sure if this is applicable to 0.9.2 since I never ran that version and wouldn't have remembered anyway. :) Step 1 : Create a directory under the FlightGear data/Models directory. I'm going to use data/Models/MyModels as an example. Step 2 : Inside the data/Models/MyModels drirectory create an xml file called foomodel.xml with the following contents : ?xml version=1.0? PropertyList pathfoomodel.3ds/path animation typerange/type min-m0/min-m max-m25000/max-m /animation /PropertyList Step 3 : Create an 3ds model called foomodel.3ds and save it into the data/Models/MyModels directory. Notice that the xml file references the 3ds model file and tells FG that it must be visible from 0 meters up to 25 km. Step 4 : Start FG and fly (or use UFO model and move) to the location where you want to place the model. Open up the property browser in FG and write down the lat, lon and altitude where you want to place the model. (File-Browse Internal Properties-Position) Step 5 : In CVS there is a perl program called calc-tile.pl that works out what stg file a geodetic coordinate falls in. You can get it here if you don't feel like playing with CVS and don't have the CVS branch installed : http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/*checkout*/FlightGear/scripts/perl/scenery/calc-tile.pl?rev=HEADcvsroot=FlightGear-0.9content-type=text/x-perl Run the perl script in a terminal window passing it the longitude and latitude that you wrote down in step 4. You'll probably have to install perl first if you run on a MS OS's. Example : [EMAIL PROTECTED] scenery]$ ./calc-tile.pl -55.5 30.3 Longitude: -55.5 Latitude: 30.3 Tile: 2039314 Path: w060n30/w056n30/2039314.stg Step 6 : Open the corresponding stg file in your scenery directory (in my case SceneryDir/w060n30/w056n30/2039314.stg) Step 7 : Add the following lines to the stg file replacing the parameters with your own : OBJECT_SHARED Models/MyModels/foomodel.xml -55.5 30.3 1000.0 0.00 The format is : OBJECT_SHARED Relative path to model xml file lon lat altitude above wgs84 ellipsoid rotation/heading Step 8 : Start FG and fly to where you added the model and it should be there. Hope that helps Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery questions
I have a few questions regarding scenery building. First question : What datasets and parameters are used when building the global scenery? I want to be able to duplicate the scenery building process so that I get *exactly* what is released. For example what sort of max error is used when using TerraFit? Second question : Can I edit the datasets like VMAP0, the DEM and whatever else is used and submit the changes? For example KDCA looks like it's on a table top with small cliffs all around whereas in real life it's practically at river level. The only way to fix scenery problems is to fix the data that gives the problems. What I want to do is fix some data in the datasets, rebuild a scenery chunk and check the results. If I'm not happy repeat the process till the final product looks right. Then submit the dataset changes to be included in the next scenery release. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear CVS errors
Hermann Schiffer wrote: --opengl-headers Normally, installation does not install NVIDIA's OpenGL header files. This option enables installation of the NVIDIA OpenGL header files. The nVidia installer puts the header files under /usr/share/doc/NVIDIA_GLX-1.0/include/GL by default or where ever your distros documentation folder is. I just do a normal install and then copy them by hand to /usr/include/GL If you have all the mesa devel stuff installed it's unnecessary to use the nVidia headers although they won't hurt. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 01:44, Manuel Massing wrote: The real problem is that it's hard to get detailed textures for the whole world (and storage hungry!!). What I'd like to experiment with later on is to let a classifier run over the globally available 28.5m landsat textures, and use the resulting classifications to generate missing detail at runtime. But first things first... I don't see why we have to limit ourselves to *having* to have world coverage for the engine to be useful. This engine could be used to display synthetically generated textures which are pre-built along a specific flight path. One could build corridors of scenery from departure to destination before the flight or we could use the terrain engine to display synthetic scenery that is generated on the fly (like FS2004). Or people may have access to free photo scenery for their country or area and wish to use it for VFR flight or for familiarization of areas around an airport before going for a real flight. I think there is a mindset that one has to have all the scenery installed on hard disk which is a waste of space. How many people fly in all the countries of the world with FlightGear on a regular basis? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 12:54, Christian Mayer wrote: Manuel Massing schrieb: Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html There's still no open source alternative to jpg when it comes to storage size and storage is the major issue when dealing with lots of satellite or aerial photos. I did a test with the 18 century crop texture : JPG : 1024x1024 @ 85% quality = 508.4 KB PNG : 512x512 @ level 9 compression = 630.4 KB Four times higher resolution with hardly any noticable loss in quality (even when zoomed in) and it still comes out with a smaller footprint than a PNG that is 4 times lower resolution. Sometimes size does count. What do you suggest as a replacement to JPG that will give a similiar footprint size? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 13:49, Paul Surgeon wrote: On Saturday, 29 January 2005 12:54, Christian Mayer wrote: Manuel Massing schrieb: Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html There's still no open source alternative to jpg when it comes to storage size and storage is the major issue when dealing with lots of satellite or aerial photos. I did a test with the 18 century crop texture : JPG : 1024x1024 @ 85% quality = 508.4 KB PNG : 512x512 @ level 9 compression = 630.4 KB Four times higher resolution with hardly any noticable loss in quality (even when zoomed in) and it still comes out with a smaller footprint than a PNG that is 4 times lower resolution. Sometimes size does count. What do you suggest as a replacement to JPG that will give a similiar footprint size? Paul I am corrected once again ... Norman just pointed JPEG 2000 out to me which is open source (and royalty free for GPL projects) and far better than the standard JPEG most of us use. It uses state-of-the-art wavelet compression and some of the comparisons I've seen are incredible. It supports both lossless and lossy compression. Some comparisons : http://www.leadtools.com/SDK/Raster/Raster-Addon-JPEG2000-Example.htm http://www.geocities.com/ee00224/btp2.html It could be worthwhile looking into if we need to store large images. The SDK with source code is available at http://www.ermapper.com Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 15:10, Christian Mayer wrote: For normal photographs that's great - for textures that get scaled, projected, sheared (sp?), lit, ... the uses assumptions dodn't hold anymore. An extreme example: when you use a very high compression rate you'll see the blocking artefacts. So you use a not so high compression and are hapy with the result. If you zoom into the picture you'll start to see the blocking again as the pixels got large enough. When you use that picture as an texture and fly low enough you are basically zooming into the picture. Same problem as above. So JPEG isn't usefull. Who said we have to use high compression levels? A JPEG with 95% quality does not display ANY blocking artifacts whatsoever yet is still 1/4 the size of a compressed PNG. Even when viewed at 1600% i could still not spot any blocking or banding. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 19:39, Frederic Bouvier wrote: It is still true that JPEG have no alpha channel, so not all textures could be converted. There is no reason why the alpha channel cannot be shipped in a separate 8 bit bitmap of some sort with the JPEG just providing the color map. I've seen this done before to save space or bandwidth in commercial projects. It's really easy to combine the two images while loading them into RAM. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday, 28 January 2005 22:14, Manuel Massing wrote: I completely agree with you on the integration part. I think the engine is technically adequate for its intended purposes (i.e. satellite-textured landscapes). If you have any questions concerning the technical side, feel free to ask. I would love to see an alternative terrain engine that supports satellite/aerial images. I do have a few questions though : Does the current code that you have handle texture paging? What sort of texture resolutions will it be able to scale down to? (meters/pixel) How is the mipmapping handled (if it currently uses mipmaps)? What will the maximum visual range be? Are you using any sort of texture compression like S3TC/DXTC to save space in VRAM? In this light, its also important to see it as an alternative, not a replacement, for the current scenery, because each engine will have its own set of advantages and disadvantages. Yes, I'm sure there are plenty of users who are happy with the current scenery engine and one of the advantages it has is that there is no paging of huge textures while flying. This allows for high speed flights without any pausing and can also be run on older hardware or where CPU cycles are best used elsewhere like instrument updates or FDM's. Last time I tried a Mach 5 flight in FS2004 I ended up with blank/grey scenery tiles because it couldn't build and page the textures fast enough. :) For sub-sonic speeds and VFR flight an eye candy terrain engine would be very much appreciated. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
On Thursday, 27 January 2005 20:47, David Luff wrote: Note that the EGLL poly count is already hitting my frame rate to begin with - at daytime it's about 60 with view away from airport, 30 with view including airport. Then 10 with the lighting added. The frame rate with lighting enabled at EGLL is completely independent of anisotropic filtering, FSAA, or screen resolution - it's pegged solidly at 10. I guess it's either CPU or AGP bus limited - any way to try and find out / guess which? [AMD XP2000+, GF5900XT 128M, 4x AGP]. Is this with or without enhanced runway lighting enabled? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Airports
On Wednesday, 26 January 2005 17:44, Curtis L. Olson wrote: Fred is pondering/working on a more optimal solution for the next release. There are a number of good ideas he can try so I'm sure he'll come up with something that works quite well. :-) Does fgrun scan the scenery directories everytime it is run?! Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Runway lighting
I played around with some runway lighting today to see if textured polygons are feasible. Here is what textured, billboard runway lights look like : http://surgdom.hollosite.com/flightgear/screenshots/index.html With 6 * 1 ft runways all in view at one time my frame rate dropped from 50 down to 20 FPS on an old Ti 4200. I think 6 * 1 ft runways should pretty much cater for any large airport. That's close to 5000 runway lights. This is just a hardcoded test to see what the performance impact is if one uses a brute force approach with zero performance enhancements. One could probably cull in between lights beyond certain distances which would help performance and look a bit better from a distance. Also I'm not sure what sort of impact billboarding and distance scaling has on performance - it would probably be faster if I had fixed polygons. If my Ti4200 can do the job then I'm sure newer video cards like the nVidia FX 5700 and up should handle these lights quite nicely. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Airports
On Wednesday, 26 January 2005 20:28, Frederic Bouvier wrote: Quoting Paul Surgeon: On Wednesday, 26 January 2005 17:44, Curtis L. Olson wrote: Fred is pondering/working on a more optimal solution for the next release. There are a number of good ideas he can try so I'm sure he'll come up with something that works quite well. :-) Does fgrun scan the scenery directories everytime it is run?! Yes, and I hope to fix that soon. Still pondering. The approach I took for my airport selection code was : On first time startup, build a DB of installed airports and save to disk. Later on if the user installs more scenery they can click on the rebuild airport DB button. This way the loading is quick and one can filter out non-installed airports and/or flag them as not installed when displayed in a list. It works well for me but you maybe you can come up with a better approach. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Tuesday, 25 January 2005 10:33, Vivian Meazza wrote: Paul Surgeon wrote: On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: After reading the glPointSize doc, I think the problem is in using point sizes bigger than 1 and point antialiasing at the same time I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and see it there is an fps improvement Bingo! With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the same speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) Are there any unwanted effects elsewhere, or can this be used as a patch to our code? Well the endhanced lighting with GL_POINT_SMOOTH looks awful on my Ti 4200. Big square shaped polygons. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please use meaningful subject lines
But that breaks the message threading capabilites of mail readers which some people dislike. One ends up with 2 or 3 threads on the same topic and you have to jump between them. Paul On Tuesday, 25 January 2005 11:14, Thomas Förster wrote: Hi, with sometimes more than a hundred daily posts I'm far from reading them all. Usually I just glance over the subject, read some 2 or 3 posts from the start of a thread and then decide to ignore (or follow) it completely. Having now found out that e.g. under the subject 'fgrun improvements' things like frame rate drops for specific video cards, enhanced lighting at airports etc. were discussed makes me wonder what I have missed in other threads.. :-( So please, if you find that the topic of the post doesn't find the subject line, don't hesitate to change it. Probably in the form Topic YYY (was: Topic XXX). Or even better start a new thread. Thank you, Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Tuesday, 25 January 2005 12:11, you wrote: On Tuesday, 25 January 2005 10:33, Vivian Meazza wrote: Paul Surgeon wrote: On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: After reading the glPointSize doc, I think the problem is in using point sizes bigger than 1 and point antialiasing at the same time I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and see it there is an fps improvement Bingo! With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the same speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) Are there any unwanted effects elsewhere, or can this be used as a patch to our code? Well the endhanced lighting with GL_POINT_SMOOTH looks awful on my Ti 4200. Big square shaped polygons. Paul Oops! I meant enhanced runway lighting looks awful *WITHOUT* GL_POINT_SMOOTH enabled. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: AirportList
On Monday, 24 January 2005 10:48, Erik Hofman wrote: Maybe it's even a better idea to have a world map image where you can zoom in in three or four steps to select the desired airport? If someone could add ssgContext support or some way to render to a texture or window inside of FG I could add it within 2 weeks. I already have code that renders a textured WGS 84 ellipsoid in OpenGL with pan/zoom functionality. Adding airports to the globe with picker support would take no more than a day or two. The only issue is that I'm using rather large texture maps - it would take a bit more work to add vector maps. This issue of not being able to render to a sub window is coming back to bite us everytime. If it's not stuff like this then it's moving map/GPS/ND type instruments. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday, 24 January 2005 20:32, Curtis L. Olson wrote: The opengl interface itself (for a variety of good reasons) doesn't provide you a way to directly tell if something is implimented in hardware or software. Note that this isn't dropping your whole card into software rendering mode, it's just the specific things that aren't supported in hardware need to be done in software. There are two sides to the issue of having the api tell you whats done in hardware vs. software. Believe me, it's been debated by a lot smarter people than we have here. :-) OpenGL has chosen a certain way to do it (for valid reasons) so we need to make the best of it. But what we can do is check what type of video card or driver is being used and only allow that feature to be switched on if the hardware supports it. For instance my system returns : OpenGL vendor : NVIDIA Corporation OpenGL version : 1.5.2 NVIDIA 66.29 OpenGL renderer: GeForce4 Ti 4200 with AGP8X/AGP/SSE/3DNOW! If you need an SGI machine for the enhanced lighting then if you detect an nVidia or ATI string just disable the enhanced lighting or hide the option. Or alternatively check for an SGI string and if one is not found assume that the feature is not supported. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: After reading the glPointSize doc, I think the problem is in using point sizes bigger than 1 and point antialiasing at the same time I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and see it there is an fps improvement Bingo! With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the same speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FG GUI toolkits
Can someone comment on how FLTK works under OpenGL? Would it be possible to use FLTK and all it's nice widgets in FG and drop the rather crude PUI toolkit? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG GUI toolkits
On Sunday, 23 January 2005 16:07, Norman Vine wrote: Full screen mode is doable in FLTK http://fltk.org/documentation.php/doc-1.1/Fl_Window.html#Fl_Window.fullscre en From some of the messages I've read it seems as if it's not truly full screen - just a maximized window without any borders. Also note that it doesn't work with all window managers (maybe because it can't get them to hide their menu bars?) One guy did a test - he used SDL + FLTK. The SDL set up the full screen window but as soon as he tried to add a FLTK widget it flipped back into windowed mode. What a pity ... it would make coding a decent GUI for FG so much easier. It's a lot of work to write all those controls from scratch. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: AirportList
On Sunday, 23 January 2005 17:54, Andrew Midosn wrote: It might be more useful to be able to apply a filter to the list to reduce it in size. Probably filtering by state for the USA and by country for (most) of the rest of the world would be OK. Of course, we would have to have access to that information, which I don't think is available in apt.dat. I spoke to Robin Peel about this a couple of weeks ago. The country codes for airports are already Robin's database - in fact he uses them as part of the primary key. However he won't add it to the airport file because X-plane doesn't use them and Austin Meyer doesn't want anything in the apt.dat that is not X-Plane related. I feel that they should be added because they will prove to be very valuable for filtering but I haven't got enough weight to get them added. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] link to my homepage
On Saturday, 22 January 2005 13:01, Melchior FRANZ wrote: I hereby formally object to my name and my code contributions being dragged into potential religious conflicts, and to using them for proselytizing purposes. It's sad to see that the repeated calls for keeping political and other controversial stuff off FlightGear don't seem to apply any more. Please remove the link to my former flightgear page from http://www.flightgear.org/links.html (FlightGear: Support for joysticks with digital axes; which is quite outdated anyway) I'll happily join again, once flightgear treats all its users and developers again without distinction of any kind, such as race, colour, sex, language, *RELIGION*, political or other opinion, national or social origin, property, birth or other status. m. Is this the way things should go? Melchior is not the only person who find the current situation unacceptable. Maybe I should make a package with a file included that says : Kill all 'em Niggers and get it put up on the FlightGear site. I say pull the package in question. If the author wants to distribute it on his own site then that is fine with me but as it stands it looks like we endorse what is in that package. I'd rather upset one contributor than piss off the whole FG community. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Patch for : Input/Joysticks/Microsoft/sidewinder-force-feed-pro.xml
The rudder and throttle need swapping based on the OS just like the Sidewinder Precision Pro. Paul Index: Input/Joysticks/Microsoft/sidewinder-force-feed-pro.xml === RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/Microsoft/sidewinder-force-feed-pro.xml,v retrieving revision 1.3 diff -u -r1.3 sidewinder-force-feed-pro.xml --- Input/Joysticks/Microsoft/sidewinder-force-feed-pro.xml 12 Jan 2004 17:49:44 - 1.3 +++ Input/Joysticks/Microsoft/sidewinder-force-feed-pro.xml 22 Jan 2005 14:36:44 - @@ -46,8 +46,12 @@ /binding /axis - axis n=3 + axis descRudder/desc + number + unix2/unix + windows3/windows + /number binding commandproperty-scale/command property/controls/flight/rudder/property @@ -55,8 +59,12 @@ /binding /axis - axis n=2 + axis descThrottle/desc + number + unix3/unix + windows2/windows + /number binding commandproperty-scale/command property/controls/engines/engine[0]/throttle/property ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGMetar.cxx
On Saturday, 22 January 2005 18:09, Frederic Bouvier wrote: I would really like to sort this out and feel I am contributing in a small way to the project, but I'm not sure enough of what this code is trying to do. Sorry. You really have screwed your SimGear tree, if you think it is up to date. I think Frederic is right - your SimGear is messed up. I tried to compile FG a few minutes ago and initially got the same errors as you did. (rain, hail, snow undeclared). So I did a cvs update of SimGear compiled it, installed it and then FG compiled without any problems. I think you should start with fresh copy of SimGear. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Friday, 21 January 2005 14:59, Frederic Bouvier wrote: I forgot this one. It is not an improvement though, rather a fix ;-) The scenery scan is done every time and is very long although it is threaded and doesn't prevent you to launch flightgear. Curt suggested to show all the content of apt.dat.gz and check the availability afterward. I am now thinking to check only against the first level of directories to see if they lie in an existing 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base package ). And rely more on the refresh button already present than a systematic scan. Why not store the results of the scan and allow the user to rebuild the DB manually at a later stage? New users will 99% of the time run FG without installing extra scenery so the initial DB build will be VERY quick. Then when users add more scenery at a later stage they can build a new DB manually. I wrote this functionality into an app I was busy coding before I got sidetracked with other projects. http://surgdom.hollosite.com/flightgear/fg_central/index.html Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] v1.0 musings (was: Aircraft included in basepackage)
On Thursday, 20 January 2005 19:49, Giles Robertson wrote: 1) Fgrun/fgfs. For the average windows user, this is *highly* counterintuitive. In so far as Windows has an overarching user interface and tool design philosophy, it's integration. The concept of a GUI that launches the program doesn't make sense to them; they expect to be able to run flightgear, and for it to present a menu that reads something like New flight/Saved Flight/Options/Exit. I'm not saying this is the way we should go, but I'd like to note that many users, when presented with the current method, get *very* confused, especially by the absence of a flight planner. Many also find restarting FlightGear in order to change aircraft counterintuitive I couldn't agree more with the above. However I feel a launcher app will be successful if it is more tightly integrated with FG to the point where the user cannot distguish that they are two separate applications. I was busy writing a new launcher that would control FG through the Telnet interface including being able to flip between the launcher screen and FG screen automatically. This app would include aircraft selection, airport selection and a flight planner. Unfortunately I got side tracked by more interesting things like taxiway editors. :) I would like to add one more thing to the required list for 1.0 : We need errors to popup in a dialogue if FG is unhappy. Users keep coming to the IRC channel and they say that nothing happens when they launch FG. They have no idea that an error message is being displayed in file 13 and in a lot of cases they don't know how to run programs from a command prompt to get an error message or they run fgrun and still see no errors. Most of the potential user base will come from the Windows platform so we do need to make things easier for them even if our *nix roots scream otherwise. With those users will come artists, sound editing people, programmers, people with access to useful information, etc. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday, 20 January 2005 03:57, David Megginson wrote: You know, after reading some of the other comments, I'm starting to like the idea of having just the c172p in the base package. You should try helping clueless windows users to install scenery files in the IRC channel sometime. A lot of them need help to extract, copy and paste. I'd say yes if FG had an automated way of installing aircraft but till then I don't like the idea too much. It's just an extra step that can potentially cause more hassles and confusion. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
On Thursday, 20 January 2005 21:24, Arthur Wiebe wrote: Hi Everyone, In case you don't know I'm the one who created the distribution in question. First of all I believe that the contents of the RTF file should be welcomed by everyone, and I also believe they are true. But I also realize that it may be harmful to this project by turning people away from it. I am not a religious person but do believe Jesus Christ meant it when he said Go ye into all the world, and preach the gospel to every creature and saw this as another potential medium. What I will do and am in the process of doing is update the package to include this in an About.rtf file: The following contents have been included by Arthur Wiebe and may not reflect the views of any of the contributors or developers of the FlightGear project. O hope that satisfies this issue. I also believe the Bible when it says, If it be possible, as much as lieth in you, live peaceably with all men. By the way I am also going to fix the permissions issue at the same time. Arthur, I share the same beliefs as you do but I also feel that there are times and places which are not appropriate to share ones faith. For instance in an office environment where your employer is paying you to do a job - not saving souls. That would be stealing from your employer unless it was during a lunch break. Or for instance where people do not wish to hear your beliefs. Let people rather ask you instead of shoving it in their face. That only serves to alienate people instead of drawing them to Christ. When one reads the gospels you see in nearly every account that the gospel was preached to those who came on their own accord to listen. People went out to hear John the baptist yelling Repent! in the desert - John didn't go around bashing people doors down or dropping pamphlets in people's mail boxes. The same with Jesus - people came to him because he had something to offer. The few times he was confrontational was when he was challenging the religious leaders of the time for their hypocrisy. God gave Adam and Eve a free will to choose between good and evil and I certainly think he expects us to treat others the same way. That doesn't mean you have to respect what they believe but rather their choice to believe what they want to. I can't tell you how you should reach out to the lost around you but I do believe one should always do so in a PERSONAL capacity, always respecting the beliefs of those around you even if you think they are wrong and are on the way to hell. Whether you want to remove the file or not is your choice but just consider for a moment that a lot of people have put work into FG and they don't necessarily share the same beliefs. You may possibly be offending them by re-distributing their hard work with your beliefs. If I was a *radical* Muslim I would probably come and burn your house down. ;-) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
On Thursday, 20 January 2005 22:42, Curtis L. Olson wrote: Yes, most likely. I need to come up with a reasonably easy/compact/maintainable way to expose our mirrors directly so people don't have to wind their way through the mirror directory structure themselves to find what they need on the mirrors. I was about to bring this topic up because tonight a user on the IRC channel was battling to download the win32 0.9.8 binary. Can't we have direct links to the files on the mirrors much like other download sites? Example : Ready to Run Windows Binaries (Updated for v0.9.8) * Download the self extracting/installing fgsetup-0.9.8.exe. Mirror 1 : fgsetup-0.9.8.exe Mirror 2 : fgsetup-0.9.8.exe Mirror 3 : fgsetup-0.9.8.exe What about a BitTorrent download option as an alternate download source? BitTorrent is great for distributing large files efficiently. I'm more than willing to keep a BitTorrent client running serving up FG files (although I have a slow connection) and I'm sure there are others here who would do the same. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
On Friday, 21 January 2005 00:28, Martin Spott wrote: Paul Surgeon wrote: Can't we have direct links to the files on the mirrors much like other download sites? A few years ago the idea of a round-robin algorithm on the download page. Maybe it's time to reanimate this topic, Martin. Will the algorithm check the user limit and how many users are connected to a server before serving up the URL? There's no point in serving up a full server is there? A simple list of direct links will suffice in my opinion and be a lot easier to autogenerate from a script. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wednesday, 19 January 2005 22:05, Lee Elliott wrote: The control issue is more straightforward and it's easy to see how someone might get miffed if something they spent a lot of time making, so that they could give it away to people for free, is then used by someone else for their own profit, with no need to recompense the person who actually did the work. The GPL specifically allows this. LeeE This is a big issue with MSFS addons. For instance there are people who spend MONTHS filtering and editing sound recordings of aircraft to produce a sound package for a single aircraft. They do it for free and for the community. Then some scumbag comes along and collects a whole lot of these free contributions, removes the credits, labels them as his own work, puts them onto a CDs and sells them for $30 - 50 profit. This has happened several times (2 that I know of) in the MSFS community and the authors get irrate that someone is charging money and taking credit for what they freely gave to the community. Fortunately most of these works are copyrighted and not GPL and they managed to get lawyers involved and stop these pricks from carrying on their underhanded business. If the authors released their work as GPL those low lifes wouldn't even have to change the credits and what sort of recourse would the authors have then? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wednesday, 19 January 2005 23:28, David Megginson wrote: As I mentioned before, I also think that the user community will vote for the open source models with its feet (or, I guess, mice) and tend to stomp out others with social pressure or at least apathy. There is still place for non-GPL addons. There are guys who code addons for flightsimulators for a living and will not release their products under GPL otherwise someone can just copy it as much as they like and they don't get a cent in return. Sure GPL can work in some scenarios but if your market is 1000 copies and you charge $50 for your product you can't possibly afford to license your work as GPL and expect to keep food on the table for your kids to eat. It takes months of work with a team of 5 or 6 people to create one top notch aircraft like what Phoenix Software Simulations put out. GPL is not the be all and end all when it comes to software licensing although it is a nice license. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday, 18 January 2005 13:04, Durk Talsma wrote: So, are you suggesting we should do it ourselves and shift priorities? Work on glass cockpits Instead of creating 3D models, and FDMs? Doesn't sound like its gonna work. There are currently some really talented people working on 3D models, but these people are not necessarily great programmers. And the opposite is true as well. Good programmers might be lousy 3D modellers. So, shifting priorities wouldn't work here. I don't see why the 3D modelling people shouldn't continue to work on new models. My experience with FlightGear over the years has alway been that if there is something you can do *now*, that will benefit the program in the long run that do it[1]. Point taken - model away! :) I just find it frustrating when I start up a nice aircraft to find out that there no way to navigate the thing across open oceans. I don't think real world pilots use a magnetic compass to navigate where VOR's and NDB's don't live. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday, 18 January 2005 15:34, Innis Cunningham wrote: Paul what do you consider an empty cockpit, do you for instance consider the 747 an empty cockpit and if so what instruments do you think constitutes a populated cockpit. Primarily a working FMC/FMS and ND so that one can enter waypoints in the FMS and then navigate via the ND using compass, rose or arc modes. I think this is the most important thing to get working first. Overhead, pedestal and main panels with working switches so that from a pilot perspective the aircraft functions in a procedurally correct manner. Once we have about 30% of the above functionality I'll consider a cockpit as being not empty. :) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Monday, 17 January 2005 20:51, Christian Mayer wrote: When do we have a flyable A380? It can't be that Airbus was faster than we are: http://slashdot.org/articles/05/01/17/0437202.shtml?tid=126 When we can get the specs and no I don't just mean the shape of the aircraft. We already have too many empty 3D models in FG without working FMCs, FMSs, ECAMs, NDs, etc. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
I don't want to sound like someone who likes to nitpik but ... :) Is there any good reason to use PNGs for the thumbnails? There will be 60 aircraft thumbnails and we are averaging about 32K per thumbnail at the moment even with max PNG compression. That equates to nearly 2MB just for thumbnails. JPG can do it in 360K at 85% quality (average of 6KB per thumbnail) with no visual difference to the naked eye. I know PNG is lossless and JPG is evil because it's not LGPL but I think it's the right tool for the job (photos on web pages). Some of us don't have the luxury/option of high speed Internet connections and a 2MB web page takes 6 minutes to download on a 64K line. Paul On Monday, 17 January 2005 20:49, Curtis L. Olson wrote: For the upcoming release of FG, I'm working on a couple scripts to create/manage a web page for individual downloads. Here is where I'm at so far. There is plenty room for improvement, but this will at least get us started: http://www.flightgear.org/Downloads/aircraft/ If aircraft developers put a 171x128 pixel image in the top aicraft directory called thumbnail.png, this will automatically get picked up and put on the web page. There's no need to get these all populated before the v0.9.8 image, but it would be great if people could start filling thes in with nice pictures. The one's I created can be replaced if someone comes up with something better. Aircraft developers can continue to use our base package cvs, or they can maintain their files locally and submit a ready to install .tgz package ... either way will work fine. As part of this, I hope to significantly trim down the default base package. There are obvious areas of improvement such as categorizing the aircraft and putting them in their own sections (and we should do that eventually) but this at least is a workable starting point for this release. Regards, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Tuesday, 18 January 2005 00:32, Arthur Wiebe wrote: You can also lower the quality of PNG image as well as up the compression level. Doing so can make PNG's smaller than JPEG's. Now you've made me curious. I was using GIMP2 and set the compression to level 9 (max) How how does one lower the actual quality of a PNG if it's a lossless format? Must I convert it to an 8-bit image first before saving it as a PNG (or something like that) to throw away some info outside of the PNG format? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday, 18 January 2005 04:40, Ampere K. Hardraade wrote: On January 17, 2005 02:25 pm, Paul Surgeon wrote: We already have too many empty 3D models in FG without working FMCs, FMSs, ECAMs, NDs, etc. Paul It will be nice if you can implement these systems, perferablely by Nasal so that they can be flexible. Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. I don't think Nasal is the tool for the job. What I would need to create a aircraft with glass cockpits is : 1. A way to code self rendering OpenGL intruments. i.e. The renderer loops through the intruments and lets them do their own rendering. 2. A central processing blackbox that contains all the logic for the aircraft that also get's updated in the rendering loop. The blackbox will simulate/handle the hydraulic and electrical systems, generate and feed the display data to the intruments, handle the logic for failures, receive input from all the simulated aircraft sensors and cockpit switches, etc. There are far too many aircraft specific systems than could ever be handled by FG properly. An aircraft like this is a simulation of its own. How would I model for instance the ECAM switching on an A340 at the moment? The switches are located on the center pedestal but the displays are on the center panel. Would I have to add them to the properties tree? How do I control the logic of those switches? If there is a failure I must be able to override those switch settings and display the failure without changing the position of the switch. Then the pilot must be able to acknowledge and override (yet again) those failures on the display. How do I tell the PFD or ND to display the ECAM screens? (This can be done on real Airbus aircraft) How do I close solenoid X if switch A is in postion Z but hydraulic pressure is between 1000 and 1500 psi and there is a failure on the blue hydraulic system? FlightGear cannot and should not ever have to handle all these aircraft operating procedures. 3. A generic communications bus that can be used to hook instruments/switches and the blackbox together. Using a handful of sockets is not a good way to do it and properties maybe be a bit messy and I would require hundreds of them. Unfortunately this is going to sit on the backburner for a long time as it's tons of work to implement, I'm already too busy with other projects and I doubt anybody else would be willing to tackle it in the near future. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] more google adds
On Sunday, 16 January 2005 13:37, David Megginson wrote: The challenge is all their third-party and warez sites. If all of those sites are filtered out will there be any ads left to display? What will be left over? Simulator hardware (yokes, pedals, etc)? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport codes (was Re: plib-1.8.4_RC)
On Saturday, 15 January 2005 09:42, Chris Metzler wrote: On Sat, 15 Jan 2005 09:04:08 +0200 Paul Surgeon wrote: BTW: Is Robin going to give us a fixed airport db before we release 0.9.8? i.e. The appended K's to the FAA codes is not pretty and caught me out today. Can you elaborate on what you mean here? What is it that you're saying is broken, and why? The 3 letter FAA airport codes have been prepended with a K but they never used to be. e.g. C83 now equals KC83 Is this normal? Why the change? Are these official ICAO codes? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] plib-1.8.4_RC
On Friday, 14 January 2005 22:33, Curtis L. Olson wrote: Can we have a few people fetch this and build Flight/SimGear against this and report if things work well or if there are problems. Once plib-1.8.4 is out, I'd like to push forward with FlightGear-v0.9.8 I don't notice any obvious problems with it. BTW: Is Robin going to give us a fixed airport db before we release 0.9.8? i.e. The appended K's to the FAA codes is not pretty and caught me out today. I don't know if anyone else has noticed this but if you select a non-existent airport you get dropped back on 28R at KSFO with about a 30 degree offset to the runway and off to one side. I remember always being placed on 28R aligned and ready to go when it fell back to KSFO in the past. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Wednesday, 12 January 2005 10:29, Martin Spott wrote: One other possibility you might wanna consider is allowing uploads/ dloads of terrain (e.g. tiles modified through fgsd). This is not as easy as it sounds because you'd have to redo the tiles on every scenery update. The right way to incorporate manual scenery changes would be to parametrize these changes and provide a method to add them to the automatic scenery build. Ideally all changes made to the terrain should be done at the source. i.e. VMAP0 and friends fgsd should be able to display, edit and save the vector data then use the terrgear generation tools to build the new tile and display the results. One could have a live online central repository (db) that handles the storage. fgsd can connect, request a tile of vector data for editing (The db can do some sort of locking on that tile to avoid simultaneous edits) Once the user is finished they upload the changes for everyone to use. Then when Curt builds the new scenery he just requests all the data from the updated DB. Simple stuff. Now who's going to write it? :P Seriously though a system like this would be cutting edge in comparison to the MSFS route of having every author releasing their little updates which have to be downloaded and installed piece-by-piece with no garauntees that there will be no conflicts between various authors. And boy-oh-boy do the MSFS community have problems with scenery conflicts! BTW : Does anyone know of a free VMAP0 editor for Linux? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Wednesday, 12 January 2005 22:26, Martin Spott wrote: As I already wrote we are heading for some sort of GIS application here. Storage for VMAP0 data - at least parts of it, I don't know all types of data that are covered by VMAP0 - could be the accomplished by the mentioned PostgreSQL/PostGIS database. Visualization of such data is easily done with QGIS, although for editing according to elevation data we'd need another tool. A PostGIS interface in FGSD might be a solution, but I don't think FGSD is currently capable of handlint this sort of vector data at all (I might be proven to be wrong here). We don't want a VMAP0-editor here, let's stick to standard interfaces and formats wherever possible, otherwise we are going to manouvre into a corner very soon, Ok, I see your point about not wanting to handle VMAP type directly in fgsd. Probably to first step is to write the code/scripts to load the vector data into a PostgreSQL/PostGIS DB and write an exporter for terragear so that Curt can carry on generating scenery without having to modify terragear. It would also be really handy to have a scaled down vector database (shapefiles?) in FG for moving map/GPS units as well as a basemap for flightplanners. I played with some of the terrgear tools yesterday but unfortunately they just spit out raw shape data without the associated names, descriptions, etc. which are required in maps. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Budget 'display-only' system?
On Saturday, 8 January 2005 14:02, Dave Martin wrote: Target: 1024x768x32bpp / 35fps. AMD Sempron 2200 (1.5Ghz 333FSB, 256kb cache 32bit) 256MB PC2700 DDR GeForce FX5200 128MB (128bit mem bus) What do you think? Could the above system make the target res / fps or does it need more ram / better gpu / cpu etc? The FX5200 is the weakest link but it should do the job. I'm getting at least 30 FPS at SFO on a similar system. Normally my frame rates are between 40 and 50 FPS. AMD AthlonXP 2000+ (1.67 Ghz; 266 MHz FSB; L1/128K L2/256K) 256MB PC3200 (DDR400) Geforce Ti 4200 128MB BTW : 35 fps is pretty high - I found that 25 fps is still smooth enough unless you're doing barrel rolls at 360 degrees per second. What I can't figure out is why people insist on running FG on ancient *nix boxes at 3fps when they can get a really cheap PeeCee that will do the job 10 times faster. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
