Board index FlightGear The FlightGear project

FlightGear performance ( from: How can I retire from the forum?)

Questions about the FlightGear organisation, website, wiki etc.

Re: How can I retire from the forum?

Postby Thorsten » Fri Jul 04, 2014 8:08 am

So this is not about one isolated feature causing this - maybe it's mostly TerraGear scenery that is contributing to this these days.
But the bottom line remains that such things go unnoticed because we don't provide the mechanisms/tools to detect such issues much earlier.


The mechanism as such is clear and sound: We have the Jenkins nightly GIT binaries on distribution, we distribute release candidates, these should lead to test data on a wide set of systems, which them comes back and enables people to take action.

One problem is that GIT these days isn't treated as the experimental stuff it is where things can break overnight and where people diagnose issues and report back (if that is done, for instance in the case of the JSBSim zero altitude bug crossing into the ocean, things get fixed quickly). But rather, GIT gets treated as release-quality code, people complain that potentially unstable code gets committed to the repo (where else is it supposed to be tested?).

So, rather than getting meaningful and actionable feedback from GIT users, we're seeing more and more non-actionable complaints that the version which is intended for testing and experiments isn't fully tested.

Case in point - it'd be interesting to find out why FG in junior-s system can drop from 50 fps down to 5. I've never ever seen this, I don't know anyone who has, it'd be important to find out what's the issue and see whether we can address it - but rather than a structured bug report, or anything I could try to help to diagnose, what I see of this is 'FG is becoming unusable, how do I retire from the forum'.

With a user-side attitude like 'If it's broken, let someone else figure it out, not my job' we can't do it. We don't have an array of different computers at home so that we could do specific testing - I have my laptop to test, and that's it. We rely on users entering an issue tracking process, making systematic tests under guidance, reply to questions.

Whenever this happens, the chance is perhaps 80% that there is a fix at the end. Whenever this doesn't happen, the chance is perhaps 5% that by random chance things will improve.

It is simply not true that such things go unnoticed. I made a report about 2.0 scenery resource consumption to the devel list prior to the 3.0 release. There have been many discussions on memory consumption.

and we don't fix the infrastructure to allow non-coders to more easily tell when/why things are going haywire and to make better informed bug reports, i.e. in terms of concrete features & subsystems I mean, not actual C++ functions (which can really only be expected of people who build from source and who know how to patch SG/FG or even OSG).


Well. Obviously you have your agenda here just as well. We all have our different strategies to identify problems and track bugs. You like working from a debugger, you'd use tools to profile and optimize shaders, I don't - I like to debug from Nasal-internally and do performance testing GLSL internal. Whether we need monitoring tools or not is a question of debugging strategy.

I can usually track GLSL and AW Nasal issues if somebody really works with me - is willing to tell me what happens if code blocks I indicate are commented out, describes the detailed sequence of steps which lead to weird behavior. I can't track issues based on vague reports 'X is broken' when I don't see it myself.

From where I stand, we're mainly lacking willingness of users to actually run tests under guidance. If people can't be bothered to report their system specs or what they're actually doing in detail, then I can't see how they'd report more internal diagnostics.

Also, what we can (and largely have) established are the facts of resource utilization. We're not lacking information here. Here's Rebecca's data on memory consumption by different texture scheme and scenery selection for instance

Code: Select all
In Ubuntu 64-bit, measured using System Monitor after it stabilizes (~1min)
Except as stated, c172p stationary on KSFO 28R, night, Terrasync
scenery, default settings (regional textures, LOD range 1500/9000/30000)
baseline: 2.3-2.4GB
Changing shader effects level or enabling/disabling random
objects/trees/buildings: no significant change
Global texture set: 2.2GB
DDS texture set: 2.2GB
Global texture set, no Textures.high: 2.1GB (and some missing effects
textures, as they don't have the "try Textures.high first, then
Textures" fallback mechanism)
LOD range 1500/9000/10000: 1.4GB
LOD range 1500/2000/30000: 2.3GB
LOD range 500/9000/30000: 2.3GB
1.0 scenery (from flightgear-data 3.0 due to above issue): 1.1GB
Ocean location: 0.75GB
F-14: 2.1GB
777-200: 2.6GB


Now you know the facts.

Into what action should this translate? It's choices. FG alone (i.e. above the ocean) uses 0.75 GB - all the rest then is scenery and such. Random buildings cost some, visibility costs a lot, detailed scenery costs a lot.

Which means, there is now a choice - given how much memory your computer provides, you can start to fill it with memory-consuming things till it's full, but there's no unique way to fill it.

You can use 1.0 scenery and lots of visibility (4 GB will buy you 200 km if you de-activate trees and buildings). You can use hires scenery and lower visibility (4 GB will perhaps buy you 40-50 km). And anything else. Obviously, if you're flying an airliner, your choice might be different than if you're flying a single prop.

It'd be nice to have that choice made semi-automatically (I'd still like to customize it), but the question remains - FG allows you to focus on what is important for you. Whether you see an issue or not depends on what choice you're trying to make and how it is supported by hardware.

I wasn't actually talking about the texture, but the 3D meshes composing the ground. Even if the picture I saw was wrong (which I doubt because the scenery has a lot of different 3D complexity levels) it doesn't erase the fact that FG's scenery is way too much detailed.


I'm sorry, but you're making strong statements here. You're saying the what the scenery is bad because it is composed of little 40x40 cm squares, and that creates a lot of problems for you. Others read it in this thread, might believe it, possibly report it elsewhere. You create an impression.

Does it matter whether what you say is true?

