[Flightgear-devel] Interesting read on hosting huge git repos
FG seems not to be the only project which has problems with multi GB git repos. The Linux kernel and Android are in the same league and they have experiences of their own. This might be an interesting read: https://plus.google.com/112413860260589530492/posts/EJCsVq6o1vF Stefan -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..build fixed, was: ..is only the "explicit data-dir" checked for udev??? FG builds now fail.
On Wed, 28 Dec 2011 12:32:58 +0100 (CET), Frederic wrote in message <9b5f9916-d282-4499-b940-37ba05a2c...@zimbra59-e10.priv.proxad.net>: > Hi, > > > De: James Turner > > > > On 25 Dec 2011, at 23:58, Csaba Halász wrote: > > > > > > > > As far as I can see, udev is not the reason for the failed build, ..I fixed my udev error with 'aptitude install libudev-dev '. > > > X11_Xft_LIB and X11_Xinerama_LIB are. ..ditto with libxft-dev and libxinerama-dev, these pull in a few dependencies too, builds nicely now, but segfaults now with: arnt@nb6:~/FG-git$ ./run_fgfs.sh --enable-fullscreen \ --disable-ai-scenarios --disable-ai-traffic & [1] 18852 arnt@nb6:~/FG-git$ Animated jetways ... initialized KI266 dme indicator #0 initialized Submodels: Unable to read AI submodel list Segmentation fault [1]+ Exit 139./run_fgfs.sh --enable-fullscreen --disable-ai-scenarios --disable-ai-traffic arnt@nb6:~/FG-git$ arnt@nb6:~/FG-git$ ./run_fgfs.sh --enable-fullscreen & [1] 14021 arnt@nb6:~/FG-git$ Animated jetways ... initialized KI266 dme indicator #0 initialized loading scenario 'nimitz_demo' Segmentation fault [1]+ Exit 139./run_fgfs.sh --enable-fullscreen -- ..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. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..the USPTO MO, was: DDS texures (Was: Improving random trees & buildings)
On Fri, 30 Dec 2011 11:13:43 -0800 (PST), Gene wrote in message : > On Fri, 30 Dec 2011, Mathias Fröhlich wrote: > > > blobs? > > We could try to decompress the blobs? ---> No, patent > > infringement!!! > > I call shennanigans. There's no way a process that obvious could be > patented ..you never heard of the USPTO modus operandi? ;o) http://groklaw.net/ 's Patent overwiew page with sad etc stories: http://groklaw.net/staticpages/index.php?page=20050402193202442 > and if some mouth breathing derp DID patent it, it needs to > be ignored. ..nope, we need those troll patents reexamined and rejected by the USPTO or the courts. The "ignored" idea simply and quickly invites US$ 3M lawsuits on any "ignorant" infringing party such as yourself from the patent trolls, Microsoft is just one such. -- ..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. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft issues: Vostok-1, dc-3, dhc6, CRJ700, pa24-250-CIIB
> * dhc6: Nice to see more details in the cockpit. Just, how the hell do I > switch all the warning signs off? After starting the engines, the whole > warning panel lit up (which I know from some other aircraft as a test > mode), but the lights never went out. Plane was flying fine though. I dont see that problem here, but it does have a warning light test button , I'll take a look and see if i missed something in the commit. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft issues: Vostok-1, dc-3, dhc6, CRJ700, pa24-250-CIIB
On Sun, 1 Jan 2012, thorsten.i.r...@jyu.fi wrote: > > An (incomplete) list of issues I have observed in flying various aircraft > recently - maybe some of them can be fixed by maintainers before the > release: > > * Vostok-1 is currenty a no-show - it crashes before doing anything, the > log seems to point to a property as the cause. I guess it *may* be a > JSBSim issue (?). Being one of the few people who has actually flown the > beast into orbit, I think it's a model well worth maintaining (especially > as I am now able to create a bit better environment up at 120 km altitude > using the skydome shader). In the forum vitos (the original creator) has > clearly announced his intention not to maintain the model any further > since we haven't delivered a new rendering engine, so it's looking for a > new maintainer. Maybe some JSBSim person can have a look? Hi, Vostok-1 seems to be missing a property. I forward-declared the missing property and then it loads. However, it seems the property in question (ic/sea-level-radius-ft) is no longer provided by JSBSim so it will always read 0 now. This is likely to be a problem. To try it get the vostok-1 branch from my fgdata clone: git://gitorious.org/~andersg/fg/anders-fgdata.git I also added a pile of missing var-keywords to make it run on the slightly pickier version of Nasal I use.. (each detected missing var-keyword problem is a potential future name-clash bug in FG). No test flight, though - no time for the required training. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to compile Terragear-cs ?
How about this at the top of the script (in tried yet) $0 2>$1 |tee $logfile & Rediredt all script output and tee in background. Exit status should still stop the build and out put should be on screen as well as in the log file Sent from Samsung tabletGeoff McLane wrote:On Sun, 2012-01-01 at 16:40 +0100, Clément de l'Hamaide wrote: > Hi Pete, Geoff, > > Now my script work perfectly. > Hi Clément, Glad to hear it is all now working fine... Sorry my explanation was not clear... 1. I assume, like Francesco's script, and mine, you have the command in the early part of the script, like - set -e This command asks the script to EXIT, stop, when the last process returns other than 0 as a return value... Without this the default action of a script is to continue even when the last process gives an error exit... non zero... So if you do not do this set -e, or do not want this, then forget this... 2. Also as I understand it, the script can ONLY react to the LAST process in a chain of commands... So if you have a chain of commands like cmake ... 2>$1 | tee -a $LOGFILE then the LAST command in this process is the 'tee' So even if there is a cmake error exit, then the script will continue, since the last action, the tee, does not return an error... Is that clearer? 3. Now the situation is DIFFERENT with a simple redirection like - cmake 2>&1 >>$LOGFILE or make ... 2>&1 >>$LOGFILE In this case the script will STOP on an error, since redirection is established BEFORE starting cmake or make, command, so in this case the LAST command is the cmake or make error... But in doing this, as you point out, there is NO OUTPUT to the console... Except as Jari pointed out, you can start the script as a background process, and use a repeated tail command to view the end of the LOG in a console... Or even start the script in a terminal, and open another terminal to do the tail command, repeatedly... This is what I tend to do, since I too redirect the SVN or git actions to a log file, and use tail in another terminal to 'see' what is happening... especially when it seems to be taking too long ;=() BUT yes, I too LOVE the fact that 2>&1 | tee -a $LOGFILE sends ALL cmake or make output to BOTH the LOG file for later review, AND to the console... So it is a compromise ;=(( You can either have ALL output put to the LOG file, AND to the console, BUT then the script will NOT stop on an ERROR... Or you can remove this and the script will STOP on an error... but there is LESS information to the console if you use a redirection to a log... So you must choose what ever you think best... That is all... and I attach a simple example below... Re: Building terragear-cs with "-DNO_OPENSCENEGRAPH_INTERFACE=1" I am not sure if this is the SAME as -D SIMGEAR_HEADLESS=ON but I am sure they are, in some ways at least, very 'similar'... Maybe others who know more about this can comment further, to clarify... I have only ever used "-DNO_OPENSCENEGRAPH_INTERFACE=1"... which I know works fine to keep OSG dependency out of the terragear-cs tools... Regards, Geoff. Example: testexit1 #!/bin/sh BN=`basename $0` LOGFILE="/tmp/templog.txt" echo "$BN: Testing error exit conditions..." | tee -a $LOGFILE make -f nofileexists echo "$BN: 1: Last exit was $?, but the script is continuing..." # set it to stop on error set -e make -f nofileexists 2>&1 | tee -a $LOGFILE echo "$BN: 2: Now last exit is zero $?, so the script is continuing..." make -f nofileexists 2>&1 >> $LOGFILE echo "$BN: 3: Since the redirection is set up BEFORE" echo "$BN: running make then this output will NOT be seen as the " echo "$BN: script will have exited due to the 'make' error." PS: And remember to try the very LATEST terragear-cs tools in development you need to clone and switch to the 'newconstruct' branch... -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Fli
Re: [Flightgear-devel] How to compile Terragear-cs ?
On 2012-01-01 20.17, Geoff McLane wrote: > But in doing this, as you point out, there is NO OUTPUT > to the console... > > Except as Jari pointed out, you can start the script > as a background process, and use a repeated tail > command to view the end of the LOG in a console... > > Or even start the script in a terminal, and open > another terminal to do the tail command, repeatedly... The -f option to tail will make tail output everything added to the file by one single start of the tail command. Jari -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to compile Terragear-cs ?
On Sun, 2012-01-01 at 16:40 +0100, Clément de l'Hamaide wrote: > Hi Pete, Geoff, > > Now my script work perfectly. > Hi Clément, Glad to hear it is all now working fine... Sorry my explanation was not clear... 1. I assume, like Francesco's script, and mine, you have the command in the early part of the script, like - set -e This command asks the script to EXIT, stop, when the last process returns other than 0 as a return value... Without this the default action of a script is to continue even when the last process gives an error exit... non zero... So if you do not do this set -e, or do not want this, then forget this... 2. Also as I understand it, the script can ONLY react to the LAST process in a chain of commands... So if you have a chain of commands like cmake ... 2>$1 | tee -a $LOGFILE then the LAST command in this process is the 'tee' So even if there is a cmake error exit, then the script will continue, since the last action, the tee, does not return an error... Is that clearer? 3. Now the situation is DIFFERENT with a simple redirection like - cmake 2>&1 >>$LOGFILE or make ... 2>&1 >>$LOGFILE In this case the script will STOP on an error, since redirection is established BEFORE starting cmake or make, command, so in this case the LAST command is the cmake or make error... But in doing this, as you point out, there is NO OUTPUT to the console... Except as Jari pointed out, you can start the script as a background process, and use a repeated tail command to view the end of the LOG in a console... Or even start the script in a terminal, and open another terminal to do the tail command, repeatedly... This is what I tend to do, since I too redirect the SVN or git actions to a log file, and use tail in another terminal to 'see' what is happening... especially when it seems to be taking too long ;=() BUT yes, I too LOVE the fact that 2>&1 | tee -a $LOGFILE sends ALL cmake or make output to BOTH the LOG file for later review, AND to the console... So it is a compromise ;=(( You can either have ALL output put to the LOG file, AND to the console, BUT then the script will NOT stop on an ERROR... Or you can remove this and the script will STOP on an error... but there is LESS information to the console if you use a redirection to a log... So you must choose what ever you think best... That is all... and I attach a simple example below... Re: Building terragear-cs with "-DNO_OPENSCENEGRAPH_INTERFACE=1" I am not sure if this is the SAME as -D SIMGEAR_HEADLESS=ON but I am sure they are, in some ways at least, very 'similar'... Maybe others who know more about this can comment further, to clarify... I have only ever used "-DNO_OPENSCENEGRAPH_INTERFACE=1"... which I know works fine to keep OSG dependency out of the terragear-cs tools... Regards, Geoff. Example: testexit1 #!/bin/sh BN=`basename $0` LOGFILE="/tmp/templog.txt" echo "$BN: Testing error exit conditions..." | tee -a $LOGFILE make -f nofileexists echo "$BN: 1: Last exit was $?, but the script is continuing..." # set it to stop on error set -e make -f nofileexists 2>&1 | tee -a $LOGFILE echo "$BN: 2: Now last exit is zero $?, so the script is continuing..." make -f nofileexists 2>&1 >> $LOGFILE echo "$BN: 3: Since the redirection is set up BEFORE" echo "$BN: running make then this output will NOT be seen as the " echo "$BN: script will have exited due to the 'make' error." PS: And remember to try the very LATEST terragear-cs tools in development you need to clone and switch to the 'newconstruct' branch... -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to compile Terragear-cs ?
On 2012-01-01 16.40, Clément de l'Hamaide wrote: > When I remove all " 2>&1 | tee -a $LOGFILE" and I replace it by a > simple ">> $LOGFILE" I see many less information in terminal when > script is running. It's very annoying to haven't information about > step in terminal... For example, when the script downloading OSG from > SVN there is nothing written in terminal... I wait during some minute > without know if my script is running. Before, with " 2>&1 | tee -a > $LOGFILE" I could see all downloading files in real time. > > (1) Have you an other solution about " 2>$1 | tee -a $LOGFILE" ? (Or > may be re-explain me again with an example) Start your script as a background process and then you can do 'tail -f logfile' to follow the progress on screen. Jari -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to compile Terragear-cs ?
Hi Pete, Geoff, Now my script work perfectly. When I remove all " 2>&1 | tee -a $LOGFILE" and I replace it by a simple " >> $LOGFILE" I see many less information in terminal when script is running. It's very annoying to haven't information about step in terminal... For example, when the script downloading OSG from SVN there is nothing written in terminal... I wait during some minute without know if my script is running. Before, with " 2>&1 | tee -a $LOGFILE" I could see all downloading files in real time. (1) Have you an other solution about " 2>$1 | tee -a $LOGFILE" ? (Or may be re-explain me again with an example) (2) Is it possible to use " 2>$1 | tee -a $LOGFILE" at least for write a simple text in terminal AND in Log File ? (For exemple : <> seem to be not dangerous and can't create fatal error) About "-DNO_OPENSCENEGRAPH_INTERFACE=1", I saw in CMakeLists.txt (from SIMGEAR repository) the option "SIMGEAR_HEADLESS". I think it would be better to use this option to specify "without GUI". TerraGear already use this option in the CMakeLists.txt at line 114 (in TERRAGEAGR-CS repository) I've added -D SIMGEAR_HEADLESS=ON and now I have a "-- headless mode" ;) You can follow the thread on forum where I announce what I do : http://www.flightgear.org/forums/viewtopic.php?f=20&t=14849 I've added TerraGear GUI compilation and automatic fill of TerraGear Root field in TerraGear GUI. If you find something unusual or strange your experience is welcome ! Cheers, Clément -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announcing Project Rembrandt
Hi Mathias, > De: Mathias Fröhlich > > On Friday, December 30, 2011 11:45:21 Frederic Bouvier wrote: > > The problem I have to solve currently is how to feed the G-Buffer > > to the Effect system because the textures used to store it are > > camera-dependent (in a multi screen context) but the pass (which > > is a stateset) is built once for all. > > I do not exactly understand. I see that the effects collide in some > sense with this kind of an approach. Partly effects do try to > achieve some similar results in the good old fixed function derived > world, than you get once your code is used, but as far as I see, > the intermediate screen sized textures should not be processed > anymore with the effects? Or at least how would you know which > fragment to process with witch effect? Or I think that all the > effects probably need to be changed to write their > color/reflection/whatever information into the appropriate render > target? > > So, far how I understand the question. I am almost sure I miss your > point. > > Ahh, ok do you want to write the compositing step as a usual effect > file? Then, I understand the problem. Well, If this is the problem, > I do also not see an easy solution. I would think that this final > compositing step is so different from the rest off the effect stuff, > that inserting these textures using non generic custom code for this > special purpose is fine. > So, for this kind of problem currently no solution - may be one when > I think about this for some time. > Let me know If I am looking at the right problem ... Exactly. I want to give access to every stage of the rendering to the effect system. The geometry pass outputs to render target, but the fog, the lights, the bloom need to have access to the textures of the buffer, and there is a separate one for each camera associated to windows or sub windows. I have found a solution where I can make an association between the cull visitor and the G-buffer and then modify the pass of the effect on the fly. I hope some multi-threading model will not screw up this scheme. > > Currently, the fog is computed using the depth buffer as a > > post-process pass. Any smarter computation (like atmospheric > > scattering) is just a matter of writing a single shader that > > would replace the default fog computation. > > Exactly. And you are looking into the sky if you find a far clipping > plane depth value. Actually, it's a null normal. I could also use the stencil buffer but I already messed with combined depth/stencil shared between fbos without much success. > > > So, may be just one question for what you have done already again > > > without looking into any code: > > > > > > You do not require float textures? > > > As far as I can see, there is a patent issue on this extension > > > and usually this is not strictly required. > > > Using a fixed point representation that makes use of the usual > > > depth buffer - one that scales differently than the usually > > > perspective depth - could be used instead and I think we should > > > use this in the end. In the end this really gives even better > > > accuracy than a float representation since floats waste some > > > bits for the exponent, where a fixed point representation could > > > just use all the bits for accuracy. > > > > I used Policarpo's tutorial on deferred shading so I don't store > > absolute world position in a float texture. As described in the > > tutorial, I used the view direction and the depth value to compute > > the eye space position of the fragment. > > That's fine! That's what I had in mind also. The fragment position > gives the view direction by the projection matrix and together with > the depth value fed through the inverse projection matrix yields the > right values. > > > Nevertheless, I use float texture to store the normals. I tried > > setting up a normal buffer with just luminance and alpha with > > half-float while the color buffers were rgb8 but it was very slow. > > Instead I used rgba16f for all textures (except the depth buffer). > > As I use additive blending to collect the lights, I thought it > > would be possible to have some kind of HDR without the risk of > > saturating the 8bit color components. I can try to use 2 color > > channels to store the x and y components of the normal and > > reconstruct the z part with sqrt(1 - (x^2+y^2)) but that won't > > solve the saturation issue. Some use LUV color space to store > > higher intensity in RGB8 but afaik, it don't support additive > > blending. > > Ok, I have not thought at the normals yet. Lets first make this work > and then care for a fallback or nice trick that does not need float > textures and looks fine performance wise. Regards, -Fred -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure acc
[Flightgear-devel] Aircraft issues: Vostok-1, dc-3, dhc6, CRJ700, pa24-250-CIIB
An (incomplete) list of issues I have observed in flying various aircraft recently - maybe some of them can be fixed by maintainers before the release: * Vostok-1 is currenty a no-show - it crashes before doing anything, the log seems to point to a property as the cause. I guess it *may* be a JSBSim issue (?). Being one of the few people who has actually flown the beast into orbit, I think it's a model well worth maintaining (especially as I am now able to create a bit better environment up at 120 km altitude using the skydome shader). In the forum vitos (the original creator) has clearly announced his intention not to maintain the model any further since we haven't delivered a new rendering engine, so it's looking for a new maintainer. Maybe some JSBSim person can have a look? * CRJ700: The altimeter on the main glass instrument is currently unreadable or displays the wrong altitude - the band hundreds runs correctly, but the numerals before can't be deciphered. Probably a simple graphics issue, the AP holds correct altitude. * dc-3: Very nice cockpit work - the manual needs an update though, starting the engine seems to require at least one more step than advertized (the selection of a fuel tank). Even then for some reason I got only the left engine on - repeating symmetrically what I did never started the right engine until I used the autostart function. * dhc6: Nice to see more details in the cockpit. Just, how the hell do I switch all the warning signs off? After starting the engines, the whole warning panel lit up (which I know from some other aircraft as a test mode), but the lights never went out. Plane was flying fine though. * pa24-250-CIIB: I still suspect that there's something not working correctly with the engine at high altitude. In 14.000 ft with mixture full rich, I should be choking the engine, but I don't seem to, it just runs fine and EGT drops to an abysmally low value. * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announcing Project Rembrandt
Hi, On Friday, December 30, 2011 11:45:21 Frederic Bouvier wrote: > The problem I have to solve currently is how to feed the G-Buffer > to the Effect system because the textures used to store it are > camera-dependent (in a multi screen context) but the pass (which > is a stateset) is built once for all. I do not exactly understand. I see that the effects collide in some sense with this kind of an approach. Partly effects do try to achieve some similar results in the good old fixed function derived world, than you get once your code is used, but as far as I see, the intermediate screen sized textures sould not be processed anymore with the effects? Or at least how would you know which fragment to process with witch effect? Or I think that all the effects probaly need to be changed to write their color/reflection/whatever information into the appropriate render target? So, far how I understand the question. I am almost sure I miss your point. Ahh, ok do you want to write the compositing step as a usual effect file? Then, I understand the problem. Well, If this is the problem, I do also not see an easy solution. I would think that this final compositing step is so different from the rest off the effect stuff, that inseriting these textures using non generic custom code for this special purpose is fine. So, for this kind of problem currently no solution - may be one when I think about this for some time. Let me know If I am looking at the right problem ... > Currently, the fog is computed using the depth buffer as a post-process > pass. Any smarter computation (like atmospheric scattering) is just > a matter of writing a single shader that would replace the default > fog computation. Exactly. And you are looking into the sky if you find a far clipping plane depth value. > > So, may be just one question for what you have done already again > > without looking into any code: > > > > You do not require float textures? > > As far as I can see, there is a patent issue on this extension and > > usually this is not strictly required. > > Using a fixed point representation that makes use of the usual > > depth buffer - one that scales differently than the usualy > > perspective depth - could be used instead and I think we should > > use this in the end. In the end this really gives even better > > accuracy than a float representation since floats waste some > > bits for the expontent, where a fixed point representation could > > just use all the bits for accuracy. > > I used Policarpo's tutorial on deferred shading so I don't store > absolute world position in a float texture. As described in the > tutorial, I used the view direction and the depth value to compute > the eye space position of the fragment. That's fine! That's what I had in mind also. The fragment position gives the vew direction by the projection matrix and together with the depth value fed through the inverse projection matrix yields the right values. > Nevertheless, I use float texture to store the normals. I tried > setting up a normal buffer with just luminance and alpha with > half-float while the color buffers were rgb8 but it was very slow. > Instead I used rgba16f for all textures (except the depth buffer). > As I use additive blending to collect the lights, I thought it > would be possible to have some kind of HDR without the risk of > saturating the 8bit color components. I can try to use 2 color > channels to store the x and y components of the normal and > reconstruct the z part with sqrt(1 - (x^2+y^2)) but that won't > solve the saturation issue. Some use LUV color space to store > higher intensity in RGB8 but afaik, it don't support additive > blending. Ok, I have not thought at the normals yet. Lets first make this work and then care for a fallback or nice trick that does not need float textures and looks fine performance wise. Greetings Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
flightgear-devel@lists.sourceforge.net
Hi Erik, On Friday, December 30, 2011 11:39:37 Erik Hofman wrote: > On Fri, 2011-12-30 at 10:42 +0100, Mathias Fröhlich wrote: > > * If it's just the mipmaps. May be we can precompute the mipmaps using > > the cpu in the database loader thread. This would help all textures not > > only the ones that could be converted. May be this is the most generic > > solution. > Ok I'm quite convinced it's a mipmap problem. > I tested uncompressed dds textures with pre generated mipmaps with > different compression techniques but none of them improve the situation > much. Switching to uncompressed DDS textures with mimaps however speeds > things up roughly three times (just onder 3 sec. instead of around 10 > sec to switch). Great to know! Thanks for testing. I think then, computing mipmaps for any texture file on the CPU in the loader thread should globally improove the situation. Also avoiding the compression already in the files should help every use case. Except that the on disk memory consumption is higher. Well and except that the database loader has more work to do on the CPU. Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees & buildings)
Hi, On Friday, December 30, 2011 11:11:39 Frederic Bouvier wrote: > > * If it's just the mipmaps. May be we can precompute the mipmaps using > > the cpu in the database loader thread. This would help all textures not > > only the ones that could be converted. May be this is the most generic > > solution. > I implemented a mipmap control and generation tool in effects when I last > updated the urban shader. For the moment, it relies on hardware when the > average operator is used for all texture channels but it could easily be > modified to compute all mipmap on the CPU. look the effect > option and mipmap.[ch]xx in SG material lib Thanks, I will look into that! Greetings Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees & buildings
Happy new year! Vivian, On Friday, December 30, 2011 10:48:40 Vivian Meazza wrote: > The hangs are caused by mipmap generation on the fly by OSG? The hangs are caused by mipmap generation by the driver which happens on forst use of a texture. > The old texture files are static and I would expect them to work into the > future, but the new dds textures will leave them further behind as work > progresses. The only problem in htat is that some users will lose out on > some eyecandy - it will not affect the basic operation of the sim. Which is in this case sad I think. If it's easy to fit both needs I think we should. > > You do not experience any hangs? > > None that I have seen so far Ok. I have also seen one of the machines at the flightgear booth at the fsweekend which did not show any problems. But Thorstens huge machine really hangs in an unaccaptable way. I would really never tolerate this as a user ... > > What is the motivation for you to use dds files? > > It's a better way of storing cubemaps for reflections or other layered > images. The built in mipmap OSG algorithm is a bit slow - using dds works > around this (for some systems) Ok, granted. Use it for that. > > What do you gain by not using the usual image files? > > Dds textures remain in video memory, so we get improved performance when > switching textures. We expect that at least some people will see smoother > performance when loading scenery textures. I haven't been able to measure > any gain, but there are some have reported that they see a subjective > improvement. No, this really should not be a difference. Probably this is what I refer to as these hangs. But the reason is not that dds is in video memory and other textures are not. These *are really all* in video memory. There is no difference between dds and png. The driver decides where to put which buffer objects so that it is accessible to the gpu. And depending on the memory pressure on GPU's memory of the whole system driver the driver might page something out or not. So, once you really reach these huge GPU boards memory limits you might see that using compression you start paging less. But our working set is way below. The real reason appears to me like being the initial mipmap computation when allocating a texture in the driver. And an other post of Erik in this thread tells me that we should try to provide a mipmapping method that already runs in the database loader thread so that on initial allocation in the driver the mipmaps are already present. Also according Eriks comment, compression on the fly on the upload path in the driver seems to work without delay. So, for drivers that announce the compresin extension we can still tell the driver to store the textures compressed on the gpu to minimize gpu memory paging. So, still, since it is technically incorrect to provide these s3 patent precompressed textures to a driver that does not announce the apropriate extension and since we are not allowed to code something that deompresses this, I think we should avoid using this compression for all the provided models/textures. I think of a warning that is issued from the image loader in flightgear that detects when these precompressed textures are seen. So even people using drivers that just offer this extension have a chance to see that the provided textures will not work for others. > > The motivation behind this mentioned change is to sort out the best > > compromise > > so that the hangs hopefully disappear - which I hope to get with > > precomputed > > mipmaps - and being able to display fine with any driver/gpu. > > Seems to work here - I have tried > > --prop:sim/rendering/texture-compression="dxt5" > > I hope that is the right syntax - no warning from fg anyway. I don't see any > problems with running the F16 using that. I might be entirely wrong of > course. Yes, that is thought like that. But since you do not see the hangs in any configuration you can just sit down and watch us testing :) Thanks anyway! Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear
If I am understanding you correctly, you want to get access to various variables within flightgear. Isn't the Property Tree via telnet or http something that might work for you? Should be easy to access it from a web service even. Or define a generic protocol, the wiki had an example how to make it talk json or similar format you can parse and generate easily. /T -- On 1.1.2012 6:50 Pedro Morgan wrote: I'm looking at part of FG in various scenarious.. So Can I propose we "expand" the "scope" to the simgear code.. The intention would be to make available all the "maths" within simgear.. for all other langs// Geoff has got the perl.. I got some python.. there's some java in openradar and indeed I got some php... but expand it to other langs as well So we got constants and "calcs" so Indeed having them under one banner would be good... for all of us.. a Starting Point.. no need to have to fiture other stuff out.. its there use as required.. The way to do it I think would be to have the current scenarios"...And then have some "externals".. in git/// MAIN PROBLEM.. is to create the stable code.. and its in there and safe and tested.. But it will save a lot of frustration.. Main COSNTANTS = defined *** conversions *** Define and Consolidation would be a good "appraisal" of FG system... imho in all scopes Need to find the distance to DME marker from x.y.. Maybe we need to focus on context.. and the dead reckoner more.. pete -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
