General Remove "likelihood" feature, it is unnecessary in the current version of the FSS

[Rat Catcher]

True enough but that still doesn't alter the fact that, to scan or not to scan takes exactly the same amount of time as the previous FSS, as scanning a planet with, say 48 geological sites will still take over 15 seconds unless you cancel it. When an immediate 'none' still takes no time at all. Of course there is the possibility ( not one I've had yet) that a 'likely' scan will return zero sites which then means the scanning has actually cost you time which as you state in a vulnerable stationary position is not a desired situation.

I had my first likely return a zero a couple of days ago. The same as previously when a scan completed and returned a zero despite the body having volcanism.
I'll admit to being fortunate that a full scan only takes around 6 seconds, so waiting isn't too much of a chore.

You do get the liklihood displayed immediately, with an error rate of less than 1% I'd guess, which is fine. Bio/other is also immediate so overall, against pre-patch scanning is considerably faster if one doesn't wait for completion.

 

[Darkfyre99]

This conversation with @bitstorm started on another thread, where it was off topic. It is very much on topic here, so we’re coming here to continue it.

Previous post:

Spoiler

Frame rate is not the same as GPU utilization. Frame rate can be used as a shorthand for GPU utilization, relative to the refresh rate of your monitor or VR headset, but its not the same. Frame rate is how many frames per second your GPU can output to the visual device of your choice. GPU utilization how much of a graphic card's processing power is currently being used.

GPU utilization will affect frame rate, naturally. The more work a GPU has to do, the fewer frames it can churn out in a second. Elite: Dangerous' planet generation algorithm uses the GPU, rather than the CPU, to create a planet's surface. The amount of time it takes to generate the surface depends upon how much "free resources" the GPU has. A GPU that's able to output 300 fps to a monitor that refreshes at 60 hz is basically being used at 20% capacity. So it has a lot of "free cycles" to use for other things... cycles that are basically wasted on unused frames.

So why does a video card that has its frame rate capped at 60 fps take longer to generate a planet surface if that card is being used at 20% capacity? Because the purpose of frame rate capping is to artificially limit GPU utilization in order to reduce energy consumption, reduce heat, and/or reduce fan noise. Some people think it will also reduce screen tearing, but that's what v-sync is for. There are two ways to cap frame rates that don't involve 3rd party software: the video card, and the game itself. In the case of the former, the video card simply discards calls to the GPU if its too early to draw the next frame. If its the game itself, then it won't send calls to the GPU until its time to draw the next frame.

Given that frame rate capping does affect planetary generation speed, I suspect that like most modern games on the market, Frontier is using modern video cards' native frame rate capping ability in its Cobra engine. After all, why reinvent the wheel? But because they also use the GPU for surface generation, rather than the CPU, there's an unexpected side effect.

Awesome, thanks for that, an actual explanation!

So I now have some questions if this is ok.

We are saying the framerate limit in ED, does not just limit the framerate it literally slows down your GPU? (I mean I'd argue framerate is the wrong term for this if it's the case, or at least add an informational to the interface FSS)

Does this also apply to the vsync options? Enabling vsync also breaks/fixes my mouse speed, I haven't tested geo but I'm gonna assume the same. Also has it always been the case that enabling vsync essentially kneecapped your GPU? My understanding is having framerate and processing independent was a problem solved a very long time ago.

You say that ED is likely using "native framerate capping, after all why reinvent the wheel". So from this I'm going to assume that solving the geo scan is not impossible as claimed? But perhaps a rather significant amount of work?

I think that the term “Graphics Card” these days is a misnomer. They’re better called a “Gaming Card,” because they do so more than graphics these days, in particular physics simulation and collision detection. This allows game developers to offload these tasks to the GPU, and use CPU resources for other tasks necessary for operating the game, like AI. Of course, while the modern “Gaming Card” is designed for games, it’s still basically a computer within a computer, and it can be used that way with some know how... as Bitcoin Miners demonstrated.

Which is why I think Frontier decided to use the GPU for surface generation, rather than the CPU: they needed these functions for their proc-gen anyways, and why reinvent the wheel? The “problem” is that I susoect that these functions are tied to fame rate by default. 99% of the time, this makes sense. In most games you want these functions operating in sync with each other, along with user input, since the most likely bottleneck is the CPU, and weird things can happen if various processes are out if sync. But because Frontier is using the GPU for proc-gen surface generation, not just “normal” game functions, so when the frame rate is artificially throttled, there are unexpected side effects.

When it comes to v-sync vs frame rate caps, and why they have an effect on the surface generation, I think it’s best to think of them as turnstiles at a subway station. By default, they let through as many commuters as possible, as quickly as the trains can load them. By default, the griaphics card driver assumes a commuter is an adult (next video frame) with a briefcase for work (physics, collision detection, etc.). Elite: Dangerous, though, sometimes sends a second type of commuter, one the driver isn’t designed to handle separately: a child with a backpack for school (surface generation). By default, it assumes any child will be accompanied by an adult.

