Visuals over physics?

[Incarnation of Chaos]

22 hours ago, SciMan said:

I'm one of those people that's played video games for so long that I don't really care what they look like anymore. Yes, good visuals are nice and all, but that's not why people keep coming back to a game.

For that, there's only one thing that fits the bill. That's the gameplay. And for a simulator like KSP (and as much as it's a game, it's even more so a simulator), the only gameplay that matters is "how accurate are the physics".

So yes, incorporating things like Compression Lift or some way of calculating buoyancy of a ship's hull that's made from structural panels and not fuel tanks (but I'll just take a roughly tenfold reduction in the amount of drag that the water creates on things, perhaps combined with making aerodynamic parts like fins have increased effectiveness underwater) would be things I'm interested in much more than something like "clouds and/or volumetric lighting".

All those graphics improvements seem to do for me is make my graphics card run hotter, they don't make me play the game any better, or let me build better rockets or other vehicles.

 

Why not both tho? The PhysX physics engine was originally made to run on a piece of hardware mostly similar to a graphics card, right? If a game like Dyson Sphere Program can use the GPU to simulate a gigantic interstellar factory, why can't it simulate the physics of one or more rocket-propelled vehicles such as spacecraft?

I know, you're going to say "it's not that easy!" or "it's more complex than that". At the end of the day, it's all just math. You can solve an incredibly greater number of math problems on a graphics card than you can on a CPU, simply because of the greater core count (that's one of the reasons DSP is such a good factory game, even if it is somewhat more simple than a game like Satisfactory in the graphics department).
So why can't you do that with a flight simulator? I'm pretty sure that for professional flight simulators that are used to train real pilots, that the simulation is largely being run on what's essentially a graphics card without the video rendering engine part of it (in other words whatever Nvidia is calling their purpose-designed GPU computation card these days, the last name that I can think of is "Quadro").

Go write a basic compute shader for physics and say all of this again.

GPU is a different beast programming wise, and it's a very different model and syntax than conventional programming.

That's not to say it's impossible, but that you need to use a different set of math and a different syntax for programming instructions for a GPU

That isn't to mention the big elephant in the room, which is getting this all to work cross platform. CUDA won't work on AMD, so you really only have openGL / vulkan as an option. 

And then you have to compile your compute shaders at runtime for every individual machine deal with some nasty parallization stuff so you don't run into deadlock or infinite loops.

So if you have two options, one being to optimize the crap out of what you know and get great performance or to attempt writing a entire physics system from scratch just to make use of the GPU that you're entirely unfamiliar with... the first makes much more sense.

Can it be done? Yes

Was it financially practical for the ksp2 devs? Apparently not vs just optimizing what they had.

 

 

 

[SciMan]

You'll note that you never said it was impossible, which is precisely my entire point.

I never mentioned practicality a single time, and that was done intentionally. I'm fully aware that KSP would need an entire core engine re-write to have the whole thing run on the GPU.

But what I did mention is that the GPU is much better equipped to handle these sorts of "do a lot of physics calculations all at once" kind of problems that a flight simulator has if it's not modelling the wings as "just a set of overly-simple equations that don't actually reflect changes made to their shape".

I'm not saying you need to use full-on real-time CFD to make a flight simulator. But you can get a more detailed model to respond quickly, if you have the resources of the GPU to assist or take over for calculating the physics, since PhysX (what KSP is basing its physics on) is basically ALREADY "a physics shader made to run on a GPU", unless I'm grossly misunderstanding something about how PhysX acceleration is implemented on Nvidia GPUs.

[mcwaffles2003]

3 hours ago, SciMan said:

I never mentioned practicality a single time, and that was done intentionally. I'm fully aware that KSP would need an entire core engine re-write to have the whole thing run on the GPU.

So are you just hypothesizing what might be possible if everyone owned super computers and could run the game as a genuine simulation or something? Because, even so at the end of the day, some things can't run in parallel, like rigid body dynamics. Doing so, as I understand it, leads to things like multiple values for the same variable and thus causes great amounts of instability. These problems are circumvented while they are running in series likely with what has been hinted at, an LOD system where in every part doesn't necessarily need to be simulated but instead you can clump groups of parts into blocks and simulate the interaction of those blocks as parts, overall reducing the part count greatly and increasing framerates/performance at the sacrifice of some accuracy. The sacrifice of accuracy in this case is a bit exaggerated though since I wouldn't consider the existence of kraken attacks to be "accurate".

A lot of the games performance hit actually came from fuel flow calculations surprisingly, so I think with that being mitigated as an understood issue we're in for several performance increases. All this said, I'm on board with the attitude of run anything you can in parallel with a GPU and utilize multithreading if possible, but it's a lot easier for me to state that want than it is for it to be manifested in reality.

[SciMan]

Oh yeah I'm fully aware that it would take a lot of coding to get that working. But that's the thing. There are many things in KSP to simulate, that only loosely interact with the rigid bodies simulation.

And yes, fuel flow and other resource calculations are one of those "loosely interacting" things.
If fuel flow calculations don't update for a frame or two, nothing explodes like if you had a kraken strike.
On the other hand, if the rigid bodies miss an update or two, things have a tendency to get accelerated to FTL speeds by the Kraken.
Fixing the "jump to lightspeed" Kraken could actually be fixed in the code rather easily by establishing a "maximum velocity" that things can reach, and if anything reaches that speed its velocity is simply clamped to that maximum speed (with the direction of that velocity kept the same, accounting for the effects of gravity due to whatever body the vessel is orbiting of course).
And to prevent the "jump to lightspeed" in the first place, you'd clamp the "jounce" (aka rate of change of acceleration, I think it's measured in m/s^3) to a sane rate. To prevent this from impacting "normal" simulation, you'd set the jounce limit to be DOUBLE the acceleration of "just the engine" with the highest TWR in the game, assuming that the vessel being measured is composed of ONLY the engine, and that the infinite fuel cheat is on (so you aren't carrying any fuel mass).
This value should be impossible to reach in any case, but if you do reach it, the game will simply use the acceleration value and vector from the PREVIOUS physics frame, for the CURRENT frame.

