Jump to content

KSP physics on OpenCL


Recommended Posts

This is more of a unity question, but how worth it would it be to do physics on a GPU. In theory, KSP physics work by many simple floating point calculations, and video cards do those faster than CPUs. Would this work?

Link to comment
Share on other sites

Video cards do physics calculations slower than CPUs do.

They can just run thousands of physics calculations side-by-side.

Now, this has two major consequences for KSP:

#1: I'm not sure how rigid-body physics are usually handled, but it's possible that it's difficult to impossible to thread them. In that event, OpenCL physics acceleration is an outright no-go, because each individual CPU core is far more powerful than a GPU core.

#2: Even if it's theoretically possible, threaded code is an absolute bear to write. Everything becomes more complicated when you have to worry about things like work balancing, cache synchronization and interference, and the typical languages for GPU programming (OpenCL, CUDA) are not known for ease of programming and productivity.

The Unity engine on which KSP runs was chosen in part because it already had the rigid-body physics engine they would need; it's not a super-optimized engine, and it only runs on a single thread per vessel, but it existed. It runs reasonably well on small part count vessels, but really chugs once you get past a certain level. What doesn't help in the slightest is that the physics engine exhibits super-linear scaling; for N parts, it needs to do more than O(N) calculations.

I can't right now say it's impossible, but I can say with reasonable confidence that it would be an enormous coding project to offload physics calculations to an OpenCL kernel, and I doubt Squad has the money to see that through.

Link to comment
Share on other sites

It depends on the type of physics.  Joint physics, which is what KSP primarily uses between parts, can't effectively be done on a GPU.  Cloth and smoke/steam physics can be done well on a CPU, so in theory if Unity supported it, they could add a more realistic engine plume... or a more realistic flag at KSC.  Ultimately it isn't worth it.  The Smoke Screen mod does just fine without it and who cares about the flag at KSC?

Link to comment
Share on other sites

There are several decent GPU-based physics engines that could vastly improve KSP, but implementing them inside Unity is probably a massive task and very tedious. KSP gets most physics right, or close enough for the game's sake.

PhysX would mean only Nvidia-GPU users would benefit, and it does have its benefits but also its flaws. Bullet is probably just too slow - usually firing up a blank scene takes much longer than PhysX, for example. You'd really feel that in-game.

I use GPU-physics all the time in Maya but you can't directly compare that to Unity. Not even the same universe, really. A better comparison would be Universe Sandbox², which is a beautiful use of GPU physics but still only recreates a gravity field, not the unified gravity/charge field we experience in reality. For example, the elliptical orbits of the planets are hard-coded, not the dynamic gravity/charge orbits we have in real life.

What I'd like to see someday is the Universe engine inside KSP. Along with the Planetbase engine. But hey, a dragon can dream, right?

us2pe1.jpg

Link to comment
Share on other sites

21 hours ago, 322997am said:

This is more of a unity question, but how worth it would it be to do physics on a GPU. In theory, KSP physics work by many simple floating point calculations, and video cards do those faster than CPUs. Would this work?

Those simple FP calculations are dependent on the results of other simple FP calculations, because KSP vessels are a set of chained, constrained rigidbodies. So you get one processing unit in the GPU waiting for the results of another before doing its part and so on down the line, and those units are less powerful individually than the FP units in a CPU. GPUs are only faster at FP stuff that is embarrassingly parallel (this is actually a technical term), for the type of physics problem that a KSP vessel represents it would be a step backwards performance-wise, unfortunately.

There is some benefit to threading, though. Physics calculations of independent vessels are not usually dependent on each other, so there is some benefit to assigning one thread per vessel so they can crunch away on separate CPU cores; this is what KSP has been doing since 1.1.

Link to comment
Share on other sites

So far as I can tell, there are a few parallelized rigid-body dynamics solvers out there, but they haven't extensively penetrated into actual game software yet.

Which is kinda funny, when a big part of rigid-body dynamics is avoiding penetration.

As to why they aren't being used in current games, that's due to a few different things.

#1: Only relatively recently did it become the case that consumer CPUs became multithreaded and GPUs used for anything but pixel-pushing.

