[Flightgear-devel] Shader menu structure
Anyway, just reporting what I see, but I am sure other users must get VERY confused by such strange - it works, then it does not work - behavior... but I suppose when it is all documented the sun will shine, and shadows cast... Indeed. Forum reports suggest that users do get confused. So what do we do? The problem: A shader for object X isn't an independent entity which you can switch on and off at your leisure independent of what else is going on - it needs to share the fogging and lighting scheme of the rest of the scene, otherwise it creates visual artefacts. At the moment, we have three such schemes: a) default in which the light is always the sunlight and the fog is always exp(-(const * length/vis)**2) b) Rembrandt in which the light can come from multiple sources and sunlight may be blocked by a shadow, fog remains as is c) Lightfields in which the sunlight is the only light source but at dusk or dawn becomes a function of position in the scene and in which the fog has a more complicated 2 component structure Each of the schemes has a justification to be there in terms of features vs. performance. Making a shader of one scheme work in a different scheme is a non-trivial exercise, in the case of water reflection shader into lightfields it cost me about half a week of really good coding time (kids with grandparents). So we simply don't have all shaders in all schemes, and I don't even know if all would run with enough fps in all schemes. How to present it to the user? I don't know off-hand how Rembrandt handles non-Rembrandt shaders. In the lightfield scheme, the first solution was to let the user do the configuration, i.e. when the main selector (skydome/atmospheric scattering) was checked, all other special shaders continued to work, leading to really bad visual artefacts and a couple of bug reports. No good. The current solution involves overrides - the lightfield scheme declares before the default scheme, and as a result when lightfields are on, the shader configuration menu in essence changes function and switches higher detail shaders on only if implemented, whereas sliders do nothing if the corresponding shader isn't implemented. That's a good solution insofar as it largely prevents users from creating visual mismatches between schemes, but leads to complaints that 'shader X doesn't work when atmospheric light scattering is on'. So, still not good enough and creating confusion. *The* solution is of course to make all shaders work in all schemes. Certainly not for 2.8, that would be my 3.0 idea as stated elsewhere. In the meantime, what would be the best way to make it clear in the GUI that Rembrandt and lightfields are genuinely different lighting schemes and come with their own set of shaders? Should there simply be text in the GUI? Should there be an on-screen message printed? Should the GUI change in some way and present only the actually existing options dependent on scheme? Please give some feedback - how can we communicate better what is happening and why there are limitations? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] www.whenthunderrolled.com
Hi All, I received this today. It is a commercial venture, so I don't feel inclined to contribute directly. Has anyone else been contacted by them? This bit keep between us of course made me feel like a child being groomed for nefarious reasons. Cheers, Vic Hi Vic, We know it might be a long shot, but figured why not at least reach out. Please keep between us of course, but would you ever have an interest in supporting/contributing some of your models to this historical project designed to replicate the experiences of a decorated fighter pilot? We have partnered with other individuals from the FlightGear community already and it has been a great experience. Let me know your thoughts when you can and you can read more about the project at... Read more here: www.whenthunderrolled.com Thanks for your time and consideration. Regards, Steve-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] www.whenthunderrolled.com
Do you want to contribute your free models to our commercial product? Seems there *is* a reason for my NCGC* license after all... *(Non-commercial use only; give credit where due) *Shakes head* B. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
Hi Thorsten, As of my last rendering dialog update, atmospheric scattering shader options are invisible when Rembrandt is enabled. We could apply that same scheme to all the other effects... But I sort of lost track of what effects do work and what do not. The water shader for example looked better than ever with Rembrandt enabled, until Fred told me it wasn't supposed to and I found out that it only looks okay at certain times of day... So.if.someone.could.setup.a list of effect(combination)s that don't work, I can try to construct something. Cheers, Gijs From: thorsten.i.r...@jyu.fi To: flightgear-devel@lists.sourceforge.net Date: Tue, 19 Jun 2012 09:23:09 + Subject: [Flightgear-devel] Shader menu structure Anyway, just reporting what I see, but I am sure other users must get VERY confused by such strange - it works, then it does not work - behavior... but I suppose when it is all documented the sun will shine, and shadows cast... Indeed. Forum reports suggest that users do get confused. So what do we do? The problem: A shader for object X isn't an independent entity which you can switch on and off at your leisure independent of what else is going on - it needs to share the fogging and lighting scheme of the rest of the scene, otherwise it creates visual artefacts. At the moment, we have three such schemes: a) default in which the light is always the sunlight and the fog is always exp(-(const * length/vis)**2) b) Rembrandt in which the light can come from multiple sources and sunlight may be blocked by a shadow, fog remains as is c) Lightfields in which the sunlight is the only light source but at dusk or dawn becomes a function of position in the scene and in which the fog has a more complicated 2 component structure Each of the schemes has a justification to be there in terms of features vs. performance. Making a shader of one scheme work in a different scheme is a non-trivial exercise, in the case of water reflection shader into lightfields it cost me about half a week of really good coding time (kids with grandparents). So we simply don't have all shaders in all schemes, and I don't even know if all would run with enough fps in all schemes. How to present it to the user? I don't know off-hand how Rembrandt handles non-Rembrandt shaders. In the lightfield scheme, the first solution was to let the user do the configuration, i.e. when the main selector (skydome/atmospheric scattering) was checked, all other special shaders continued to work, leading to really bad visual artefacts and a couple of bug reports. No good. The current solution involves overrides - the lightfield scheme declares before the default scheme, and as a result when lightfields are on, the shader configuration menu in essence changes function and switches higher detail shaders on only if implemented, whereas sliders do nothing if the corresponding shader isn't implemented. That's a good solution insofar as it largely prevents users from creating visual mismatches between schemes, but leads to complaints that 'shader X doesn't work when atmospheric light scattering is on'. So, still not good enough and creating confusion. *The* solution is of course to make all shaders work in all schemes. Certainly not for 2.8, that would be my 3.0 idea as stated elsewhere. In the meantime, what would be the best way to make it clear in the GUI that Rembrandt and lightfields are genuinely different lighting schemes and come with their own set of shaders? Should there simply be text in the GUI? Should there be an on-screen message printed? Should the GUI change in some way and present only the actually existing options dependent on scheme? Please give some feedback - how can we communicate better what is happening and why there are limitations? * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel
Re: [Flightgear-devel] Shader menu structure
So.if.someone.could.setup.a list of effect(combination)s that don't work, I can try to construct something. From my side: Lightfields currently support - of the detailed shader config dialog: water reflection (water slider) and snow/dust (currently on landmass slider), all other sliders are ignored - of other shader-generated stuff: 3d-clouds, Stuart's random buildings, random vegetation is unsupported * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A plan for a 3.0 release?
On Wednesday 13 June 2012 12:05:42 Renk Thorsten wrote: Now, random vegetation seems to increase vertex count a lot, and this may well be not doable by just taking the code and applying it to the vegetation (it didn't work with clouds either). So it probably needs a dedicated approximation scheme making use of the fact that vegetation is drawn relatively close to the position and not 100 km distant to run at all. Given my framerate when switching on lightfields and random vegetation without lightfield shading, I'm not too optimistic :-( But worth a try. * Thorsten There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as: float fragmentDepth = gl_ProjectionMatrix[3].z/(gl_FragCoord.z * -2.0 + 1.0 - gl_ProjectionMatrix[2].z); (Currently, if taking depth info in the vertex shader for the trees, you need to do some ugly hacks to get the right depth, hacks that fail to work most of the times. ) As for performance concerns, yes, fragment operations might be slower than vertex ones for the same complex task, but they are generaly done on a limited amount of fragments that varies only with camera position/orientation and isn't adversely affected by high vertex count scenes. And the trend is for vertex count increase. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A plan for a 3.0 release?
There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as (...) Right... but I need the projection of the vertex position into the sun direction in the horizon plane to compute light - that's the part which doesn't go easily into the fragment shader. Maybe we have enough varying to pass all raw vectors involved right through the vertex shader - then everything can be done in the fragment part? The problem might also be that similar to clouds, tree textures are transparent in places, and so the fragment part may be slower than expected (for clouds, moving too much into the fragment shader gets very slow for that reason). Thanks for the suggestion in any case - plenty of things need to be tried... * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A plan for a 3.0 release?
On Tuesday 19 June 2012 12:29:34 Renk Thorsten wrote: There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as (...) Right... but I need the projection of the vertex position into the sun direction in the horizon plane to compute light - that's the part which doesn't go easily into the fragment shader. Maybe we have enough varying to pass all raw vectors involved right through the vertex shader - then everything can be done in the fragment part? The problem might also be that similar to clouds, tree textures are transparent in places, and so the fragment part may be slower than expected (for clouds, moving too much into the fragment shader gets very slow for that reason). Thanks for the suggestion in any case - plenty of things need to be tried... * Thorsten Just look in the tree shader, there's a line there dropping the fragment if it hits the transparent part, so no there won't be any penalty incurred for the transparent bits in the trees. You can have the position, properly interpolated, in the fragment shader. You already have it in most shaders. And if you don't you just replace the current varying holding the result of your work in the vertex shader with a varying passing the position/ecPosition depending on what you need. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
Please try https://gitorious.org/fg/fgdata/merge_requests/163 We basically open a special shader dialog when the lightfield renderer is enabled; a dialog without all the shaders that are not supported. Also moved the atmospheric sliders to that dialog, as those are advanced options. I did not disable the random vegetation, as people (including myself) might prefer to have badly fogged trees over no trees at all. Fog is the only issue, right? Comments are welcome. Gijs -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] www.whenthunderrolled.com
On Tue, 19 Jun 2012 12:04:48 +0200, Björn wrote in message cadxdtfju8rs3btbhrksc_x5psh_vwayhw4vq+y4scao-umm...@mail.gmail.com: Do you want to contribute your free models to our commercial product? ..they ask nicely, and it _sounds_ (to me) like they want to dual-license their commercial product. ..in my opinion, they should launch their product the way Red Hat launched their distro business in the 1990ies, a set of binaries for money, and the source for free, and both under the GPL. :o) Seems there *is* a reason for my NCGC* license after all... *(Non-commercial use only; give credit where due) ..your NCGC license is not compatible with the GPL, because of your 2 additional requirements. You can of course dual-license your own work as you see fit. *Shakes head* ..no conflict with the GPL. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..subtle FG AR inspirational video, was: Volunteer required in Edinburgh, Scotland
On Mon, 18 Jun 2012 20:50:10 +0100, Stuart wrote in message CAP3ntytK3WkTKdaJ2ojAApoBghScjsS=M9E=k_s_y9g+hcs...@mail.gmail.com: There's a rather dull picture here showing the setup of a single projector and a joystick: http://wiki.flightgear.org/File:FlightGear_demo_at_museum.jpg ..20 more minutes of subtle FG AR inspiration, from rocket science to the 8'th mass medium :o) http://www.youtube.com/watch?v=EvyfHuKZGXU -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] www.whenthunderrolled.com
For whatever it's worth, my reading of their site suggested that they are basing their commercial product off some other software/simulation engine and are looking for content. If they are proceeding with permission of the content authors and in compliance with licensing then I wish them all the best. And I think it's worth noting that these guys are generally creating content and scenarios; they are building stuff; adding to what's already there and rolling in the experience of a real combat pilot. This is a ton of time and effort (they aren't simply copying someone else's work and trying to spam the internet with it like some of our less favorite friends are known to do.) Curt. On Tue, Jun 19, 2012 at 10:09 AM, Arnt Karlsen wrote: On Tue, 19 Jun 2012 12:04:48 +0200, Björn wrote in message cadxdtfju8rs3btbhrksc_x5psh_vwayhw4vq+y4scao-umm...@mail.gmail.com: Do you want to contribute your free models to our commercial product? ..they ask nicely, and it _sounds_ (to me) like they want to dual-license their commercial product. ..in my opinion, they should launch their product the way Red Hat launched their distro business in the 1990ies, a set of binaries for money, and the source for free, and both under the GPL. :o) Seems there *is* a reason for my NCGC* license after all... *(Non-commercial use only; give credit where due) ..your NCGC license is not compatible with the GPL, because of your 2 additional requirements. You can of course dual-license your own work as you see fit. *Shakes head* ..no conflict with the GPL. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] www.whenthunderrolled.com
On Tue, 19 Jun 2012 10:21:33 -0500, Curtis wrote in message cahtsj_dni0cdegbx0stxwjwh9j5vfxf2aderk5jpde40n1s...@mail.gmail.com: For whatever it's worth, my reading of their site suggested that they are basing their commercial product off some other software/simulation engine and are looking for content. If they are proceeding with permission of the content authors and in compliance with licensing then I wish them all the best. And I think it's worth noting that these guys are generally creating content and scenarios; they are building stuff; adding to what's already there and rolling in the experience of a real combat pilot. This is a ton of time and effort (they aren't simply copying someone else's work and trying to spam the internet with it like some of our less favorite friends are known to do.) Curt. On Tue, Jun 19, 2012 at 10:09 AM, Arnt Karlsen wrote: On Tue, 19 Jun 2012 12:04:48 +0200, Björn wrote in message cadxdtfju8rs3btbhrksc_x5psh_vwayhw4vq+y4scao-umm...@mail.gmail.com: Do you want to contribute your free models to our commercial product? ..they ask nicely, and it _sounds_ (to me) like they want to dual-license their commercial product. ..I got too triggerhappy here, I _meant_ to say: they ask nicely, and it _sounds_ (to me) like they want to dual-license your code, art etc GPL work, for use in their commercial product. ..in my opinion, they should launch their product the way Red Hat launched their distro business in the 1990ies, a set of binaries for money, and the source for free, and both under the GPL. :o) Seems there *is* a reason for my NCGC* license after all... *(Non-commercial use only; give credit where due) ..your NCGC license is not compatible with the GPL, because of your 2 additional requirements. You can of course dual-license your own work as you see fit. *Shakes head* ..no conflict with the GPL. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] www.whenthunderrolled.com
Le 19/06/2012 11:49, Vic Marriott a écrit : Hi All, I received this today. It is a commercial venture, so I don't feel inclined to contribute directly. Has anyone else been contacted by them? Yes, I think so. I've been contacted privately around October 2010 by Steve (Swanbast ?) who was very kindly asking permission to use some of my models suitable for Vietnam war era. As all the models were already licensed under the GPL and also as Steve was asking with a lot of attention, I said him okay for the models I had 100% authorship (namely the A-6 Intruder and a few hangars). I'm happy to see that his project is going well along. Alexis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] mpserver02 mpserver07
Hi, Can anyone tell me definitively (or close to definitively, or even speculatively) what the status of mpserver02.flightgear.org and mpserver07.flightgear.org are? I can't ping them at the moment. Host names are cheap (maybe even cheaper than version numbers) but if these hosts are long gone, we might as well recycle an old number in sequence rather than creating a new host name and leaving dead gaps in the sequence. Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A plan for a 3.0 release?
Fragment discard isn't anywhere near as free or beneficial as you think it is. It's pretty crippling on a lot of older hardware. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Slow frame rates
Hi, On Sunday, June 17, 2012 13:00:15 castle...@comcast.net wrote: This email rekindled an idea from a while back. Last year while working on the 747 sim with multiple projectors and a quad core CPU I experimented with setting up three instances of fgfs - one for each cpu, graphics card, and projector. The improvement in the frame rate was quite dramatic; from around 20-22 fps to over 55 fps for each instance. The down side was that all the dynamic features (3d clouds, AI objects, random stuff, etc) all ran in their own graphics context. so while all the static scenery sync'd across the projectors, the dynamic objects ended at the display boundaries. Multi-core machines have been around for some time now. Perhaps it is time to think beyond running Flighgear as a monolithic process in a single CPU configuration. It is my understanding that all three platforms ( MS, Mac, Linux) support some form of shared memory IPCs. I use shared memory in the 737/747 cockpit software to great advantage with a global section for all common data and sharing data between the Captian, FO, and MCDUs processes. In Linux creating a shared memory segment is simple and straight forward. The master fgfs would create the shared segment and compute the graphical objects, in this case clouds and AI, and the fgfs slaves would simply access the shared segment for the data required to create their visual scene. Hopefully, I'll have some time in the fall to pursue this idea further. In the mean time, the floor is open to anyone who would like to comment or pursue this idea on their own. Well, that's about what I am about to do with the HLA stuff. The nice thing is that the ipc is hidden behind something that is also able to distribute this across multiple machines. A local network connect is mostly sufficient. But doing the same by an infniband connect is possible too. Experimenting with shared memory did not bring notable improovements over a system local network connect. At least not on linux... In any case I think this could be fast enough to do this stuff. Also this stuff is based on a standard that is probably enables us to be a little more connective in the end. At least this is a slight hope from me. John, by this way, I did send you some mails regarding the unwrapping, but did never get an answer - did you recieve them? Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