This works out to be essentially a simple "Sanity check" for the physics engine, with "insane" values being thrown out and using the previous value instead (or if the fuel ran out, 0 acceleration, of course).
Sanity checking is critically important in any physics simulation, because glitches DO happen.

The other krakens can be exterminated in similar fashion, you just need to figure out which variable occasionally jumps to insane values, and put clamping logic on it with limits set so that it should not be possible to hit the limiter in the first place, meaning that if the limit is hit the value is clearly not stable.

EDIT:

And before you say it, no, I don't have any clue how much this would effect how fast you can run the simulation. Considering that they're an "only do the expensive thing if something's not right" type of limit, I hope that the act of comparing against the limits wouldn't cost that much in terms of computing power.

Edited April 6, 2022 by SciMan

[Vl3d]

The issues aren't limits, but bitwise number representation, floating point inaccuracies. For KSP2 I understand devs implemented dynamic frame of reference center points by volume-dividing the universe.

[SciMan]

Ah but with the things I'm describing, the issues ARE when certain dynamic variables exceed a certain limit (or get bit-flipped to be + or - a very large number).

Math's different, solution's the same. If you have to do it bit-wise, do it bit-wise.
The solution remains to make it so that if a variable exceeds a certain (theoretically impossible to reach) rate of change, you clamp it back to the rate of change it had on the previous frame.
Maybe you have to account for frame-of-reference, maybe not.
The point I'm trying to make is that a craft shouldn't be able to wobble itself to the point that it achieves velocities faster than light, and that's what the solution I'm proposing intends to solve.

The whole idea I had is "if you can prove the physics engine is wrong, you throw out the result for this frame and substitute the value used for last frame".
The concept should be able to be applied without regard to how the math is being done in the physics engine itself. After all, it's a "sanity check, and if it's not sane do something about it" type solution.

EDIT: Put another (hopefully easier to understand) way, we already have a setting in KSP 1 called "max physics delta-(Time) per frame" right?
That roughly controls how much the game is allowed to fudge the physics in order to maintain framerate.
What I'm proposing is something related, but also different. I'm proposing to implement "Max physics delta-(acceleration) per frame". In all 6 axes (three linear, 3 rotational).
The idea is that you set the limits so that if things don't go crazy, you don't hit the limit and the game just does its thing.
But when you DO hit the limit, that means something has gone wrong, but instead of just having the game crash or throw up an error on the screen while still catapulting your vessel out of the solar system at say 100 times light speed, you just.... pretend that the game didn't ever calculate that result in the first place, by discarding the (bad) result, and using the (probably was OK) result that was arrived at in the previous physics frame.

