Re: [Flightgear-devel] How to change minimum distance to activate next waypoint?
My observations are similar to this. However, I don't think that it's a problem with the accuracy of the calculations as such. The route manager code is relatively old and tries to set a straight course to it's next waypoint. It doesn't consider the wind blowing the aircraft off its lateral track. The autopilot tries to compensate by keeping the aircraft on a heading straight to the next waypoint. Now, as we get closer, this happens at an increasingly greater rate, until the rate of required course adjustment exceeds maximum turn-rate. I've seen a few occasions where the 747 couldn't reach the next waypoint because of this phenomenon and started flying around it in endless circles, until I manually popped it. Cheers, Durk On Saturday 05 June 2004 03:28, Ampere K. Hardraade wrote: The violent maneuvers I was describing occur when the plane is a few kilometers away from the waypoint. Therefore, it should have little to do with the way that pid controller reacts to the jump in waypoints. One explanation for the violent maneuvers that I thought of is this: as the distance between the plane and the waypoint decreases, the accuracy required in the course calculations increases. Since it takes time for the autopilot to respond, and takes even more time for the plane itself to respond to the commands of the autopilot, the plane will never align itself perfectly with the waypoint. Hence, the autopilot will keep trying to catch the waypoint until the very last moment, thus causing the violent maneuvers. One solutions to the above problem is to pop the waypoint when the plane is still some distance away, thereby preventing the autopilot from making all those course adjustments. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs CVS: build a breeze! running gives OpenAL errors galore.
Lee Elliott wrote: On Saturday 05 June 2004 00:20, Chris Metzler wrote: OK, I finally got a big block of time to commit to building plib, SimGear, and FlightGear from CVS, only to find that I didn't need it. I was expecting to have to solve lots of problems; instead, the builds went like a breeze. No problems at all. Unfortunately, running it was problematic. I guess between version 0.9.4 in Debian testing/unstable and the current CVS, sound was switched to OpenAL. I ran into one problem and one oddity: 1. constant pops, crackles, etc., while error messages of the form } Oops AL error in sample set_volume()! 1.3 for /home/cmetzler/Projects/FlightGear-0.9//data/Sounds/coughing.wav scroll up the screen by the score. I don't know anything about OpenAL; but I'm surprised to have sound problems, since this is a system that's been built/tuned for doing audio work, with Robert Love/Andrew Morton's patches in place and a lot of latency testing done. 2. the c172 sound in the cockpit is very different from outside it. From a view outside the cockpit, it sounds like it did in version 0.9.4. But from the cockpit view, it has a high pitch and more distorted-sounding noise. This may be intentional; maybe cockpit noise really does differ in such a way (I only wish I was a pilot). But I figured I'd check anyway. Any advice, especially on #1, would really be appreciated. Thanks. -c I think #1 is due to the volume scaling set up in the corresponding sound.xml config - it looks like the volume level that's generated is 1. I had this with all the a/c I've done when the OpenAL switch occurred and had to adjust the sound configs to ensure that the max volume wouldn't exceed 1. Yes, that's correct. Some one has to go through all (or at least the most important) sound configuration files to update the files. Probably of most importance is the default aircraft. For #2, there were some sound changes to the c172 sound file to try to mimic the difference between internal and external sounds for at least the c172. The changes were made prior to switching to OpenAL though, so that might needs some more attention also. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new world scenery build
Curtis L. Olson wrote: We should probably start thinking seriously about doing our next FlightGear release soon so that we can have an official release out there that can take advantage of some of the new scenery features. While I agree with you we should be careful with this release because of some major changes to the code base. Switching to OpenAL still has some lingering glitches to solve, the AIModel (and AITraffic) code has had a lot of updates which quite frankly didn't make FlightGear any faster. So we might want to think about limiting the demo scenario, and possibly disabling the Traffic code for this release. BTW. The radio towers really make the scenery come alive! It's a very nice build this time. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SID, STAR, and airway data
On Sun, 30 May 2004 21:58:12 +0200 Durk Talsma wrote: I hadn't really thought about that so much. However, while these SIDs and STARs wouldn't be very useful for AI traffic, they probably wouldn't be too problematic either. As long as there is an initial and a final waypoint, the expect vectors would then simply be the most direct route between these two. More precisely, you can define some arbitrary waypoints. For instance, if the SID says climb to zzz ft, you can determine the point (distance) at which the aircraft reaches that altitude, and have it marked as a waypoint in the internal AI flight plan. The next waypoint would then be the first en-route waypoint. Likewise, if the STAR says expect vectors, and if you are supposed to go for an instrument final approach, you can safely assume that ATC will try and vector you to a point approximately 4-6NM before the Final Approach Point, on the same axis as the final approach. I'm currently again leaning more toward a straight-in straight-out take on AI traffic as the first step, because that would simplify automatic flight plan/waypoint generation by quite a bit. Then next, if we have the data available on approach and departure procedures, these could be used instead. And that's more or less the way it works in real life, usually the first step is writing the flight plan, and for this you usually try and find SID and STAR flight paths. If you can't find them, you fall back on direct-to-waypoint-type paths. A good thing to do would be to try and implement the way ATC works as close to real life as possible. You can define these default flight plans for AI aircraft, and implement a clearance limit, which means that the aircraft can follow the flight plan safely up to a given point (usually a waypoint); you can also have altitude clearance (usually in order to avoid other traffic). Before reaching a clearance, an AI aircraft could ask for further directions/clearance from the ATC. If the ATC has a radar, it can detect that the aircraft is approaching the limit and give further directions without having to be asked for them. You might be interested in the rules of ATC (traffic separation using time or distance or altitude), most of it should be in the ICAO document . I don't know where to get it, but I had been given one while I was preparing for the ATPL theory exam. I did a little search with Google, and apparently the document (official title Procedures for Air Navigation Services - Air Traffic Management or PANS-ATM, ICAO document number ) is for sale for $161 on the ICAO website... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Linspire to provide FlightGear binaries
Hi, I just received the Linspire weekly mailing and they now provide binaries for Linspire users for free at: http://info.linspire.com/mailers/ww/02-0504.html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linspire to provide FlightGear binaries
Erik Hofman wrote: Hi, I just received the Linspire weekly mailing and they now provide binaries for Linspire users for free at: http://info.linspire.com/mailers/ww/02-0504.html Looking at the changes they made I think it would be a good idea to incorporate most of them in FlightGear: http://www.linspire.com/lindows_products_details.php?id=1671pg=specs Does anybody have any objections? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 00:25, Lee Elliott wrote: This might be due to the ordering of the transparent objects relative to the non-transparent parts. Is/are the model objects in .AC format? I use Blender, and export to .AC format. If so (I don't know if this also applies to other object formats such as .3DS) try moving the transparent parts to the bottom of the object hierarchy/list. How do I do that? Editing the .AC file with a text editor? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
Roy Vegard Ovesen wrote: If so (I don't know if this also applies to other object formats such as .3DS) try moving the transparent parts to the bottom of the object hierarchy/list. How do I do that? Editing the .AC file with a text editor? In AC3D I can trick the program in doing that by selecting just one object and select merge. I don't know if other editors behave similarly. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: King Air cockpit progress (and question)
* Roy Vegard Ovesen -- Saturday 05 June 2004 11:10:
On Saturday 05 June 2004 00:25, Lee Elliott wrote:
try moving the transparent parts to the bottom of the object
hierarchy/list.
How do I do that? Editing the .AC file with a text editor?
Either that, but I prefer to let the computer do the boring stuff. A simple Perl
script (attached) sorts all objects (to make diffs smaller) and puts the listed
ones at the top. It is called from a Makefile that does also modify the material
entries etc.
I call it like this for the bo105:
cat ${AC}|ac3d-sort shadow_fuselage shadow_rotor strobe_halo_T strobe_halo_B \
beacon_halo_T beacon_halo_Bf beacon_halo_B nav_halo_L \
nav_halo_R tailrotor ${AC}.tmp mv ${AC}.tmp ${AC}
The sctips doesn't work for *.ac files with object groups, though. (Which isn't a
problem, as Blender doesn't export groups, anyway.)
m.
ac3d-sort
Description: Perl program
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 04:08, Ampere K. Hardraade wrote: I don't know how things are done in other 3D modelling softwares, but in 3D Studio, each effect has a seperated mapping channel. For example, if you want transparency in certain areas of a texture, you need to assign a map to the transparency channel of that texture inorder for those certain portions of the latter to possess true transparency. Usually, the map can be the same file as the texture itself, though you have to play around with the options a bit so that the transparency is based on the Alpha instead of RGB. Check this out: http://waylon-art.com/uvw_tutorial/tut401_a.jpg Notice the various mapping channels: ambient, diffuse, specular color, specular level, glossiness, self illumination; the list is quite long. As I said, I don't know how things are done in other 3D modelling softwares. Your best bet will be looking for the dialog box that allows you to apply different effects to a texture in the 3D modelling software that you are using. In Blender one can select, at least, opaque or alpha, but I guess that this does not get carried through in the export to AC3D format. AC3D uses alpha. But as you can see from the screenshot the holes _are_ transparent because you can see the other panel texture through it.But you can't see the gauge face texture through it. The difference between the other panel texture and the gauge face texture is that the panel texture is part of the plane 3d model, and the gauge face texture is included to the model through the model xml config file. I suspect that this is what is causing the problem. Regards, Ampere On June 4, 2004 06:25 pm, Lee Elliott wrote: On Friday 04 June 2004 21:44, Roy Vegard Ovesen wrote: Here is a shot of the King Air cockpit i'm modeling: http://home.tiscali.no/rvovesen/king-air-cockpit.jpg Also I have a question: The fuel panel texture on the left has two semi circles that have alpha 0% (transparent) in order to show fuel level gauges that are supposed to be placed slightly behind the panel. The fuel level gauge that is visible on the right side of the fuel panel actually has a textured face, but it is not visible through the transparent semi circle. Note that the Fuel system circuit breakers panel texture is visible through the transparent semi circle. The fuel level gauge has been included in the model xml file as a model tag. Could this be the reason why the gauge face texture is not visible? I believe David Megginson's Piper cockpit uses the same technique: A panel texture with transparent holes and instruments behind those holes, so I guess it should be possible. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
Roy Vegard Ovesen said: Here is a shot of the King Air cockpit i'm modeling: http://home.tiscali.no/rvovesen/king-air-cockpit.jpg Also I have a question: The fuel panel texture on the left has two semi circles that have alpha 0% (transparent) in order to show fuel level gauges that are supposed to be placed slightly behind the panel. The fuel level gauge that is visible on the right side of the fuel panel actually has a textured face, but it is not visible through the transparent semi circle. Note that the Fuel system circuit breakers panel texture is visible through the transparent semi circle. The fuel level gauge has been included in the model xml file as a model tag. Could this be the reason why the gauge face texture is not visible? I believe David Megginson's Piper cockpit uses the same technique: A panel texture with transparent holes and instruments behind those holes, so I guess it should be possible. So far this cockpit is really looking great! Very nice work on the control box. Scanning the other responses, I don't think this has been answered yet (sorry if it has). If your fuel panel is part of the main model, then it should be lower on the stack and what you expect should be working. However, I think this might be affected by a select animation especially if the fuel panel is grouped with objects like the fuel guage models (or other animations, but I assume the only animation on a fuel panel would be select). In any case the problem isn't going to be solved by changing texture/polygon/color properties. That hole looks sufficiently transparent to me :-) If none of this helps, then send your models and configs and I'll take a look. That wouldn't be until Sunday night at the earliest, because of a trip down to Portland. FWIW when modeling flat panels with bezeled guages I'm not sure there is any advantage to using this method unless there's something specific being modeled below the panel surface (e.g. certain mag compasses). For example on the p51d and the cub it isn't all that obvious that the faces aren't below the surface. On the other hand you may need this method for that side fuel panel, because it is so close...not sure. I guess I would always try it without the transparency to see what looks like first. Keep in mind that there is a performance cost to rendering things through a transparency. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172 autopilot
On Thu, 27 May 2004 17:00:17 -0400 David Megginson wrote: shammake wrote: Has anyone tried taking the c172 autopilot and converting it into a graphical representation? For possible use into Simulink? Do you mean creating a 2D or 3D instrument? Actually, I think he meant a graphical representation of the algorithms used, with boxes and links... Examples of simulink uses: http://www.ecpsystems.com/subPageImages/rtlt_sim_download.gif http://www.mathworks.com/cmsimages/sl_mainimage_wl_4221.gif http://www.mathworks.com/products/demos/stateflow/sfcar.jpg http://www.mathworks.com/products/demos/stateflow/sf_electrohydraulic.jpg -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to change minimum distance to activate next waypoint?
All these issues are a matter of adjusting the autopilot coefficients to specific aircraft dynamic characteristics. In order to avoid the spiral into waypoint problem, you should try and implement something like this: compute a track to the waypoint from the present position, memorize it, and subsequently correct the trajectory so as to remain on that track (not heading). It's also better to correct this by using a lateral error (distance to the memorized track, not only angle), which makes these corrections independent from the distance to the waypoint. The inputs are: aircraft track (not heading, or you have to allow for a difference between held heading and desired track), desired track, lateral error. The output is a rate of turn. The pop waypoint condition is more efficient this way: aircraft beyond a line orthogonal to the desired track to the waypoint, and located at a distance 'd' from the waypoint (see diagram attached). In real-life IFR, if you are flying a non-RNAV aircraft, you're actually supposed to overfly the waypoints. I know, it sounded weird to me too. Of course, no one will really scold you if you manage to nicely anticipate the turn in order to find yourself just on track to the next waypoint. RNAV aircraft are supposed to anticipate every turn so as not to overshoot airways. -- Jorge Van Hemelryck attachment: nextwp.png___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does Flight Gear Support Multiple Aircraft
On Fri, 28 May 2004 11:00:47 -0400 shammake wrote: being simulated at once. For instance, if you wanted to show Aerial Re-fueling, with a 747 tanker, and a UAV? What exactly do you have in mind ? Actually, there are several ways to see other aircraft in your FlightGear. There are AI aircraft (work in progress, ask David Megginson and David Culp), or if you want aircraft with actual FDMs, you can have other FlightGear programs running on other computers and connected to your own computer via the network for instance (multiplayer mode). Or you can have external FDMs controlling 3D models on your computer (a little bit more complicated). -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linspire to provide FlightGear binaries
On Saturday 05 June 2004 09:43, Erik Hofman wrote: Erik Hofman wrote: Hi, I just received the Linspire weekly mailing and they now provide binaries for Linspire users for free at: http://info.linspire.com/mailers/ww/02-0504.html Looking at the changes they made I think it would be a good idea to incorporate most of them in FlightGear: http://www.linspire.com/lindows_products_details.php?id=1671pg=specs Does anybody have any objections? Erik What changes are you referring to? I couldn't see any on those links. I was a bit amused to see them call the Piper Cub a 'Cessna' and the 1903 Wright Flyer an old school biplane :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: King Air cockpit progress (and question)
Melchior FRANZ wrote:
* Roy Vegard Ovesen -- Saturday 05 June 2004 11:10:
On Saturday 05 June 2004 00:25, Lee Elliott wrote:
try moving the transparent parts to the bottom of the object
hierarchy/list.
How do I do that? Editing the .AC file with a text editor?
Either that, but I prefer to let the computer do the boring stuff. A simple Perl
script (attached) sorts all objects (to make diffs smaller) and puts the listed
ones at the top. It is called from a Makefile that does also modify the material
entries etc.
I call it like this for the bo105:
cat ${AC}|ac3d-sort shadow_fuselage shadow_rotor strobe_halo_T strobe_halo_B \
beacon_halo_T beacon_halo_Bf beacon_halo_B nav_halo_L \
nav_halo_R tailrotor ${AC}.tmp mv ${AC}.tmp ${AC}
The sctips doesn't work for *.ac files with object groups, though. (Which isn't a
problem, as Blender doesn't export groups, anyway.)
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Actually, it does. All you have to do is parent objects under and empty, and
the empty becomes the group in the .ac file. It's worth reading the comments at
the start of the python export script, it can do a few other tricks as well.
Josh
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
Roy Vegard Ovesen wrote: On Saturday 05 June 2004 00:25, Lee Elliott wrote: This might be due to the ordering of the transparent objects relative to the non-transparent parts. Is/are the model objects in .AC format? I use Blender, and export to .AC format. If so (I don't know if this also applies to other object formats such as .3DS) try moving the transparent parts to the bottom of the object hierarchy/list. How do I do that? Editing the .AC file with a text editor? I recently discovered that you can do that in the .xml animation file using the 'null' animation type. If you have in your model say Object1, Object2 and Object3 and want this order reversed, just add : animation object-nameObject3/object-name object-nameObject2/object-name object-nameObject1/object-name /animation and each mentionned object will be reparented and reordered. You can also have : animation nameNewSubBranch/name object-nameObject3/object-name object-nameObject1/object-name /animation animation object-nameObject2/object-name object-nameNewSubBranch/object-name /animation to make new sub branches if you want to without the need to create an 'empty' object with Blender. You can have a look at ggb-fb.xml. At the end, there is : !-- Transparency fix branch -- animation object-nameBridge/object-name object-nameSolidLights/object-name object-nameStreetNightLights/object-name /animation Bridge will be drawn first, then SolidLights will be blended with Bridge, and finally, StreetNightLights will be blended with the first 2, without z fighting, and no matter blender will rearange them in the .blend file or in the generated .ac file. I also used that trick in sutro-fb.xml Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: King Air cockpit progress (and question)
* Josh Babcock -- Saturday 05 June 2004 19:10: Melchior FRANZ wrote: The sctips doesn't work for *.ac files with object groups, though. (Which isn't a problem, as Blender doesn't export groups, anyway.) Actually, it does. All you have to do is parent objects under and empty, and the empty becomes the group in the .ac file. It's worth reading the comments at the start of the python export script, it can do a few other tricks as well. OK. I've never really used groups. At least the python importer doesn't handle them correctly. It messes up all group/object names. So, if you import the Hunter and export it again there are no groups or wrong object names. FlightGear didn't like that and preferred to crash. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new world scenery build
Curtis L. Olson wrote: I'm pretty close to being finished with the new world scenery build. A quick check with du shows that the previous build consumed 11.7 Gb (extracted.) The new build consumes about 17.8 Gb extracted, which is about 50% larger. I haven't had a chance to look closely, but I believe much of this increase is due to the much higher terrain resolution for europe, asia, africa, and south america. I have just started building tarballs of the 10x10 degree chunks a few minutes ago. I'm guessing this will run a while. In the mean time you can rsync or terrasync the latest scenery from scenery.flightgear.org::Scenery-0.9.5 We should probably start thinking seriously about doing our next FlightGear release soon so that we can have an official release out there that can take advantage of some of the new scenery features. Regards, Curt. Hmm, I did this: [EMAIL PROTECTED] FlightGear]$ rsync -r scenery.flightgear.org::Scenery-0.9.5 @ERROR: Unknown module 'Scenery-0.9.5' rsync: connection unexpectedly closed (51 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(150) Has anyone successfully grabbed these files? Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new world scenery build
Oops, you are right. I have fixed the configuration on the server. I also updated the default module in cvs terrasync.cxx. Regards, Curt. Josh Babcock wrote: Curtis L. Olson wrote: I'm pretty close to being finished with the new world scenery build. A quick check with du shows that the previous build consumed 11.7 Gb (extracted.) The new build consumes about 17.8 Gb extracted, which is about 50% larger. I haven't had a chance to look closely, but I believe much of this increase is due to the much higher terrain resolution for europe, asia, africa, and south america. I have just started building tarballs of the 10x10 degree chunks a few minutes ago. I'm guessing this will run a while. In the mean time you can rsync or terrasync the latest scenery from scenery.flightgear.org::Scenery-0.9.5 We should probably start thinking seriously about doing our next FlightGear release soon so that we can have an official release out there that can take advantage of some of the new scenery features. Regards, Curt. Hmm, I did this: [EMAIL PROTECTED] FlightGear]$ rsync -r scenery.flightgear.org::Scenery-0.9.5 @ERROR: Unknown module 'Scenery-0.9.5' rsync: connection unexpectedly closed (51 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(150) Has anyone successfully grabbed these files? Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] bump map clouds
How do I turn off the bump mapped cloud feature? Under some conditions it looks great, and other times it looks horrible. I'd like to turn it off to compare. Here's what I'm seeing right now at KSFO: http://www.flightgear.org/~curt/tmp/clouds.jpg Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 14:16, Jim Wilson wrote: So far this cockpit is really looking great! Very nice work on the control box. Thanks. I found some very detailed close-up photos of a cockpit that I've recreated with a vector drawing program (OpenOffice Draw). Scanning the other responses, I don't think this has been answered yet (sorry if it has). If your fuel panel is part of the main model, then it should be lower on the stack and what you expect should be working. However, I think this might be affected by a select animation especially if the fuel panel is grouped with objects like the fuel guage models (or other animations, but I assume the only animation on a fuel panel would be select). In any case the problem isn't going to be solved by changing texture/polygon/color properties. That hole looks sufficiently transparent to me :-) Frederic's solution to change the order using select animation in the xml file worked great. I also think that that was by far the most attractive solution too. Thanks Fred. I suspect that moving the fuel panel all the way to the bottom of the of the AC model file would not have worked. When including the fuel level gauge as another AC model, it would be placed below everything else anyway, right? If none of this helps, then send your models and configs and I'll take a look. That wouldn't be until Sunday night at the earliest, because of a trip down to Portland. FWIW when modeling flat panels with bezeled guages I'm not sure there is any advantage to using this method unless there's something specific being modeled below the panel surface (e.g. certain mag compasses). For example on the p51d and the cub it isn't all that obvious that the faces aren't below the surface. On the other hand you may need this method for that side fuel panel, because it is so close...not sure. I guess I would always try it without the transparency to see what looks like first. Keep in mind that there is a performance cost to rendering things through a transparency. Is there perhaps a difference when using a perfectly transparent er... transparency and a semi-transparent transparency, performance wise?! I've also thought about using a textured needle instead of an object colored one. The textured one might look a lot better with variable alpha creating an anti-alias effect, but I'm concerned about performance. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] King Air cockpit progress (and question)
On Saturday 05 June 2004 21:34, Roy Vegard Ovesen wrote: Frederic's solution to change the order using select animation in the xml file worked great. Ooops! That wasn't select animation it was just null animation or whatever I should call it. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: bump map clouds
Curtis L. Olson [EMAIL PROTECTED] writes: How do I turn off the bump mapped cloud feature? Under some conditions it looks great, and other times it looks horrible. I'd like to turn it off to compare. Here's what I'm seeing right now at KSFO: http://www.flightgear.org/~curt/tmp/clouds.jpg i see the same thing (only on my desktop with an nvidia card. on my laptop with an ati card i don't see it at all) but setting /sim/rendering/bump-mapping=false didn't help. i actually starting seeing this when some recent changes to the cloud rendering were made, but i can't find the cvs commit message to know what to revert. maybe erik can help since i am pretty sure it was his commit. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: bump map clouds
Alex Romosan wrote: Curtis L. Olson [EMAIL PROTECTED] writes: How do I turn off the bump mapped cloud feature? Under some conditions it looks great, and other times it looks horrible. I'd like to turn it off to compare. Here's what I'm seeing right now at KSFO: http://www.flightgear.org/~curt/tmp/clouds.jpg i see the same thing (only on my desktop with an nvidia card. on my laptop with an ati card i don't see it at all) but setting /sim/rendering/bump-mapping=false didn't help. i actually starting seeing this when some recent changes to the cloud rendering were made, but i can't find the cvs commit message to know what to revert. maybe erik can help since i am pretty sure it was his commit. I am surprised --prop:/sim/rendering/bump-mapping=false don't work for you. I am also able to turn it on and off with the property browser during flight. The default value is set in fg_init.cxx. Search bump-mapping in that file. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linspire to provide FlightGear binaries
Lee Elliott wrote: What changes are you referring to? I couldn't see any on those links. There is a link further down the page while links to a diff near Link to Source Code I was a bit amused to see them call the Piper Cub a 'Cessna' and the 1903 Wright Flyer an old school biplane :) Yeah, I noticed that too :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: bump map clouds
Frederic Bouvier [EMAIL PROTECTED] writes: I am surprised --prop:/sim/rendering/bump-mapping=false don't work for you. I am also able to turn it on and off with the property browser during flight. it turns the bump mapping off but the ugly clouds are still there. i am convinced it has something to do with some other cloud rendering changes. this all started to happen with a 2 line commit, or something like that. i've been trying to track it down. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linspire to provide FlightGear binaries
On Saturday 05 June 2004 22:36, Erik Hofman wrote: Lee Elliott wrote: What changes are you referring to? I couldn't see any on those links. There is a link further down the page while links to a diff near Link to Source Code Ah - right! - found it. Most of it was over my head though:) Hmm... possible name for the news letter perhaps;) I was a bit amused to see them call the Piper Cub a 'Cessna' and the 1903 Wright Flyer an old school biplane :) Yeah, I noticed that too :-) Erik LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linspire to provide FlightGear binaries
Lee Elliott wrote: On Saturday 05 June 2004 22:36, Erik Hofman wrote: Lee Elliott wrote: What changes are you referring to? I couldn't see any on those links. There is a link further down the page while links to a diff near Link to Source Code Ah - right! - found it. Most of it was over my head though:) Hmm... possible name for the news letter perhaps;) What, Linspire? Flinspire? How about Slipping the Surly Bonds ... ... of proprietary software. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linspire to provide FlightGear binaries
On Saturday 05 June 2004 23:48, Curtis L. Olson wrote: Lee Elliott wrote: On Saturday 05 June 2004 22:36, Erik Hofman wrote: Lee Elliott wrote: What changes are you referring to? I couldn't see any on those links. There is a link further down the page while links to a diff near Link to Source Code Ah - right! - found it. Most of it was over my head though:) Hmm... possible name for the news letter perhaps;) What, Linspire? Flinspire? How about Slipping the Surly Bonds ... ... of proprietary software. Curt. Nonononono:) I meant 'Over my head' :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Linspire to provide FlightGear binaries
LOL... got to love instance inspiration. :P Regards, Ampere On June 6, 2004 12:28 am, Lee Elliott wrote: On Saturday 05 June 2004 23:48, Curtis L. Olson wrote: Lee Elliott wrote: On Saturday 05 June 2004 22:36, Erik Hofman wrote: Lee Elliott wrote: What changes are you referring to? I couldn't see any on those links. There is a link further down the page while links to a diff near Link to Source Code Ah - right! - found it. Most of it was over my head though:) Hmm... possible name for the news letter perhaps;) What, Linspire? Flinspire? How about Slipping the Surly Bonds ... ... of proprietary software. Curt. Nonononono:) I meant 'Over my head' :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
