Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 25, 2002 at 05:07:16PM -0800, Andy Ross wrote: > > No, it's not. Imagine what happens when one thread is reading it > > while another thread is writing to it. :-) > You missed my point. First, the Vector class *is* threadsafe; check > all the methods, they're synchronized. There is no way, in Java, to > corrupt the state of a Vector object by modifying it in multiple > threads. Okay okay, I'll admit that I'm not 100% (con)current on Java. > My point was that this buys you *nothing*. You can still write all > the race conditions you want by assuming that the object won't be > modified from another thread. See my post about the nuclear bomb > safety lock; even a perfectly threadsafe property system is > susceptible to race conditions. So essentially you are saying that it is impossible to completely defend against sloppy programming and lack of documentation. Or, to put it another way, if you make something foolproof, they just come up with a better fool. :-) > The point, again: *all* multithreaded code is susceptible to race > conditions and deadlocks. There is *no* way around this. Obviously. But my point is that you can hide a lot of the complexity that comes with multithreading, *if* you properly define the interfaces, and don't stray from the path. > Now, are you getting the point? :) Yes. We desperately need a comprehensive FG hacker's guide to the galaxy. :-) - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Mon, Feb 25, 2002 at 05:07:16PM -0800 X-S-Issue: [EMAIL PROTECTED] 2002/02/27 01:34:27 2ed0948a567b8aeaac36e3a8338e87ea -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx8KZsACgkQN880WP6HRIt/CwCfa/2C0NN+vWyjWW6/ySGccf5z 6ioAn0VfiySeXw6x1FmumRBABYrPNitL =Qx0v -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
>>I like the consept of multiple programs (communicating through sockets >>or pipes) over threading anyhow, and that *forces* you to think about >>it :-) >> >>You are right about the example you gave, the pth packages only >>removes the multiple r/w operations on the same value at the "same" >>time (which might be a good step foreward anyhow), but indeed it >>doesn't save you from *all* problems. >> > > ..say I build my self a plane the EAA (eea.org) way, in 4 years. > And that I want to use a class cockpit and build upon FlightGear code. > > ..which of the above concepts is easier to make airworthy, > and to certify as airworthy? The latter (if yo're concerned about software only). You could certify all the subprograms and the socket interface in seperate runs. Once certified there is no need to look after it, except when it changes. But changing one wouldn't hurt the others. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
On Tue, 26 Feb 2002 10:53:11 +0100, Erik Hofman <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Andy Ross wrote: > > > safety lock; even a perfectly threadsafe property system is > > susceptible to race conditions. > > > > The point, again: *all* multithreaded code is susceptible to race > > conditions and deadlocks. There is *no* way around this. The only > > way to avoid them is to be very, very careful with your design. You > > cannot rely on libraries to save you. You cannot rely on simple > > techniques to save you. You have only your mind, your experience, > > and the minds and experience of the yahoo threading cowboys working > > on the rest of the project to rely on. Now, are you getting the > > point? :) > > I like the consept of multiple programs (communicating through sockets > or pipes) over threading anyhow, and that *forces* you to think about > it :-) > > You are right about the example you gave, the pth packages only > removes the multiple r/w operations on the same value at the "same" > time (which might be a good step foreward anyhow), but indeed it > doesn't save you from *all* problems. ..say I build my self a plane the EAA (eea.org) way, in 4 years. And that I want to use a class cockpit and build upon FlightGear code. ..which of the above concepts is easier to make airworthy, and to certify as airworthy? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Erik Hofman wrote: > I like the consept of multiple programs (communicating through sockets > or pipes) over threading anyhow, [...] and - what I like most: It enables you to run different parts of the sim on different machines in case you lack CPU cycles at your workplace, 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] New subsystem: FGEnvironment
Andy Ross wrote: > safety lock; even a perfectly threadsafe property system is > susceptible to race conditions. > > The point, again: *all* multithreaded code is susceptible to race > conditions and deadlocks. There is *no* way around this. The only > way to avoid them is to be very, very careful with your design. You > cannot rely on libraries to save you. You cannot rely on simple > techniques to save you. You have only your mind, your experience, and > the minds and experience of the yahoo threading cowboys working on the > rest of the project to rely on. Now, are you getting the point? :) I like the consept of multiple programs (communicating through sockets or pipes) over threading anyhow, and that *forces* you to think about it :-) You are right about the example you gave, the pth packages only removes the multiple r/w operations on the same value at the "same" time (which might be a good step foreward anyhow), but indeed it doesn't save you from *all* problems. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen wrote: > Andy Ross wrote: > > For those with Java experience, consider the Vector class. It's > > threadsafe, right? > > No, it's not. Imagine what happens when one thread is reading it > while another thread is writing to it. :-) > > > Right. Now enumerate over it in one thread while > > modifying it in another. Is *that* threadsafe? :) > > Now what did I just say? Pay attention please. ;-) You missed my point. First, the Vector class *is* threadsafe; check all the methods, they're synchronized. There is no way, in Java, to corrupt the state of a Vector object by modifying it in multiple threads. Each thread is guaranteed to see a consistent object; there is no way to add two elements at the same index, for example, or to remove an item more than once. The library designers got this part right. Your suggestion about how to add threadsafety to the property system would achieve the same level of functionality. My point was that this buys you *nothing*. You can still write all the race conditions you want by assuming that the object won't be modified from another thread. See my post about the nuclear bomb safety lock; even a perfectly threadsafe property system is susceptible to race conditions. The point, again: *all* multithreaded code is susceptible to race conditions and deadlocks. There is *no* way around this. The only way to avoid them is to be very, very careful with your design. You cannot rely on libraries to save you. You cannot rely on simple techniques to save you. You have only your mind, your experience, and the minds and experience of the yahoo threading cowboys working on the rest of the project to rely on. Now, are you getting the point? :) 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
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 25, 2002 at 12:55:07PM -0800, Andy Ross wrote: > Martin van Beilen wrote: > > Actually it is fairly easy to make the property manager Thread > > Safe. All regular r/w locking can happen on a per-node basis, and > > can be encapsulated transparently. > Making the property manager threadsafe isn't the issue; sure it can be > done. The problem is that *using* the property manager (or anything) > from multiple threads leaves you open to race conditions that occur > due to unsynchronized changes to the property values. Hmmm.. I think we have different definitions of "threadsafe". > For those with Java experience, consider the Vector class. It's > threadsafe, right? No, it's not. Imagine what happens when one thread is reading it while another thread is writing to it. :-) > Right. Now enumerate over it in one thread while > modifying it in another. Is *that* threadsafe? :) Now what did I just say? Pay attention please. ;-) A solution is to subclass a MutexVector that provides transparent locking on member access. Since there is only one mutex involved, deadlocks cannot occur. It is now Thread Safe for all r/w operations. Of course, this breaks when deleting the vector. Which is what my earlier post was about. Not that it matters, since we're not doing multithreading on properties in the first place. :-) - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Mon, Feb 25, 2002 at 12:55:07PM -0800 X-S-Issue: [EMAIL PROTECTED] 2002/02/26 00:24:34 0800dc9a27bf18f991a6c1eb2a5bc123 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx6x7kACgkQN880WP6HRIsKIgCdFja4q0wUowN2D5WS4YaaLTp4 7roAoJeRQTRvEmPu//KaNi+MSR54IGm7 =6/c6 -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Erik Hofman wrote:
> Andy Ross wrote:
> > Amen. The only purpose to doing threading in a C/C++ environment is
> > SMP scalability (in Java, you have to use them for I/O multiplexing
> > too; I consider this a bug, but at least there you have language
>
> Well, the main reason for using multi-threading in a single CPU
> environment is to use the CPU cycles when a program (or thread) is in
> an IO lock ...
No. That's what I meant by "I/O multiplexing" in the java note, and I
hold to my statement: using threads for this is a bug. The right way
to do this is to use non-blocking or multi-blocking I/O calls
(select() being the poster child, but Win32 has non-blocking calls
too) that allow you to sanely and safely use the CPU at all times
without fear of race conditions.
> BTW. There are thread schedulers which work in a single address space,
> pth is one example:
>
> http://www.gnu.org/software/pth/
>
> This would remove the need for locking (expept for OpenGL I gueass).
Ack, no, it wouldn't. It would remove the need for locking against
preemptive scheduling that might schedule another thread. This is
*not* the only kind of race condition! For a specific example, you're
liable to the following bug:
if(!fgGetBool("/controls/trigger-safety-lock")) {
SG_LOG("Bombs away!");
dropNuclearArmament();
}
The race condition? The logging statement does I/O, and thus allows
the scheduler to pick another thread which might toggle the value of
the property. The safety lock thus isn't guaranteed to be off when
the bombs drop.
Now, you can fix this via explicit locking
("/controls/trigger-safety-lock-lock", heh), or implicit design (only
one thread sets the /controls tree). But simply saying expecting the
userspace thread library to keep you out of trouble isn't going to
work. You need to design threadsafety in from the beginning; no
options.
All of this is just a long-winded way of making Curt's point:
threading is a *hard* problem, and there's simply no way to make it
easy. There are no magic bullets here -- you can't use a single
library, or tool, or technique, and be able to say "my code is
threadsafe".
Threads are dangerous. Stay away whenever possible (this means: stay
away unless you need more than one thread for a fundamental reason,
like SMP scalability).
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
Re: [Flightgear-devel] New subsystem: FGEnvironment
Erik Hofman wrote: > > This would remove the need for locking (expept for OpenGL I gueass). guess, guess, guess. (I'm improving). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Andy Ross wrote: > Curtis L. Olson wrote: > > Threading is *really* scarey in a program of this magnitude. > > > > I'd be adverse to adding additional threading especially if it > > involves something like the property manager. > > > > There might be specific isolated instances where we can do it > > reliably, but there is way too much that can bite us if we try to do > > much threading. > > Amen. The only purpose to doing threading in a C/C++ environment is > SMP scalability (in Java, you have to use them for I/O multiplexing > too; I consider this a bug, but at least there you have language Well, the main reason for using multi-threading in a single CPU environment is to use the CPU cycles when a program (or thread) is in an IO lock ... BTW. There are thread schedulers which work in a single address space, pth is one example: http://www.gnu.org/software/pth/ This would remove the need for locking (expept for OpenGL I gueass). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen wrote: > Actually it is fairly easy to make the property manager Thread > Safe. All regular r/w locking can happen on a per-node basis, and > can be encapsulated transparently. The property manager seems like an > ideal candidate for IPC messaging, so if we want, it can be done. This is the Great Myth of multithreading. Threadsafe components are not sufficient to protect against threadsafety violations. The only way to avoid deadlocks and race conditions is for the whole architecture to support them from top to bottom. Making the property manager threadsafe isn't the issue; sure it can be done. The problem is that *using* the property manager (or anything) from multiple threads leaves you open to race conditions that occur due to unsynchronized changes to the property values. For those with Java experience, consider the Vector class. It's threadsafe, right? Right. Now enumerate over it in one thread while modifying it in another. Is *that* threadsafe? :) 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
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson wrote: > Threading is *really* scarey in a program of this magnitude. > > I'd be adverse to adding additional threading especially if it > involves something like the property manager. > > There might be specific isolated instances where we can do it > reliably, but there is way too much that can bite us if we try to do > much threading. Amen. The only purpose to doing threading in a C/C++ environment is SMP scalability (in Java, you have to use them for I/O multiplexing too; I consider this a bug, but at least there you have language syntax for the synchronization primitives). The property system is not likely, ever, to be a performance limitation requireing parallelization. There's nothing wrong with spawning a worker thread to do texture generation for a tile, or FDM computations, or whatnot. But glue them all together in the main loop. 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
Re: [Flightgear-devel] New subsystem: FGEnvironment
"Curtis L. Olson" wrote: > > D Luff writes: > > Fair enough. I was under the impression that it was the disk > > access taking the time. > > Registering new textures with opengl can take a noticable amount of > time (especially when they are large.) Freeing memory (and any > associated garbage collection) can actually be a *big* hit at times. > It actually is a very complicated problem to do tile paging properly > in a separate thread. What we have now mostly works but has grown > pretty ugly in response to some of the practical difficulties with > doing this well. Well, I don't know the current threading code (well, it won't run under MSVC anyway AFAIK). But I'm under the impression that on my compiles the disk access is quite a problem (noticeable 'jumps' for each tile). That's no surprise. Current disks have an access time of 10 ms. If we need - say - 10 files we'll have 100 ms. (unrealistical guess as there's caching, etc., but that's w/o the work that's done as soon as the files are loaded). 100 ms is 1/10 s and that's very noticeable. Just reading the data in an extra thread into a buffer and doing the rest in the main thread should help a bit. To avoid memory (re)allocation we can recycle that buffer. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Feb 24, 2002 at 08:27:37PM -0600, Curtis L. Olson wrote: > Threading is *really* scarey in a program of this magnitude. Even the > current threaded tile manager is a big time bomb waiting to happen. > We are getting away with doing stuff that's not guaranteed to work. > We've taken a lot of steps to try to minimize the potential problems, > but as the scenery and modeling gets more complex this problem is only > going to get worse. Well, I gather from your subtle hints that the property manager is only used by the main thread at this time. That simplifies things a lot. > I'd be adverse to adding additional threading especially if it > involves something like the property manager. Actually it is fairly easy to make the property manager Thread Safe. All regular r/w locking can happen on a per-node basis, and can be encapsulated transparently. The property manager seems like an ideal candidate for IPC messaging, so if we want, it can be done. - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sun, Feb 24, 2002 at 08:27:37PM -0600 X-S-Issue: [EMAIL PROTECTED] 2002/02/25 18:24:09 ec3e9cde4f3bf456ab66f6fa6ba31d85 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx6c0EACgkQN880WP6HRIvQQwCfWZVOC6Oj9jBVt56U3d+70PZe PugAn35OIGds3SrcdSfS+Es3DLWe7W8y =zugr -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
D Luff writes: > Fair enough. I was under the impression that it was the disk > access taking the time. Registering new textures with opengl can take a noticable amount of time (especially when they are large.) Freeing memory (and any associated garbage collection) can actually be a *big* hit at times. It actually is a very complicated problem to do tile paging properly in a separate thread. What we have now mostly works but has grown pretty ugly in response to some of the practical difficulties with doing this well. 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] New subsystem: FGEnvironment
Curtis L. Olson writes: > D Luff writes: > > Surely it is possible to do a byte by byte copy of the tile from disk > > to memory in a separate thread, without *any* Opengl/ssg/plib > > dependency, such that the main thread need only access memory > > and not disk? > > Surely it is possible, but if your goal is to push all time consuming > portions of the tile paging process out into a separate thread to > avoid rendering pauses, then this doesn't buy you as much as you > might hope. > Fair enough. I was under the impression that it was the disk access taking the time. Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
D Luff writes: > Surely it is possible to do a byte by byte copy of the tile from disk > to memory in a separate thread, without *any* Opengl/ssg/plib > dependency, such that the main thread need only access memory > and not disk? Surely it is possible, but if your goal is to push all time consuming portions of the tile paging process out into a separate thread to avoid rendering pauses, then this doesn't buy you as much as you might hope. 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] New subsystem: FGEnvironment
Curtis L. Olson writes: > David Megginson writes: > > What you need to do is isolate the tile manager completely, so that it > > has (almost) no dependencies on the rest of the program, except for > > one structure for data exchange. > > I don't think the solution can be that trivially simple. The render > thread has opengl/scene graph dependencies. The tile pager has > opengl/scene graph dependencies. That in itself forces you to do a > *lot* of horsing around. > > For instance, you can't directly call a plib model loader in the tile > paging thread because that could involve creating textures (which > would involve opengl calls) and you'd open yourself up for strange > crashes and wierd visual anomalies. Surely it is possible to do a byte by byte copy of the tile from disk to memory in a separate thread, without *any* Opengl/ssg/plib dependency, such that the main thread need only access memory and not disk? Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
David Megginson writes: > > Anyway, in the back of my head, someday, I want to try to develop a > > case against the threaded tile pager and maybe figure out a way to to > > partial per frame model loading and unloading ... not that I don't > > desparately wish we could do it, it's just that I'm not sure we can do > > it reliably in the face of all the things the tile loader will need to > > do in the long term ... (?) > > What you need to do is isolate the tile manager completely, so that it > has (almost) no dependencies on the rest of the program, except for > one structure for data exchange. I don't think the solution can be that trivially simple. The render thread has opengl/scene graph dependencies. The tile pager has opengl/scene graph dependencies. That in itself forces you to do a *lot* of horsing around. For instance, you can't directly call a plib model loader in the tile paging thread because that could involve creating textures (which would involve opengl calls) and you'd open yourself up for strange crashes and wierd visual anomalies. 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] New subsystem: FGEnvironment
Curtis L. Olson writes: > Textures: any threading that involves portions of opengl needs to be > handled very delicately. No, I wouldn't touch OpenGL. I'm talking about generating textures in-memory; they would then be passed off to the main thread for use by OpenGL. We're a long way from that, though, so there's no need to worry. > Anyway, in the back of my head, someday, I want to try to develop a > case against the threaded tile pager and maybe figure out a way to to > partial per frame model loading and unloading ... not that I don't > desparately wish we could do it, it's just that I'm not sure we can do > it reliably in the face of all the things the tile loader will need to > do in the long term ... (?) What you need to do is isolate the tile manager completely, so that it has (almost) no dependencies on the rest of the program, except for one structure for data exchange. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
David Megginson writes: > Threading is relatively safe if each thread is forced to play in a > sandbox. A subsystem running in a separate thread must *not* touch > any other subsystem (including the property manager), and must send > and receive all information through a single, tightly-controlled > interface. That implies that a subsystem in a separate thread should > not even include other FlightGear header files, much less access > FGGlobals, FGInterface, the property manager, or anything else > directly. > > The best candidates for separate threads are processes that have > relatively little input or output but require a lot of computation. > For example, if some day we have an incredibly sophisticated weather > simulator that actually models air currents over different terrain > types, we might actually let it do its computations in a low-priority > background thread and report back every minute or so. I don't think > that threads are a panacea for whatever ails us. Another good > candidate for a separate thread would be auto-generated, > smoothly-transitioning terrain textures. Textures: any threading that involves portions of opengl needs to be handled very delicately. OpenGL is single threaded / global state and can't tolerate any other threads calling opengl commands at arbitrary times. (What if the thread does something while the main render loop is between a glBegin() and glEnd() ... at best you'll get sporadic unintended visual effects, but at worst (which is the likelier case, the program will crash.) Likewise, anything that touches the scene graph needs to be done from the main thread, because if we are modifying the scene graph while plib is in the middle of an ssgCullandDraw() we could likewise crash the program. Model loading is tough to do in a thread because it wants to both load textures (and make opengl calls) and then modify the scene graph. Anyway, in the back of my head, someday, I want to try to develop a case against the threaded tile pager and maybe figure out a way to to partial per frame model loading and unloading ... not that I don't desparately wish we could do it, it's just that I'm not sure we can do it reliably in the face of all the things the tile loader will need to do in the long term ... (?) 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] New subsystem: FGEnvironment
Curtis L. Olson writes: > Threading is *really* scarey in a program of this magnitude. Even > the current threaded tile manager is a big time bomb waiting to > happen. We are getting away with doing stuff that's not guaranteed > to work. We've taken a lot of steps to try to minimize the > potential problems, but as the scenery and modeling gets more > complex this problem is only going to get worse. Threading is relatively safe if each thread is forced to play in a sandbox. A subsystem running in a separate thread must *not* touch any other subsystem (including the property manager), and must send and receive all information through a single, tightly-controlled interface. That implies that a subsystem in a separate thread should not even include other FlightGear header files, much less access FGGlobals, FGInterface, the property manager, or anything else directly. The best candidates for separate threads are processes that have relatively little input or output but require a lot of computation. For example, if some day we have an incredibly sophisticated weather simulator that actually models air currents over different terrain types, we might actually let it do its computations in a low-priority background thread and report back every minute or so. I don't think that threads are a panacea for whatever ails us. Another good candidate for a separate thread would be auto-generated, smoothly-transitioning terrain textures. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen writes: > Working from a single thread is obviously the easiest solution, > where possible. However, in the case of our property system, > potentially any part of the code may want to access those > properties. We'd have to assign one thread as the property > manager, and do all property access via the/an inter-thread > messaging system. Not very nice, IMHO. I think it would be better for the main thread to read the information from the property manager and then pass it to an object that the other thread can access. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Threading is *really* scarey in a program of this magnitude. Even the current threaded tile manager is a big time bomb waiting to happen. We are getting away with doing stuff that's not guaranteed to work. We've taken a lot of steps to try to minimize the potential problems, but as the scenery and modeling gets more complex this problem is only going to get worse. I'd be adverse to adding additional threading especially if it involves something like the property manager. There might be specific isolated instances where we can do it reliably, but there is way too much that can bite us if we try to do much threading. Curt. Martin van Beilen writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Sat, Feb 23, 2002 at 08:47:17PM -0500, David Megginson wrote: > > > Martin van Beilen writes: > > > It may be necessary to implement a locking scheme to prevent > > > simultaneous access and deletion of a property. (Only if DELETE > > > is set, of course.) > > > > From my experience with Java, I think the trick with threading is > > to do all write access from a single thread; otherwise, things get > > amazingly ugly (personally, I'd prefer doing all read access from that > > thread as well). > > Working from a single thread is obviously the easiest solution, > where possible. However, in the case of our property system, > potentially any part of the code may want to access those > properties. We'd have to assign one thread as the property > manager, and do all property access via the/an inter-thread > messaging system. Not very nice, IMHO. > > The only trivial solution I can think of is using one single > master lock for all dynamic access. Not particularly elegant > either. I can probably come up with a better (per-node) scheme, > but I need to t(h)read very carefully and give it some more > thought. I'm dropping this issue for now and will start working > on the cloud layers. > > - -- > Regards, "I RADIS, do you?" > =Martin=http://www.iradis.org/ > > PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B > > > From: Martin van Beilen <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment > In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on >Sat, Feb 23, 2002 at 08:47:17PM -0500 > X-S-Issue: [EMAIL PROTECTED] 2002/02/25 01:16:48 >a8e24c3bfcb47364f995b5835fa3f007 > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.6 (GNU/Linux) > > iEYEARECAAYFAjx5gngACgkQN880WP6HRItozACgoQYuPkPzkHpAIWQuQrrY01f9 > enUAnjIyPHx8eoqRofpsTG3CPqMMpqc+ > =5iLF > -END PGP SIGNATURE- > > ___ > 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] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Feb 23, 2002 at 08:47:17PM -0500, David Megginson wrote: > Martin van Beilen writes: > > It may be necessary to implement a locking scheme to prevent > > simultaneous access and deletion of a property. (Only if DELETE > > is set, of course.) > > From my experience with Java, I think the trick with threading is > to do all write access from a single thread; otherwise, things get > amazingly ugly (personally, I'd prefer doing all read access from that > thread as well). Working from a single thread is obviously the easiest solution, where possible. However, in the case of our property system, potentially any part of the code may want to access those properties. We'd have to assign one thread as the property manager, and do all property access via the/an inter-thread messaging system. Not very nice, IMHO. The only trivial solution I can think of is using one single master lock for all dynamic access. Not particularly elegant either. I can probably come up with a better (per-node) scheme, but I need to t(h)read very carefully and give it some more thought. I'm dropping this issue for now and will start working on the cloud layers. - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sat, Feb 23, 2002 at 08:47:17PM -0500 X-S-Issue: [EMAIL PROTECTED] 2002/02/25 01:16:48 a8e24c3bfcb47364f995b5835fa3f007 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx5gngACgkQN880WP6HRItozACgoQYuPkPzkHpAIWQuQrrY01f9 enUAnjIyPHx8eoqRofpsTG3CPqMMpqc+ =5iLF -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen writes: > Well, that's the easy part. We can add a DELETE flag and set it > on all dynamic properties. I'm more worried about multithreading. > It may be necessary to implement a locking scheme to prevent > simultaneous access and deletion of a property. (Only if DELETE > is set, of course.) >From my experience with Java, I think the trick with threading is to do all write access from a single thread; otherwise, things get amazingly ugly (personally, I'd prefer doing all read access from that thread as well). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Feb 23, 2002 at 06:16:19PM -0500, David Megginson wrote: > Properties exist for life because any number of different modules > might be holding pointers to them. We'll have to figure out some kind > of management scheme if we want node removal. Well, that's the easy part. We can add a DELETE flag and set it on all dynamic properties. I'm more worried about multithreading. It may be necessary to implement a locking scheme to prevent simultaneous access and deletion of a property. (Only if DELETE is set, of course.) - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Sat, Feb 23, 2002 at 06:16:19PM -0500 X-S-Issue: [EMAIL PROTECTED] 2002/02/24 01:02:26 8746db0a0cea416c4497d06a7120862e -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx4LZkACgkQN880WP6HRIuZhgCdFIFCkbgntF27zIl7nWTBQTlB ssEAnR4M9aB11Dgjyl7tnyjvEJAphsEi =YemD -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen writes: > Removal is a bit of a problem though. In the current situation > properties are created for "life". We could just leave unused > nodes, or I could add a delChild() method, or I could add it to > the destructor. What do you think? Properties exist for life because any number of different modules might be holding pointers to them. We'll have to figure out some kind of management scheme if we want node removal. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Feb 22, 2002 at 04:54:44PM -0600, Curtis L. Olson wrote: > However, it's more complicated with cloud layers. In the case were a > cloud layer disappears, or is added or changes types, we probably want > to do some sort of slow blending over time to make the transition less > apparent. Somewhere we need to track the 'current' values, the target > values, and where we are in the transition. Can't we just stick with magically appearing and disappearing layers for now? Sure, it's ugly, but better than nothing. You could maybe raise or lower a layer gradually, but blending is difficult. You'd need some kind of dynamic texture generator. In any case, both methods are unrealistic. In the real world clouds are individual objects. Clouds don't "blend", you simply fly past them much like you do with the ground scenery. IMHO the price(programmer hours) / performance(realism) ratio is not favourable. It'd be better to stick with magic layers for now, and move to volumetric clouds from there. That said, if anyone wants to go the distance and write the code, go right ahead. :-) - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Fri, Feb 22, 2002 at 04:54:44PM -0600 X-S-Issue: [EMAIL PROTECTED] 2002/02/23 21:45:17 9dccc70c8c7cdb47bb4b6660a8ca20dc -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx3/2QACgkQN880WP6HRIuLsACfa6OkaTAP+ZrOae9e7nhkXUtR CnwAn30/MvXaptp1h//VXY1I5n9R/dqx =SuAX -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Feb 22, 2002 at 05:46:11PM -0500, David Megginson wrote: > I'd suggest something like this: > /environment/cloud-layer[0]/enabled > /environment/cloud-layer[0]/type I'll stick to /environment/clouds/layer[n] for now. There's more to clouds than just layers. It can always be changed later. > and so on (I'm not sure exactly what sub-properties you'll need), up > to a maximum of, say, eight layers. Actually, I was thinking of adding and removing layers dynamically as needed. I extended the props interface so it can create nodes with values of any type. Removal is a bit of a problem though. In the current situation properties are created for "life". We could just leave unused nodes, or I could add a delChild() method, or I could add it to the destructor. What do you think? > Before too long, FGEnvironment will be able to modify these properties > dynamically during the flight, but to start, we'll just have to set > the properties manually in the property browser. Indeed. That's the general idea. - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Fri, Feb 22, 2002 at 05:46:11PM -0500 X-S-Issue: [EMAIL PROTECTED] 2002/02/23 20:48:54 fb987c4aba33a35a7765901a555eedf5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx38i0ACgkQN880WP6HRItobQCZAVI72FD1OW6sF7jKCUw7zY2E NiEAoK3ytkHtCAQHoeecDQOiYQzuwKcT =+Kuy -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Curtis L. Olson writes: > However, it's more complicated with cloud layers. In the case were a > cloud layer disappears, or is added or changes types, we probably want > to do some sort of slow blending over time to make the transition less > apparent. Somewhere we need to track the 'current' values, the target > values, and where we are in the transition. I'll naively suggest that that might be easy to manage: keep an FGEnvironment object for the current location, and (say) eight more in a circle around the current location with a certain horizontal offset (such as 10km), then interpolate. That makes the whole thing relatively stateless, if it can work. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen writes: > How about first seeing whether it would be useful (and possible) > to integrate some of that code before throwing out the baby with > the bathwater? Just for the record, nothing's being thrown out right now. Christian's code is still the default, and it's all still there. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
> That's also to be determined. As I mentioned, I'm working from front > to back. FGEnvironment contains a set of environment information for > a single place and time. Once we get that working better, I'll add > FGEnvironmentManager to get the environment information for places > (and times?) beyond the aircraft's current locus; at first, it will > return the same information for everywhere, but later it will start > differentiating in different ways. The rest of FlightGear won't have > to know about that -- all it has to know is how to get an environment > object: I've said it before and I'll say it again ... The METAR information is _mostly_ useless in describing both flight conditions and simulation parameters for the purposes of FlightGear. The purpose of the report is to describe conditions on the _surface_ and _at_ the airport with no considerations for anywhere else in the area. Only if you're doing touch-n-goes, is this valuable and appropriate. Once you leave the airport environment, either by climbing a few thousand feet, or by flying a couple of miles in any direction, the METAR no longer gives information, unless you use a WAG (wild assed guess) to extrapolate the whole airmass from it. > In time. It depends on how the manager develops. For now, I just > want to be able to have the basics: temperature, winds, clouds, > visibility, magnetic variation, etc. The only reporting format that describes local conditions, as seen by an aircraft and/or a pilot, is the PIREP. This is also the best way to describe the conditions that the instructor or pilot wishes to have created. It includes localization in position, altitude and time, as well as supporting airmass motion and temperature data. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 21, 2002 at 10:09:45PM -0500, David Megginson wrote: > > It seems to me that fgfs has some (a lot of?) 'orphaned' features. > > That's right -- I think we have to be stricter about not accepting > unintegrated code and about cleaning out code that's not being used. How about first seeing whether it would be useful (and possible) to integrate some of that code before throwing out the baby with the bathwater? I agree though, that we should ask contributors to integrate their code before accepting it. Personally, I like to start by defining the interface, documenting it, and then add code from there. Yes, I know I'm weird writing documentation before writing even a single line of code. :-) - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Thu, Feb 21, 2002 at 10:09:45PM -0500 X-S-Issue: [EMAIL PROTECTED] 2002/02/23 00:34:27 ab7aabfa707a0876ec94cd7a228a4d50 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx21YoACgkQN880WP6HRIshOwCeN8/4keEwWePgo63YAGJYrxDD JkgAoLAgSZPun9aVnJje7GxOwJKBJrIT =QpL0 -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
David Megginson writes: > Martin van Beilen writes: > > > After reading David's comments, I think I can safely add the > > property interface to SGCloudLayer. But I'm starting with the > > network interface. > > I'd suggest something like this: > > /environment/cloud-layer[0]/enabled > /environment/cloud-layer[0]/type > /environment/cloud-layer[0]/altitude-ft > /environment/cloud-layer[0]/thickness-ft > /environment/cloud-layer[0]/enabled > /environment/cloud-layer[1]/type > /environment/cloud-layer[1]/altitude-ft > /environment/cloud-layer[1]/thickness-ft > /environment/cloud-layer[2]/enabled > /environment/cloud-layer[2]/type > /environment/cloud-layer[2]/altitude-ft > /environment/cloud-layer[2]/thickness-ft > > and so on (I'm not sure exactly what sub-properties you'll need), up > to a maximum of, say, eight layers. > > Before too long, FGEnvironment will be able to modify these properties > dynamically during the flight, but to start, we'll just have to set > the properties manually in the property browser. David, >From a visual standpoint, FlightGear cares about visibility and cloud layers. These can change as you fly. In the case of visibility, the environment manager could hide the change logic and just provide a slowly changing value. However, it's more complicated with cloud layers. In the case were a cloud layer disappears, or is added or changes types, we probably want to do some sort of slow blending over time to make the transition less apparent. Somewhere we need to track the 'current' values, the target values, and where we are in the transition. Thinking about this more, it might work just fine to handle this on the flightgear side. FlightGear could keep track of the 'current' values and use the values in the property manager as the goal/target. The visual system could then slowly fade layers in and out, or move them up / down as needed. I probably need to think about this more, and I'm imposing my ideas for one particular cloud implimentation. Certianly there could be more advanced cloud effects if someone wanted to work on them. 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] New subsystem: FGEnvironment
Martin van Beilen writes: > After reading David's comments, I think I can safely add the > property interface to SGCloudLayer. But I'm starting with the > network interface. I'd suggest something like this: /environment/cloud-layer[0]/enabled /environment/cloud-layer[0]/type /environment/cloud-layer[0]/altitude-ft /environment/cloud-layer[0]/thickness-ft /environment/cloud-layer[0]/enabled /environment/cloud-layer[1]/type /environment/cloud-layer[1]/altitude-ft /environment/cloud-layer[1]/thickness-ft /environment/cloud-layer[2]/enabled /environment/cloud-layer[2]/type /environment/cloud-layer[2]/altitude-ft /environment/cloud-layer[2]/thickness-ft and so on (I'm not sure exactly what sub-properties you'll need), up to a maximum of, say, eight layers. Before too long, FGEnvironment will be able to modify these properties dynamically during the flight, but to start, we'll just have to set the properties manually in the property browser. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 21, 2002 at 07:51:01PM -0600, Curtis L. Olson wrote: > In this case, there is support at the simgear level for 'n' cloud > layers each with their own properties. However, there was no > 'interface' to this in flightgear and we only hardcoded in the > layers. No one has gotten around to building a proper interface. Well, today might be your lucky day. :-) After reading David's comments, I think I can safely add the property interface to SGCloudLayer. But I'm starting with the network interface. > Just like we have competing FDM's with different focus, strengths and > weaknesses, I don't think it is bad to have competing > weather/environment management systems with different focus, strengths > and weaknesses. In that case, would it be useful to make it a run-time option? - -- Regards, "I RADIS, do you?" =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Thu, Feb 21, 2002 at 07:51:01PM -0600 X-S-Issue: [EMAIL PROTECTED] 2002/02/22 18:22:52 2bb03599b8501d0f8a3d78403a39893d -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx2fnQACgkQN880WP6HRIs3IgCfcFGBZkzUnu5+NXysAsmAzKzg thEAni7T9NFeAiPQKg20D1pgqT+78LPu =0Sdw -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
[EMAIL PROTECTED] writes: > Is it safe to assume that if one wanted to add support for winds > aloft reports, they would only need to add code to acquire the data > and then parse it into some kind of data structure defined by your > system? That's to be determined. > How much support will there be for data beyond that which is included > in the METAR's? Winds aloft reports are one example of additional > data sources that exist outside FG, but not all weather data would > exist outside the application. That's also to be determined. As I mentioned, I'm working from front to back. FGEnvironment contains a set of environment information for a single place and time. Once we get that working better, I'll add FGEnvironmentManager to get the environment information for places (and times?) beyond the aircraft's current locus; at first, it will return the same information for everywhere, but later it will start differentiating in different ways. The rest of FlightGear won't have to know about that -- all it has to know is how to get an environment object: const FGEnvironment * env = globals.get_env_mgr()->getEnv(lat, lon, alt); As the quality of the information improves, the other FlightGear subsystems should be able to use it automatically; for example, the FDM might get FGEnvironment objects for the centre point of each lifting surface as well as for the CG; in the future, if we add microbursts (etc.), the FDMs will see them automatically. > It could be possible to have weather > data generated from inside FG itself in the form of thermals or "ridge > lift". (I use that term very loosely.) Would FGEnvironment be able to > accept and manage data from these various sources? In time. It depends on how the manager develops. For now, I just want to be able to have the basics: temperature, winds, clouds, visibility, magnetic variation, etc. > Will there be anything beyond basic interpolation? It depends on what people contribute. Right now, I'm trying to get the basic interface nailed down so that future work won't require too much extra integration in the rest of FlightGear. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
On Fri, 22 Feb 2002, David Megginson wrote: > > 2. conversion from raw form to a source independent format stored > > either in memory, or a persistent format > > Yes, if you mean METAR parsing and the like. Yes, that's what I meant. > I'll probably isolate that behind a generic interface, so that we > can use different kinds of information providers. It will be in > the Environment/ subdirectory, but will really be a separate > package behind the same front-end. Is it safe to assume that if one wanted to add support for winds aloft reports, they would only need to add code to acquire the data and then parse it into some kind of data structure defined by your system? How much support will there be for data beyond that which is included in the METAR's? Winds aloft reports are one example of additional data sources that exist outside FG, but not all weather data would exist outside the application. It could be possible to have weather data generated from inside FG itself in the form of thermals or "ridge lift". (I use that term very loosely.) Would FGEnvironment be able to accept and manage data from these various sources? > > 3. logical analysis of the code to isolate relevant data > > I'm not sure what you mean by "code" here. Oops, I meant data, not code. > If you mean interpolation among weather station data points, then > yes, I'll have to support that. Will there be anything beyond basic interpolation? > Right now there's a tiny bit of rendering code in FGEnvironment, > left over from the old FGWeather class, but I want to remove that > completely. Good to hear! > I'm following the build-for-today rule from Extreme Programming: > I'll add support for (say) volumetric clouds when we can render > volumetric clouds. We *can* render cloud layers today, so I will > add support for that. I'd just hate to see a chicken/egg situation arise where someone willing to improve the cloud visuals is turned off because FGEnvironment doesn't provide the necessary data in a usable manner. While implementing volumetric clouds might not be feasible today, I don't think anyone would argue that it will be soon. Much sooner if one were to aim for "faked" volumetric clouds like those in FS2002 or FLY2. I don't think it would be a waste of time to put a little thought into what better looking clouds might require from FGEnvironment. It could have a significant effect on how FGEnvironment deals with the data. Thad ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
[EMAIL PROTECTED] writes: > When you say "weather/environment management system" what do you mean? > Do you mean something that includes the following? > > 1. weather data retrieval mechanism Yes. I'm starting with the front-end (the interface between FlightGear and the rest of the environment code) and working backwards. FGEnvironment holds the weather information for a specific place and time; I'll also add an FGEnvironmentManager to look up the information for other arbitrary places and times (i.e. the ATIS station tuned in on COM1, or the left wingtip). > 2. conversion from raw form to a source independent format stored > either in memory, or a persistent format Yes, if you mean METAR parsing and the like. I'll probably isolate that behind a generic interface, so that we can use different kinds of information providers. It will be in the Environment/ subdirectory, but will really be a separate package behind the same front-end. > 3. logical analysis of the code to isolate relevant data I'm not sure what you mean by "code" here. If you mean interpolation among weather station data points, then yes, I'll have to support that. > 4. code to render the visible aspects of the weather No, that will be entirely separate. Right now there's a tiny bit of rendering code in FGEnvironment, left over from the old FGWeather class, but I want to remove that completely. > If so, that's cool, but to me it seems like this is sort of slicing > the pie the wrong way. I would hate to think that any alternate > "weather/environment management system would have to duplicate > functionality across so many layers of code. It just seems to me > that it would make sense to isolate the steps so that each one > could be replaced individually. Yes, I agree. I'm not touching rendering at all, and I'm going to be careful to keep the rest nicely segmented. > Also, are there any goals regarding weather in FG? If someone were to > rewrite the weather subsystem, would it be more appropriate to simply > do another system like what we have or would it be more appropriate to > plan for the day when we move beyond flat plane cloud layers? I'm following the build-for-today rule from Extreme Programming: I'll add support for (say) volumetric clouds when we can render volumetric clouds. We *can* render cloud layers today, so I will add support for that. > It seems that the current FG weather system is a lot like > X-Plane's. With the exception of ATIS reading the string > appropriate for its location, the weather for the entire world is > identical to the weather at the aircraft's current location. I think that everyone agrees that we want different weather at different locations. FGEnvironment will deal only with the data issues, not with the rendering issues (i.e. it's an open question whether you'll be able to *see* the different weather). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
On Thu, 21 Feb 2002, Curtis L. Olson wrote: > Just like we have competing FDM's with different focus, strengths > and weaknesses, I don't think it is bad to have competing > weather/environment management systems with different focus, > strengths and weaknesses. When you say "weather/environment management system" what do you mean? Do you mean something that includes the following? 1. weather data retrieval mechanism 2. conversion from raw form to a source independent format stored either in memory, or a persistent format 3. logical analysis of the code to isolate relevant data 4. code to render the visible aspects of the weather If so, that's cool, but to me it seems like this is sort of slicing the pie the wrong way. I would hate to think that any alternate "weather/environment management system would have to duplicate functionality across so many layers of code. It just seems to me that it would make sense to isolate the steps so that each one could be replaced individually. Also, are there any goals regarding weather in FG? If someone were to rewrite the weather subsystem, would it be more appropriate to simply do another system like what we have or would it be more appropriate to plan for the day when we move beyond flat plane cloud layers? It seems that the current FG weather system is a lot like X-Plane's. With the exception of ATIS reading the string appropriate for its location, the weather for the entire world is identical to the weather at the aircraft's current location. If one wanted to simulate approaching a line of thunderstorms, the weather model would need to manage the data in such a way that that different geographic areas could have different weather. Forgive me if I stepped on anyone's toes. Thad ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen writes: > > sorry, but I can't understand that. I don't know why you try to > > do multiple work instead of working together and increasing the > > output. > > That puzzled me too. It seems to me that fgfs has some (a lot of?) > 'orphaned' features. The problem is that the code is there, but > there's no way to activate these features, and no documentation. That's right -- I think we have to be stricter about not accepting unintegrated code and about cleaning out code that's not being used. We have very, very few active developers on the project, and each of us can concentrate only on a tiny area at once (between bug fixes). Christian's code looks nice, but it has sat mostly unintegrated for one (maybe two) years. So far, I'm adding my code in a separate module and leaving Christian's as the default; you have to configure --with-new-environment to get mine. If mine ends up doing what we need, we'll switch the default and move Christian's code to the attic; otherwise, we'll bug Christian to integrate his code and move mine to the attic. There's nothing personal, either way -- that's just how Open Source works (look at the memory-management wars in the Linux kernel for a more brutal example). > For example, I've found that the code supports multiple cloud > layers with varying degrees of coverage, from FEW to OVC. I'm going to try to pull that in to the new environment module. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen writes: > It seems to me that fgfs has some (a lot > of?) 'orphaned' features. The problem is that the code is there, > but there's no way to activate these features, and no > documentation. > > For example, I've found that the code supports multiple cloud > layers with varying degrees of coverage, from FEW to OVC. The > required textures appear to be present. Unfortunately users can > only set the cloud base for the first layer. Its coverage is > hard-coded to BKN, and the second layer is hardcoded FEW190. In this case, there is support at the simgear level for 'n' cloud layers each with their own properties. However, there was no 'interface' to this in flightgear and we only hardcoded in the layers. No one has gotten around to building a proper interface. Someone came along and added an option to set _just_ the bottom layer. A little strange and far from complete, but I was told it was better than nothing. Ok ... I went ahead and added the code. But, we really should fix this, and add a flightgear interface for setting arbitrary cloud layers, as well as some mechanism to change cloud layers and have the visuals smoothly adjust over some time period. > Eventually I'd like to be able to add and remove cloud layers on > the fly. I propose the following properties: > > /environment/clouds/layer[n]/ > (layers can be added from command-line, > configuration file or on-the-fly.) > > altitude-ft (double) > thickness-ft (double) > > transition-ft (double) > (what does transition do?) > > coverage (double) > [0.0 - 1.0] sky coverage fraction; also obsoletes > status property. (0 -> status=false) > > type (string) > Cumulus|Stratocumulus|Stratus|Cirrus > > speed-from-north-fps (double) > speed-from-east-fps (double) > moving clouds, not implemented yet (is the > convention for clouds to or from?) > > I'm not touching any weather-related code until this new > environment thing is resolved. I could get started on the network > interface though. I want to tread carefully here but I'll make a couple comments ... the WeatherCM code was added some time ago, but it really did very little as far as interacting with FlightGear. It mostly sat as a placeholder waiting for someone to come along and find a way to populate the database with live weather values and then build an interface so that flightgear would honor the local weather values as queried from the weather database. The flip side of this was that the FDM's really didn't do much with wind, temp, or pressure a year ago and we didn't have a way to transition between changing cloud layers. Now, the FDM's do a lot with honoring weather variables, but the weather database is complicated enough that it is difficult for anyone to come along and 'get there head around' it enough to finish the task of completely integrating it. I think what David is trying to do here is creating an alternate 'simple' weather system. Something that has much less startup overhead, something that is easier to get your head around, and something that can be more easily integrated. In some ways this is a good thing becuase if we get one weather system integrated properly and work out all the issues, then it will clear the path for the other one, so that hopefully somebody will come along and finish up the integration of WeatherCM so that it can be a fully functional system. Just like we have competing FDM's with different focus, strengths and weaknesses, I don't think it is bad to have competing weather/environment management systems with different focus, strengths and weaknesses. I don't think people should read too much into adding an alternate environment subsystem ... especially if it prompts / helps get WeatherCM more integrated and working with the rest of FGFS in the long run. 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] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Feb 20, 2002 at 07:16:59PM +0100, Christian Mayer wrote:
> sorry, but I can't understand that. I don't know why you try to do
> multiple work instead of working together and increasing the output.
That puzzled me too. It seems to me that fgfs has some (a lot
of?) 'orphaned' features. The problem is that the code is there,
but there's no way to activate these features, and no
documentation.
For example, I've found that the code supports multiple cloud
layers with varying degrees of coverage, from FEW to OVC. The
required textures appear to be present. Unfortunately users can
only set the cloud base for the first layer. Its coverage is
hard-coded to BKN, and the second layer is hardcoded FEW190.
That's one low-effort high-yield fix found, investigation
continues.
Eventually I'd like to be able to add and remove cloud layers on
the fly. I propose the following properties:
/environment/clouds/layer[n]/
(layers can be added from command-line,
configuration file or on-the-fly.)
altitude-ft (double)
thickness-ft (double)
transition-ft (double)
(what does transition do?)
coverage (double)
[0.0 - 1.0] sky coverage fraction; also obsoletes
status property. (0 -> status=false)
type (string)
Cumulus|Stratocumulus|Stratus|Cirrus
speed-from-north-fps (double)
speed-from-east-fps (double)
moving clouds, not implemented yet (is the
convention for clouds to or from?)
New commands for network properties interface:
mk{bool,int,long,float,double,string}
Create (and set) value of specified type
mkdir, rm (with alias rmdir)
you get the idea
Commands to be changed:
set
refuses to create new nodes (currently creates strings)
cd
refuses to 'enter' nodes with values
Misc:
Design a scheme to prevent deletion of "standard"
properties. (Add a FIXED attribute to SGPropertyNode?)
I'm not touching any weather-related code until this new
environment thing is resolved. I could get started on the network
interface though.
Comments?
- --
Regards, "I RADIS, do you?"
=Martin=http://www.iradis.org/
PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B
From: Martin van Beilen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on
Wed, Feb 20, 2002 at 07:16:59PM +0100
X-S-Issue: [EMAIL PROTECTED] 2002/02/22 01:33:59
d40c2b6286479dc223dfafa8e81fdf19
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
iEYEARECAAYFAjx1kgEACgkQN880WP6HRIvvYgCgiqaDwesPe1x0BXfRRysH9NTE
rkcAn1u8xThPV9W+cQTtgUpKFMTGd38P
=iy+s
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
David Megginson wrote: > > I've committed the start of a new environment subsystem to the CVS. Hi, sorry, but I can't understand that. I don't know why you try to do multiple work instead of working together and increasing the output. Apart from the FDMs using the weather stuff (all the necessary properties are already exported so that should be a no brainer) and a cryptic "set-up" system everything's there. - layerd winds - world wide coverage - layered temperature - realistical air pressure (not that of the tables that can't take tamperature into consideration) - gusts (ok, there's some code missing here, but it should be easy to add) - "realtime" worldwide weather So what's missing? - METAR - an easy menu that allows you to set the weather manually but if you write that anyway, why aren't you writing it for the existing code? > Otherwise, FlightGear still defaults to Christian's weather subsystem. > I am designing the new subsystem to be simpler than Christian's but > well integrated into the rest of the program. The only integration that's missing are the FDMs. And those can use the current exported properties easily. > Right now, it simply > tracks winds and visibility for a single point, but soon I'll be > adding temperature, variability (i.e. gusts and changing wind > direction), air pressure, magnetic variation, cloud information, and > possibly even humidity and precipitation. Have you thought about world wide coverage? Or at least as few stations? Adding that and you are as complex as the WeatherDB. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Feb 2002 01:32, you wrote: > locations, together with METAR parsing (of course), but that may have Can we have a menu option for automatically downloading METAR's, as well as an option to import/export metar file? BTW, Curt do you still have that site running with zipped up metars updating hourly? Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8c2dmF2H7v0XOYBIRAuGGAJsEQRsNTApfTjczZlqNugB6LcPUFACeNWqk 9kTUIYMB26DxNoDQq88p3ts= =V/st -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