Basically, it's like "majority rules voting" for flight computers in a fly-by-wire aircraft, but we only need "one computer" plus a bunch of limits in order to prove the result is sane or not.If it's not sane, we recalculate, if it is, we apply it. And if we recalculated a result, we check that (again) to make sure that that one too is ALSO sane. Belt and suspenders.

EDIT 2:

The issues never were the limits, the limits are put in place to SOLVE the issues.

However, as a side benefit, we do get some realism added to the simulation (it becomes impossible to go faster than the speed of light if you set the maximum velocity to be c = speed of light in a vacuum).

Edited April 6, 2022 by SciMan

[EnderKid2]

issue is that acceleration clamping is going to clip you through the ground because while the max acceleration of a bare engine might be hundreds of Gs, an impact with the ground could be thousands.

[Bej Kerman]

9 minutes ago, EnderKid2 said:

issue is that acceleration clamping is going to clip you through the ground because while the max acceleration of a bare engine might be hundreds of Gs, an impact with the ground could be thousands.

1. What are you relying to?

2. KSP 2 devs are improving collisions leaps and bounds ahead of KSP 1, clipping should happen far less.

[EnderKid2]

thought experiment: single-part rigid-body ship, no crash damage, timestep of 1/10 of a second for simplicity (though this will also apply if our craft is allowed to deform)

t=0.0: craft is heading at the ground at 100m/s. It is 10m above the ground.

t=0.1: craft contacts the ground 100m/s = 10m/0.1s

t=0.2: we have 2 options now:

1.  unconstrained phyisics engine: Craft velocity is set to 0m/s, a change of 100m/s in 0.1s, or 1000m/s^2. The craft correctly stops at the ground and all is fine.

      t=0.3+ Craft velocity is 0m/s, craft is sitting on ground.
 

2. constrained physics engine (set to 100m/s^2): Physics engine calculates that an acceleration of 1000m/s^2 should be applied to the craft and thus its velocity should be set to 0. "error checker" says "oh no you don't", and applies an acceleration of 100m/s^2 to the craft instead, setting its velocity to 90m/s (a change of 10m/s in 0.1s). 

        t=0.3: craft is now 9m below ground (moved 9m in 0.1s). Physics engine calculates that an acceleration of 900m/s^2 should be applied to the craft and thus its velocity should be set to 0. "error checker" says "oh no you don't", and applies an acceleration of 100m/s^2 to the craft instead, setting its velocity to 80m/s (a change of 10m/s in 0.1s). 

        t=0.4: craft is now 17m below ground (and so on)

You see, sometimes extreme accelerations are required for realistic physics.

Edited April 7, 2022 by EnderKid2

[Bej Kerman]

17 minutes ago, EnderKid2 said:

thought experiment: single-part rigid-body ship, no crash damage, timestep of 1/10 of a second for simplicity (though this will also apply if our craft is allowed to deform)

t=0.0: craft is heading at the ground at 100m/s. It is 10m above the ground.

t=0.1: craft contacts the ground 100m/s = 10m/0.1s

t=0.2: we have 2 options now:

1.  unconstrained phyisics engine: Craft velocity is set to 0m/s, a change of 100m/s in 0.1s, or 1000m/s^2. The craft correctly stops at the ground and all is fine.

      t=0.3+ Craft velocity is 0m/s, craft is sitting on ground.
 

2. constrained physics engine (set to 100m/s^2): Physics engine calculates that an acceleration of 1000m/s^2 should be applied to the craft and thus its velocity should be set to 0. "error checker" says "oh no you don't", and applies an acceleration of 100m/s^2 to the craft instead, setting its velocity to 90m/s (a change of 10m/s in 0.1s). 

        t=0.3: craft is now 9m below ground (moved 9m in 0.1s). Physics engine calculates that an acceleration of 900m/s^2 should be applied to the craft and thus its velocity should be set to 0. "error checker" says "oh no you don't", and applies an acceleration of 100m/s^2 to the craft instead, setting its velocity to 80m/s (a change of 10m/s in 0.1s). 

        t=0.4: craft is now 17m below ground (and so on)

You see, sometimes extreme accelerations are required for realistic physics.

What is this proving?

[t_v]

11 minutes ago, Bej Kerman said:

What is this proving?

I think it is showing how simple physics clamping can fail catastrophically. But, this doesn’t mean that it is a bad idea- simply having a priority system, with stuff like the ground takes priority over the engines, can help. 