Yes, I think it does. I think that if the scenery is in fact not composed of little 40x40 cm squares, you have no right to claim it anywhere. If we start dispensing with the truth, that's morally questionable. You may be angry at me, or at the FG project - but that doesn't give you the right to tell things about the project or me which are not true.

And on a more prosaic note, if we dispense with the truth of things, we will just have a very hard time finding out what is actually going wrong. Tracking bugs with a preconceived attitude that X must be wrong ain't working. It needs an open mind.

So I'd ask you to stick with the truth here, and if you don't know it, then you shouldn't say it. Demonstrate to me that the scenery is composed of little 40x40 cm squares please, or admit that you've been spreading wrong information if you can't. It's as simple as that. Do not lie. It's not a big thing to ask I'd think.

This is a strong suggestion there **IS** something wrong with the 2.0 scenery.


Yes. We know that. I have said it several times. The scenery people know that. It needs way too much memory, especially the line features (roads, rivers,...) eat it like mad. A third to half is zero area triangles which could be culled. There's no LOD system yet. People are working on it.

The 2.0 is an early release of a work in progress because we specifically asked for it to be released, no matter the state. It is nevertheless stunning and a big improvement over the 1.0 in level of detail - I really enjoy flying Grand Canyon these days. Once you see it as work in progress which you can use optionally if it runs for you, it has lots of merit.

But it matters what is actually wrong with the 2.0 scenery - you still can't say that it's made of 40x40 cm squares, because that is not its problem. You can't say that X is wrong with it when it's in fact Y just because something is wrong.

You just did:
Yeah, pretty much.


I'm sorry, but that's a lie.

The issue at hand was that you said that FG is becoming too resource demanding and the response of the devel team would be:

1) downgrade the game graphics quality, which are already low by default. So go ahead and fly with not-so-pretty settings and a scenery square that is smaller than you own city's quarter, because the scenery is way too much detailed;
2) buy more memory and/or a better pc.


My response actually was: Do not use the 2.0 scenery (because it is an early, imperfect work in progress release) and watch the issues disappear. I confirmed with my 'Yeah, pretty much' that I recommend putting up a warning that you need lots of memory to use the 2.0 scenery and that I would recommend stay with 1.0 if you don't have that.

I did not say to downgrade graphics settings and a small scenery square. I did not say buy more memory to run FG. I did say that 1.0 scenery runs with 100+ km visibility on 4 GB.

I find it completely inacceptable that you would distort my response so completely out of context, and I do ask you for an apology here. I'm spending a lot of time in this thread trying to point out the facts - what the issues are as they are known to people, what is been worked on, why things are the way they are. I believe strongly that we can't do without accurate facts, and that your certainty that there's something wrong with FG doesn't give you the right to just make things up which could be wrong. It matters what is actually wrong.

You do not need to buy a new computer or more memory to have very pleasant visuals of FG if you have a halfway decent GPU. I have plenty of forum screenshots in the old scenery to demonstrate that.

But to run the 2.0 scenery in its current state (which is, as I repeatedly said, an early work in progress release which the scenery team was reluctant to do) you do, and my recommendation is to stay clear of it till the issues (zero area triangles, LOD,...) are resolved.