As long as the frame rate isn’t throttled, things work as expected. As soon as you start throttling things, though, it’s on get unexpected results. The turnstile meters how many commuters are allowed through, and any child still needs to be accompanied by an adult. If Frontier wants to allow for “free-range children,” it needs to redesign the turnstiles to permit it.

Now, how you limit frame rates depends on what method you use. The main difference between a frame rate cap, and v-sync, is that one is a hard limit, the other one adjusts itself to keep the frame rate at multiples of the screen’s refresh rate. In the case of the former, if your video card can handle 300 FPS, and you limit it to 60, your GPU will be idle 80% of the time. Great for conserving battery power, not burning your lap, or reducing fan noise, but it has knock on effects.

In the case of the latter, if your monitor has a refresh rate of 60 hz, and your GPU can handle 300 FPS, then it will work at 300... until the frame rate drops below 300, where it throttles down to 240. If the frame rate drops below 240, it throttles down to 180, and so on. Below 60, it will go down to 30, then 20, 15, 10, and so on. This helps prevent screen tearing.

Unfortunately, my last break at work is over, so I’ll have to finish here. Hope this makes sense.

 

[bitstorm]

 

[GroG79]

This new feature seems very broken to me! The scans do not complete unless you keep watching. So it is indeed useless.

And scanning times increased even.

 

[bitstorm]

This conversation with @bitstorm started on another thread, where it was off topic. It is very much on topic here, so we’re coming here to continue it.

Previous post:




I think that the term “Graphics Card” these days is a misnomer. They’re better called a “Gaming Card,” because they do so more than graphics these days, in particular physics simulation and collision detection. This allows game developers to offload these tasks to the GPU, and use CPU resources for other tasks necessary for operating the game, like AI. Of course, while the modern “Gaming Card” is designed for games, it’s still basically a computer within a computer, and it can be used that way with some know how... as Bitcoin Miners demonstrated.

Which is why I think Frontier decided to use the GPU for surface generation, rather than the CPU: they needed these functions for their proc-gen anyways, and why reinvent the wheel? The “problem” is that I susoect that these functions are tied to fame rate by default. 99% of the time, this makes sense. In most games you want these functions operating in sync with each other, along with user input, since the most likely bottleneck is the CPU, and weird things can happen if various processes are out if sync. But because Frontier is using the GPU for proc-gen surface generation, not just “normal” game functions, so when the frame rate is artificially throttled, there are unexpected side effects.

When it comes to v-sync vs frame rate caps, and why they have an effect on the surface generation, I think it’s best to think of them as turnstiles at a subway station. By default, they let through as many commuters as possible, as quickly as the trains can load them. By default, the griaphics card driver assumes a commuter is an adult (next video frame) with a briefcase for work (physics, collision detection, etc.). Elite: Dangerous, though, sometimes sends a second type of commuter, one the driver isn’t designed to handle separately: a child with a backpack for school (surface generation). By default, it assumes any child will be accompanied by an adult.

As long as the frame rate isn’t throttled, things work as expected. As soon as you start throttling things, though, it’s on get unexpected results. The turnstile meters how many commuters are allowed through, and any child still needs to be accompanied by an adult. If Frontier wants to allow for “free-range children,” it needs to redesign the turnstiles to permit it.

Now, how you limit frame rates depends on what method you use. The main difference between a frame rate cap, and v-sync, is that one is a hard limit, the other one adjusts itself to keep the frame rate at multiples of the screen’s refresh rate. In the case of the former, if your video card can handle 300 FPS, and you limit it to 60, your GPU will be idle 80% of the time. Great for conserving battery power, not burning your lap, or reducing fan noise, but it has knock on effects.

In the case of the latter, if your monitor has a refresh rate of 60 hz, and your GPU can handle 300 FPS, then it will work at 300... until the frame rate drops below 300, where it throttles down to 240. If the frame rate drops below 240, it throttles down to 180, and so on. Below 60, it will go down to 30, then 20, 15, 10, and so on. This helps prevent screen tearing.

Unfortunately, my last break at work is over, so I’ll have to finish here. Hope this makes sense.

So awesome, thanks for that.

So I have some follow up questions / comments :

At normal framerate (300fps) I have a 4 second geo scan time, and an incredibly slow mouse. When I cap it to 60fps in the ED menu I get a 20 second scan and a normal speed mouse. But from what you're saying, it seems lowering the framerate in this way (say to make it align with my monitor) could impact many other things in game, although we are talking about scan times the obvious conclusion is that planetary generation will be much slower, or perhaps the quality of detail will be much less due to the greater time required to build/render terrain or similar. It's also possible capping the frames in this way has a whole host of unintended negative side effects. Does this make sense?

If so I feel this option should be clearly labelled, I bet there are people out there dealing with a 20 second geo scan literally just because they tried to stop screen tearing. I'm seeing this as a bug of the UX variety, I'll probably report this, the graphics menu has informational boxes, it's empty for the framelimit option.