[SciMan]

I do get your point, technically (if you don't bring quantized time steps into the equation) an impact on a non-deformable and immobile surface will have an infinite acceleration.
However, I have a solution.

Since the only time this infinite acceleration will reliably happen is with a terrain collision, all you need to do is check if you were going to pass thru the ground. The physics engine already does this, does it not?
Even if it does not, there is a simple solution, and I think KSP 1 already implements it (at least on Jool, but I think also on other planets). If the COM of your vessel passes below the TERRAIN (not any ocean if present, I mean the hard surface), your vessel is entirely destroyed.
This is accurate enough, and simple enough to calculate that it can be done every frame.
If you want to get more accurate, it can be done, but it's going to get much more complicated, and the result will still be partial destruction of your vessel (only the parts that passed below the ground tho).

Besides, the fact that certain parts have greater or lesser impact tolerance is already a sort of "impact acceleration clamping", and that seems to work just fine 99% of the time.

[Nazalassa]

Better graphics -> less FPS

Better physics -> less FPS

KSP2 has both so less than less FPS so like 2 FPS or so.

Why can't they do simple parts?

You know, like these 12-sided cylinders from KSP 0.13.3 (version that I still enjoy)?

[SciMan]

Because technology marches on. That's just a fact of life.

Processors get better over time, and yet (aside from what happened because of the pandemic) the usual way things work is that when something new releases, it takes the "top dollar" price point that the old stuff had, and the old stuff drops down a tier.

So remember how much a GTX 980 sold for at release? Now think of how much a 1080 sold for at release. Not too much different. Same goes with a 2080. Now, the 3080 did indeed get more expensive, but there's 2 sides to that. 1, they couldn't make as many of them so they had to set a higher MSRP, and 2, scalpers made the "cost to typical consumer" go up roughly 2.5x or more again on top of that MSRP increase.

And with AMD the prices track even better, generation to generation, within a given performance tier.

 

And as far as why games need to use more resources? Well, the computers got better. So they can do more. So if you keep the game running at a constant 60fps, and then you upgrade the hardware, you're able to upgrade the game to do a lot more stuff and STILL run at 60fps, with that new hardware.

Believe it or not, prices for PC parts are almost back to normal again. Everything that "relates to a PC but isn't a PC or part of a PC" has already returned to normal prices.

The pandemic and silicon shortage are, and always were, just going to be a blip in the market that would even out over time.

If your PC is over 10 years old, you should really consider upgrading. Not only has technology advanced, but if you use a mechanical hard drive it might be just about to wear out its spindle bearings or otherwise lose your data.

I mean I build my computers to be relatively "future proof" and yet I seem to find myself wanting to build a new one roughly every 3-5 years. That seems to be the pace at which Windows releases major revisions to its operating systems too, so that also synchronizes well.

[mcwaffles2003]

21 hours ago, Nazalassa said:

Better graphics -> less FPS

Better physics -> less FPS

KSP2 has both so less than less FPS so like 2 FPS or so.

It's not that simple.

graphics -> GPU

physics ->CPU

FPS is linked to the bottleneck between the 2. If the CPU can only process 20FPS while the GPU has no graphics to display you still only get 20FPS. So why not up the graphics to meet with the CPUs bottle neck, it's free overhead that's being under utilized.

21 hours ago, Nazalassa said:

Why can't they do simple parts?

You know, like these 12-sided cylinders from KSP 0.13.3 (version that I still enjoy)?

Because having a game full of low quality fidelity parts that are physics-less is counter to the objective of the game. Also, please don't pretend like there hasn't been great strides in it's efficiency since the game was in beta. 0.13.3 could not run nearly as well 1.12.3. 

But, if you are deadset in playing 0.13.3 then... it's still there, play it.

 

5 hours ago, SciMan said:

So remember how much a GTX 980 sold for at release? Now think of how much a 1080 sold for at release. Not too much different. Same goes with a 2080. Now, the 3080 did indeed get more expensive, but there's 2 sides to that. 1, they couldn't make as many of them so they had to set a higher MSRP, and 2, scalpers made the "cost to typical consumer" go up roughly 2.5x or more again on top of that MSRP increase.

I agree with your overall point but this was a bad analogy, the 2080 was well over $1000 and broke the mold (blame the RTX) and the 3080 continued the trend then got released into a silicon shortage and mining craze making cards spike over $2500.