#2: It takes a long, long time for algorithms developed in academica to find their way into industrial/commercial code. For an example, free energy perturbation, despite being used for quite a while now, only recently started to get used in a serious fashion by the pharmaceutical industry.

#3: Academic implementations of sophisticated algorithms tend not to lend themselves well to becoming a commercially viable API, something about "who cares about the code being clean, we need data to put in the grant, now get it finished so I can graduate you and get tenure".

#4: Not many games call for rigid-body dynamics on the vast scale KSP does. Squad doesn't have the resources to write an OpenCL kernel for rigid-body dynamics working from primary literature; an organization like the people behind Unity might, but they just don't have many customers who need that sort of performance, so their current single-threaded CPU implementation is good enough.

#5: The math can get ferociously complicated in a hurry, and whatever is difficult on single-threaded CPU codes is an endeavour to parallelize and a Herculean task to make work efficiently on a GPU... assuming it's even a problem that parallelizes in the first place.

Link to comment
Share on other sites

6 hours ago, Red Iron Crown said:

Those simple FP calculations are dependent on the results of other simple FP calculations, because KSP vessels are a set of chained, constrained rigidbodies. So you get one processing unit in the GPU waiting for the results of another before doing its part and so on down the line, and those units are less powerful individually than the FP units in a CPU. GPUs are only faster at FP stuff that is embarrassingly parallel (this is actually a technical term), for the type of physics problem that a KSP vessel represents it would be a step backwards performance-wise, unfortunately.

There is some benefit to threading, though. Physics calculations of independent vessels are not usually dependent on each other, so there is some benefit to assigning one thread per vessel so they can crunch away on separate CPU cores; this is what KSP has been doing since 1.1.

3

Could one vessel be considered as multiple chunks of vessel that have collided?

 

Like a train, the engine can be moving for seconds before the end car starts to roll. 

I wonder why the physics engine couldn't do the same with a staged rocket and still have a convincing game worthy simulation. Considering a physics frame is a such a short amount of time if it took a few frames for a change in the forces to propagate through the entire collection.  Would it matter if the top of the rocket was providing feedback forces based on thrust from the bottom of rocket 100ms ago?

Link to comment
Share on other sites

26 minutes ago, mattinoz said:

I wonder why the physics engine couldn't do the same with a staged rocket and still have a convincing game worthy simulation. Considering a physics frame is a such a short amount of time if it took a few frames for a change in the forces to propagate through the entire collection.  Would it matter if the top of the rocket was providing feedback forces based on thrust from the bottom of rocket 100ms ago?

Yes, it would be unplayable. Difference schemes build like this (equations used to get world state on the next time slice) tend to be unstable and violate physical laws, no matter how small the time step is, that's why alternative class of methods are used - and those methods are naturally serial.

Link to comment
Share on other sites

Okay, joints physics on a single thread per craft, that's how it is. But since thermal calculations have no effect on materials or joints in any way except destruction, couldn't we have those in a separate thread? And if there's not much to gain with low part count, maybe with high part count or multiple vessels? Imagine three vessels on a quad core, one core does all the thermals.

Link to comment
Share on other sites

1 hour ago, Azimech said:

But since thermal calculations have no effect on materials or joints in any way except destruction, couldn't we have those in a separate thread?

They depend on part-sun orientation\relative position, wich requires said position. Unity does not allow to qeury and modify it's objects from threads other than main, wich forces the programmer to reinvent the wheel and move most of the game state to C# runtime. And the reason for that is very simple - crap engine.

Edited by Boris-Barboris
Link to comment
Share on other sites

27 minutes ago, Boris-Barboris said:

They depend on part-sun orientation\relative position, wich requires said position. Unity does not allow to qeury and modify it's objects from threads other than main, wich forces the programmer to reinvent the wheel and move most of the game state to C# runtime. And the reason for that is very simple - crap engine.

Thanks for the explanation. I was wondering about this for years.

Link to comment
Share on other sites

7 hours ago, Boris-Barboris said:

And the reason for that is very simple - crap engine.

Personally, I'd argue that for what it was meant for, Unity is an excellent engine. By limiting access to variables to the main thread, novice programmers don't wind up 10 feet under in synchronization issues.

