[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] ANN: a new dimension to FlightGear
I dont think the alpha sorting code was ever comitted, so currently I dont beleive PLIB will alpha sort. -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
Re: [Flightgear-devel] LaSRS++ Framework
LaSRS++ is not used by FG. We do use its predecessor, LaRCsim. It is implemented purely in C. JSBSim is implemented in C++ and is fully OO. You might take a look: http://jsbsim.sf.net On Tue, 2002-07-16 at 21:11, thomas k wrote: > > Hello Guyz, > > while reading the discussions at FlightGear,I came to knpw that it has used LaSRS++ >as its core framework. As for my final year project, I all require this kind of >framework . So plz tell me from where to find it or any kind of it ? > > Looking forword for ur cool suggestions > > Thomas > > > > - > Post your ad for free now! Yahoo! Canada Personals -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
At 01:36 PM 16/07/2002 -0400, you wrote: >Curtis L. Olson writes: > > > Your cows are hideous but humorous. On my computer they are missing > > the head. :-) > >If you're flying close enough to notice, you're flying too low (I've >been waiting almost 24 hours to make that comment). > > > In real life you'd likely see clustered groups of cows rather than > > randomly spread out over a field. > >Ditto for trees -- you'll tend to see stands of trees of the same type >grouped together rather than, say, pine and maple mixed randomly. Any >suggestions? FS2K2 solves this problem with using the placement info in the textures. All you need is a 2bit texture where bit 1 means place an object here and bit 0 means no object here. You'd need these masks for each ground texture you have. Placing the objects manually on top of each texture is not that much work, unless you really have a lot of textures. It also has the advantage that 3D trees are above the trees in the image... >I suppose I should make some sheep for our friends in the UK and Eire >-- as I recall, sheep account for about 75% of the scenery over there. Please don't forget New Zealand (probably about 90% :) )!!! Cheers, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] LaSRS++ Framework
Hello Guyz, while reading the discussions at FlightGear,I came to knpw that it has used LaSRS++ as its core framework. As for my final year project, I all require this kind of framework . So plz tell me from where to find it or any kind of it ? Looking forword for ur cool suggestions ThomasPost your ad for free now! Yahoo! Canada Personals
Re: [Flightgear-devel] AC_VTAILAREA
You aren't missing anything. Not every parameter will get used with every aircraft (and this one isn't used by any at the moment) On Tue, 2002-07-16 at 12:19, [EMAIL PROTECTED] wrote: > Hi there! > > I´m trying to understand some of the FlightGear´s source code, and I´m > stuck in this: > in the aircraft config file tehre is the AC_VTAILAREA parameter whitch is > stored in the variable VTailArea in the FGAircraft class. VTailArea then > is used to calculate the variable vbarv defined as following: > vbarv = VTailArm*VTailArea / (cbar*WingArea); > > then the value of VTailArea is associated with the property "metrics/Sv-sqft" > > and the value of vbarv is associated with the property "metrics/vbarv-norm". > > then these two properties seem to never be used again. > > What am I missing? Thanks in advance > > Tony Lampada > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP RFC protocols v0.01
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.
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.
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.
You've got a really nice start here!
Cheers,
Derrell
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MP RFC protocols v0.01
I've attached a (Word generated) HTML-file with the proposed protocols/headers to be used. Plz bomb them :) I will be making them smaller, but I'm not going to 'bit fuck' too much, so it will be byte-level profit or no profit. Most notable, position protocol is still missing, guess why ? Leon __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com Title: Level 1 protocol Level 1 protocol Main header (for compression test, may or may not stay, depending on profit gained by the compression) 16b Lengte bericht 8b Compression identifyer (and endian check atm) Block data, current maximum +/- 512 bytes(see 2nd level protocol) The first 4 bytes will be compressed back in 2. Level 2 protocol 0 15 16 31 4b size header 12b FLAGS 16b TOS (Type of Service) 16b Sequence nr (from client per TOS) 16b Sequence nr (from server per TOS) Dataveld (maximaal 512 bytes) b as in bit ! List of found FLAGS (bit level, left to right) 0 Confirm msg Packet should be confirmed by server/client 1 Do NOT parse Server should NOT try to interprete the message (on the lower level) 2 To Server Packet only meant for the server 3 To ALL Packet should be sent to all clients on this server 4 To FOV Packet should be sent to all clients withing field of view 5 Loopback Packet should be loopbacked WITH interpretion (without can be set with do not parse flag) 6 Reserved flags (or slack) 7 8 9 10 11 Level 3 protocols (Client to Server [C2S] and/or Server to Client[S2C]): [C2S] Requesting a connection 0 15 16 31 8b flags 8b Minimal major version sender 8b major version sender 8b minor version sender 16b Sequence number question/response 8b len nick Nickname(max 50bytes) 8b len fdm Flight Dynamics model used (max 50bytes) 8b Max traffic downstream (kB/s) 8b Max traffic upstream (kB/s) 8b update/sec 8b reserved 16b Vliegtuig FOV b als in bit ! FLAGS(in order): 0 New connection Create a new connection, if a connection already existed then alle history will be terminated and reinitialised. 1 Mutate connection Alteration of the static parameters given by the client, history will be kept intact (when possible). 2 Drop connection Drop connection and all corresponding objects, if no such message was received, automatic clean up will happen after 10(?)seconds of idling. 3 Confirmation [S2C] Confirm initialisation/mutation/drop connection 4 Denial [S2C] Deny initialisation/mutation connection 5 Error [S2C] error in message 6 Reserved 7 Reserved [S2C] Giving the static parameters of the other clients on the server (or within FOV ?): 8b # players Reserved Reserved Reserved 8b len nick 8b Client ID (x)b Nickname (char \r terminates) maximum 20 characters (buffer limit) 8b len plane (x)b Nickname (char \r terminates) maximum 20 characters (buffer limit) 8b len fdm (x)b Flight Model (char \r terminates) maximum 20 characters (buffer limit) This should allow for at least 8 players. [C2S] Ping 32b A test long (is same as int on my platform) 32b A test float 64b A test double xBytes string Multiplayer Engine Version [...] (char \r terminates) [S2C] Pong Same message, but recompiled by server (going through all layers) Minimal protocols yet to define: Full position updates, Delta position updates, chatmessage-exchange protocols, server-info protocol, ack/neg protocols.
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
Hello, first I would say that dynamic objects are very cool. But I can testify that it eats a lot of memory and it leaks it. I am under Win2k, compile with MSVC a debug version. On startup it takes 586 Mb (read Mega) but stay still while sitting on the runway (LFLK is surrounded by forest of SomeSort material ). Then I take off and engage AP, flying A4. It then leaks 80Mb from time to time, saturating the 1Gb of ram and begins to take swap memory. I stop it before all my hardisk eaten by the Windows PageFile. CPU is 100% of my Athlon XP1800+ before beginning swaping. By comparision, startup consumes 220Mb without dynamic objects and no more memory is reclaimed after. CPU is about 50-60%. Cheers, -Fred - Original Message - From: "Erik Hofman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, July 16, 2002 7:29 PM Subject: Re: [Flightgear-devel] ANN: a new dimension to FlightGear > David Megginson wrote: > > Erik Hofman writes: > > > > > If it would be 27Mb only, there wouldn't be a problem for me because > > > FlightGear without dynamic objects leaves 39Mb spare memory. > > > > The problem seems to be that there are a lot of extra SSG nodes > > attached to every tile in the cache (one ssgTransform and one ssgRange > > for every dynamic object, whether currently visible or not). The > > solution, I think, will involve using callbacks under the group LOD > > node to manage things so that SSG nodes are created only when needed. > > During a high-speed cross-country magic carpet ride, the memory usage > > got as high as 180MB before stabilizing (vs. 80MB without > > dynamically-placed objects). > > Ouch, that's too much for me. I've 192 Mb internal memory which is > shared with the video adaptor (and textures). > > Erik > > (Does anybody have an Octane/MXE to give away?) > :-) > > > ___ > 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
[Flightgear-devel] AC_VTAILAREA
Hi there! I´m trying to understand some of the FlightGear´s source code, and I´m stuck in this: in the aircraft config file tehre is the AC_VTAILAREA parameter whitch is stored in the variable VTailArea in the FGAircraft class. VTailArea then is used to calculate the variable vbarv defined as following: vbarv = VTailArm*VTailArea / (cbar*WingArea); then the value of VTailArea is associated with the property "metrics/Sv-sqft" and the value of vbarv is associated with the property "metrics/vbarv-norm". then these two properties seem to never be used again. What am I missing? Thanks in advance Tony Lampada ___ 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: > The randomized objects are very cool, but I'm seeing one problem on > longer flights. After flying maybe 100 miles or so (?) the tile > loader locks up and the entire program hangs. I haven't had a chance > to debug this, but you might try upping the acceleration factor and go > for a quick, but longer flight and see if you can replicate this. It > doesn't appear to be a problem with RAM, but appears as if the program > goes into an infinite loop somewhere ... Ditto. It could be that very small triangles are causing problems, or it could be that we're just creating too many nodes. I'll keep playing around and see what I can find. 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
David, The randomized objects are very cool, but I'm seeing one problem on longer flights. After flying maybe 100 miles or so (?) the tile loader locks up and the entire program hangs. I haven't had a chance to debug this, but you might try upping the acceleration factor and go for a quick, but longer flight and see if you can replicate this. It doesn't appear to be a problem with RAM, but appears as if the program goes into an infinite loop somewhere ... This does not happen with the random objects turned off. Regards, Curt. David Megginson writes: > Over the weekend, I finished my first take on dynamically-placed > scenery objects. I'm attaching two screenshots: > > 1. Approaching a city over some woods, with a pasture in-between. > >http://www.megginson.com/flightsim/dynamic-01.png > > 2. Sitting on a lake, pretending to be a floatplane. > >http://www.megginson.com/flightsim/dynamic-02.png > > This is not, primarily, designed to be eye candy (well, only a bit of > it is). Dynamic objects like buildings and trees serve several very > important purposes during VFR flight: > > a. They give some indication of altitude AGL and groundspeed. Even at >low altitude Trees get very small very fast; if they're big and >there's not a runway in your windshield, add power and pull up. > > b. They provide aiming points for turns and straight flight (i.e. to >turn 90 degrees, look off your wing, pick and object, and then fly >towards it). For example, it is much easier to hold a compass >heading if you turn to the heading, pick an object off the nose, >then keep that object off the nose than if you constantly chase the >compass around. > > c. (not so nice) They cause very confusing illusions because of drift >when flying near the ground. It is easy for a pilot to get into a >spin or spiral by banking too steeply because the plane doesn't >seem to be turning much. > > Right now, I've added only a few dynamic object types, so it's a bit > monotonous. Over the next week or two, I'll try to introduce a > greater variety of buildings and trees, at least, and maybe a few pure > eye-candy things like boats out in lakes. All non-billboarded dynamic > objects also currently face the same way; I plan to fix that in the > next day or two. > > I've made very aggressive use of LOD to keep the framerates up; for > example, trees are visible only from a range of 2000m and large > buildings from 1m; I also slap a range on all the objects on each > triangle or fan, so that plib won't have to do hundreds or thousands > of LOD calculations for objects that are far out of range. Even then, > trees cannot be too dense. > > NOTE: Dynamic objects are off by default. After you update the > FlightGear and base-package CVS, you will have to set the property > /sim/rendering/dynamic-objects to true to see anything (if you change > it during the program run, you'll have to reload the scenery). > Depending on the terrain, visibility, and altitude AGL, you may > experience slow framerates for a few seconds while FlightGear places > dynamic objects on all the tiles; just wait, and everything will speed > up again shortly. > > Special thanks to Curt, whose ground-lighting code I > stole^H^H^H^H^Hused as inspiration to calculate object placement. > > > 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
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson writes: > This is a great idea, but it will make the memory problem even worse, > at least until I have a chance to implement the suggestion in my last > posting. > > > I moved the code that creates the object LOD node over to obj.cxx > > where the object is actually positioned. Now every instance of every > > 'random' object has it's own unique LOD node. The LOD range is > > calculated as range/(random(0,1)*range) + range. > > > > So if the specified object range was 2000m you would get a > > distribution that follows the form of 1/x. The minimum range would be > > 2000m, but a few would be much higher than that. > > That sounds like an excellent idea. I tweaked the random distribution a bit, but feel free to play with the formula and coefficients. > > The visual result is that you'd get a few objects way out in the > > distance and then others would fill in between more and more as you > > got closer in. It looks very similar to what you had originally but > > with a bit more variety and a few interesting objects in the distance, > > and there isn't a 'hard line' where all the objects pop in. You still > > see popping but it is maybe a slight fraction less noticable. > > > > I think this change makes the random objects look really good. Do you > > mind if I commit them (you can always back them out if you don't like > > them, or think of a better way do do this.) > > Sure, you can either commit it now, before I start working on the > memory problem, or wait a day or two (or more) for my restructuring. Ok, before I forget all about the changes, I have committed them. 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
Re: [Flightgear-devel] Re: MP what data to send (summary 1)
Martin Spott wrote: >>Billy Verreynne wrote: >> >>>"ace project" <[EMAIL PROTECTED]> wrote: >> > - I will post the encaptulation protocols tommorrow, when I have translated their essence to English (they are in Dutch atm, anybody wants them in Dutch ?) > >>Geen probleem. > Ik zal da ook kunnen lezen - zo doe maar Een mooie tekst in nederlands > is heelemal beter dan geen tekst in engels ;-) > Hehe :-) > >>I think you all should promote the South African language, it's a nice >>language and it's easy to follow for us in The Netherlands. :-) > > But speaking this language is much more difficult, because in many cases you > don't know in which one should to stick to english and in which you'd better > use the dutch ;-) Ah, so *that's* the problem. I've never realized that. Anyway, back to non-political discussions. (Hi Curt). :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: MP what data to send (summary 1)
> Billy Verreynne wrote: >> "ace project" <[EMAIL PROTECTED]> wrote: >>>- I will post the encaptulation protocols tommorrow, >>>when I have translated their essence to English (they >>>are in Dutch atm, anybody wants them in Dutch ?) > Geen probleem. Ik zal da ook kunnen lezen - zo doe maar Een mooie tekst in nederlands is heelemal beter dan geen tekst in engels ;-) > I think you all should promote the South African language, it's a nice > language and it's easy to follow for us in The Netherlands. :-) But speaking this language is much more difficult, because in many cases you don't know in which one should to stick to english and in which you'd better use the dutch ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ 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: > Right now you have the individual object LOD node attached to the > model so there is only one copy of it in memory. Right -- so the memory problem is only the transform nodes. > It might be > interesting to make a per instance LOD node above each instance of the > object so that we could vary the range for each instance of the > object. This would allow us to see just a few of the random objects > way out in the distance, but not too many to kill frame rates. This is a great idea, but it will make the memory problem even worse, at least until I have a chance to implement the suggestion in my last posting. > I moved the code that creates the object LOD node over to obj.cxx > where the object is actually positioned. Now every instance of every > 'random' object has it's own unique LOD node. The LOD range is > calculated as range/(random(0,1)*range) + range. > > So if the specified object range was 2000m you would get a > distribution that follows the form of 1/x. The minimum range would be > 2000m, but a few would be much higher than that. That sounds like an excellent idea. > The visual result is that you'd get a few objects way out in the > distance and then others would fill in between more and more as you > got closer in. It looks very similar to what you had originally but > with a bit more variety and a few interesting objects in the distance, > and there isn't a 'hard line' where all the objects pop in. You still > see popping but it is maybe a slight fraction less noticable. > > I think this change makes the random objects look really good. Do you > mind if I commit them (you can always back them out if you don't like > them, or think of a better way do do this.) Sure, you can either commit it now, before I start working on the memory problem, or wait a day or two (or more) for my restructuring. 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
Erik Hofman writes:
> Ouch, that's too much for me. I've 192 Mb internal memory which is
> shared with the video adaptor (and textures).
I've figured out the solution, but will need some time to implement
it.
Right now, I have top level transformation and range nodes for groups
of objects on every surface -- that way, if a tri-fan (for example) is
more than, say, 10km away, all of the objects on it will be skipped,
saving hundreds or thousands of individual LOD tests.
My plan is to extend the ssgRangeSelector to have an additional member
for over the maximum distance, so the range array would look something
like this:
float ranges = {0, 1f, f};
Under the ssgRangeSelector, I will put two empty ssgBranch nodes, one
for within the range (i.e. <=1m) and one for outside the range
(i.e. >1m). Each of these will have a reference to the same user
data structure containing information about the objects should should
be generated and a flag indicating whether the objects currently
exist.
I will then add a pre-traversal callback to each branch that examines
the user data. The callback for the in-range branch will check
whether the dynamic objects currently exist; if not, it will generate
them, add them to itself, and set the flag in the user data. The
callback for the out-of-range branch will check whether the dynamic
objects currently exist; if so, it will remove them from the in-range
branch (so that their memory is freed) and clear the flag in the user
data. As surfaces move out of the user-specified range for dynamic
objects, their memory will be freed automatically, and then
reallocated later if needed.
Any comments or suggestions?
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
David Megginson writes: > Curtis L. Olson writes: > > > Your cows are hideous but humorous. On my computer they are missing > > the head. :-) > > If you're flying close enough to notice, you're flying too low (I've > been waiting almost 24 hours to make that comment). I want to see the fear in their eyes as they scatter. But seriously, I really like cows, I would never try to scare them like that. :-) > > In real life you'd likely see clustered groups of cows rather than > > randomly spread out over a field. > > Ditto for trees -- you'll tend to see stands of trees of the same type > grouped together rather than, say, pine and maple mixed randomly. Any > suggestions? Tough problem. I think it will be likely that if we go beyond something simple, we'd be better off letting a human place the trees (or come up with some sort of image processing util that can pick off every tree position from a aerial/satellite image.) > I suppose I should make some sheep for our friends in the UK and > Eire -- as I recall, sheep account for about 75% of the scenery over > there. -- 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: > Your cows are hideous but humorous. On my computer they are missing > the head. :-) If you're flying close enough to notice, you're flying too low (I've been waiting almost 24 hours to make that comment). > In real life you'd likely see clustered groups of cows rather than > randomly spread out over a field. Ditto for trees -- you'll tend to see stands of trees of the same type grouped together rather than, say, pine and maple mixed randomly. Any suggestions? I suppose I should make some sheep for our friends in the UK and Eire -- as I recall, sheep account for about 75% of the scenery over there. 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
Curtis L. Olson wrote: > Erik Hofman writes: >>Ouch, that's too much for me. I've 192 Mb internal memory which is >>shared with the video adaptor (and textures). >> >>Erik >> >>(Does anybody have an Octane/MXE to give away?) > > > Perhaps we could add a property that specifies a percentage of the > random objects to create. Those with lower end systems could turn > down the amount of random objects. Those with insane amounts of > power, could turn up the number ... That might be a good idea. In the mean time I'll see if I can handle 2 dynamic objects (Just to be sure). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
Erik Hofman writes: > David Megginson wrote: > > Erik Hofman writes: > > > > > If it would be 27Mb only, there wouldn't be a problem for me because > > > FlightGear without dynamic objects leaves 39Mb spare memory. > > > > The problem seems to be that there are a lot of extra SSG nodes > > attached to every tile in the cache (one ssgTransform and one ssgRange > > for every dynamic object, whether currently visible or not). The > > solution, I think, will involve using callbacks under the group LOD > > node to manage things so that SSG nodes are created only when needed. > > During a high-speed cross-country magic carpet ride, the memory usage > > got as high as 180MB before stabilizing (vs. 80MB without > > dynamically-placed objects). > > Ouch, that's too much for me. I've 192 Mb internal memory which is > shared with the video adaptor (and textures). > > Erik > > (Does anybody have an Octane/MXE to give away?) Perhaps we could add a property that specifies a percentage of the random objects to create. Those with lower end systems could turn down the amount of random objects. Those with insane amounts of power, could turn up the number ... 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
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson writes: > Erik Hofman writes: > > > If it would be 27Mb only, there wouldn't be a problem for me because > > FlightGear without dynamic objects leaves 39Mb spare memory. > > The problem seems to be that there are a lot of extra SSG nodes > attached to every tile in the cache (one ssgTransform and one ssgRange > for every dynamic object, whether currently visible or not). The > solution, I think, will involve using callbacks under the group LOD > node to manage things so that SSG nodes are created only when needed. > During a high-speed cross-country magic carpet ride, the memory usage > got as high as 180MB before stabilizing (vs. 80MB without > dynamically-placed objects). David, Right now you have the individual object LOD node attached to the model so there is only one copy of it in memory. It might be interesting to make a per instance LOD node above each instance of the object so that we could vary the range for each instance of the object. This would allow us to see just a few of the random objects way out in the distance, but not too many to kill frame rates. Ok, I think I have something working that I like: I moved the code that creates the object LOD node over to obj.cxx where the object is actually positioned. Now every instance of every 'random' object has it's own unique LOD node. The LOD range is calculated as range/(random(0,1)*range) + range. So if the specified object range was 2000m you would get a distribution that follows the form of 1/x. The minimum range would be 2000m, but a few would be much higher than that. The visual result is that you'd get a few objects way out in the distance and then others would fill in between more and more as you got closer in. It looks very similar to what you had originally but with a bit more variety and a few interesting objects in the distance, and there isn't a 'hard line' where all the objects pop in. You still see popping but it is maybe a slight fraction less noticable. I think this change makes the random objects look really good. Do you mind if I commit them (you can always back them out if you don't like them, or think of a better way do do this.) 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
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson wrote: > Erik Hofman writes: > > > If it would be 27Mb only, there wouldn't be a problem for me because > > FlightGear without dynamic objects leaves 39Mb spare memory. > > The problem seems to be that there are a lot of extra SSG nodes > attached to every tile in the cache (one ssgTransform and one ssgRange > for every dynamic object, whether currently visible or not). The > solution, I think, will involve using callbacks under the group LOD > node to manage things so that SSG nodes are created only when needed. > During a high-speed cross-country magic carpet ride, the memory usage > got as high as 180MB before stabilizing (vs. 80MB without > dynamically-placed objects). Ouch, that's too much for me. I've 192 Mb internal memory which is shared with the video adaptor (and textures). Erik (Does anybody have an Octane/MXE to give away?) :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: MP what data to send (summary 1)
Billy Verreynne wrote: > "ace project" <[EMAIL PROTECTED]> wrote: >>- I will post the encaptulation protocols tommorrow, >>when I have translated their essence to English (they >>are in Dutch atm, anybody wants them in Dutch ?) Geen probleem. > I can read Dutch without too much of a problem. But then (too my shame) I read > and write English better than my native language, never mind Dutch. :-) I think you all should promote the South African language, it's a nice language and it's easy to follow for us in The Netherlands. :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson writes: > Erik Hofman writes: > > > If it would be 27Mb only, there wouldn't be a problem for me because > > FlightGear without dynamic objects leaves 39Mb spare memory. > > The problem seems to be that there are a lot of extra SSG nodes > attached to every tile in the cache (one ssgTransform and one ssgRange > for every dynamic object, whether currently visible or not). The > solution, I think, will involve using callbacks under the group LOD > node to manage things so that SSG nodes are created only when needed. > During a high-speed cross-country magic carpet ride, the memory usage > got as high as 180MB before stabilizing (vs. 80MB without > dynamically-placed objects). David, Your cows are hideous but humorous. On my computer they are missing the head. :-) In real life you'd likely see clustered groups of cows rather than randomly spread out over a field. 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
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
Erik Hofman writes: > If it would be 27Mb only, there wouldn't be a problem for me because > FlightGear without dynamic objects leaves 39Mb spare memory. The problem seems to be that there are a lot of extra SSG nodes attached to every tile in the cache (one ssgTransform and one ssgRange for every dynamic object, whether currently visible or not). The solution, I think, will involve using callbacks under the group LOD node to manage things so that SSG nodes are created only when needed. During a high-speed cross-country magic carpet ride, the memory usage got as high as 180MB before stabilizing (vs. 80MB without dynamically-placed objects). 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
David Megginson wrote: > Erik Hofman writes: > > > I've tried it and it looks quite nice. It seems to have a very low > > footprint (concerning framerate) so that's excelent as well. The only > > problem I have is it either leaks memory like crazy (about 4Mb per > > second) or it ernlarges the FlightGear memory footprint by more than 225 > > Mb. :-( > > > > I've looked at the code but couldn't find a place where memory leaks > > might happen. > > Do you see this sitting still or flying across tile boundaries? I Both. I even renamed the Textures.high directory to give me some more memory (the O2 processes the textures from main memory because it doesn't have any video memory). This gives the same result. It looks like it stabilizes around 50Mb free memory but after about ten seconds it starts to count down again, until all the (180 Mb) swap is used. > tried running FlightGear with and without dynamic objects, and sitting > still at the default location, RSS stabilized quickly at 79MB without > dynamic objects and 106MB with, and stayed there for over a minute in > each case. I'm using G++ 3.0. Irix 6.5.14m and MipsPro 7.2.1.3 > The 27MB inflation is, of course, still unacceptable. I can think of > some ways to decrease it by quite a bit when I have time: If it would be 27Mb only, there wouldn't be a problem for me because FlightGear without dynamic objects leaves 39Mb spare memory. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson wrote: > > Seriously, I am planning on adding the occasional barn, farmhouse, > silo, and blue aluminum storage shed. This points to another problem, > though -- as with textures, buildings will look very different in > different parts of the world and even in different parts of the same > country, province, state, or county. > > What we need is conditions in materials.xml; for example, within a > certain lat/lon rectangle, use a tumbled-down stone building for a > barn; within another, use a North-American wooden barn; and so on. We > already have XML conditions, so it's doable, but it will be a bit of > work all the same. Instead of allowing full conditions, we might > allow only a few criteria (maybe time of year, lat/lon, elevation, > slope). IMO it's better to use a lat/lon and a weighting value instead of a rectangles. So you can e.g. place a "all farms look like Object1 at lat/lon, standard weighting" in the middle of the US and place a "all farms look like Object2 at lat2/lon2, strong weighting" at a special place where the farms look a bit different. The result would be, that all farms are Object1, exept in a circle around lat2/lon2 where they are Object2. The decicion about which object should be generated is easy, just look which weight/distance_to_lat_lon is gratest... CU, Christian PS: This will automatically generate voronoii diagrams... -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
Billy Verreynne writes: > Dave (the other one :-), are you considering dynamic moving > objects? You mentioned yachts in passing... Collision detection > eats CPU cycles, but still without that dynamic objects IMO are > relegated to mainly eye candy. I think that those will need to be handled differently. Static objects are attached to a tile, and will be freed when the tile falls out of the cache; moving objects can cross tile boundaries. 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
David Findlay writes: > Of course! Mind you in Africa the the baboons will sit on a runway, > fly away as you buzz them, then sit back on the runway while you go > around the circuit for landing. They are happy to do that all > afternoon, so you just have to land and try and miss them. :-) We > should be able to implement this, although you'll have to watch > that the baboons don't bite you on the backside as you get out of > the plane. :-P In Canada, a bull moose will charge at a car's headlights or, presumably, a small plane's landing lights. Moose have very large bodies on high legs and can do a lot of damage, and a few drivers die every year from encounters. Standard driving practice when you see a moose (in time) is to turn off your headlights, stop, and wait very quietly. Natural selection tends to take care of the idiots who honk their horns and flash their lights to try to get a moose off the road. 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
Martin Spott writes: > > We need a farmer and a tractor for the farm fields here in MN. If the > > farmer's name was "Nic" then we could have a "Scenic overlook, [...] > > Hehe, we're also having really new sort of trouble with these trees - like > having one standing right in front of the runway: > > http://document.ihg.uni-duisburg.de/bitmap/FGFS/tree-approach.png > > > Fortunately one can fly through these trees ;-) This is where we need to make TerraGear smarter. We've always had forest right up to the threshold of many runways, but as long as it was a flat texture, nobody minded much. 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
Erik Hofman writes: > I've tried it and it looks quite nice. It seems to have a very low > footprint (concerning framerate) so that's excelent as well. The only > problem I have is it either leaks memory like crazy (about 4Mb per > second) or it ernlarges the FlightGear memory footprint by more than 225 > Mb. :-( > > I've looked at the code but couldn't find a place where memory leaks > might happen. Do you see this sitting still or flying across tile boundaries? I tried running FlightGear with and without dynamic objects, and sitting still at the default location, RSS stabilized quickly at 79MB without dynamic objects and 106MB with, and stayed there for over a minute in each case. I'm using G++ 3.0. The 27MB inflation is, of course, still unacceptable. I can think of some ways to decrease it by quite a bit when I have time: 1. Make sure that objects used by multiple materials are loaded only once. 2. Do some callback trickery to cull the SSG nodes for dynamic objects when they are out of range (i.e. LOD keeps them from being rendered, but we don't even want them to stay in memory). Otherwise, the branch nodes for objects are kept in memory until the tile leaves the cache. 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
Curtis L. Olson writes: > I could see that turning the materials.xml file into a complicated > nightmare. However, it would be a nice feature to have. Perhaps the > top level materials.xml could include a .xml for each material that > has a long list of conditionals. That might keep things a little > cleaner ... (?) Sure. We can do that already, if someone wants to go to the trouble; just create an $FG_ROOT/Materials/ directory, put one file for each material in it, then make materials.xml look like this: ... It will look exactly the same to FlightGear, so no C++ modifications will be required. 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
"David Findlay" <[EMAIL PROTECTED]> wrote: > Of course! Mind you in Africa the the baboons will sit on a runway, > fly away as you buzz them, then sit back on the runway while you go > around the circuit for landing. They are happy to do that all afternoon, > so you just have to land and try and miss them. :-) Yes, and then not even to mention the problems that animal life causes for aviators. ;-) Hey, as a native of Africa I'm allowed to make these non-pc jokes. Besides, where else in the world will someone actually steal a NDB but in Cape Town? :-) > We should be able to implement this, although you'll have to watch > that the baboons don't bite you on the backside as you > get out of the plane. :-P Maybe a bite on the backside is exactly what the US legislators and media need for their treatment of GA in the US. After a solid kick in the nuts. Er.. make that several kicks. ObOnTopic: Dave (the other one :-), are you considering dynamic moving objects? You mentioned yachts in passing... Collision detection eats CPU cycles, but still without that dynamic objects IMO are relegated to mainly eye candy. -- Billy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 16 Jul 2002 20:38, David Megginson entered data into a CPU register that indicated: > Actually, you might want to animate these; it would be annoying if the > kangaroo always blocked the same runway. Of course! Mind you in Africa the the baboons will sit on a runway, fly away as you buzz them, then sit back on the runway while you go around the circuit for landing. They are happy to do that all afternoon, so you just have to land and try and miss them. :-) We should be able to implement this, although you'll have to watch that the baboons don't bite you on the backside as you get out of the plane. :-P David - -- - -BEGIN GEEK CODE BLOCK- Version: 3.12 GCC d- s:-- a--- C++ UL P+++ L+++ E- W++ N++ o- K- w-- O-- M+ V-- PS PE Y+ PGP+++ t+ 5-- X-- R- tv- b++ DI D--- G e h! !r y- - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9NAvbZOfFgbBAbXARAsRtAJ9xNRAW5almaZdRQjCGzX9WXDx3rQCfSGgS g94q3+hAQ15APykdKAhEevk= =n35T -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson <[EMAIL PROTECTED]> said: > What we need is conditions in materials.xml; for example, within a > certain lat/lon rectangle, use a tumbled-down stone building for a > barn; within another, use a North-American wooden barn; and so on. We > already have XML conditions, so it's doable, but it will be a bit of > work all the same. Instead of allowing full conditions, we might > allow only a few criteria (maybe time of year, lat/lon, elevation, > slope). That would be useful for defining more realistic shoreline textures, rock colors, etc as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I have a Saitek Cyborg 3D Gold USB Stick
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > Once the kernel boots you might be able to grab something out of > /proc/pci (or other /proc entries.) There are probably hardware > detection software out there too. I think RedHat does a lot of that > (and I think Debian does hardware detection on a more limited scale.) > Kudzu is probing the package that does it, and it must use /proc/pci. You probably can build a module.conf on the fly with it, given good data. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP Who has DIS-specs ?
> Does anyone here have the exact DIS-specs ? I don't > like 'stealing' from a implementation, I rather build > it from scratch by specs, [...] You might try this as a starting point: http://www.pitch.se/fmv/default.htm Unfortunately the mentioned DMSO site is not availabe, but you will have success with searching for HLA High Level Architecture on Google, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
> We need a farmer and a tractor for the farm fields here in MN. If the > farmer's name was "Nic" then we could have a "Scenic overlook, [...] Hehe, we're also having really new sort of trouble with these trees - like having one standing right in front of the runway: http://document.ihg.uni-duisburg.de/bitmap/FGFS/tree-approach.png Fortunately one can fly through these trees ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
Erik Hofman writes: > David Megginson wrote: > > Over the weekend, I finished my first take on dynamically-placed > > scenery objects. > > I've tried it and it looks quite nice. It seems to have a very low > footprint (concerning framerate) so that's excelent as well. The only > problem I have is it either leaks memory like crazy (about 4Mb per > second) or it ernlarges the FlightGear memory footprint by more than 225 > Mb. :-( > > I've looked at the code but couldn't find a place where memory leaks > might happen. I suspected from all the extra disk activity that some sort of memory leaking might go on, but I only had a couple minutes to play last night so I didn't get a chance to take a closer look. 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
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson wrote: > Over the weekend, I finished my first take on dynamically-placed > scenery objects. I've tried it and it looks quite nice. It seems to have a very low footprint (concerning framerate) so that's excelent as well. The only problem I have is it either leaks memory like crazy (about 4Mb per second) or it ernlarges the FlightGear memory footprint by more than 225 Mb. :-( I've looked at the code but couldn't find a place where memory leaks might happen. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I have a Saitek Cyborg 3D Gold USB Stick
Martin Spott writes: > [... Curt wrote ...] > > Something I've always thought would be cool to mess around with (but > > never even have come close to having the time) would be to put > > together a custom linux distribution on a bootable cd that > > detected/supported a couple of the major 3d graphics cards. > > Some time ago I did a small Linux system, designed to run from a 16 MByte > read-only medium (flash disk, network, whatever you want). It would not be > difficult to put FlightGear on top. > > The difficulty is to detect the necessary hardware connected to the machine, > especially considering the graphics board. Does anyone have a link > describing hardware autodetection on Linux ? I don't Once the kernel boots you might be able to grab something out of /proc/pci (or other /proc entries.) There are probably hardware detection software out there too. I think RedHat does a lot of that (and I think Debian does hardware detection on a more limited scale.) 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
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
David Megginson writes: > Seriously, I am planning on adding the occasional barn, farmhouse, > silo, and blue aluminum storage shed. This points to another problem, > though -- as with textures, buildings will look very different in > different parts of the world and even in different parts of the same > country, province, state, or county. > > What we need is conditions in materials.xml; for example, within a > certain lat/lon rectangle, use a tumbled-down stone building for a > barn; within another, use a North-American wooden barn; and so on. We > already have XML conditions, so it's doable, but it will be a bit of > work all the same. Instead of allowing full conditions, we might > allow only a few criteria (maybe time of year, lat/lon, elevation, > slope). I could see that turning the materials.xml file into a complicated nightmare. However, it would be a nice feature to have. Perhaps the top level materials.xml could include a .xml for each material that has a long list of conditionals. That might keep things a little cleaner ... (?) 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
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
RE: [Flightgear-devel] ANN: a new dimension to FlightGear
David, > What we need is conditions in materials.xml; for example, within a > certain lat/lon rectangle, use a tumbled-down stone building for a > barn; within another, use a North-American wooden barn; and so on. We Splended idea. Besides, it would set us ahead of MS FS, which (AFAIK) basically does lack such a mechanism. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: a new dimension to FlightGear
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. 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
David Findlay writes: > Very nice. I tried to also do this ages ago but couldn't figure it > out. :-) What is the framework for creating the objects like? If a > good framework API could be developed, it would be easy for scenery > designers to add new objects that are locally appropiate. For > instance, kangaroos on runways in australia :-). Thanks, See my last posting. For my part of North America, it would be groundhogs on the runway, with the occasional deer or moose on smaller strips. Actually, you might want to animate these; it would be annoying if the kangaroo always blocked the same runway. 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
Curtis L. Olson writes: > We need a farmer and a tractor for the farm fields here in MN. If the > farmer's name was "Nic" then we could have a "Scenic overlook, he's > outstanding in his field." Ok, sorry about that, it was painful to > say, even for me. :-) Seriously, I am planning on adding the occasional barn, farmhouse, silo, and blue aluminum storage shed. This points to another problem, though -- as with textures, buildings will look very different in different parts of the world and even in different parts of the same country, province, state, or county. What we need is conditions in materials.xml; for example, within a certain lat/lon rectangle, use a tumbled-down stone building for a barn; within another, use a North-American wooden barn; and so on. We already have XML conditions, so it's doable, but it will be a bit of work all the same. Instead of allowing full conditions, we might allow only a few criteria (maybe time of year, lat/lon, elevation, slope). 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] Re: MP what data to send (summary 1)
"ace project" <[EMAIL PROTECTED]> wrote: > - Multicasting and broadcasting will NOT be in this > prototype, but base protocol should be able to handle > broacasting (without any change with current specs) Broadcasting should be there by default - all you need to do is give the peer IP as a broadcast address. > - Another question popped up, what Endian do we want ? Network byte order please. This ensures there are no confusion. Does not require a hack like in X-Plane where the packets are marked (wasting 2x4 byte int's) with the byte order markers. Also, network byte order to native o/s byte order conversion routines are part of the socket API. So no messing around writing custom byte swap routines (on any of these o/s's) when the language does not support it. > - I will post the encaptulation protocols tommorrow, > when I have translated their essence to English (they > are in Dutch atm, anybody wants them in Dutch ?) I can read Dutch without too much of a problem. But then (too my shame) I read and write English better than my native language, never mind Dutch. :-) > - There is another totally different design possible > Delayed transmission, delay EVERYBODY 1 sec and the > will all they exactly 1 sec out of sync. I dont think > its the way to go, but its worth mentioning it. Flying in the past...? Interesting... Curt, how about adding sub space anomolies too FG and get Dave to add support for warp engines. I'm sure we can do some very interesting TNG quantum stuff with this. :-) > BTW 2, don't look at typos, English is *not* my > primary language :) Not a problem. My Klingon spelling is a lot worse. :-) q'apla -- Billy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MP Who has DIS-specs ?
> AFAIK this is pretty similar to the algorithms used > in DIS > > Martin. Does anyone here have the exact DIS-specs ? I don't like 'stealing' from a implementation, I rather build it from scratch by specs, then messing around it other peoples low-level code. I also prefer open protocols, how else should one learn to make their own as good or better ? Leon __ 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] A real C172 cockpit
Curt, > I poked around for a few minutes but couldn't find a price on a full > panel package ... did you find one or were you just commenting on the > individual instrument prices? Go to the online store any try to buy some of the stuff. Aside the basic instruments (i/o circuit board, altimeter...), most of the stuff (switches, cover) is not yet available (they say in fall). Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
