Re: [Flightgear-devel] multiplay refuel test
Hi Geoff i guess you are seing something like that: http://www.youtube.com/watch?v=VWn6_RFp97Y where this is the closest you can see the following plane, but in fact he see itself very close to the drogue and what you want is like this: http://www.youtube.com/watch?v=kGHRDrc_n98 you should have a look at this page, wip but working fine for the few pilots testing it : http://wiki.flightgear.org/Mp-patch basically the mp sending rate is fine with 10 pps, but you need a way to compensate for the lag. I can't try a refuel with you before this WE, but i will if you are still flying the victor somewhere. jano > NOTAM: > > To flyers who fly 'probe' enabled aircraft in Europe... or > even if NOT... > > I will be flying the 'victor' refueling tanker for the next > few days from KFPY, south 180 track, then turn around at the > southern mountains, north on 360, at 12,000 feet – FL120 > STD QNA – and am interested in 'hot' flyers who want to try > air-to-air REFUELING (AAR) in suitably equiped aircraft, > well ANY aircraft... > > The tanker will maintain, under autopilot, 220 knots (KTAS), > at the said 12,000 feet, either 180 or 360, under the callsign > GA006. > > The flights will commence about noon, or before, UTC, and > close about 20:00 UTC. > > The track can be followed using http://test.fgx.ch, or other mp > map URLS. Click on 'GA006' to localize... > > Reason: > > (a) I have tried with several aircraft over the last few days, and > learned that this is QUITE difficult, but I hope NOT impossible! > > (b) The present suggested pps (Hz) is 10 when you set up –multiplay=, > but FG 2.11 has fill-in extrapolation code when fgfs packets > do not arrive in time, so maybe this is too high. This is the basic > question... > > So the idea is to reduce this IFF this fill-in code helps, ie does its > job... > > The theoretic idea is that with this code we can reduce the > bandwidth used by 10 Hz to perhaps 2-4 Hz, but this needs > to be FULLY tested, and confirmed... > > Now I have tried this over several day, in several aircraft – > A-10, f-14b, a4 and failed, FAILED to touch the trailing > drogues... it is TOUGH... autopilots help you get to the 'zone' > but it needs manual flying to get to the RIGHT PLACE... > > If you are using a joystick maybe you need to even adjust > the dead spot and the 'sensitivity' of the inputs... lots of > learning, understanding and doing fgdata xml changes... > > And I have had a few pilots joining in ad hoc, but so far > no one has actually contacted with the trailing outer wing > drogues... The 'victor' can refuel 2 aircraft at a time... and I > would LOVE to see/capture that... > > One, french I think, got so frustrated at his attempts, began firing > missiles at the tanker. Thankfully, he MISSED, but was CLOSE ;=)) > > Also if you alert me to your attempt to refuel from my tanker, via > mp chat, email, fgcom, … AND I am on board at the time -: > > (a) I will offer a VIRTUAL bottle of good Bordeau rouge to the first > pilot who maintains drogue contact for say a minute, or more ;=)) > > (b) I will take some screen shots and post them. > > Be warned, during a screen shots (F3), fgfs stops sending mp > packets for up to a second or so, and in the close fgfs the fill-in > (extrapolation) code is activated, with some interesting, and > sometimes quite alarming effects... > > Also I have heard others mention that the live metar update can > also cause mp packet delays. The tanker will be flying under the > 'Fair weather' scenario to avoid this. Maybe you should choose this > as well... > > I really seek help from other pilots to analyse this multiplayer > bandwidth situation. We have chosen 10 Hz, but WHY? > Can less than 10 Hz be used with no adverse effect? That is > the BIG question... > > Simply, what really is the optimum packets-per-second (pps) rate? > Maybe it changes depending on circumstances... > > We know the lower the Hz the lower the bandwidth used by > FGMS servers... but can the extrapolation code fill-in for > the missing packets? > > Is 10 Hz good? Should it be higher, or lower depending on > circumstance.. Lots to learn... > > Of course I am sure there are OTHER ideas... > > Hope you can help, and have some FUN at the same time;=)). > > Look forward to seeing you on my rear view... and I will > take some pics... > > Regards, > Geoff. > > CC: to users list... > BCC: to others... > -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgea
Re: [Flightgear-devel] Flight Gear for Simulation Visualization
Hi Chris, Flightgear will already visualize external data, I've done it, just not that often or recently and I can't remember the steps. Have a look at Docs/readme.IO and Docs/readme.protocol and look at the prewritten protocol files in Protocol/ Ron On Wednesday 17 April 2013 02:31:21 Christopher Fourie wrote: > Hi Everyone, > > My name is Chris Fourie - I'm a master's student in control engineering. My > work is in control systems for the autonomous flight of aircraft (primarily > helicopters). > > We do most of our simulations in MATLAB and a few other things, and I'm > looking for a good way to visualize the data that I generate in simulation. > I'm hoping to use flight gear - I have the source code but I'm struggling > to work out how everything fits together without detailed documentation. > > I'm looking to modify flightgear so that I'm able to set up a simulation > environment (using UDP for online simulation) as well as use it for offline > simulation (watching trajectories and motion using offline data that I've > generated). I need to set up environments with static landing points as > well as with moving platforms (eg. aircraft carriers) to ensure that the > systems we design work. > > I'm a bit at a loss as to where to start - I don't have that much > experience in graphics programming (not that I'm unwilling to learn though, > its really interesting) and I can't seem to find detailed information on > how everything in the code fits together. > > Is there any one that may have the time to help me or point me in the right > direction? > > Many thanks, > > Chris Fourie > ### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies > and e-mail disclaimer published on our website at > http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 > 21 650 9111. This e-mail is intended only for the person(s) to whom it is > addressed. If the e-mail has reached you in error, please notify the > author. If you are not the intended recipient of the e-mail you may not > use, disclose, copy, redirect or print the content. If this e-mail is not > related to the business of UCT it is sent by the sender in the sender's > individual capacity. ### -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Linux nightly builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm working in a local version of Jenkins to set up a nightly build for Linux Ubuntu and allow them to be uploaded to a PPA, so that non-developers can test the nightly builds. Since Launchpad doesn't allow pre-built debs, I'm planning on doing a test build to make sure it compiles in the first place and then uploading the source code to Launchpad for it to compile. Eventually, I'm hoping that the official releases can be prepared and uploaded to Launchpad from Jenkins itself. - -- Saikrishna Arcot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRbzbfAAoJEDg9nXyl50AFaEEP/RAqcJPDajBjMYGqxuy0hmbc WozarvSYyK/3C0FicOGVmHECkTPcmqV0a74HOQWMOHvQuhU7P3Ku+2ILl/J1WFrJ tbAwjzOEdnCmxa+IgDMwpM2yzeTnDZiQfrUYbAKhopsE/+s8XkyiLgIJ99fy4sTW q62kMEyW2FklhSWQm6uW6vs42xITOxeW0W1XoG95+qYh/XTUEtqxoBSktiMQMbGK x0/eqHoMDK7zOTWm/1Hf2pxOOm69f63hHg5PZRi4UlpYtCNxhMJuI2qNX2Jlk9+7 4qeWvyHXWp/SDtlSvcSd+o0XnEPaLcJGdBg6wjGN3DLYOeraB33EKWmuuV4crC5S OMWk+nzgFckOw717uaPdP0UxB116k+EJ8DfADE09/borTv+WS3ZXwgjBMNIGnMc3 S8TcSU8Z4pIn5a5fo3DZtaf8Wf+2Om5GW13cpSg0LeEoghE31mtIvH6RV3Cu710x YW9RglbUgeIKeWt5CFp/iEKwfFEzAY6W2eaAuuJzJxjpaAltsBzroUzej6lWXSeg doVEw+PrYt4Ej46TIIXxt2SZV2J8NFAvleZJYJvprQpvqAOZwzBc57i3ti0V13Sp /V3p6KO0LyNjrxnZBjJgbhGWKh9qjxOKYhcrkEW60yOHj+/rrNq961oW390Sd3uq OpUb0zWBz5UMRshdEq+k =qKP/ -END PGP SIGNATURE- -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] multiplay refuel test
NOTAM: To flyers who fly 'probe' enabled aircraft in Europe... or even if NOT... I will be flying the 'victor' refueling tanker for the next few days from KFPY, south 180 track, then turn around at the southern mountains, north on 360, at 12,000 feet – FL120 STD QNA – and am interested in 'hot' flyers who want to try air-to-air REFUELING (AAR) in suitably equiped aircraft, well ANY aircraft... The tanker will maintain, under autopilot, 220 knots (KTAS), at the said 12,000 feet, either 180 or 360, under the callsign GA006. The flights will commence about noon, or before, UTC, and close about 20:00 UTC. The track can be followed using http://test.fgx.ch, or other mp map URLS. Click on 'GA006' to localize... Reason: (a) I have tried with several aircraft over the last few days, and learned that this is QUITE difficult, but I hope NOT impossible! (b) The present suggested pps (Hz) is 10 when you set up –multiplay=, but FG 2.11 has fill-in extrapolation code when fgfs packets do not arrive in time, so maybe this is too high. This is the basic question... So the idea is to reduce this IFF this fill-in code helps, ie does its job... The theoretic idea is that with this code we can reduce the bandwidth used by 10 Hz to perhaps 2-4 Hz, but this needs to be FULLY tested, and confirmed... Now I have tried this over several day, in several aircraft – A-10, f-14b, a4 and failed, FAILED to touch the trailing drogues... it is TOUGH... autopilots help you get to the 'zone' but it needs manual flying to get to the RIGHT PLACE... If you are using a joystick maybe you need to even adjust the dead spot and the 'sensitivity' of the inputs... lots of learning, understanding and doing fgdata xml changes... And I have had a few pilots joining in ad hoc, but so far no one has actually contacted with the trailing outer wing drogues... The 'victor' can refuel 2 aircraft at a time... and I would LOVE to see/capture that... One, french I think, got so frustrated at his attempts, began firing missiles at the tanker. Thankfully, he MISSED, but was CLOSE ;=)) Also if you alert me to your attempt to refuel from my tanker, via mp chat, email, fgcom, … AND I am on board at the time -: (a) I will offer a VIRTUAL bottle of good Bordeau rouge to the first pilot who maintains drogue contact for say a minute, or more ;=)) (b) I will take some screen shots and post them. Be warned, during a screen shots (F3), fgfs stops sending mp packets for up to a second or so, and in the close fgfs the fill-in (extrapolation) code is activated, with some interesting, and sometimes quite alarming effects... Also I have heard others mention that the live metar update can also cause mp packet delays. The tanker will be flying under the 'Fair weather' scenario to avoid this. Maybe you should choose this as well... I really seek help from other pilots to analyse this multiplayer bandwidth situation. We have chosen 10 Hz, but WHY? Can less than 10 Hz be used with no adverse effect? That is the BIG question... Simply, what really is the optimum packets-per-second (pps) rate? Maybe it changes depending on circumstances... We know the lower the Hz the lower the bandwidth used by FGMS servers... but can the extrapolation code fill-in for the missing packets? Is 10 Hz good? Should it be higher, or lower depending on circumstance.. Lots to learn... Of course I am sure there are OTHER ideas... Hope you can help, and have some FUN at the same time;=)). Look forward to seeing you on my rear view... and I will take some pics... Regards, Geoff. CC: to users list... BCC: to others... -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modellers - is a grain texture useful?
Am Tue, 16 Apr 2013 06:34:26 + schrieb Renk Thorsten : > > I have a question to aircraft/cockpit modellers: Would a shader > effect with the equivalent of a grain texture be useful to you? > > For the terrain, the grain texture is a semi-transparent overlay > pattern of grainy dots - which is superimposed on the normal texture > at 25 times the nominal resolution (so while a usual pixel on the > terrain might be 4x4 m sized, a pixel of the grain pattern is 16cm x > 16 cm. This gives the appearance of a texture resolution which is > much higher than it actually is: > > http://www.flightgear.org/forums/viewtopic.php?f=47&t=18628#p173410 > > In cockpits, I often see many monochromatic surfaces. When I look at > the panel of my card, the plastic is monochromatic but has a fake > leather pattern imprinted. The roof of my car has a cloth structure. > My computer has some rhombus pattern imprinted. Metal surfaces often > have some brush stroke structure. All these things are literally > screaming for an overlay texture, as they are artificial repeating > patterns and there is in fact no tiling problem as in terrain shading > - they can just be superimposed, creating sub-millimeter-sized > resolution on cockpit details at the expense of a single texture > lookup. > > Now, I would offer to code a slot for a grain texture into the > high-quality model shader of Atmospheric Light Scattering, but since > I am not a 3d modeller and I suspect there are some issues with the > uv-mapping which are a bit different from the way terrain works, I > would need someone from the model side who is interested in exploring > this idea. > > Let me know if anyone is interested. I like the idea. It is always a problem to get the Cockpit looking right. Using a high res texture gives a lot of details, but requires a lot of work and resources. Seamless textures save a lot of texture memory and improves the look of the wide areas a lot, but denies any use of e.g Ambient Occlusion. AO gives a somehow grainy appearence which looks ok, but with large interiours (e.g Transports, Bombers) it requires huge texture sizes to look good. I guess using a Shader for interiour will improve the overall look (I already use the model shader for interiour and it definitly improves the look and feel). Since I'm currently working on improving the Sabre Cockpit I would be ready to try some things out. Greetings > > * Thorsten > -- > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for > building apps and a phenomenal toolset for data science. Developers > can use our toolset for easy data analysis & visualization. Get a > free account! http://www2.precog.com/precogplatform/slashdotnewsletter > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] map and flight projection...
Hi, Seems in the latest 2.11 git, the 'map' has lost the forward projected yellow dotted line from the aircraft... Was this intentional? I thought the projection was a very good way to line up on an ILS, head to a VOR, etc, etc... Or is it a 'bug'? Or can I re-enable it somehow? Regards, Geoff. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flight Gear for Simulation Visualization
Hi Everyone, My name is Chris Fourie - I'm a master's student in control engineering. My work is in control systems for the autonomous flight of aircraft (primarily helicopters). We do most of our simulations in MATLAB and a few other things, and I'm looking for a good way to visualize the data that I generate in simulation. I'm hoping to use flight gear - I have the source code but I'm struggling to work out how everything fits together without detailed documentation. I'm looking to modify flightgear so that I'm able to set up a simulation environment (using UDP for online simulation) as well as use it for offline simulation (watching trajectories and motion using offline data that I've generated). I need to set up environments with static landing points as well as with moving platforms (eg. aircraft carriers) to ensure that the systems we design work. I'm a bit at a loss as to where to start - I don't have that much experience in graphics programming (not that I'm unwilling to learn though, its really interesting) and I can't seem to find detailed information on how everything in the code fits together. Is there any one that may have the time to help me or point me in the right direction? Many thanks, Chris Fourie ### UNIVERSITY OF CAPE TOWN This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity. ### -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt and ALS combined or switchable
Hej Thorsten! :) > From: thorsten.i.r...@jyu.fi > To: flightgear-devel@lists.sourceforge.net > Date: Wed, 17 Apr 2013 07:22:42 + > Subject: Re: [Flightgear-devel] Rembrandt and ALS combined or switchable > > > I was wondering if there is a future plan in uniting these two amazing > > attributes of FG... > > My development plan as outlined for the period between 2.10 and 3.0 > (hopefully...) > http://wiki.flightgear.org/User:Thorsten > is still valid: > > "After thinking about this for a while, I have decided that I am definitely > not going to do this on my own. Being maintainer of one major rendering > scheme and one weather system is quite enough to keep me busy, and it's not > something which is very close to my heart. However, if there is a decision > that there is going to be a team effort making this work, I will join it and > do my part." > > > I suspect the programming challenges must be more than easy, yet I > > assume we would all like to have these features together, without having > > to quit and edit config files for choosing one of them at a time. > > I'm not a frequent Rembrandt user, but my understanding is that you have to > start Rembrandt with a certain set of > commandline options, but don't have > to edit config files. Can you elaborate? Oops, I use FG with .fgfsrc, so I have the Rembrandt command on a line which I comment/uncomment. Sorries for not clarifying this. > > I was wondering, could a button between Rembrandt and Atmospheric Light > > Scattering be made in-game so that one can be turned off, thus allowing > > the other to be turned on?? > > Starting from the default rendering scheme, Rembrandt is a change in > rendering architecture, whereas Atmospheric Light Scattering is merely (?) a > change in effect and shader code. Which is to say that Atmospheric Light > Scattering has to be largely re-written to work inside the Rembrandt > architecture, and which is why one can switch in-sim from default to > Atmospheric Light Scattering (because they use the same architecture) but not > from default to Rembrandt. Maybe Fred can explain this better. > > I've been given to understand that the easiest way to implement things inside > the Rembrandt framework is to make all computations in the fragment shader - > this is now done, ubershader-lightfield.frag contains all the main operations > of lighting and fogging in five distinct and well-structured code blocks. I > assume they would be more or less run when just copy/pasted into their > counterpart locations in the Rembrandt framework. > Is this why Rembrandt overrides any Antialias options I try to set? > So the current roadblock is that someone sufficiently familiar with the > structure of Rembrandt needs to write a skeleton framework and move these > bits where they belong and implement the xml logic to switch things on and > off. Once such a skeleton exists, I could take over from there and modify and > adapt it to get all the procedural texturing and other fragment > postprocessing effects in. > > What I can't do easily is design the skeleton from scratch, because I know > only for ~ 2/3 of the lines in effect files what they're actually for (to be > able to modify an existing file is not the same as being able to come up with > one from scratch, especially if that is supposed to work in a different > architecture...), and I have no prior experience in Rembrandt, and 'would be > nice to have' is not sufficient to motivate me to spend a lot of time > learning all of this. The offer stands - if anyone does the skeleton using > what's in ubershader-lightfield.frag and gets a minimal system running in > Rembrandt, I'll do the rest. > This sounds like heavy-duty programming and it won't be easy, of course. But, again, the fruition of this merging will be immensely beneficial, as we all can imagine, I guess! > > * Thorsten > Thanks and cheers!/KlearchosSE-MUA -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt and ALS combined or switchable
> I was wondering if there is a future plan in uniting these two amazing > attributes of FG... My development plan as outlined for the period between 2.10 and 3.0 (hopefully...) http://wiki.flightgear.org/User:Thorsten is still valid: "After thinking about this for a while, I have decided that I am definitely not going to do this on my own. Being maintainer of one major rendering scheme and one weather system is quite enough to keep me busy, and it's not something which is very close to my heart. However, if there is a decision that there is going to be a team effort making this work, I will join it and do my part." > I suspect the programming challenges must be more than easy, yet I > assume we would all like to have these features together, without having > to quit and edit config files for choosing one of them at a time. I'm not a frequent Rembrandt user, but my understanding is that you have to start Rembrandt with a certain set of commandline options, but don't have to edit config files. Can you elaborate? > I was wondering, could a button between Rembrandt and Atmospheric Light > Scattering be made in-game so that one can be turned off, thus allowing > the other to be turned on?? Starting from the default rendering scheme, Rembrandt is a change in rendering architecture, whereas Atmospheric Light Scattering is merely (?) a change in effect and shader code. Which is to say that Atmospheric Light Scattering has to be largely re-written to work inside the Rembrandt architecture, and which is why one can switch in-sim from default to Atmospheric Light Scattering (because they use the same architecture) but not from default to Rembrandt. Maybe Fred can explain this better. I've been given to understand that the easiest way to implement things inside the Rembrandt framework is to make all computations in the fragment shader - this is now done, ubershader-lightfield.frag contains all the main operations of lighting and fogging in five distinct and well-structured code blocks. I assume they would be more or less run when just copy/pasted into their counterpart locations in the Rembrandt framework. So the current roadblock is that someone sufficiently familiar with the structure of Rembrandt needs to write a skeleton framework and move these bits where they belong and implement the xml logic to switch things on and off. Once such a skeleton exists, I could take over from there and modify and adapt it to get all the procedural texturing and other fragment postprocessing effects in. What I can't do easily is design the skeleton from scratch, because I know only for ~ 2/3 of the lines in effect files what they're actually for (to be able to modify an existing file is not the same as being able to come up with one from scratch, especially if that is supposed to work in a different architecture...), and I have no prior experience in Rembrandt, and 'would be nice to have' is not sufficient to motivate me to spend a lot of time learning all of this. The offer stands - if anyone does the skeleton using what's in ubershader-lightfield.frag and gets a minimal system running in Rembrandt, I'll do the rest. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
