[Flightgear-devel] Pictures of flight over Jura
Hello, in case someone is interested, here are the photos taken during my first solo flight in a PA-28 around LFLK. It was my 90th hour of flight. Mont Blanc is supposed to be on one picture or two but it didn't impressed the digital film very well. http://perso.wanadoo.fr/frbouvi/photos/020708/ I can send 2272x1704 versions by PM to those interested. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP RFC protocols v0.01
--- [EMAIL PROTECTED] wrote:
ace project [EMAIL PROTECTED] writes:
I've attached a (Word generated) HTML-file with
the
proposed protocols/headers to be used. Plz bomb
them
:)
I have only a few comments right now. More as I
have time to delve into this further...
1. If you establish a TCP/IP connection, then
provide a way to pass a
protocol version number upon connection
establishment. If using UDP,
then a protocol version number should be passed
in each packet. There are
a few ways to do this:
a. Add two extra bytes in the Level 1 or Level 2
header. You likely don't
want to add extra bytes, so the other options
are probably better right
now.
b. Allocate 3 bits in FLAGS as a version number,
with '111' reserved for
versions greater than 6 (with some place to
put them added later and
known to exist because of the reserved '111'
value.
c. Allocate 1 bit in FLAGS to mean initial
protocol (version 1.0). If
not enabled, then the non-initial protocol
must define where/how the
version number is encoded. It should be well
documented that any
subsequent protocol version MUST define a way
of specifying the protocol
version number.
If you don't provide for a protocol version
number, you'll likely end up
(in version 1.1 or 2.0) with things that you'd
like to do but can't, while
still maintaining backwards compatibility.
Version numbering per packet should not be necessary,
we will set the version that will be used in the
client-initialisation packet. This packet should not
change or be 'autodetect'. BTW client init should NOT
have compression...
Other version controlling methods are still under
consideration.
2. Providing only 12 bits of flags seems really
skimpy to me. This isn't
really an issue, though, when you add the
protocol version number feature
described above. If more bits are needed for a
future protocol version,
they can be added by that version.
3. FDM is declared as 50b in one place, and 20b in
another. Ditto for
Nickname.
4. Flight Dynamics Model as text sounds risky. What
about having FDMs
registered at FlightGear.org (with a numerical
identifier assigned to them)
and then just passing the appropriate FDM id?
5. Why is a termination character ('\r') required
for plane and FDM when
there's a length field provided? It shouldn't be
necessary.
3,5:
We have not yet decided on this issue, we could use 1
length and then plit them up or (as defined atm) use
length field and split them up manually.
6. Eight players seems like a severe limitation. I
can see the potential for
hundreds of players. It would be nice to design
the protocol such that
there's no limit on number of players.
That would be easy, just send multiple packets of
player list, the only thing to add is a 'final flag as
in:
1. list 1-10 final=false
2. list 11-21 final=false
3. list 22-30 final-true
You've got a really nice start here!
Cheers,
Derrell
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: a new dimension to FlightGear
Gouthas, Themie writes: I dont think the alpha sorting code was ever comitted, so currently I dont beleive PLIB will alpha sort. Really? I thought this was something that Steve had in place even in the early days of plib ... unless it was broke along the way and still needs to be fixed? Regards, Curt. -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 16 July 2002 9:10 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] ANN: a new dimension to FlightGear David Megginson writes: David Findlay writes: Just noted one problem. The billboard backgrounds are transparent only for the ground, not other objects. This doesn't look great when you're buzzing through the forest. Other than that it looks great. Thanks, Noted. Unfortunately, alpha transparency is a nightmare -- only things drawn *before* the object with transparency will show through. I draw the dynamically-placed objects after the ground, so you can always see the ground through them, but they are drawn before the clouds in the sky (since you will want to see them through the gaps in the clouds). It will be (apparently) random whether any individual tree shows up through the alpha portion of any other individual tree's texture. I know of no appropriate solution for this problem. The current arrangement works best for the normal situation, flying above 100ft AGL, but you're right that it can cause problems when you're buzzing cows. David, What you need to do is set the transparent flag in the ssgSimpleState for these objects. That way plib can sort them and draw them back to front. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ 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 -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: a new dimension to FlightGear
Curtis L. Olson writes: Really? I thought this was something that Steve had in place even in the early days of plib ... unless it was broke along the way and still needs to be fixed? No, unfortunately we've already been through this with the 3D models. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
Gouthas, Themie wrote: I dont think the alpha sorting code was ever comitted, so currently I dont beleive PLIB will alpha sort. I'm not sure this is a great idea in any case. There are a *lot* of these objects, and doing an NlogN sort of them (with attendant geometry processing to get the distances, not to mention the cache effects of doing an extra sweep over all of them) every frame is likely to be awfully slow. Hacking around the issue by diddling the rendering order (and maybe double-rendering problem objects like nearby clouds) sounds like the best idea to me. We could also investigate the use of destination alpha, which is available and fast on high end hardware these days. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Randomly-placed objects, take 2
I've just checked in a major revision to my new randomly-placed object code: it cuts down the memory usage a fair bit and eliminates long pauses when complex tiles fall out of the cache. There are still some stutters at very high speeds (i.e. 3000kt), but at normal speeds, all seems smooth now. The basic principle is that I add only a placeholder to the scene graph for the objects in each triangle. When it falls into range, a callback creates the objects, and when it falls out of range, another callback frees them again. That way, we have objects added only to triangles that are close to the plane, and there is no need to free hundreds or thousands of objects at once when a tile falls off the cache. I also modified the material code so that an object and its texture are loaded only once, no matter how many materials use it. According to some quick tests, with randomly-placed objects disabled, FlightGear uses 214MB of which 79MB are RSS; with randomly-placed objects enabled, FlightGear uses about 237MB of which 102MB are RSS. That's a bit of a blow-up, but not nearly as bad as it was, and after a while the memory usage stops increasing and sometimes actually falls a bit. Please everyone give this a brutal workout to find any further problems. To enable randomly-placed objects, use fgfs --prop:/sim/rendering/dynamic-objects=true All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: I've just checked in a major revision to my new randomly-placed object code: i Please everyone give this a brutal workout to find any further problems. To enable randomly-placed objects, use fgfs --prop:/sim/rendering/dynamic-objects=true Frame Rate report Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX drivers from NVIDIA at default startup location no HUD no Panel Latest changes~17fps your original code~32 fps no dynamic objects ~75fps Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: a new dimension to FlightGear
Granted, about the NlogN and cache misses penalties.. but whateve solution you choose will be at a cost. Double rendering cloud layers? There goes your fill rate out the window! If anyone is interested in experimenting, I'll be happy to provide the code that you can toggle alpha sorting. Ive never done a performace comparison, but seeing as you guys have something implemented that can excersise it, it might be worth your while to assess its merits quantitavely. By the way, do you mind elaborating on what you mean by use of destination alpha. regards, Themie -Original Message- From: Andy Ross [mailto:[EMAIL PROTECTED]] Sent: Thursday, 18 July 2002 2:22 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] ANN: a new dimension to FlightGear Gouthas, Themie wrote: I dont think the alpha sorting code was ever comitted, so currently I dont beleive PLIB will alpha sort. I'm not sure this is a great idea in any case. There are a *lot* of these objects, and doing an NlogN sort of them (with attendant geometry processing to get the distances, not to mention the cache effects of doing an extra sweep over all of them) every frame is likely to be awfully slow. Hacking around the issue by diddling the rendering order (and maybe double-rendering problem objects like nearby clouds) sounds like the best idea to me. We could also investigate the use of destination alpha, which is available and fast on high end hardware these days. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ 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
RE: [Flightgear-devel] Randomly-placed objects, take 2
Norman Vine writes: Frame Rate report Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX drivers from NVIDIA at default startup location no HUD no Panel Latest changes~17fps your original code~32 fps no dynamic objects ~75fps Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps Here's a fairer test: moving at 120kts, 1500ft AGL starting at the default location: no dynamic objects: ~35fps dynamic objects (latest code): ~28fps So yes, there is a hit, but I'm not seeing a significant difference between the old and new code, and nothing like the spreads you're seeing. The default location is a complex one; I get much better framerates in simpler terrain. To be fair, I've never been able to reproduce your framerate reports. Patches that, say, add or subtract 20 or 50% framerate for you (Norm) usually make a difference of less than +-5% for me. I wonder what difference in our systems could account for this. What framerates are showing up for other people? Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: a new dimension to FlightGear
Gouthas, Themie writes: If anyone is interested in experimenting, I'll be happy to provide the code that you can toggle alpha sorting. Ive never done a performace comparison, but seeing as you guys have something implemented that can excersise it, it might be worth your while to assess its merits quantitavely. You might see a difference alpha-sorting, say, 5000 billboarded trees that didn't show up for a few simple polys. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps That's with AGP disabled. At AGP 4x I get ~41fps and ~36fps. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: Norman Vine writes: Frame Rate report Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX drivers from NVIDIA at default startup location no HUD no Panel Latest changes~17fps your original code~32 fps no dynamic objects ~75fps Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps David, My frame rate trends typically are more in line with yours. However, with the latest cvs code, default startup aiport, no hud, no panel, I'm seeing: dynamic objects (latest code): ~23-24fps no dynamic objects (latest code): ~75fps So I am seeing a huge difference with dynamic objects on vs. off. This is with a 1Ghz class cpu, 256Mb RAM, and GeForce2MX running Linux. With dynamics objects on I'm also seeing a lot of choppiness (i.e. inconsistant frame rates.) Regards, Curt. Here's a fairer test: moving at 120kts, 1500ft AGL starting at the default location: no dynamic objects: ~35fps dynamic objects (latest code): ~28fps So yes, there is a hit, but I'm not seeing a significant difference between the old and new code, and nothing like the spreads you're seeing. The default location is a complex one; I get much better framerates in simpler terrain. To be fair, I've never been able to reproduce your framerate reports. Patches that, say, add or subtract 20 or 50% framerate for you (Norm) usually make a difference of less than +-5% for me. I wonder what difference in our systems could account for this. What framerates are showing up for other people? Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] LaSRS++........info required.
Hi, the project on which i am working is using framework which has the same architecture as that of LaSRS++. since FG is not using it plz can you refer some other mailing list, contact, URL etc or anything which would prove to be helpful to me. i am guy stranded on a tiny winny island...so maximum help needed from all quarters! keeping my fingers crossed thomas.Post your ad for free now! Yahoo! Canada Personals
RE: [Flightgear-devel] Randomly-placed objects, take 2
David Megginson writes: To be fair, I've never been able to reproduce your framerate reports. Patches that, say, add or subtract 20 or 50% framerate for you (Norm) usually make a difference of less than +-5% for me. I wonder what difference in our systems could account for this. I believe your GFX system is 'fill limited' in comparison to mine so you don't get to 'see' the effect of the code as much. eg. When starting up over the open ocean where all the tiles are 'generated' I get ~375fps reported with 800x600x32 when looking straight down.What do you get ? FYI I have recompiled fgfs with the old and the new 'dynamic-objects' several times (5 each) tonight and once the new code was 'slightly' faster, similar to your results. All other times it is roughtly 50% the speed of the older code. I am finding this quite bewildering ?? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: a new dimension to FlightGear
Well, here is a simple way to actually get a qualitative feel.. perhaps you may be pleasantly surprise, perhaps you can chant I told you so! with conviction and a wry grin. All I'm suggesting is try it before dismissing it. Just replace ssgDlist.cxx with this version, no other changes are necessary. If your billboards have the translucent bit set, they will subsequently, be sorted before each frame. If it works well for 500 trees and provides good visual integrity over 5000 unsorted trees that keep sporadically disappearing behind invisible walls, perhaps a more judiciuos use of LOD and fewer billboards might be the overall best result. Most Visual Simulation packages and DIS Stealth Viewers do this, which is why I'm not convinced that its completely dismissible. I would prefer to test, and report the results myself, but I'm only a lurker on this mailing list for inspiration and ideas, so I am not set up to build FSGear. :-) -Original Message- From: David Megginson [mailto:[EMAIL PROTECTED]] Sent: Thursday, 18 July 2002 11:00 AM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] ANN: a new dimension to FlightGear Gouthas, Themie writes: If anyone is interested in experimenting, I'll be happy to provide the code that you can toggle alpha sorting. Ive never done a performace comparison, but seeing as you guys have something implemented that can excersise it, it might be worth your while to assess its merits quantitavely. You might see a difference alpha-sorting, say, 5000 billboarded trees that didn't show up for a few simple polys. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ssgDList2.cxx Description: Binary data