And I won't have you lie into my face that I dismiss everything with 'Just buy a new computer or use 10 km visibility range'. Because I don't. And I'm really angry about this comment. I understand you're frustrated, but that doesn't give you the right to distort what I say. I'm just trying to explain things to you (I won't say help you because your mind is already set, but I do believe I help others in making them see that people are aware of issues and that action is taken and that FG development is not a bunch of morons).

2nd: I think I've posted a good number of times about optimizing the terrain code, yet nobody seems to read that


Adrian, you know that James has now pushed your changes to the tile manager, do you?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How can I retire from the forum?

Postby Thorsten » Fri Jul 04, 2014 8:23 am

For the scenery issue, and actually every issue, i think it is important for a developer to ask himself: "what would a user want/need".


Which user?

Quoting myself from elsewhere:

If users would give coherent feedback pointing a certain direction, then probably most developers would give it serious thought, but the reality is that 'user-friendly' usually (and with exceptions far and inbetween) means 'me-friendly' - people use that term to argue that FG should have features they personally want, that things should be accessible on the channel they personally prefer, that things should be configurable how they think works best... regardless of what other users may want.

For instance, Advanced Weather has been criticized for being too complicated and offering too many GUI options about as much as it has been criticized for being too opaque and not offering enough GUI options to micro-manage weather. The FG project has been criticized in equal measure for not supporting legacy systems enough and for not throwing legacy support out of the window and making all the fancy effects new hardware allows work. Aircraft startup procedures have been criticized as being too complicated and putting users off just as well as not being realistic enough. You get the picture.

There's really nothing users coherently want, except better graphics combined with better framerate, which really is a contradiction in terms just as well.


Case in point - I've been given to understand by users that our scenery resolution close to the ground is way too bad and that we should increase the resolution or use geometry shaders for dynamic tesselation.

Does that trump your request?

I mean, in the specific case, a terrain LOD system is entirely reasonable and is being developed, but in general, the attitude to ask what the user wants doesn't lead anywhere except into contradictions.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How can I retire from the forum?

Postby anonymous2 » Fri Jul 04, 2014 10:29 am

.
Last edited by anonymous2 on Thu Oct 02, 2014 10:03 am, edited 1 time in total.
anonymous2
Retired
 
Posts: 49
Joined: Sun Jan 31, 2010 3:19 pm

Re: How can I retire from the forum?

Postby Thorsten » Fri Jul 04, 2014 11:37 am

If you folks would code as much on fg as you spend on writing forum posts, flightgear 4.0 would be out already


And users all over the place would complain even more that nobody takes their opinion seriously. That questions are never answered. That the devel community is completely disconnected from everything.

And if I would spend as much time flying the sim as I spend coding or answering forum posts, I'd probably be much happier.

There you go.

Final summary from my side:

Yes, there are issues. FG isn't perfect, it's rough around the edges, the GUI is far from optimized,...

But we won't ever resolve them by saying 'The project is going into a bad direction.' The only way to solve them is constructively - establish the facts of what is actually going wrong. Trying to understand whether things can be fixed in the current framework, whether existing settings need to be exposed better, whether we lack information, or whether new development is needed. If it's the latter, make a good case for that new development and convince the people who matter. Document in the wiki what you found out can be done. Blanket-bashing the project won't help. Complaining that X is broken without providing the info necessary to fix it won't help. Making claims that feature X is causing a problem without having any evidence won't help. Ascribing opinions to developers which never have been said won't help.

And of all posters here, I want to explicitly not direct that comment to Adrian, because he has tried being constructive very hard, and I've seen what I think were genuine improvements from his side being treated badly, and I'm sorry for the way this went, and if I would have had any say in the matter, things would have been different.

The lesson I take from all this (and related discussions) that I will be in the future very careful to make any rendering code available on GIT which isn't guaranteed fool-proof and might lead to less than perfect visual sometimes. If the general mood is that we bash the project for a release early, release often policy, then I will stop with it. You can still enjoy the screenshots.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How can I retire from the forum?

Postby junior-s » Fri Jul 04, 2014 12:15 pm

I'm sorry, but you're making strong statements here. You're saying the what the scenery is bad because it is composed of little 40x40 cm squares, and that creates a lot of problems for you. Others read it in this thread, might believe it, possibly report it elsewhere. You create an impression.
I didn't say that is a bad thing. I said that's OK for short distances.

Yes, I think it does. I think that if the scenery is in fact not composed of little 40x40 cm squares, you have no right to claim it anywhere. If we start dispensing with the truth, that's morally questionable. You may be angry at me, or at the FG project - but that doesn't give you the right to tell things about the project or me which are not true.
I know that, and I'm saying it's 40x40 because I don't have that picture, but that was what it looked like. I don't know how to verify the scenery at such detail, but I wouldn't mind getting to know what it's actually composed of. If someone knows how to do this, please do and we'll talk on actual numbers.

And on a more prosaic note, if we dispense with the truth of things, we will just have a very hard time finding out what is actually going wrong. Tracking bugs with a preconceived attitude that X must be wrong ain't working. It needs an open mind.
You're giving too much importance to little details. It doesn't matter if the scenery is made of 40x40cm polygons or 30x30 or 50x50, the veracity of these numbers don't matter a lot to insinuate someone is a liar; what matters is that it consumes too much memory for the size it is.

So I'd ask you to stick with the truth here, and if you don't know it, then you shouldn't say it. Demonstrate to me that the scenery is composed of little 40x40 cm squares please, or admit that you've been spreading wrong information if you can't. It's as simple as that. Do not lie. It's not a big thing to ask I'd think.
I don't know where you got your notions of lie, but it ain't what's happening here. I'm not lying -the scenery did look like it was made of squares that size, and that's what I'm telling. That doesn't make me a liar.

The 2.0 is an early release of a work in progress because we specifically asked for it to be released, no matter the state. It is nevertheless stunning and a big improvement over the 1.0 in level of detail - I really enjoy flying Grand Canyon these days. Once you see it as work in progress which you can use optionally if it runs for you, it has lots of merit.
I know, it's amazing and a very good scenery.

But it matters what is actually wrong with the 2.0 scenery - you still can't say that it's made of 40x40 cm squares, because that is not its problem. You can't say that X is wrong with it when it's in fact Y just because something is wrong.
OK then, I won't say it's made of 40x40 if that's what you're still crying about. Let's say the scenery is made of too much detail for medium/long ranges, and that IS a problem because that impedes people to use higher ranges without having lots of memory.

My response actually was: Do not use the 2.0 scenery (because it is an early, imperfect work in progress release) and watch the issues disappear. I confirmed with my 'Yeah, pretty much' that I recommend putting up a warning that you need lots of memory to use the 2.0 scenery and that I would recommend stay with 1.0 if you don't have that.

I did not say to downgrade graphics settings and a small scenery square. I did not say buy more memory to run FG. I did say that 1.0 scenery runs with 100+ km visibility on 4 GB.


That quote didn't mention any names, I don't why you're so upset about it.

I find it completely inacceptable that you would distort my response so completely out of context, and I do ask you for an apology here.

I'm not distorting your words and I'm not going to apologize over an error I didn't make. That quote DIT NOT mention names.

I'm spending a lot of time in this thread trying to point out the facts - what the issues are as they are known to people, what is been worked on, why things are the way they are. I believe strongly that we can't do without accurate facts, and that your certainty that there's something wrong with FG doesn't give you the right to just make things up which could be wrong. It matters what is actually wrong.

I'm not a developer so, please, don't expect me to give the detail you want. I'm an end user, that's all. What I know is that there ***IS*** something wrong with FG because it's getting slow over time. What I do know is that a plane with a level of detail of the 777-S should NOT eat that much ram. What I do know is that there are other simulator which renders a lot more scenery than FG and yet they don't eat too much RAM. What I do know is that sims like FSX will make the scenery as low detail as possible when you get far from it. Hell, if you're 500m from a mountain it'll start to get such low polygon count it'll actually look like a 90's game. Does it matter? No, because probably most people don't pay much attention to what's far.

I don't need to make things up. I'm pointing what I think it's the problem, based on my low level of knowledge. Do you think you have the right to call me a liar just because I don't know exactly what's causing the problems or because I don't know the exact size of the polygons? That's BS.

You do not need to buy a new computer or more memory to have very pleasant visuals of FG if you have a halfway decent GPU. I have plenty of forum screenshots in the old scenery to demonstrate that.

But to run the 2.0 scenery in its current state (which is, as I repeatedly said, an early work in progress release which the scenery team was reluctant to do) you do, and my recommendation is to stay clear of it till the issues (zero area triangles, LOD,...) are resolved.

And I will stay away from it. It makes me sad that I have to abandon FG atm, but I believe one day it will work properly for everybody.

And I won't have you lie into my face that I dismiss everything with 'Just buy a new computer or use 10 km visibility range'. Because I don't. And I'm really angry about this comment. I understand you're frustrated, but that doesn't give you the right to distort what I say. I'm just trying to explain things to you (I won't say help you because your mind is already set, but I do believe I help others in making them see that people are aware of issues and that action is taken and that FG development is not a bunch of morons).

I already said your name was not mentioned, I just said what it seems to be the solution to the problem in the developers' view in my opinion. So calm yourself and stop calling me a liar because I'm not. I might be misinformed, and I really don't mind stating I was wrong about something, but I'm not a liar, no matter how many times you say I am.
junior-s
Retired
 
Posts: 212
Joined: Tue May 21, 2013 3:27 am
Location: Wonderland
Callsign: junior-s
Version: GIT
OS: Arch Linux

Re: How can I retire from the forum?

Postby Hooray » Fri Jul 04, 2014 1:18 pm

Thorsten wrote:Case in point - it'd be interesting to find out why FG in junior-s system can drop from 50 fps down to 5. I've never ever seen this, I don't know anyone who has, it'd be important to find out what's the issue and see whether we can address it - but rather than a structured bug report, or anything I could try to help to diagnose, what I see of this is 'FG is becoming unusable, how do I retire from the forum'.

Certainly true, but I believe this to be simply the initialization process: Initially, you'll get much higher frame rates - but once all subsystems are running, things WILL obviously be affected. As long as this is happening during the first 60-90 seconds, I've seen it before. If it's happening later, I'd GUESS that it's related to rogue Nasal callbacks (timers/listeners), because that's what''s typically happening when using reset/re-init a few times: viewtopic.php?f=30&t=21185&p=202921&hilit=#p202921

Thorsten wrote:One problem is that GIT these days isn't treated as the experimental stuff it is where things can break overnight and where people diagnose issues and report back (if that is done, for instance in the case of the JSBSim zero altitude bug crossing into the ocean, things get fixed quickly). But rather, GIT gets treated as release-quality code, people complain that potentially unstable code gets committed to the repo (where else is it supposed to be tested?).

I don't disagree at all - but I'd also be inclined to simply create a wiki article explaining the situation, and then posting a link whenever that discussion comes up.

(Originally, there actually was a conceptual separation i.e. WRT to master/next branches, but this hasn't been used in years, despite having been established by Tim Moore as such.
But these days, we're simply lacking the manpower to do so.)

Thorsten wrote:The mechanism as such is clear and sound: We have the Jenkins nightly GIT binaries on distribution, we distribute release candidates, these should lead to test data on a wide set of systems, which them comes back and enables people to take action.

As you know, many people don't even know how to get/deploy and use a nightly snapshot, let alone actually provide useful/actionable data, "useful" in the sense that developers can actually act upon that data, and you keep saying this yourself:

Thorsten wrote:rather than getting meaningful and actionable feedback from GIT users, we're seeing more and more non-actionable complaints that the version which is intended for testing and experiments isn't fully tested. [...]
Complaining that X is broken without providing the info necessary to fix it won't help. Making claims that feature X is causing a problem without having any evidence won't help. Ascribing opinions to developers which never have been said won't help. [...]
With a user-side attitude like 'If it's broken, let someone else figure it out, not my job' we can't do it. We don't have an array of different computers at home so that we could do specific testing - I have my laptop to test, and that's it. We rely on users entering an issue tracking process, making systematic tests under guidance, reply to questions.


So I am not sure where you knee-jerk reaction of disagreeing with this/me comes from...

Thorsten wrote:It is simply not true that such things go unnoticed. I made a report about 2.0 scenery resource consumption to the devel list prior to the 3.0 release. There have been many discussions on memory consumption.

yes, recently - mostly raised by 2-3 people. But like I said, some of our end-users have been bringing this up as early as 4-5 years ago, and they're obviously feeling not amused now, which I can relate to. I, too, belonged to the camp of people who would simply post instructions rather than take them more seriously. This thread alone has resulted in a handful of people sending "messages of support" to me via PM, which includes past contributors. I think part of the problem is the focus on, discussions. We've seen this on the forum, too - people think that a discussion will "suffice", and obviously that applies even less so to forum discussions than devel list discussions. But overall, the right thing to do would be filing an issue and gathering all related information there, kinda like a "meta bug". And not having roughly a dozen of discussions in 2-3 different places (forum, devel list and wiki).


Thorsten wrote:Obviously you have your agenda here just as well. We all have our different strategies to identify problems and track bugs. You like working from a debugger, you'd use tools to profile and optimize shaders, I don't - I like to debug from Nasal-internally and do performance testing GLSL internal. Whether we need monitoring tools or not is a question of debugging strategy.

You are mis-interpreting what I wrote, even though I never said that I didn't have an "agenda", I never suggested to include any kind of "debugger" like you are saying now. I just said that we need to provide mechanisms to allow non-developers to provide actionable data, without having to be expert developers or highly-experienced contributors.
I don't agree at all that the question whether we need integrated monitoring mechanisms is a matter of "strategy" as long as we're expecting non-developers to make GOOD bug reports.
Obviously someone familiar with Nasal, GLSL and C++ doesn't need such tools, but these people can usually also provide good bug reports without any hand-holding. But the instant we expect our end-users to make useful bug reports, we need to integrate and provide optional diagnostics - analogous to the system/performance monitor or the OSG on-screen stats, otherwise we'll keep on having these discussions for another 5+ years probably.
To be honest, I find your whole point about "not needing a debugger/profiler" kinda moot actually - you are without doubt referring to your own work here, which you're highly familiar with. Then again, I am sure that our degree of improving performance issues in FG would be much better if we had access to such tools, because it would no longer necessarily involve all the manual work, and we'd be much more likely to look at areas that we didn't write ourselves originally. I've really only seen 2-3 guys around here who regularly roll up their sleeves and try to "debug" Nasal-induced performance issues reported by end-users. And even core developers keep emphasizing how the lack of a debugger is making Nasal less appealing, here's a more recent example: Subject: Instruments for homecockpit panel.
Torsten wrote: no proprietary scripting language without a debugger.


I haven't been tracking your commits lately, so I cannot really state whether I've seen you make performance fixes to Nasaal code that you haven't written yourself, but a few of us have actually made such improvements, and that's pretty much when having good run-time diagnostics is a huge time-saver. Otherwise, the whole process would be highly manual, explicit and really tedious. It is only "expertise" and internals knowledge that makes this somewhat straightforward.

Thorsten wrote:I can usually track GLSL and AW Nasal issues if somebody really works with me - is willing to tell me what happens if code blocks I indicate are commented out, describes the detailed sequence of steps which lead to weird behavior. I can't track issues based on vague reports 'X is broken' when I don't see it myself.

right, but please just keep in mind that the majority of FG contributors do not work like you - the number of contributors able to actually do the kind of "scientific research", and even monte carlo runs is not exactly huge - I think you are basically the first, and only, guy to actually post "statistics" for common coding constructs and patterns. But at the end of the day, this is usually just about your own work, and doesn't automatically help code created by others. Most of our end-users do not hold PhDs in maths or physics, so it is unreasonable to expect them to adopt the same kind of working model obviously. If we expect good issue reports, we need to make things better accessible - also to people who may not have a technical/academical background.

Thorsten wrote:From where I stand, we're mainly lacking willingness of users to actually run tests under guidance. If people can't be bothered to report their system specs or what they're actually doing in detail, then I can't see how they'd report more internal diagnostics.

I don't know - personally, I believe we simply couldn't deal with the results: Just look at some of the recent developments in this area, such as the integrated "Crash Reporting" system: We've been seeing dozens of users making extensive use of this - and then it became obvious that the SINGLE recipient of all these bug reports simply couldn't deal with the sheer number of reports, because we never established any mechanism to process all the feedback at a larger scale. Or look at the issue tracker and the number of "critical" bugs there - which I think kinda proves the point that we, as a project, cannot deal with too much feedback. Even though that may not necessarily apply to other contributors, like yourself. But the few people who do not just have 2-3 "pet projects", but who maintain the whole simulator, cannot deal with the sheer amoung of feedback.
Thus, I think that built-in diagnostics and automated regression testing would help us more in the long term, i.e. kinda like the whole "benchmark" debate we've been seeing for years. The final result could then be a "flight recorder tape" that includes important run-time info, i.e. stats but also log files.

Thorsten wrote:Also, what we can (and largely have) established are the facts of resource utilization.

The whole posting provides the point, because how many people were able to provide such numbers ?
And let's keep in mind that this is about a single thing: textures.
Would it have helped us 4 years ago when "random buildings" were gobbling up GBs of memory ?
Would it have helped us identify the TG 2.0 issues earlier ?
Probably not. Still, it would make a ton of a difference if this info could OPTIONALLY be accessed at run-time in FG, so that developers can more easily track what's going on.

Gotta stop responding now, this has already taken way too much time ... :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How can I retire from the forum?

Postby adrian » Fri Jul 04, 2014 5:29 pm

Thorsten wrote in Fri Jul 04, 2014 8:08 am:Adrian, you know that James has now pushed your changes to the tile manager, do you?


You're definetly wrong on this one, Thorsten. I was surprised to hear this, so I just took a look at the source tree. None of my changes are in next. Otherwise there would be no more complaints about memory. I can run 40-60 km visibility in Swiss mountains with only 2 GB of memory in use by FG. It would be a bad idea to merge my changes in anyway now, since the whole simgear tile loading api has changed a lot since I last hacked on it.

I'll post it again again here, in order to be able to complain later on that nobody actually reads my posts:
The tile cache does not need to be twice as large as the visible terrain, because the tower view issue can simply be solved by restricting the view to only a few km away from the tower.

There. Now I can retire. Oh, btw I changed my mind, please make it purple.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 3:15 pm

Re: How can I retire from the forum?

Postby Thorsten » Fri Jul 04, 2014 5:44 pm

This thread alone has resulted in a handful of people sending "messages of support" to me via PM, which includes past contributors.


Yes. Stop and think a moment. For what did you get support?

What is it we want?

There's the 'kingdom of heaven' approach: We picture FG how it should be. Fast. Efficient. Easily customizable. Able to auto-adjust to the hardware performance. Great graphics. High detail close to the ground. Visibilities up to orbital altitudes. No high memory footprint. Then we applaud every time someone suggests to make it like that. Because somebody else will probably make it so if we tell them long enough that what they've done so far is trash, and if we let them know that all these things really should be possible.

And like the kingdom of heaven, it will come eventually.

And there's the 'republic of heaven approach'. In which we realize that FG is ours. So we, every one of us, can start fixing and improving it right here, right now. None of this will be perfect. We realize that there's a problem with scenery size - so we think what we can do right now to address it. The issue needs to be documented, the people who can need to be convinced that a LOD system needs to be written, this kind of thing. We need to explore what can be customized, what should be customized, we need to start with what we have.

Yeah, the kingdom would be nicer. I admit that. Offered as a choice, I'd also go for it.

But the republic thing has always worked better for me. Somehow, the kingdom didn't ever come.


You're giving too much importance to little details. It doesn't matter if the scenery is made of 40x40cm polygons or 30x30 or 50x50, the veracity of these numbers don't matter a lot to insinuate someone is a liar; what matters is that it consumes too much memory for the size it is.


Well, I think it does matter. You're accusing people of doing something wrong. You say the design of the scenery is bad because.... You say it consumes too much memory for the size it is. You're stating the developers don't care and just argue to buy a new computer.

So - does it matter if you're right or wrong?

Yes - it matters very much. It matters to you if I accuse you of lying - does it have relevance whether you actually lied or not? It sure does for you. So the same way it matters the other way round.

(The scenery isn't made of regular polygons at all, in case you'd like to know. The typical size scale of CORINE data is 10-30 m, which means you got the vertex density by about a factor 1000 wrong. If I'd claim the framerate is 1fps whereas it really is 1000, would you think that factor 1000 matters?)

Let's say the scenery is made of too much detail for medium/long ranges, and that IS a problem because that impedes people to use higher ranges without having lots of memory.


The scenery doesn't have a LOD system yet, yes. I gather the philosophy was we need a viable scenery first before we can simplify it down to implement a LOD system - so we have the first step done, and the second is in progress. What you're upset about is that the second step isn't done yet and the scenery team was stupid enough to listen to people like me and gave us what they had so far. But people needed to start with the first.

Here, sounds far less dramatic if you say it like that. Why don't you?

I'm not distorting your words and I'm not going to apologize over an error I didn't make. That quote DIT NOT mention names.


I asked you to point me to an instance where anyone in the forum had said this, you choose to point me to my own post, so I think you DID mention my name quite clearly in doing that. And hence I ask an apology.

I'm not a developer so, please, don't expect me to give the detail you want. I'm an end user, that's all. What I know is that there ***IS*** something wrong with FG because it's getting slow over time.


I'm saying this over and over, but FG, the aircraft you run in it and the scenery you display are distinct objects (and even the shader effects you run to some degree are). If I have a buggy aircraft, FG will do weird things, but that's not the fault of the core code.

You can't use a bad aircraft to argue that the core code is bad. You can't use memory-consuming scenery to argue that the rendering has bad effects. This is not how things are. You need to be careful how to assign blame.

There's nothing wrong with FG as far as I know - it will probably run fine on your computer and deliver quite decent visuals if you customize it. There's a lot wrong with the way the information how to customize it to your needs is documented and transmitted. And this is where the republic of heaven thing could come in - rather than complain and write support PNs for the kingdom to come, you (all) could help to assemble, improve and spread this information.

But what do I know - I just want to keep FG from being perfect, so you need to support Hooray against me.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How can I retire from the forum?

Postby Thorsten » Fri Jul 04, 2014 5:47 pm

The tile cache does not need to be twice as large as the visible terrain, because the tower view issue can simply be solved by restricting the view to only a few km away from the tower.


Tile cache is by default now gone... Sorry if I got this wrong, this is probably not how you did it literally, but James followed the spirit of your argument certainly. So only visible tiles occupy memory now.

Here's James' description

I’ve added some optional features to reduce memory consumption, and since ‘next’ is for testing, I’ve switched them both on by default in current Git. They are:

- /sim/tile-cache/enable

Previous was effectively ‘true’, the default on next right now is ‘false’, so the tile cache is disabled. This leads to some visible popping when switching between tower and cockpit views, but otherwise I can’t see any problem with disabling the cache - and it saves an enormous amount of memory. Unless testing reveals any problem, I’d propose to make this default to ‘false’ for 3.2.0 too.

- /sim/rendering/max-paged-lod

This exposes an OSG value, which we previously did not adjust. This is how many PagedLODs to keep around, even when they are inactive (outside the current view, in practice). This controls how quickly we unload Paged elements of tiles - trees & random buildings principally. The default value of 300 means we’re keeping many PagedLODs for tiles outside the view, so this has been lowered on next to 8. Some tuning of this value is welcomed, whether 0, 8, 16 or 32 make any appreciable difference to popping or memory consumption. I can imagine setting it to zero leading to more visible popping of trees & buildings when flying circuits around an airfield - that’s the motivation for the current value.

If you comment out the new entries in prefrences.xml, the C++ code will use the old values (cache enabled, max-paged-lod=300) automatically.

Of course, the mose important test is if this makes the 2.0 scenery usable on 32-bit machines. I can’t perform that test, so hopefully some other people here can.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: How can I retire from the forum?

Postby Hooray » Fri Jul 04, 2014 6:22 pm

No need to turn into drama queens ... and no need to tell me how the project works vs. how it should work. But like you mentioned yourself, we've seen patches being ignored/rejected that would address some of the issues mentioned here. And I think people providing patches are the epitome, if not the pillars, of your whole "republic of heaven approach". Some of us actually realized, even years ago, that we're facing a problem here, and some of us rolled up their sleeves to provide patches, to help address some of the underlying issues - no matter if it's Adrian's patch or mine. We wouldn't be having this conversation in its current form if these patches, or improved versions of them, had it been applied several years ago.

Again, you are making this very specific to scenery currently, even though I've demonstrated that this is just the current manifestation of a deeper problem.

But I really don't think it's fair to state that I am "against you". Far from it, but you will find that what applies to you, doesn't necessarily apply to other contributors, and certainly not most end-users.
I am not interested in providing end-user support, or in dealing with poor bug reports, I am interested in enabling people to provide people with means to provide us with good information that we can act upon, and I don't want this to be specific about a single technology, let alone a single subsystem like AW/ALS etc, or even require the people who originally wrote the code to be around to make sense of an issue. But I never said anywhere that I wanted to integrate a profiler or debugger necessarily - those are fairly low-level tools and most end-users couldn't deal with them either.
In fact, there's an integrated profiler, which while optional, is being used by fellow coders - and I was the one who provided the corresponding patch. Yet, I fully realize that is has not much of a merit when it comes to dealing with end-users.

I don't think we need to resurrect the whole debate about OpenGL/GLSL-level profiling and your disagreement with using established tools and techniques - I am not involved, or even interested, in GL/GLSL stuff currently, so I should have hardly any say on how you do your troubleshooting - no matter how many columns you can find online, written by professional OpenGL/GLSL developers (like e.g. the X-Plane devs) that say otherwise. At least for me, part of the problem here revolves around the fact that the major tools are Windows-based, which I simply don't use very often these days.

But like I said, there are issues outside rendering that need to be understood, documented and addressed over time - even regardless of any OpenGL/GLSL issues.

Personally, I find it kinda short-sighted to limit, or even just associate, the whole debate with TerraGear and scenery development. Anybody who's been around for a few years, knows that we've had a plethora of non-scenery features that ended up gobbling memory, even though I do agree that mentioning random buildings in this context was probably not very smart, I just did so, because it's a feature that has basically zero to do with TG. In other words, we're having issues regardless of TG, and I don't think it's fair to really blame it all on TG, which is a huge, complex and intimidating code base, so I don't envy the few people involved in working with it.

I do think that my whole point about troubleshooting code that we also didn't write originally still holds true - I've worked with code like AW and Bombable, and quite a few other non-trivial scripts/applications, and here, having OPTIONAL tools to help diagnose issues (CPU/RAM utilization) is the most essential time-saver, and basically the motivator and key-prerequisite to actually consider such attempts.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How can I retire from the forum?

Postby adrian » Fri Jul 04, 2014 7:21 pm

Oh, I see what you mean now. But James' restructuring has nothing to do with my original inner ring/ outer ring approach. It must be based on Mathias' improvements in Simgear. Basically I did not trust OSG PagedLod, mainly because I didn't fully understand how it worked, so instead I relegated all the terrain management to FG/Simgear. My way is a sure method to decrease memory consumption, albeit a bit hackish. Maybe James' code is better? Don't know, can't test it without a graphics card. Anyone donating a machine with a modern graphics card?

Purple please, thank you very much.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 3:15 pm

Re: How can I retire from the forum?

Postby adrian » Fri Jul 04, 2014 7:31 pm

Thorsten wrote in Fri Jul 04, 2014 5:44 pm:But the republic thing has always worked better for me. Somehow, the kingdom didn't ever come.


That's because we didn't have a queen. Every kingdom needs a queen, I thought you knew that?

The scenery doesn't have a LOD system yet, yes.


I was right on track for a 3-level LOD system for the terrain which didn't require modifying the TG toolchain. Unfortunately I was ultimately derailed into doing more interesting stuff for other projects. Eventually someone will get fed up and just write the thing.
adrian
 
Posts: 362
Joined: Wed Sep 15, 2010 3:15 pm

Re: How can I retire from the forum?

Postby junior-s » Fri Jul 04, 2014 7:54 pm

Well, I think it does matter. You're accusing people of doing something wrong. You say the design of the scenery is bad because.... You say it consumes too much memory for the size it is. You're stating the developers don't care and just argue to buy a new computer.

You're mixing things and putting them out of context. The quote you just linked refers to the veracity of my claims towards the scenery detail size -and not my view of what it looks developers say to people who claim FG is too resource hog.

So - does it matter if you're right or wrong?
To me? Not anymore.

Yes - it matters very much. It matters to you if I accuse you of lying - does it have relevance whether you actually lied or not? It sure does for you. So the same way it matters the other way round.
Accusing someone of lying is way worse than having some numbers wrong, specially when I don't have the exact numbers and rely on some picture I don't even know where it is.

(The scenery isn't made of regular polygons at all, in case you'd like to know. The typical size scale of CORINE data is 10-30 m, which means you got the vertex density by about a factor 1000 wrong. If I'd claim the framerate is 1fps whereas it really is 1000, would you think that factor 1000 matters?)
Of course, when you do know the exact numbers.

What you're upset about is that the second step isn't done yet and the scenery team was stupid enough to listen to people like me
That's your view, which isn't accurate at all.

What does this LOD system mean, actually? If it means it will manage scenery detail in a better way, then I'm not mad about it not being here now. And I'm not mad at the scenery team either.

I asked you to point me to an instance where anyone in the forum had said this, you choose to point me to my own post, so I think you DID mention my name quite clearly in doing that. And hence I ask an apology.
Apology accepted as long as you apologize me for not being so clear at some posts :)

I'm saying this over and over, but FG, the aircraft you run in it and the scenery you display are distinct objects (and even the shader effects you run to some degree are). If I have a buggy aircraft, FG will do weird things, but that's not the fault of the core code.
Got it.

You can't use a bad aircraft to argue that the core code is bad. You can't use memory-consuming scenery to argue that the rendering has bad effects. This is not how things are. You need to be careful how to assign blame.
I know that what I said was too generic, but I also mentioned here what causes the memory consumption to be high, be it the 777, rembrandit (mentioned now), or the scenery.

There's nothing wrong with FG as far as I know - it will probably run fine on your computer and deliver quite decent visuals if you customize it. There's a lot wrong with the way the information how to customize it to your needs is documented and transmitted. And this is where the republic of heaven thing could come in - rather than complain and write support PNs for the kingdom to come, you (all) could help to assemble, improve and spread this information.

I'm not saying some aspects -as the scenery or some aircraft- are bad (much the contrary), but it's resources consumption are high for the quality they deliver.

But what do I know - I just want to keep FG from being perfect, so you need to support Hooray against me.
I never wanted to put people against each other here, and I don't have participation on what Hooray says. I just wanted to retire from the forum :?
junior-s
Retired
 
Posts: 212
Joined: Tue May 21, 2013 3:27 am
Location: Wonderland
Callsign: junior-s
Version: GIT
OS: Arch Linux

Re: How can I retire from the forum?

Postby junior-s » Fri Jul 04, 2014 8:03 pm

Pardon me for posting contents of another simulator here, but I think this might be interest to someone.

Here are the detail level of the FSX scenery on TNCM. Please look at the polygon count:

Cliffs a few hundred meters away http://postimg.org/image/6um495zv9/

At 1500ft http://postimg.org/image/olxqnmf9x/

At 5000ft http://postimg.org/image/g4tmyyl79/

Some island http://postimg.org/image/okj7ggo2d/

TNCM at 10000ft http://postimg.org/image/leylq95g5/

At 15000ft http://postimg.org/image/bf3pacu6t/

At 30000ft http://postimg.org/image/9anxn0hxx/

Some other island http://postimg.org/image/klqlbdot1/

TNCM at 35k ft http://postimg.org/image/6e0wmqc45/

The most important: TNCM at 10.000ft and a few miles away http://postimg.org/image/c0so6gp91/
junior-s
Retired
 
Posts: 212
Joined: Tue May 21, 2013 3:27 am
Location: Wonderland
Callsign: junior-s
Version: GIT
OS: Arch Linux

Re: How can I retire from the forum?

Postby Thorsten » Sat Jul 05, 2014 7:28 am

You're mixing things and putting them out of context. The quote you just linked refers to the veracity of my claims towards the scenery detail size -and not my view of what it looks developers say to people who claim FG is too resource hog.


For the record, I also didn't back up your claim on scenery detail size.

junior-s - a terrain LOD system is what you describe as the state which it should be and what's in your links - a technique by which faraway terrain is rendered in few polygons and close terrain is rendered in many. We're not stupid, we know how this works :-) This has been discussed starting years ago, and after the advent of the new scenery, people got busy preparing it.

But the salient point is - LOD works by downsampling the resolution of scenery, and the plan, I think, is to do this offline. So you need to be able to create the hires scenery before you start downsampling it, that's non trivial and took years to make the toolchain ready for the current state. The scenery which TG assembled before was simply not viable.

Which, in a nutshell, means - people are right now busy doing exactly what you think should be done. That's the bad way the project is on. *sigh*

Anybody who's been around for a few years, knows that we've had a plethora of non-scenery features that ended up gobbling memory, even though I do agree that mentioning random buildings in this context was probably not very smart


I posted the numbers. Rebecca finds that above Ocean, FG uses 0.75 GB and at KSFO (!) using the old scenery 1.1 GB. Hardly any dependence on effects, random trees, or textures resolution.

I don't particularly care what everyone 'knows' when the numbers say otherwise. Did you even read through them? The numbers say that without any doubt, 2.0 scenery is what uses all the memory, nothing else - not hires textures, not trees. What's the use of analysis tools if you're willing to throw out test results because 'everyone knows'?


Well, there's a pattern to recent forum discussions. And I'm going to play drama queen (see, we have one) now because:

The FG project has been criticized

- because ALS would be unstable code and make FG crash
... whereas in actual reality ALS is GLSL code run on the GPU and has nothing to do with the core code, and unless the graphics driver has serious issues, it can't crash the core conceptually.

- because ALS would gobble up everyone's performance
... whereas in actual reality it is optional and doesn't drain any resource if it isn't run, the shaders aren't even compiled

- because the scenery would use small 40x40 cm square patches
... whereas in actual reality it uses an irregular mesh of triangles which are significantly larger.

- because the tile cache would store unneeded scenery up to twice the visibility range
... whereas in actual reality it has been switched completely off by default

- because developers would not care and just suggest to buy new software
... whereas in actual reality I haven't seen a single instance in which a developer has said it suggested that, but I have seen many instances where decisions were made with explicit concern for compatibility with old hardware

- because a memory analysis as done by Rebecca would be really complicated and require special skills
... whereas in actual reality all you need to do is open the system monitor of the OS, start FG with a certain set of config options and read off the numbers from the system monitor

- because lots of different features would gobble up memory
... whereas the actual numbers show that memory usage is driven by a single feature, i.e. 2.0 scenery

- that the project would be on a bad way
... when in actual reality people working on precisely the features which junior-s had in mind.


See a pattern?

Anyone feels free to simply claim these things and criticize ahead. It doesn't seem to matter any more whether the points are actually true - people are dissatisfied, and so they feel entitled, and if their actual claim is wrong, then at least the idea behind must be right, because, damn it, we know. Screw the facts!

And the sad thing is - I haven't seen a single person step up and say: Sorry, what I said was wrong, I made a mistake here. And that's where you should start thinking.

Is this the community you want to be in? Where everyone can say bad things because he's frustrated about something, where truth and facts are secondary concerns? Because that's sure as hell not the user community I want to be in touch with.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 4 guests