On your vsync/framelimit analogy. I did test this, with vsync enabled (in the ED menu) I get exactly the same issues as when limiting frames to 60 via the ED framelimit menu. So I think at least in ED's case your vsync description probably isn't applicable, but intersting to know this probably isn't the case with other games.

And just generally the bigger picture here seems to be yes that 90s game dev practices eliminated framerate bound processing (for the game engine and such). But GPUs are tied to framerate and due to the increased flexibility of GPUs they are now being used for parts of the game where the assumptions that tie the GPU to the framerate aren't necessarily valid anymore. Is this an accurate representation.

If so, do you know is this a general issue that devs are dealing with now, or have more modern engines now been able to decouple gpu processing from the framerate such that we are just seeing side effects of an older engine?

 

[[VR] M4st0d0n]

FDev needing our graphic cards to generate whole planets texture/height maps to display two digits and a site type in a FSS is just another example of them failing to integrate player tools on the same level of simple databases like EDSM or EDDB.

Props for the third party sites, who managed to keep ED playable while the original keep sinking money and user resource on technical debts and spaghetti code.

 

[Darkfyre99]

So awesome, thanks for that.

So I have some follow up questions / comments :

At normal framerate (300fps) I have a 4 second geo scan time, and an incredibly slow mouse. When I cap it to 60fps in the ED menu I get a 20 second scan and a normal speed mouse. But from what you're saying, it seems lowering the framerate in this way (say to make it align with my monitor) could impact many other things in game, although we are talking about scan times the obvious conclusion is that planetary generation will be much slower, or perhaps the quality of detail will be much less due to the greater time required to build/render terrain or similar. It's also possible capping the frames in this way has a whole host of unintended negative side effects. Does this make sense?

If so I feel this option should be clearly labelled, I bet there are people out there dealing with a 20 second geo scan literally just because they tried to stop screen tearing. I'm seeing this as a bug of the UX variety, I'll probably report this, the graphics menu has informational boxes, it's empty for the framelimit option.

On your vsync/framelimit analogy. I did test this, with vsync enabled (in the ED menu) I get exactly the same issues as when limiting frames to 60 via the ED framelimit menu. So I think at least in ED's case your vsync description probably isn't applicable, but intersting to know this probably isn't the case with other games.

And just generally the bigger picture here seems to be yes that 90s game dev practices eliminated framerate bound processing (for the game engine and such). But GPUs are tied to framerate and due to the increased flexibility of GPUs they are now being used for parts of the game where the assumptions that tie the GPU to the framerate aren't necessarily valid anymore. Is this an accurate representation.

If so, do you know is this a general issue that devs are dealing with now, or have more modern engines now been able to decouple gpu processing from the framerate such that we are just seeing side effects of an older engine?

Unfortunately, you've pretty much exhausted the limits of my knowledge. I'm an amateur enthusiast, a tinkerer, not an actual game developer... and I haven't really tinkered in the last ten years, thanks to life consuming more and more time. One of the ironies of my life today is that thanks to the wonders of mobile devices, I find I have more time to kibitz on the forums of the games I play than I do to actually play them. This is doubly true for Elite: Dangerous, because the way I play the game demands my full attention, even when I didn't play in VR.

Most of my speculation about what's going on under the hood in Elite: Dangerous is that, speculation, not insider knowledge. In the case of planetary surface generation, I'm basing that on my experiences in early Minecraft, a game that is also heavily proc-gen, and the trials and tribulations that first Notch, and later the entire Mojang team, communicated to those of us who were interested and were around during the Alpha and early Beta of the Java edition. Little things like developing x-ray vision and running into invisible hills because the visuals were out of sync with things like collision detection and terrain generation, or suddenly falling through the ground and then suffocating, because the terrain's hit box generation failed to keep up with the visuals.

 

[-VR- Max Factor]

True enough but that still doesn't alter the fact that, to scan or not to scan takes exactly the same amount of time as the previous FSS, as scanning a planet with, say 48 geological sites will still take over 15 seconds unless you cancel it. When an immediate 'none' still takes no time at all. Of course there is the possibility ( not one I've had yet) that a 'likely' scan will return zero sites which then means the scanning has actually cost you time which as you state in a vulnerable stationary position is not a desired situation.

That's why I want the scan to be removed or as an optional extra which has to be initiated instead of being automatic.

 

[bitstorm]

Unfortunately, you've pretty much exhausted the limits of my knowledge. I'm an amateur enthusiast, a tinkerer, not an actual game developer... and I haven't really tinkered in the last ten years, thanks to life consuming more and more time. One of the ironies of my life today is that thanks to the wonders of mobile devices, I find I have more time to kibitz on the forums of the games I play than I do to actually play them. This is doubly true for Elite: Dangerous, because the way I play the game demands my full attention, even when I didn't play in VR.

No, it's all really interesting. thanks very much for taking the time for that.