Re: [Flightgear-devel] Multiplayer, the next steps
Hi Oliver, On Sonntag 23 Oktober 2005 23:56, Oliver Schroeder wrote: after some discussions here on the list, but most of the time on irc, I have drawn some conclusions on how to improve the multiplayer mode. So, here they are. Feel free to flame me on any part which might be awfully wrong. Well, I for myself do not like irc, because of the fact that you never know when something important will happen. Also due to the time difference, we will never have most people there. Mail is much better IMO, because you can read when you have time ... So thanks for asking on the list too! And appologies if I rethink what you might have already told about on irc ... 3) sending properties for the carrier (Nimitz) In order to prepare flightgear to send abitary properties, I think the carrier is predestined. Everything we need is almost already there. What we need is a method in FGAICarrier which I can call from the network code and is able to extrapolate position, speed etc from network data. As far as I know, it should be sufficient to send position, speed and rudder angle. There is possibly more to say (eg. how to elect the feeder and what happens when the feeder dies etc). I have ideas on that, but we will see how to cope with that when we know how we actually handle carrier properties. To that topic, I might be able to help. Positions and speeds (both linear and rotational) together with a timestamp when this state is valid should be enough. From that you should be able to predict the position in some way. That is the way the carrier is moved below the FDM during one timestep. Ask if you have questions for the extrapolation ... Also I think we should not focus on the carrier itself, I think we should send the data of an object like an aircraft or carrier or whatever over the net. Such a thing has positions (position and orientation) and a timestamp (may be something to identify the object). Additionally it has a list of properties it needs to send (Some deflections - whatever). In a first stage, I think, we can send just the propery names together with the values in each packet. In a second stage, think about a scheme where we do not need to resend the mapping between the property names and the values in each packet. May be a separation between a 'realtime packet' only having a uuid to identify the model and some minimal binary data and a 'uuid description' which provides the mapping between the property values in the 'realtime packet' and the property names which need to be set from that values. For the election which properties need to be sent, there must be a, at best generic, mechanism to get that from the specific object (carrier, FDM, ...). Also Ideas, comments? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Winter Textures - screenshot
Oliver C. wrote:
Does VMAP0 data has different data for salt water and freshwater?
I'll investigate if the VMAP0 contains this information in principle,
but I doubt. Currently we only distinguish between the following:
crimson: 10:20:10 ~/TGPostGIS grep hydro FGScenery.conf | awk -F \| '{print
$2}'
rivers_stream
rivers_intermittentstream
canals_stream
lakes_lake
lakes_intermittentlake
floodland_floodland
You _might_ use that to determine if the water contains salt or not.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] problems experienced with the recent c150
Vassilii Khachaturov wrote: H even an empty aircraft doesn't get blown away that easy. I can't believe it will be blown away by anything under 15 knots, especially with the brakes engaged. This is correct. At least you can land and taxi a C150 at 15 kts crosswind without significant trouble - not that I'd say that the C150 is well-suited for such strong wind :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Multiplayer, the next steps
Mathias Fröhlich wrote Oliver Schroeder wrote: ...snip 3) sending properties for the carrier (Nimitz) In order to prepare flightgear to send abitary properties, I think the carrier is predestined. Everything we need is almost already there. What we need is a method in FGAICarrier which I can call from the network code and is able to extrapolate position, speed etc from network data. As far as I know, it should be sufficient to send position, speed and rudder angle. There is possibly more to say (eg. how to elect the feeder and what happens when the feeder dies etc). I have ideas on that, but we will see how to cope with that when we know how we actually handle carrier properties. To that topic, I might be able to help. Positions and speeds (both linear and rotational) together with a timestamp when this state is valid should be enough. From that you should be able to predict the position in some way. That is the way the carrier is moved below the FDM during one timestep. Ask if you have questions for the extrapolation ... AICarrier passes the initial position, base course and speed to AIShip, which then handles the positional and rotational updates, which it passes back to AICarrier for further manipulation. If the carrier needs to alter course in response to a command or its simple AI rules, AICarrier passes tgt course and/or tgt speed to AIShip which uses these data to adjust position and orientation using some pragmatic calculations involving rudder angle, speed and turn radius, and passes them back to AICarrier. AIShip is not a Ship Dynamic Model - it uses some voodoo to simulate reasonably realistic ship movements. We should be able to adapt and use this mechanism to both update the carrier position from the network and extrapolate the current position/orientation between network updates. This method might or might not need the network update to be timestamped. We might try without first since this avoid the need to time-synchronize all players. Also I think we should not focus on the carrier itself, I think we should send the data of an object like an aircraft or carrier or whatever over the net. Such a thing has positions (position and orientation) and a timestamp (may be something to identify the object). Additionally it has a list of properties it needs to send (Some deflections - whatever). In a first stage, I think, we can send just the propery names together with the values in each packet. In a second stage, think about a scheme where we do not need to resend the mapping between the property names and the values in each packet. May be a separation between a 'realtime packet' only having a uuid to identify the model and some minimal binary data and a 'uuid description' which provides the mapping between the property values in the 'realtime packet' and the property names which need to be set from that values. For the election which properties need to be sent, there must be a, at best generic, mechanism to get that from the specific object (carrier, FDM, ...). Also Ideas, comments? In general, Oliver's work plan seems a sensible way forward, and is supported. The inclusion of the carrier in the multiplayer environment is in particular a very worthwhile enhancement, which I think could be built on existing code without too much difficulty (famous last words):-). By choosing to work on the carrier first we can move incrementally to the longer term aim of making all MP objects AI objects, thus making use of existing methods of setting properties and extrapolating position etc. We should not lose sight of this aim when designing the necessary messages. We need to ensure that there is only one carrier named Nimitz in the environment. (Other names are of course available). We also need to ensure that the carrier model is moved smoothly otherwise I think there remains the possibility that any aircraft on deck will become detached and fall off. This might pose particular problems when initiating and/or updating. While there is some low-pass filtering in AIShip, this might need enhancing. We only need send data on initiation and then on change. So far as election of the feeder is concerned, network latency might do that for us, although some there might be some risk that a deadlock might occur. Just some explanation and further thoughts, hopefully helpful Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] problems experienced with the recent c150
On Mon, 24 Oct 2005, Martin Spott wrote: Vassilii Khachaturov wrote: H even an empty aircraft doesn't get blown away that easy. I can't believe it will be blown away by anything under 15 knots, especially with the brakes engaged. This is correct. At least you can land and taxi a C150 at 15 kts crosswind without significant trouble - not that I'd say that the C150 is well-suited for such strong wind :-) I was saying it won't be blown away or tumble due to wind even when *empty* (which is actually what is modelled now since it doesn't account for the pilot weight) when under 15 kts. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Speed problems under Solaris
Hello. Someone said that it is no problem to run FlightGear even on an Ultra-5 machine. I run FlightGear on a Blade 1000 with an 750 MHz UltraSparc processor (this is equal to a Pentium machine with 2,3 or 3 GHz speed). The screen refreshes every 8 seconds. Any keyboard input requires 8 seconds until FlightGear processes the keyboard input. My Windows machine has 2 GHz of speed and the time is less than one second. The top tool says that 96% of the processor time is used by fgfs and only 1% by Xsun. This shows me that 3D graphics is not the problem because the 3D graphics is done by the X server (Xsun - or more exactly by the 3D graphics accelerator card). I thought that sound would be the problem but --disable-sound will not enhance the speed. Another problem is that there is no text in the menu but only some random graphics. Any ideas ? I need help with that. Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Winter Textures - screenshot
On Sun, 23 Oct 2005 23:11:19 +0200, Oliver wrote in message
[EMAIL PROTECTED]:
On Sunday 23 October 2005 22:16, Ralf Gerlich wrote:
Hi,
Arnt Karlsen schrieb:
On Sat, 22 Oct 2005 11:27:56 +0200, Ralf wrote in message
I'd say we need different texture-names for lakes which freeze in
the winter and those that don't.
..aye. Delay lake freezing around river mouths and speed thawing
there, the currents. We want Artic ocean 'n bay 'n fjord freezing
too? ;o)
Erm, ok...working on custom scenery all the time I forgot that the
VMAP0 data does not give us this information. %-)
Does VMAP0 data has different data for salt water and freshwater?
If yes, then:
// Beginning Pseudocode
if (water==freshwater)
{
if (temperature 0 )
..Kelvin? ;o)
{
usetexture(freshwater_freezed);
}
else
{
usetexture(freshwater_unfreezed);
}
}
else
{
usetexture(saltwater);
..freezes too, the salt just drops the freezing a coupla degree (or
Kelvin ;o) ), depending on salinity. Most lakes above sea level stay
fresh because the salt is run off to sea or a lower lake, like the Dead
Sea in between Palestine and Jordan. The higher-than-sea-level
salty lakes are usually quite far from the seas.
}
This is not a perfect solution, but better than nothing in most cases.
:)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Rosenau wrote: Someone said that it is no problem to run FlightGear even on an Ultra-5 machine. This could have been my statement, but in this form it is incomplete. I _do_ expect that the CPU of an Ultra5 is sufficient for running FlightGear _but_ you have to have an appropriate graphics board. I'd expect that you need something in the XVR-1000 range and I don't know if that fits into an Ultra5. I run FlightGear on a Blade 1000 with an 750 MHz UltraSparc processor This should be capable of carrying a graphics board that qualifies. Which board do you currently use ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Speed problems under Solaris
I'd expect that you need something in the XVR-1000 range and I don't know if that fits into an Ultra5. Hello. I think it is not only a problem of graphics. Even the network stuff (e.g. props at TCP port 5501) has 8 seconds delay. This should be capable of carrying a graphics board that qualifies. Which board do you currently use ? I use an Elite-3D-m6 card. Thanks. Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Rosenau wrote: I think it is not only a problem of graphics. Even the network stuff (e.g. props at TCP port 5501) has 8 seconds delay. I suspect the network stuff is coupled to the same loop as is the screen display. Just a guess, though I use an Elite-3D-m6 card. As far as I remember the Elite doesn't have any texture memory at all. Not having texture definitely memory kills FlightGear frame rates since the shading mode has been removed long time ago. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New joystick bindings XML file for WIngman Force 3D USB
On Sunday 23 October 2005 09:14, Buchanan, Stuart wrote: I've created a new XML binding file for the USB version of the Wingman Force 3D joystick. I've been using a USB Wingman Force3D stick with FG (under Linux) for quite a few months now using the current config (OK, a hacked version for my own setup). Which axes did you have trouble with? Never mind, the config file was ripe for updating, so thanks for bringing it under scrutiny :-) Annoyingly the axes assignments are different from the Wingman Force 3D (assuming that file is correct), so it isn't just a case of adding a new name field to wingman-force-3d.xml. I think we've determined now that one file is all that that's necessary for this stick and your problem was due to windows assigning the order of the axes differently to linux? Following on, On Sunday 23 October 2005 09:43, Melchior FRANZ wrote: BTW, this looks fishy, too: property/controls/engines/engine[0]/throttle/property offset type=double-.3/offset factor type=double-1.0/factor Did you write this for an uncalibrated joystick? Really -0.3? I think has come about because the throttle (on my stick at least, but going from that entry, probably on others too) does not map nicely from 0 to 1, but from about 0.25 to 1. Calibration shouldn't be necessary on this stick, and it always gives the same values for min and max positions, unlike an uncalibrated analogue stick that generally gives different numbers each time it's plugged in until calibrated. Unfortunately, I've never got round to tweaking the config so that it moves the throttle value from min right through to max, but I might have a play with it if I find the time. Anyway, and most importantly, this _is_ as far as I can tell, a straight replacement for the current wingman-force-3d.xml, so can we please ensure that it has the current two name tags added to it before it's committed? As always, I'm ready to be corrected if someone out there has a wingman force 3d stick that doesn't work properly under the new config - mine appears to after adding the correct name tag although I've not tested the rudder part as I have pedals on a different interface. As an aside, I much prefer the two big buttons on the base for gear up and gear down, the left hand set of stick-top buttons for flaps and the RHS ones for elevator trim, but each to their own and all that - I'm perfectly happy modifying my own config to do what I want. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Spott wrote: I suspect the network stuff is coupled to the same loop as is the screen display. Just a guess, though It is. Everything except for terrain tile I/O is driven out of the main loop. Probably something that should be fixed... Note that we're going to have to start thinking about threading designs soon anyway, if we want to take advantage of all the fancy multi-core/multi-thread CPUs coming down the pipe. Rendering obviously has to stay within a single thread, but how much non-rendering work can we push out to worker threads? Ideally, everything would be handed to the renderer thread each frame, with all the matrices pre-cooked and ready for OpenGL calls. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Andy Ross wrote: Martin Spott wrote: I suspect the network stuff is coupled to the same loop as is the screen display. Just a guess, though It is. Everything except for terrain tile I/O is driven out of the main loop. Probably something that should be fixed... Note that we're going to have to start thinking about threading designs soon anyway, if we want to take advantage of all the fancy multi-core/multi-thread CPUs coming down the pipe. Rendering obviously has to stay within a single thread, but how much non-rendering work can we push out to worker threads? Ideally, everything would be handed to the renderer thread each frame, with all the matrices pre-cooked and ready for OpenGL calls. I would like to make a case for non-threading from the standpoint of simplicity. We have had (and probably still have) some extremely subtle and extremely difficult to track bugs in our threaded tile loader. We've been forced to use threading for our tile loader simply because of performance reasons. We can't afford a big stutter in our animation when ever we need to load new tiles. When a single person is writing a smaller threaded app, things can work out quite well because one person (who understands all the underlying issues) can think through the code very carefully and ensure that all possible timing, locking, and communication related events are handled robustly. But now project that onto a project like FlightGear. Even if one highly skilled person set us up with lots of threading that worked perfectly, given all the contributions from a variety of sources (many of which I know have no clue about threading issues) how long do you think it will be before everything is hopelessly fouled up? Some simple naive change to fix some bug or add a new feature could inadvertantly introduce a subtle threading bug that only happens very rarely, but is still unacceptable. Personally, I think that the idea of threading in the context of FlightGear is a *very* scary idea, especially from the standpoint of long term maintanence and keeping our code robust. I'd perhaps favor splitting our code out into separate applications that use networking or shared memory or pipes to communicate. You lose some of the context switching efficiency of threads, but I think the code becomes more robust and maintanable because changes have less of a chance to propagate elsewhere to unintended areas ... Just my 2 cents ... :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Threading for SMP, boon or bane?
Curtis L. Olson wrote: I would like to make a case for non-threading from the standpoint of simplicity. We have had (and probably still have) some extremely subtle and extremely difficult to track bugs in our threaded tile loader. I don't disagree at all. Everything you say is true, and a reason to avoid threading wherever possible. Naive thread architectures are invariably a disaster. But unfortunately the hardware world conspires against us -- SMP is rapidly becoming the rule rather than the exception for high performance desktops. Note that there are a few spots where we could split out separate threads in a relatively clean manner: + FDM: Put a lock around the input and output stages (or wrap them into an object that can be placed in a synchronized queue) and let the actual numerics work happen on a different CPU. The advantage here is that you can crank up the simulation rate quite a bit on SMP/multicore boxes, leading to (at least with YASim) more stable ground handling. + Audio: drive the OpenAL thread with a simple command stream from the main loop. One many systems, this will (might, if OpenAL doesn't already do this) move the mixing off of the main CPU, which is good. Even better, it will decouple the audio stream from the main loop latency issues and make skips easier to handle. + Rendering: One idea here would be to clone a separate scene graph (just the non-leaf animation nodes, really) and let one thread (the renderer) draw it while another (the main loop) gets the next one ready for rendering. When done, you do a synchronized graph swap, or even triple-buffer it for higher throughput at the expense of latency. This would require significant surgery to the existing model/animation code (and, to a lesser extent, the GUI and tile code) to store the property values somewhere instead of reading them at render-time. + Everything else: This thread would contain the existing main loop, and its basic structure wouldn't change. Note that this design allows threads live by relatively simple rules. The main loop doesn't change much except where direct calls are replaced by commands to be queued. And the worker threads all work only on their internal data; they don't need (and are forbidden) to touch external state like the property tree. The first two could be done with fairly minimal code, actually. The renderer changes would be more significant. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Threading for SMP, boon or bane?
___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Speed problems under Solaris
Hello. I found out that for each simulation step an usleep(93 ms) is done. The screen is updated only every 64 simulation steps. 93 ms X 64 = ~7 seconds I have no idea why the display is only updated ONLY every 64th simulation step. Textures are not the problem; I can use --disable-textures to get single-color triangles if textures are the problem. But I think that textures are no problem because - as far as I know - the texture stuff is done in the X server process which needs only few processor time. Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Rosenau wrote: Hello. I found out that for each simulation step an usleep(93 ms) is done. The screen is updated only every 64 simulation steps. 93 ms X 64 = ~7 seconds I have no idea why the display is only updated ONLY every 64th simulation step. Textures are not the problem; I can use --disable-textures to get single-color triangles if textures are the problem. But I think that textures are no problem because - as far as I know - the texture stuff is done in the X server process which needs only few processor time. This *sounds* like you do not have opengl hardware acceleration on your machine. Even with textures off, FlightGear still uses opengl funtionality for it's depth buffer (hidden surface removal), fog, lighting, and transforming vertices from world coordinates to screen coordinates. All of this is really slow in software on a general purpose cpu which is why dedicated 3d hardware exists. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Curtis L. Olson wrote: Personally, I think that the idea of threading in the context of FlightGear is a *very* scary idea, especially from the standpoint of long term maintanence and keeping our code robust. I'd perhaps favor splitting our code out into separate applications that use networking or shared memory or pipes to communicate. I suspect more people would jump on this train if we manage to agree on the idea, that platform independent interfaces were a good thing (TM). We should 'hijack' this thread to start a discussion about wether it makes sense simply to take the current network interface protocols as given and write them down in some sort of an 'official' interface description. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New Release of Lake Constance custom scenery
Ralf Gerlich schrieb: Hello all, Ingrid has been working hard on the scenery data and we're proud to release a new version of the Lake Constance custom scenery. In fact it is not only a scenery of Lake Constance anymore. The nearest airport to Fuessen is Reutte (LOIR), a nice little grass airstrip with a challenging traffic pattern. Hi Ralf, thank you and all the Lake Constance Team Members for improving that wonderful piece of (scenery) cake for VFR flyers. I just managed due to lack of freetime to make a freeflight around LOIR (to the south and north) and could clearly see what you improved when passing the borders of the scenery in the south (barrier). Flying further it really looks very odd! Next weekend I'll take out some charts and do some more real flights. Regards Georg (EDDW) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
On Saturday 22 Oct 2005 18:53, Oliver C. wrote: On Saturday 22 October 2005 19:09, Lee Elliott wrote: Hello Geoff, just tried fgfs --fog-disable --visibility=12 and it seemed to start ok. Didn't try flying as I'm just off out. This is on a Debian Linux system. LeeE I tried it too. It works okay running at about 7-11 fps on an Athlon 2000+, 1 GB Ram and Geforce 4200 Ti 64 MB on a Linux Slackware 10.0 machine. But the lightning is wrong, it is too dark in the far distance at midday. See screenshot: http://img460.imageshack.us/my.php?image=fgfsdark3xu.jpg Best Regards, Oliver C. Do you mean that the sky colour is wrong? That's a bit of a difficult one to assess because at low altitudes we always see through a lot of atmosphere. Setting no fog is a bit like removing _all_haze from the view, which is something you'll never see in real life, except perhaps at very high altitudes. Removing the fog is a bit like elevating your altitude. It may not be perfect but you'd be hard pressed to do much better with a fully featured ray-traced renderer, let alone OpenGL. Don't get me wrong, with ray-tracing you could account for variable refractive index and scattering based on altitude and wavelength but it would take a long time. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
