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
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
-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
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
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
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: 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: 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
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: 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: 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 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
Martin van Beilen wrote: Actually it is fairly easy to make the property manager Thread Safetm. 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
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
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
-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 Safetm. 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 Safetm 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
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
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 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
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 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: 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
[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 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: 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
-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
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
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
