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?