Re: [Flightgear-devel] An empassioned plea
On Fri, 2012-05-04 at 20:40 +0200, flightg...@sablonier.ch wrote: Selectively disabling features is probably not going to work reasonable as long as the features in question are required to play nice in order to get disabled, there's no such infrastructure as a kill-switch to prevent the use/loading of *any* shaders (or whichever additional feature). Personally, I think the problem is that easy enabling/disabling shaders goes along discussion of personal preferences and technical/graphical wow!-game-competition of some developers temporary, and not along other discussion. The effects and shader inheriting system is not used as it could for such switches, at least for me. But dont get this wrong, because it might be right in sense of moving forward in such a project ! Its just a lazy comment of a man with varying interest, trying to follow every graphical enhancement the last years. Cheers, Yves After yesterday's git pulls, Flightgear will no longer run at KSFO, having exhausted my 4G of memory and a good load of swap space as well. Indeed, until I increased the amount of swap, it just died with an unceremonious Killed message. Runs fine at my local airport EGPF. Is there a way I can limit the amount of scenery being loaded? I have tried using --visibility-miles=10, but it still just goes on loading dozens of stg files. Can anyone offer me a solution to this perplexing problem? Regards, Alasdair -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Wed, 2012-06-27 at 10:45 +0100, Alasdair wrote: After yesterday's git pulls, Flightgear will no longer run at KSFO, having exhausted my 4G of memory and a good load of swap space as well. Indeed, until I increased the amount of swap, it just died with an unceremonious Killed message. Runs fine at my local airport EGPF. Is there a way I can limit the amount of scenery being loaded? I have tried using --visibility-miles=10, but it still just goes on loading dozens of stg files. Can anyone offer me a solution to this perplexing problem? Regards, Alasdair OK, sorry for the noise. I was all those random buildings. With the maximum setting of 5.0, FG uses a massive 6.3 GB of memory on another machine. Setting it to 0, the memory usage drops to a more reasonable 1.6GB. I wonder if there could be any way of storing just on instance of each building type, regardless of the number of times this was duplicated throughout a city? This is probably an insane question since I know absolutely nothing about graphics :( Regards, Alasdair -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Wed, 2012-06-27 at 14:13 +0100, Alasdair wrote: OK, sorry for the noise. I was all those random buildings. With the maximum setting of 5.0, FG uses a massive 6.3 GB of memory on another machine. Setting it to 0, the memory usage drops to a more reasonable 1.6GB. I wonder if there could be any way of storing just on instance of each building type, regardless of the number of times this was duplicated throughout a city? This is probably an insane question since I know absolutely nothing about graphics :( Regards, Alasdair Forget all this! I just found a thread on this very subject. Been away a while, so have not caught up with all the Fg-dev mail. AC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Alex Perry wrote: It would probably make things a lot simpler for the average user if FGFS included a wizard that automatically identified which combinations of features would be usable on a specific installation. Using that result as constraining logic in the menus would allow unusable features to be kept disabled and trivially cheap features (for the given hardware) to be kept enabled. I think the biggest obstacle on this route is the fact that there's no reliable switch for disabling certain features. Just think about previous discussions on disabling shaders which: As far as I remember the bottom line, disabling shaders relies on every shader honouring a certain property. Some, maybe most shaders honour one property, others honour a second property and even if you try to disable shaders by toggling these properties, some are still getting activated because they don't care about switches at all. Selectively disabling features is probably not going to work reasonable as long as the features in question are required to play nice in order to get disabled, there's no such infrastructure as a kill-switch to prevent the use/loading of *any* shaders (or whichever additional feature). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Selectively disabling features is probably not going to work reasonable as long as the features in question are required to play nice in order to get disabled, there's no such infrastructure as a kill-switch to prevent the use/loading of *any* shaders (or whichever additional feature). Personally, I think the problem is that easy enabling/disabling shaders goes along discussion of personal preferences and technical/graphical wow!-game-competition of some developers temporary, and not along other discussion. The effects and shader inheriting system is not used as it could for such switches, at least for me. But dont get this wrong, because it might be right in sense of moving forward in such a project ! Its just a lazy comment of a man with varying interest, trying to follow every graphical enhancement the last years. Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Bj?rn Kesten said, I don't want no friggin' wizard to tell me what I can or can't do... ;) Is this a wind-up, or what. How can a simple request for developers to optimise their coding on new improvements end up with statements like this? I was hoping this thread had served it's purpose and could now be allowed to rest in peace. Vic -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Vic: I was kidding. B. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
It would probably make things a lot simpler for the average user if FGFS included a wizard that automatically identified which combinations of features would be usable on a specific installation. Using that result as constraining logic in the menus would allow unusable features to be kept disabled and trivially cheap features (for the given hardware) to be kept enabled. Wouldn't a tool tip with a hint (3D clouds. Performance intensive; disable on older hardware) suffice? I don't want no friggin' wizard to tell me what I can or can't do... ;) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
As an aside: When working on the codebase, I maintain a local script that launches FGFS by disabling whatever features prevent the simulation from being flyable on my development machine. When I am unable to turn off features that prevent the simulator from running, and disabling them in source isn't clean enough to maintain as a local patch, I stop working on the project until the next time I buy a machine ... at which point I revisit the script. Flyability includes being able to sustain at least 3 FPS. It would probably make things a lot simpler for the average user if FGFS included a wizard that automatically identified which combinations of features would be usable on a specific installation. Using that result as constraining logic in the menus would allow unusable features to be kept disabled and trivially cheap features (for the given hardware) to be kept enabled. On Wed, Apr 18, 2012 at 2:36 AM, Erik Hofman e...@ehofman.com wrote: On Wed, 2012-04-18 at 09:46 +0100, Vic Marriott wrote: It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. Why does anybody always expect the most imressive results on their old Intel 486DX? Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Personally, I'd build the best white-box machine I could afford and throw Linux on it. Hi Gene, Once again the point is being missed. Things like food and shelter are higher up the finances queue than another computer set-up. Those of you who can afford such luxuries might like to have a thought for the rest of the world, which is still paying the price for what a few greedy bankers have done to world economics. My other half moans enough about the time I spend on this Silly Game as it is. Imagine what would happen if I bought another computer just for FG. Cheers, Vic-- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Mon, 23 Apr 2012, Vic Marriott wrote: Personally, I'd build the best white-box machine I could afford and throw Linux on it. Hi Gene, Once again the point is being missed. Things like food and shelter are higher up the finances queue than another computer set-up. Those of you who can afford such luxuries might like to have a thought for the rest of the world, which is still paying the price for what a few greedy bankers have done to world economics. Oh for f*cks sake. Look, this discussion isn't about who can afford what, it was originally about getting the most performance you can by incrementally upgrading. This isn't the place to whinge about world economics. If you can afford it, great. If you can't, well you can't. So there you go. My other half moans enough about the time I spend on this Silly Game as it is. Imagine what would happen if I bought another computer just for FG. You might try denigrating THEIR hobby and when complaints result, say, sucks when the shoe is on the other foot, doesn't it? *plonk* g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Mon, Apr 23, 2012 at 3:16 AM, Vic Marriott vic...@btinternet.com wrote: Things like food and shelter are higher up the finances queue than another computer set-up. When I take a look at my family (of 4) finances, I see that for what we spend on food each month (not including going out to eat which doesn't happen all that much anymore) I could buy a new computer better than the one I have now. I'm not sure that suggesting my family out to lose a few pounds next month would work very well though ... :-) So I just need to figure out a way to avoid eating and I could get a new computer every month. Hey, would anyone want to trade a month old computer for a month's worth of grocery bills? :-) Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Can we just settle for a general do as much performance optimization as feasible approach? Btw: Is the multithreading feature being actively worked on? It would at least help to bring modern multi-core CPUs to bear. -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
a Mac Pro can get periodic upgrades just like any other PC or Linux box. As I hinted before Gene, those of us on limited budgets can't really justify the spend for a Mac Pro. Erik, You are forgiven :0) James, I think you have an advantage in that you run Linux on your Mac, so you can utilise the best of both worlds. I think this topic has been spent now. Thanks for all your replies. I shall just have to go on choosing which special effect to have switched on on any particular flight. Best regards, Vic p.s. Really looking forward to Rembrant (if it will run on my ancient hardware).-- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Sun, 22 Apr 2012, Vic Marriott wrote: a Mac Pro can get periodic upgrades just like any other PC or Linux box. As I hinted before Gene, those of us on limited budgets can't really justify the spend for a Mac Pro. Maybe not, but you could buy a used one and tweak it if you're insistant on having Apple hardware. Personally, I'd build the best white-box machine I could afford and throw Linux on it. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Thu, 2012-04-19 at 09:50 +0100, Vic Marriott wrote: Sorry for causing such a volatile reaction. I was only asking for those who know how to to optimise as much as possible. I probably overreacted a bit, I'm sorry for that. Erik -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On 19 Apr 2012, at 09:50, Vic Marriott wrote: I have discussed this with Tat, and he has managed somehow (I don't even understand what most developers are talking about) to make each new release work on my machine. I have a 3 year old iMac running OS X 10.6. I don't consider this to be a decrepit old monster, but I do admit it needs a bit more Ram (which I will purchase as and when my pension allows). Speaking as a fellow Mac user, you are unfortunately in the worst possible place in terms of bang-for-buck to use FlightGear - while your Mac has plenty of horse-power in the general case, it wasn't that fast at 3D when new, and you've no way to fix that. Apple tend not to ship cutting edge GPUs in their computers. Of course, many 3D apps will run just fine on your Mac - the major problem is our scene graph tends to trade flexibility and ease of modelling for performance. For most users, and developers, they can spend $100 on a faster GPU and solve that issue if they care, but alas you can't. (This isn't to say we can't and shouldn't spend effort supporting older hardware, or improving performance, of course) James -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Fri, 20 Apr 2012, James Turner wrote: Speaking as a fellow Mac user, you are unfortunately in the worst possible place in terms of bang-for-buck to use FlightGear - while your Mac has plenty of horse-power in the general case, it wasn't that fast at 3D when new, and you've no way to fix that. Apple tend not to ship cutting edge GPUs in their computers. This has become a huge issue recently with X-Plane users. Version 10 of XP is just *crushing* older Macs and people are up in arms about it. Nobody seems to understand that it's not the fault of the software - some of these guys have G5s and such and are just getting shellacked. If you're doing ANY kind of heavy 3D work, be it simulation or modeling, you can't tie yourself to a platform you can't at least incrementally upgrade. Doesn't matter what the OS is either - a Mac Pro can get periodic upgrades just like any other PC or Linux box. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
And a more simple second question, what do the developers accept as proper performance (value) in regards of frames per second. Perhaps i demand/expect too much, but 20 - 30 fps i find rather disappointing, flight is far from smooth at such numbers, but others might find that (more then) ideal. It depends on what I want to do. Using the default rendering scheme and a moderate visibility range ~40 km in default terrain, no special shaders I get about 70-80 fps in moderate cloud cover - that's the framerate I want for aerobatics or air combat training. On the other end of the scale, when I have an airliner cruising at 33.000 ft under AP control, I mainly want to watch scenery and weather, so usually I do this in custom scenery, ask for 120 km visibility range and atmospheric scattering rendering scheme, clouds drawn out to 75 km distance and might do this at sunrise, in which case my framerate may drop as low as 10 fps (which is hardly noticeable, because the apparent motion of terrain and clouds is slow anyway). I also like flying mountains with single engine planes - here a visibility ~50 km and framerates between 15 and 20 fps work for me. There is no such thing as standard performance - I can completely freeze my computer by asking 250 km visibility in custom scenery in atmospheric scattering rendering scheme and heavy cumulus development out to max. range, in which case I end up with 3-4 fps. I can also go above 100 fps by disabling 3d clouds and choosing 10 km visibility range in default scenery. I try to adapt the options to what I want to do and what I want to see. It would be very helpful in determining if some change brought improvement or made performance worse by a proper measuring instead of staring at the FPS counter in the bottom of the screen during gameplay and 'estimating' if things improved or not. Not that simple. For instance, I do many tests with 1200x900 screen resolution to be able to watch the console, but actually fly with 1920x1200 resolution. For lower screen resolution, it pays off to transfer more work to fragment shaders and reduce the load of vertex shaders. However, since the number of fragments more than doubles for full resolution, a different workload balance leads to the best result. The smaller your screen resolution, the better is it to let the fragment shaders do all work. So if there's an improvement to the code might depend on what screen resolution you run. Other changes bring improvements if your graphics card plays along, but deteriorates matters dramatically if not. And so on. Cheers, * Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Wed, 2012-04-18 at 15:33 +0200, EViLSLT - Rob wrote: Hi All! The new rembrandt project is really cool, it seems to be the eyecandy that's currently missing. I check for new and watch the youtube updates quite regularly, mostly clips of fred etc. (wish there we some more hehe) However,I'm not that happy with performance (FPS) with or without rembrandt and in my humble opinion my hardware is not outdated, I seems to get the same performance between the regular renderer en Re,brandt when I select the ufo. Switching to the C172 affects the frame-rate quite a bit. I'm not familiar with the internals of Rembrandt but maybe it will be solved if the 3d model of the C172 is updated for Rembrandt? Erik -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
What do people think about dynamically scaling the eye candy to meet a target framerate? -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
What do people think about dynamically scaling the eye candy to meet a target framerate? Define 'the eye candy' and you'll spot the problem. In general, the performance-driving factors are (not an exhaustive list) 1) visibility range, i.e. number of terrain vertices in the scene 2) cloud visibility range and density, i.e. number of cloud vertices in the scene 3) random vegetation density and visible range 4) number of instructions per vertex the shader has to perform 5) number of instructions per fragment the shader has to perform 6) number of instructions per frame of (aircraft, weather,...) Nasal in the background Trying to scale all of them will likely get you into an unstable loop. 4) and 5) are not continuously scalable, a shader can be on or off, so do we want a flickering snowline based on performance fluctuations? Others people feel should not be scaled - for instance visibility range is a physical property of the world, and if you start on a VFR flight, you shouldn't end up doing an IFR approach beacuse your anti-virus program decided to take just that moment for a scan. I had a control loop for cloud visibility range based on a framerate target (I think that's distributed in 2.4 (?)) - after re-organizing the weather, I didn't put it back in, because I never used it and I never heard anyone say he misses it. It's not particularly difficult to put it back to work, but I never liked its results. It's not so obvious to me what you would really want to downscale in a given situation. * Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Assuming shaders ON, you can scale the fragment workload continuously by using dynamic resolution rendering. Pick your resolution per-frame, pay a constantish cost to copy it to the display buffer (which you're paying anyway if you need to tonemap down from an hdr buffer) -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Erik said, Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. I don't want to appear unappreciative, but for the last 3 releases I have been in danger of being left behind unless I update my computer. I have discussed this with Tat, and he has managed somehow (I don't even understand what most developers are talking about) to make each new release work on my machine. I have a 3 year old iMac running OS X 10.6. I don't consider this to be a decrepit old monster, but I do admit it needs a bit more Ram (which I will purchase as and when my pension allows). Sorry for causing such a volatile reaction. I was only asking for those who know how to to optimise as much as possible. Cheers, Vic-- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. Vic -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
What *is* the baseline hardware fg ought to be aiming at? -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Wed, 2012-04-18 at 09:46 +0100, Vic Marriott wrote: It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. Why does anybody always expect the most imressive results on their old Intel 486DX? Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
What *is* the baseline hardware fg ought to be aiming at? I guess in practice every developer works such that stuff runs well on his own system. What else can we do? I'm not buying a second computer just to test how it would run on a Mac. Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Actually, as Stuart or Mathias have demonstrated here, that's not always true. We seem to be getting more random buildings for less framerate impact for instance. Same was true with the clouds or with the geodinfo() which suddenly was a factor 50 faster. There are sometimes clever ways of doing a task much faster, and one has to spot them. More often, there are clever ways to do a task a bit faster. Taking a week to streamline shader code, I have typically gained 10-20% improvement in the past, at the expense of making the code difficult to understand. Not much, but I notice it, especially summing up several such effects. I didn't get the impression we usually make things as efficient as they could be. Many slow-changing quantities are determined per frame, or when it's clear that they're not needed for instance. An example is ridge lift which is updated per frame at agl altitudes of 20.000 ft when its value is ~1e-5 and it's clear that there can't be any real lift. Many distance calculations in Nasal scripts in the visible scene use spherical geometry while they could be in local Cartesian geometry which is about a factor 5 faster to compute. The problem with making things efficient is that you have to understand well what you're doing. If you approximate an expression by something that works faster with the same accuracy in most cases, you need to take care of the case when it doesn't work. It's a weakness of the modular structure of the Flightgear project that there's hardly anyone with the 'big picture' who knows enough to realize where computations are repeated and how we could streamline the whole. So, I think we can agree that spending performance on improvements, optionally implemented, is reasonable and desirable, burning performance in inefficient code is not desirable, but how to translate this into practical consequences isn't as easy to see. People are trying as a rule. Cheers, * Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Vic wrote: It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Sorry, but I think the point is being missed here. Where is the sense in making very impressive advancements to FG, if the average user has to turn most of them off in order to get a usable fps. The point is that those have halfway decent hardware can use the new features, and those who haven't can't. If we want to make the effort - well that's free. If we could find a way of doing shadows etc. which could run on older hardware then we would. Perhaps as development continues we will be able to optimise the system to find more framerate. By the way - just how old is the hardware you are using? The hardware needed to run this stuff can be picked up on eBay for peanuts. Vivian -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Wed, 2012-04-18 at 10:33 +, Renk Thorsten wrote: What *is* the baseline hardware fg ought to be aiming at? I guess in practice every developer works such that stuff runs well on his own system. What else can we do? I'm not buying a second computer just to test how it would run on a Mac. Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Actually, as Stuart or Mathias have demonstrated here, that's not always true. We seem to be getting more random buildings for less framerate impact for instance. Same was true with the clouds or with the geodinfo() which suddenly was a factor 50 faster. There could sometimes be room for improvement but that is only because of slightly less optimal use of resources in the current implementation. But in general the argument sticks. Don't get me wrong; every improvement is great (and welcome) but it is silly to expect (or almost demand) Rembrandt to run on older hardware. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Hi All! The new rembrandt project is really cool, it seems to be the eyecandy that's currently missing. I check for new and watch the youtube updates quite regularly, mostly clips of fred etc. (wish there we some more hehe) However,I'm not that happy with performance (FPS) with or without rembrandt and in my humble opinion my hardware is not outdated, My machine: Core i7 920 2.8 ghz 24 Gbyte ram ocz vertex 2 and sandforce SSD storage 4x 1 tbyte SATA ATI 5870 Asus Xonar d2x soundcard I often choose to fly in areas with very little or non exciting scenery, basically because when i do my frames per second either fluctuate too heavily, and gameplay stutters which is quite annoying and setting max fps to the lowest stable number isn't really a preferred option as the lowest value is simply to low for smooth simulation/gameplay. Or simply because i find performance too low (e.g. 20 - 30 fps), e.g. KSFO, EHAM the more 'advanced' scenery. When i do fly in those areas i basically disable all the eyecandy you want on, random vegetation, buildings (has been improved indeed) and 3d clouds, things that make the world look more real just to have that bit of extra performance to keep things running as smooth as possible. Though as many of the people that have this comment in regards of the frames per second performance, my programming skills and knowledge of the internal workings of FG, OSG, SimGear are lacking quite a bit, and investigation and testing of this would go dramatically slow and bad if this was up to me. Though i do have a question in relation to this: Is there a benchmarking tool/setup for flightgear? For example a preconfigured/prerecorded flight with fixed variables (weather, time, fov, etc), fixed nr of frames. Basically everything fixed except rendering options and that it measures how long it takes to render/run and calculate the average FPS? People would be able to compare this value, and one would not be comparing apples with pears. Everybody ran the same benchmark/flight. It would be very helpful in determining if some change brought improvement or made performance worse by a proper measuring instead of staring at the FPS counter in the bottom of the screen during gameplay and 'estimating' if things improved or not. And a more simple second question, what do the developers accept as proper performance (value) in regards of frames per second. Perhaps i demand/expect too much, but 20 - 30 fps i find rather disappointing, flight is far from smooth at such numbers, but others might find that (more then) ideal. (rembrandt though not really the focus of my email cuts my performance generally in 2, 8 - 15 fps at EHAM when lucky). This was my penny Kindest Regards and happy flying Rob - EViLSLT - Original Message - From: Erik Hofman e...@ehofman.com To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Wednesday, April 18, 2012 1:12:36 PM Subject: Re: [Flightgear-devel] An empassioned plea On Wed, 2012-04-18 at 10:33 +, Renk Thorsten wrote: What *is* the baseline hardware fg ought to be aiming at? I guess in practice every developer works such that stuff runs well on his own system. What else can we do? I'm not buying a second computer just to test how it would run on a Mac. Advances in quality always requires more resources. Period. If your hardware doesn't support it, bad for you but be grateful FlightGear at least provides an option to turn to less nifty rendering. Actually, as Stuart or Mathias have demonstrated here, that's not always true. We seem to be getting more random buildings for less framerate impact for instance. Same was true with the clouds or with the geodinfo() which suddenly was a factor 50 faster. There could sometimes be room for improvement but that is only because of slightly less optimal use of resources in the current implementation. But in general the argument sticks. Don't get me wrong; every improvement is great (and welcome) but it is silly to expect (or almost demand) Rembrandt to run on older hardware. Erik -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https
Re: [Flightgear-devel] An empassioned plea
On Sun, 15 Apr 2012 18:44:26 +0200 Gijs de Rooy gijsr...@hotmail.com wrote: Pat wrote: Would having a dialog to set options for various PC capabilities help? What's wrong with View Rendering Options? For a novice user, would they know that performance could be affected by view rendering settings? which ones would they set, and at what levels? The idea would be to have sets of option settings pre-configured to fit common hardware limitations at various levels. While doing this I would not want to make it a default, just give the user the option. Then again, maybe I'll just get a better graphics card. I've done that once already, just for flightgear but it didn't increase my framerate much. -Pat Core2 8400 4Gig Nvidia 420 P.S. I've got an old 386 laptop with 80 meg of memory and a 2 gig hard drive somewhere around here. Perfect for running flightgear on the go! -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Fri, 13 Apr 2012 10:56:41 +0200 Erik Hofman e...@ehofman.com wrote: snip It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Erik Would having a dialog to set options for various PC capabilities help? -Pat -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
Pat wrote: Would having a dialog to set options for various PC capabilities help? What's wrong with View Rendering Options? -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] An empassioned plea
Hi, More and more, the FG forums are showing that the most recent improvements, added to the existing code, are too memory consuming for operation on anything less than a high powered, up-to-date, well equipped computer. Though I, and probably most other FG users, am delighted that improvements from your efforts continue at such a rate, can I please ask the hard-core developers to give some thought to making the current set of bells and whistles more memory friendly. There is little more frustrating than to read about the marvellous additions, but then being unable to run them without FG slowing down to unusable levels. There is only so much users can do to keep their computers as up-to-date as possible, but simple things like the lack of funds can easily put a limit on that. Please consider having a concerted effort towards making FG less memory hungry. Best regards, Vic -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An empassioned plea
On Fri, 2012-04-13 at 09:25 +0100, Vic Marriott wrote: Hi, More and more, the FG forums are showing that the most recent improvements, added to the existing code, are too memory consuming for operation on anything less than a high powered, up-to-date, well equipped computer. Though I, and probably most other FG users, am delighted that improvements from your efforts continue at such a rate, can I please ask the hard-core developers to give some thought to making the current set of bells and whistles more memory friendly. There is little more frustrating than to read about the marvellous additions, but then being unable to run them without FG slowing down to unusable levels. There is only so much users can do to keep their computers as up-to-date as possible, but simple things like the lack of funds can easily put a limit on that. Please consider having a concerted effort towards making FG less memory hungry. It's probably not so much about memory consuming but more about resource consuming. But be assured that most new options are easily turned off. Erik -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