Unity might not be a high-performance engine, but for the tasks it was designed for, it is a good engine, because most of what it's intended for are mobile and indie games where the CPU wakes up for a couple hundred microseconds, yawns, registers the user input, moves a couple variables around, and goes back to sleep for another few milliseconds.

I would prefer it were KSP on a higher-performance game engine, but I entirely understand why they chose Unity: it was free, had an extensive API, rigid-body dynamics were already implemented, and so Squad could get KSP off the ground quite quickly so we could get our rockets off the ground.

Link to comment
Share on other sites

Just now, Boris-Barboris said:

I personally don't judge things for "what they were ment for".

The Saturn V was truly a terrible paperweight, indeed. Way too heavy to be practical.

It's almost as though there are multiple programming tools for multiple types of problem.

Link to comment
Share on other sites

10 minutes ago, Starman4308 said:

It's almost as though there are multiple programming tools for multiple types of problem.

Enter "Unity3d" in google. First sentence I see, quote: "Unity is the ultimate game development platform. Use Unity to build high-quality 3D and 2D games, deploy them across mobile, desktop, VR/AR, consoles or the..."

I expect much more from an ultimate platform for high-quality games.

Edited by Boris-Barboris
Link to comment
Share on other sites

Just now, Boris-Barboris said:

Enter "Unity3d" in google. First sentence I see, quote: "Unity is the ultimate game development platform. Use Unity to build high-quality 3D and 2D games, deploy them across mobile, desktop, VR/AR, consoles or the..."

I expect much more of an ultimate platform for high-quality games.

That is marketing hype. There is a reason it is called hype: because it is exaggerated to get people to use it.

Link to comment
Share on other sites

Just now, Starman4308 said:

That is marketing hype. There is a reason it is called hype: because it is exaggerated to get people to use it.

That's why you don't assume anything about "the tasks it was designed for" and form your own opinion, comparing with other solutions and your needs\ideals. You've seen my opinion, I've seen yours.

Link to comment
Share on other sites

This is yet another example of "going the cheap route" to design something that shouldn't be done cheaply. Unity is what it is - a basic game development engine. It was never intended to replace or compete with CryEngine or Frostbite, much less Unreal. When KSP began, however, the cost to license Unreal was also unreal, so Squad chose to go with a free engine that at least let them get the game up and running rapidly and still allowed them to take a paycheck. Unreal has since changed their pricing scheme, but unless Squad were to hand off the project to another team with more Unreal experience and prep KSP 2.0 for Unreal instead, it's just not going to happen.

Cases in point: Subnautica vs. Everspace. Subnautica is a great game so far, a huge underwater landscape several square KM in size and 1KM in depth, give or take. It's the best of its kind - but is still a Unity game. It stutters everywhere, even on the best machines. The graphics aren't great. The water is nice enough and has come a long way, but doesn't behave much like a liquid.

Then you have Everspace, on the Unreal engine. It's even bigger than Subnautica, as its in space, and has roughly the entire volume of Subnautica in every level - which are procedurally generated and different every time you play. It's beautiful. It's smooth as silk, even on lower-end machines. The controls are not only perfect but genre-redefining. It's everything Subnautica isn't.

I don't see KSP switching engines at this point, so what we can hope for is ANOTHER game, similar, but using the Big Kid engine instead. If KSP continues to garner such fan support, I have no doubt a Big Kid game in the same vein would get even more support.

And Unreal supports GPU-based physics far, far better than Unity.

Link to comment
Share on other sites

What if instead of changing the whole game. They changed it so multiple physics options were available to load per craft. You could simply make it so the craft has a notation as to which physics to load on runway/launchpad. Then you can mark it in the VAB/SPH and make different craft. Or if needed have different saves with different options for which physics on start. It would be easier than replacing one type as far as player end. And it gives more options to players.

Has anyone nagged unity to make more physics available by default. I bet all games would use them. The argument about not adding more because existing customers not using more is a bad argument because they technically just made games based on the engines abilities at the time. So, of course they don't use more!

Edited by Arugela
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...