Re: [Flightgear-devel] Reducing AI Model complexity
For those interested in trying this out, I've uploaded a simple patch to http://www.nanjika.co.uk/flightgear/ai.diff It's not suitable for committing in it's present form - at the very least the properties should be loaded from the FG tree rather than SimGear and I'm not sure that the SGReaderWriterXMLOptions object is the correct container for the switch. To disable loading of submodels, set /sim/rendering/load-submodels=0 You can also set the LOD range for AI aircraft (though I haven't tested this) by setting /sim/rendering/model-range-m to the required range in m. Note that neither of these settings are dynamic - they only take effect for any new models that are loaded. So, they are best set from the command-line. -Stuart -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Alexis Bory wrote: > When using dual control like in Anders c172p-dual-control and > ZLT-NT blimp, or the f-14b-bs, the copilot is actually flying in an AI > model which needs all the eavy stuff we would like to disappear in > most other situations. > > There is also a big demand of visual details and eyes candy > from a important part of FG users and we can't neglect that. > > Now, this leads effectively to a huge waste of h/w resources and > anyway much of all this eye candy stuff is not visible at more than > 50ft. LOD animations works well for saving fps and the work > spent on it worth it. > > The problem remains at AI aircraft load time and I think a majority > of user doesn't need to wait for the Tomcat to load each minute or > so. > > In any case we should have the ability to choose what level of > detail we want. In a dream world this would be user definable and > on a per aircraft basis. This could be something like: use only light > AI models by default or define somewhere a list of aircrafts you > prefer to see a high level of detail. In the cases like dual-control, > modelers could add at run time the needed models to this list. My proposal is to allow the user to select (via a property) whether they want to load the entire model or not, so there's no loss of function. So, I would envisage that those wanting to use the dual control options would want to set this off. In fact, as it's a property (say /sim/rendering/load-submodels), it could be set in the -set.xml file. Though this goes against our general principle that the user has control over features rather than the aircraft, I think in these special cases where the dual-control simply won't work, we could make an exception. Providing a higher granularity of control would be tricky but not impossible - I guess you could define a list of model names that are to be loaded completely... -Stuart -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Jason Shepard wrote: > Stuart: >> 1) A control to disable sub-model loading for AI aircraft. This >> effectively stops the model loader from recursing into tags, >> and therefore stops it from loading any sub-models such as cockpits, >> instruments, pilots etc. > > Csaba: >> I want to see AI/MP aircraft in full detail when I am near >> one - or even inside. > > Well, the only 2 ideas I have regarding this would be selectable options > within the FGRun GUI and/or the command-line: > > 1) An option to enable/disable the LOD capabilities of the program > 2) An option to select either "AI Models (simple)" or "AI Models > (advanced)". > a) AI Models (simple) would be AI Models which always appear without > their interiors/cockpit installed. This would be effective for those people > who do not "hitch rides" or who want best performance at all times. > b) AI Models (advanced) would AI Models which appear fully detailed at > the closest LOD limits. This would be the best choice for those who like to > see their AI aircraft in full detail and jump onboard occasionally, like > Csaba. That is indeed what I'm proposing :) I should have been clearer in my original post - by having a "control" I meant adding an entry in the property tree to toggle whether submodels are loaded or not. Similarly I am proposing setting the AI LOD distance from a property as well. You can then set the property from the command-line, FGRun, or in-sim (though it would only affect models loaded from that point). -Stuart -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart Buchanan a écrit : > In an effort to help with this I've been looking at two fixes: 1) A > control to disable sub-model loading for AI aircraft. This > effectively stops the model loader from recursing into tags, > and therefore stops it from loading any sub-models such as cockpits, > instruments, pilots etc. > Comments? When using dual control like in Anders c172p-dual-control and ZLT-NT blimp, or the f-14b-bs, the copilot is actually flying in an AI model which needs all the eavy stuff we would like to disappear in most other situations. There is also a big demand of visual details and eyes candy from a important part of FG users and we can't neglect that. Now, this leads effectively to a huge waste of h/w resources and anyway much of all this eye candy stuff is not visible at more than 50ft. LOD animations works well for saving fps and the work spent on it worth it. The problem remains at AI aircraft load time and I think a majority of user doesn't need to wait for the Tomcat to load each minute or so. In any case we should have the ability to choose what level of detail we want. In a dream world this would be user definable and on a per aircraft basis. This could be something like: use only light AI models by default or define somewhere a list of aircrafts you prefer to see a high level of detail. In the cases like dual-control, modelers could add at run time the needed models to this list. Alexis -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart: > 1) A control to disable sub-model loading for AI aircraft. This > effectively stops the model loader from recursing into tags, > and therefore stops it from loading any sub-models such as cockpits, > instruments, pilots etc. Csaba: > I want to see AI/MP aircraft in full detail when I am near > one - or even inside. Well, the only 2 ideas I have regarding this would be selectable options within the FGRun GUI and/or the command-line: 1) An option to enable/disable the LOD capabilities of the program 2) An option to select either "AI Models (simple)" or "AI Models (advanced)". a) AI Models (simple) would be AI Models which always appear without their interiors/cockpit installed. This would be effective for those people who do not "hitch rides" or who want best performance at all times. b) AI Models (advanced) would AI Models which appear fully detailed at the closest LOD limits. This would be the best choice for those who like to see their AI aircraft in full detail and jump onboard occasionally, like Csaba. Durk: > So, if done correctly, we could happily use the regular > aircraft models, also for AI /Multiplayer purposes, because most of the time, > only the lower LOD versions would be active. This would probably give better > performance than we currently have. In addition to that, we could also make > more effective use of the incredible collection of liveries made by Brett > Harrison, which quite a few magnitudes better then the rather bleak ones I > made for the AI aircraft. As I have only recently noticed, there are only certain aircraft in my AI Models folder - and not even close to the same number as I have downloaded and installed. This leads me to believe that only certain aircraft make use of the AI Models directory and either a) those are the only AI Models that you can have unless you create your own files or b) the other Models are rendered as AI Aircraft from the original model files anyway. If it is Option A, then I believe a solution to re-route our current AI Models directory structure to our original models directory structure should be implemented along with Stuart's control option to make it so that separate AI Models would not have to be generated and stored separately. This would reduce the overall size of FG (although probably not by much), but it should also have the side benefit of simplifying some of the code (since there wouldn't be 2 directory structures to do the similar actions), correct? If it is Option B, then we already have the file structure in place to use Stuart's proposed modification to "auto-create" AI Models which would make the AI Model tree unnecessary, correct? Which would also mean that ALL of our models would also be capable of being AI Models instead of only a limited few. Thanks, Jason -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 48, Issue 2
Hi helijah, > > I'm sorry, but this kind of attacks wearies me. If you could speak and understand better english, you would have pretty understand that this wasn't a attack. So let the previous post and this better translate by someone who can speak french and english and then answer again, please! You tried to fix the shape of the fuselage in YASIm with Melchior's script, which was indeed a good idea. But with changing the shape you also accidently change the cg and tensors, which were calculated by Maik to match original datas. It is possible to have both, but Me or Maik need some time for it. >I actually > changed the > work of HHS. But not for the worse, but simply to make it > logical and > usable. It it isn't my work. It is work by Maik Justus. Only added the elevator due to information given in the flight manual, but which should still be checked by Maik, who has access to the real datas.. All other things- Balance, weight, Cog, Tensors I didn't change- just because it was well calculated by Maik. I compared the file I send you with the one right now in CVS- the difference is quite visible. > > And I show you the results to prove it. > > http://helijah.free.fr/uh1-fdm.png > > Maik, if you accept, without question, the presence of a > third rotor in > an UH-1 FDM, then I have nothing more to say. But it will > still show me > its usefulness. The third rotor is the stabilisator on the rotor. It has to be there as it influence the behaviour of the rotor. Please again, Emmanuel- let this and all others mails translate by someone who speak french and english, not Google Translate please! You understand a lot of things completly wrong whic hmakes things really worse, which should not be! Heiko __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 48, Issue 2
http://wiki.rigsofrods.com/pages/Portal/ :) There is 2 years since I compile RoR. It is really impressive. Unfortunately, it is it is extremely resource-intensive. I do not know if it comes from OGRE or RoR programming. But it is really very greedy, too greedy. But it is a product to try. Like CSP, who has the advantage of being 100% OSG : http://csp.sourceforge.net/wiki/Main_Page Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 48, Issue 2
Message: 4 Date: Tue, 30 Mar 2010 23:57:48 + (GMT) From: Heiko Schulz Subject: Re: [Flightgear-devel] FG - Helicopter FAA - AATD To: FlightGear developers discussions Message-ID:<741574.96640...@web23204.mail.ird.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Hi, The UH1 was the one with the most realistic flightmodel. Unfortunately as helijah corrected the fuselage shape in YASim, he broke the whole balance settings. Tensors and CoG seems not right anymore, visible as the whole aircraft is turning on ground with stopped engine. That didn't happen before. I don't find the time right now to look and fix it, but maybe in 2-3 weeks unless someone other is faster. Regards Heiko. I'm sorry, but this kind of attacks wearies me. I actually changed the work of HHS. But not for the worse, but simply to make it logical and usable. And I show you the results to prove it. http://helijah.free.fr/uh1-fdm.png Maik, if you accept, without question, the presence of a third rotor in an UH-1 FDM, then I have nothing more to say. But it will still show me its usefulness. Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Route Man / AP
On Apr 2, 2010, at 10:38 AM, James Turner wrote: > > On 2 Apr 2010, at 15:28, Peter Brown wrote: > >> Quick question for James I think - when the route manager passes the last >> listed nav point, the AP doesn't disengage, it turns west (from the east >> coast). This is a default heading to KSFO or some other pre-determined >> "home" ? > > The intended behaviour is that the GPS (which is doing the actual waypoint > sequencing) should switch back to OBS mode - so the GPS will start to follow > whatever OBS radial is selected on the device (note this is different to the > Nav1 radial, though in FG2.0 they are linked - which turned out to be a Bad > Idea, so that feature has been removed in CVS) > > If you have the log-level set to info (or higher), you should see: > 'GPS route finished, reverting to OBS' > > on the log output, when passing the last way point. > > Of course, it's entirely possible there's a bug lurking in this area - it > would be good for you to cross-check what status the generic GPS dialog > reports after passing the final waypoint. > > Regards, > James > Thanks James, I'll take a look. On a similar subject, is there a master list of the nav fixes that appear on the mpmap? It doesn't seem to correspond to the list accessed via the route manager, so often I need to enter fixes until I get one that is known and accepted. I'd like to either delete unknown's from the mpmap, or access the same list from the route manager. Peter -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: The most amazing airplane in history!!!
Oh btw I just ordered Topeka's(was Google) toilet based internet connection service, is it good? Has anyone tested it? Or is it crappy? ^__^ Also I'm trying to install Android on my ARM dev kit so I can try their new animal voice translation app :) Nice plane. > Curtis Olson wrote: > > Why don't we have this aircraft modeled for FlightGear??? > > > You are a day late , Curt :-) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: The most amazing airplane in history!!!
Curtis Olson wrote: > Why don't we have this aircraft modeled for FlightGear??? Here's what that hoax is based on. http://www.pilotfriend.com/photo_albums/potty/8.htm Now this might be interesting, Ive certainly had some fun with the ANT-20. This is bigger I believe. -- Best Regards Willie Fleming -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: The most amazing airplane in history!!!
Curtis Olson wrote: > Why don't we have this aircraft modeled for FlightGear??? > You are a day late , Curt :-) -- Best Regards Willie Fleming -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: The most amazing airplane in history!!!
Hello, There we go: http://en.wikipedia.org/wiki/Kalinin_K-7 Length: 28 m (91 ft 10 in) Wingspan: 53 m (173 ft 11 in) smaller than a 747 And here the truth: http://blogs.airspacemag.com/daily-planet/2009/03/27/urban-legendinski/ :-) But it would be interesting, to create a fdm which should match to the rendered aircraft and how it would fly... Heiko __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: The most amazing airplane in history!!!
Curtis Olson wrote: > Why don't we have this aircraft modeled for FlightGear??? I think we are short of one engine. Erik > -- Forwarded message -- > > > > > The most amazing airplane in HistoryFor the Airplane > Buffs > > Built in Russia during the 1930s, it flew 11 times before crashing > and killing 15 people. > > The designer, Konstantin Kalinin, wanted to build two more planes > but the project was scrapped. > > Later, Stalin had Kalinin executed. > > Evidently, it was not good to fail on an expensive project under Stalin. > > It's got propellers on the back of the wings, too. You can count 12 > engines facing front. > > The size would be equivalent to the Empire State Building on its > side, with cannons. > > And you think the 747 was big... not only a bunch of engines but > check out the cannons the thing was carrying. > > Can you imagine what it would be like sitting in this thing when > those cannons go off? > In the 1930s the Russian army was obsessed by the idea of creating > huge planes. > > At that time they were proposed to have as many propellers as > possible to help carrying those huge flying fortresses into the air, > jet propulsion has not been implemented yet. > Not many photos were saved from those times because of the high > secrecy levels of such projects and because a lot of time has > already passed. > > Looks like something out of a Jules Verne novel. > > > > > -- > Curtis Olson: http://baron.flightgear.org/~curt/ > > > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Route Man / AP
On 2 Apr 2010, at 15:28, Peter Brown wrote: > Quick question for James I think - when the route manager passes the last > listed nav point, the AP doesn't disengage, it turns west (from the east > coast). This is a default heading to KSFO or some other pre-determined > "home" ? The intended behaviour is that the GPS (which is doing the actual waypoint sequencing) should switch back to OBS mode - so the GPS will start to follow whatever OBS radial is selected on the device (note this is different to the Nav1 radial, though in FG2.0 they are linked - which turned out to be a Bad Idea, so that feature has been removed in CVS) If you have the log-level set to info (or higher), you should see: 'GPS route finished, reverting to OBS' on the log output, when passing the last way point. Of course, it's entirely possible there's a bug lurking in this area - it would be good for you to cross-check what status the generic GPS dialog reports after passing the final waypoint. Regards, James -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Route Man / AP
Quick question for James I think - when the route manager passes the last listed nav point, the AP doesn't disengage, it turns west (from the east coast). This is a default heading to KSFO or some other pre-determined "home" ? Thanks, Peter -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Solved: Shift key stuck once pressed
Hi all, This problem is also present in 2.0. I do not know what software contains the bug, but the issue is related to switching between keyboard layouts. Specifically if I configure Gnome keyboard layout preferences in a way that "both shift keys together change the layout", I get the issue. I chose another configuration that does not use the shift keys and the issue is gone. I did not do any further testing, but now you should be able to reproduce the issue. Cheers, Vik Melchior FRANZ wrote: > JFTR: I confirm recent sporadic keyboard misbehaviour. > > m. > > -- > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with Landmassshader in CVS
On Fri, 2 Apr 2010, James Sleeman wrote: > On 02/04/10 19:45, Frederic Bouvier wrote: >> I can see there is a huge performance penalty on 2-years old GPUs, so we >> also need performance vs eye candy user setting to choose which technique >> could be applied besides simple advertised extension support > Turning on Landmass effects cuts my framerate from over 30 to under 3 :-( Hi, On my system I go from 47 -> 20 fps where the first value is with a frame rate throttle. I disabled the geometry shader based effect and use the first relief map effect instead (it is still in the landmass effect file). I think it would be a good idea to export on/off properties for the various techniques. We could also look into making an even cheaper landmass shader alternative than the relief map - I suspect even it might be too expensive on some older systems. A plain normal map or parallax map, perhaps. For those in need of downgrading to the next best landmass shader: Index: Effects/landmass.eff === RCS file: /var/cvs/FlightGear-0.9/data/Effects/landmass.eff,v retrieving revision 1.6 diff -u -p -r1.6 landmass.eff --- Effects/landmass.eff29 Mar 2010 06:13:43 - 1.6 +++ Effects/landmass.eff2 Apr 2010 08:48:03 - @@ -19,6 +19,7 @@ +0 /sim/rendering/landmass-shader /sim/rendering/shader-effects Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with Landmassshader in CVS
On 2 Apr 2010, at 09:25, James Sleeman wrote: >> I can see there is a huge performance penalty on 2-years old GPUs, so we >> also need performance vs eye candy user setting to choose which technique >> could be applied besides simple advertised extension support > Turning on Landmass effects cuts my framerate from over 30 to under 3 :-( 40 -> 13 here (on an Ati radeon 3870 Mac edition) - the other shaders don't have anything like the same impact. It's a great effect though, and this is sort of the point of shaders - we can scale the renderer scene at runtime, instead of requiring a one-pipline-fits-all solution with a fixed pipeline. Keep up the good work, I'm sure my hardware will catch up. Err, well, I'm on Mac, so what I mean is, sooner or later I'll spend huge amounts of money for a 18-month old graphics card ;) James -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue with Landmassshader in CVS
On 02/04/10 19:45, Frederic Bouvier wrote: > I can see there is a huge performance penalty on 2-years old GPUs, so we > also need performance vs eye candy user setting to choose which technique > could be applied besides simple advertised extension support Turning on Landmass effects cuts my framerate from over 30 to under 3 :-( -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C1 & C2
On Thu, 1 Apr 2010, Peter Brown wrote: > I understand that, so I don't understand why it's happening. I can fly > around KSFO with 40 a/c, but if I fly within 1/2 mile of these two it > drops. > Apparently you flew up them and didn't have any issue? > > None-the-less.who/what/why are they there? Someone running a > longevity test on the server? It could be some sort of (semi-flawed) AI server test. Can you check the console for NaN warning messages from OSG? If some of the MP properties needed to render the MP/AI model has the value NaN that might slow down FlightGear significantly. (NaN = Not a Number - an undefined floating point value. Floating point instructions might trap into software when NaNs are encountered or at least these are rare cases that aren't fully optimized.) Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Me: > However, would the one stated above prevent models which use submodels for > wing-flex effects from appearing to have wings? (Wait... are there any such > models, or are the wings animated components of the main model?) Stuart: > I would expect that the wing flex would be an animated component of the main > model, just like flaps, gear etc. usually are. Ah, okay -- I got my terminology confused for a second there. Disregard. -R. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Rob Shearman, Jr. > However, would the one stated above prevent models which use submodels for > wing-flex effects from appearing to have wings? (Wait... are there any such > models, or are the wings animated components of the main model?) I would expect that the wing flex would be an animated component of the main model, just like flaps, gear etc. usually are. However, if they were submodels, they wouldn't be visible. -Stuart -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Hi All, On Friday 02 April 2010 09:19:45 am Stuart Buchanan wrote: > > Yes, but there's unlikely to be much advantage as most of the AI models > used in single player (tanker, AI aircraft) are already low-poly models. > > However, it does affect the Nimitz carrier, which is quite a detailed > model, so would benefit those seeing low FPS with the carrier. > > > b) If so, would we still have to maintain the AI model files or, with > > this patch included, would the AI aircraft be able to be "read" from the > > standard models folder thereby eliminating the needs for an AI "branch" > > on the FG tree? > > There is still a place for the AI Models - this doesn't do anything about > the complexity of the main model, nor does it scale any textures. > In general, I'm in favor of Stuart's proposed patch, as long as it continues to play nicely along with the existing AI branch (I'm happy to help testing / committing in this respect). Just to add some additional thoughts, the current scheme of using a separate AI branch was added back in the plib days, when LOD wasn't easily accessible, after I found out that the then current version of FlightGear wasn't able to handle the impact of 100+ aircraft placed in a scene by the traffic manager. If I understood correctly, one of the major advantages of OSG over plib is that it can do very clever LOD management, which -if effectively applied- could by itself reduce the amount of pausing due to aircraft model loading considerably. So, if done correctly, we could happily use the regular aircraft models, also for AI /Multiplayer purposes, because most of the time, only the lower LOD versions would be active. This would probably give better performance than we currently have. In addition to that, we could also make more effective use of the incredible collection of liveries made by Brett Harrison, which quite a few magnitudes better then the rather bleak ones I made for the AI aircraft. My own experience is that the AI/ Traffic Manager code in itself runs quite efficiently, but that the rendering of the AI models has a huge impact. Currently, for the AI code, the model isn't made visible until it gets close to the current visibility limit. Once that happens, and the AI models are set to become visible, that's where I usually notice quite a frame rate drop. Relatedly, when flying away from a busy airport, I notice quite an increase in performance, even though the AI aircraft are then still within visibility range. This actually makes me wonder whether there is something in the AIModels core code that makes the current rendering of AIModels rather inefficient. I'd be interested to hear one of our OSG experts' opinion on this. Cheers, Durk -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart: > 1) A control to disable sub-model loading for AI aircraft. This > effectively stops the model loader from recursing into tags, > and therefore stops it from loading any sub-models such as cockpits, > instruments, pilots etc. Csaba: > I want to see AI/MP aircraft in full detail when I am near > one - or even inside. Perhaps a range-test of 1-2nm (or even better, a configurable distance) on submodel loading? Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart: > A number of people on the forums have mentioned performance issues on > lower-spec system on MP, particularly due to loading complex models > for other aircraft causing stuttering. > > In an effort to help with this I've been looking at two fixes: > 1) A control to disable sub-model loading for AI aircraft. This > effectively stops the model loader from recursing into tags, > and therefore stops it from loading any sub-models such as cockpits, > instruments, pilots etc. I am in LOVE with any idea which reduces unnecessary lag time when flying over the multiplayer network. However, would the one stated above prevent models which use submodels for wing-flex effects from appearing to have wings? (Wait... are there any such models, or are the wings animated components of the main model?) Cheers, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Csaba Halász wrote: > Generally I prefer proper LOD and getting rid of specialized AI > versions. I want to see AI/MP aircraft in full detail when I am near > one - or even inside. Ideally I want to see all the instruments > properly working when I hitch a ride using model+cockpit view. In the > long run, I hope we will be able to couple animations to MP protocol, > so that the required properties (and only those!) would be transmitted > automatically as dynamically determined by the current LOD. I prefer proper LOD as well, but it requires effort from modellers, and there is still the overhead of loading the entire model, and keeping the model in memory. This approach simply allows a user to choose whether they want that overhead or not. To be perfectly honest, this is just a speculative piece of work. On my new system, I don't have any problem handling KSFO on a busy day, but I think it should help those on lower powered machines significantly. -Stuart -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Jason Shepard wrote: > As far as what you have written here: > > 1) As I understand this, it basically does exactly the same thing as going > through the individual model files and removing the cockpits/interiors/etc., > correct? Correct. > a) Would this work on single-player? Yes, but there's unlikely to be much advantage as most of the AI models used in single player (tanker, AI aircraft) are already low-poly models. However, it does affect the Nimitz carrier, which is quite a detailed model, so would benefit those seeing low FPS with the carrier. > b) If so, would we still have to maintain the AI model files or, with this > patch included, would the AI aircraft be able to be "read" from the standard > models folder thereby eliminating the needs for an AI "branch" on the FG > tree? There is still a place for the AI Models - this doesn't do anything about the complexity of the main model, nor does it scale any textures. However, it means there's no real need to create AI models for everything. > 2) I don't 100% understand how LOD works, but if I get it basically > correctly, LOD reduces the resolution of a model based on the distance from > your viewpoint that it is? If this is the case, would it not stand to > reason that there should be several different stages of LOD? For example, a > model made with 2048x2048 textures would be at full resolution within 5nm. > From 5.1nm-10nm, it would be rendered at 1024x1024. From 10.1nm-20nm, it > would be rendered at 512x512. Or am I way off-base here? Is this even > possible? It is possible, but requires significant work on the part of the modeller. In this case, the LOD means the range at which and aircraft will become visible. At the moment this is hardcoded to 50nm. -Stuart -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
