Visual design disasters I hope KSP 2 will steer away from

[paul23]

It's what I'm saying: you *can* simulate for a whole craft if you optimize/precalculate during launch/ship geometry changes. Of course if you program it inefficiently you can't gain efficiency.

 

If we use thin walled approximation (or some other) you can also do this for stresses etc.

Edited October 14, 2019 by paul23

[Guest]

1 hour ago, paul23 said:

It's what I'm saying: you *can* simulate for a whole craft if you optimize/precalculate during launch/ship geometry changes. Of course if you program it inefficiently you can't gain efficiency.

Certainly you can, but if you treat the entire craft as a single physics object, the behaviour of the game will change noticeably.

1 hour ago, paul23 said:

If we use thin walled approximation (or some other) you can also do this for stresses etc.

I'd be quite curious to hear more about this. Simulating stresses, flex with "springiness," etc still sounds like a qualitatively different problem to me than aero simulation on a single physics object.

Consider the following use cases:

(1) A heavy plane with large wings consisting of many wing components each -- say, 12 components each wing, for a total of 24 components. When you fly it, you will see the wing flex as you manoeuvre, and if you pull enough gees, it'll come apart. How would you simulate the flex, springiness, stresses, and eventual RUD in a multithreaded simulation?

(2) Two moderately complex spacecraft, say about 100 parts each. They collide at 20 m/s. How do you simulate the effects of the shock of the collision passing through the structures in a multithreaded simulation?

To my understanding, the bottleneck with KSP's physics simulation is precisely here: it's either impossible or very difficult to parallelise the required computations, because -- like is most obvious in the collision scenario -- the forces experienced by each part depend on the forces experienced by every other part. I do not know of any technique that could solve this without materially changing the behaviour of the system.

(Star Theory has hinted at a "physics LOD" system which would weld parts into groups that are treated as a single part for physics calculations, keeping the total part count always below the maximum the engine can reasonably handle. I think this would be a very good solution, but it would change the way the game behaves.)

[Incarnation of Chaos]

2 hours ago, Brikoleur said:

FAR simulates aerodynamics for the entire craft. KSP has to simulate interactions between parts, with flex and stresses that may lead to failures. You’re not describing the same problem.

And mind you most of this requires you to know how previous interactions affected them; all of this runs away into exponentially increasing numbers of calculations even when assuming we can get around this. Which makes me really wonder even if you were running matrix multiplication on the GPU if it wouldn't quickly saturate it to the point where we're right back into stutter and lag.

[paul23]

Honestly I'm going to sound quite "up there" now, but this isn't the topic to discuss this.

 

I can however just start copying all text books in material engineering and flight dynamics I used during my studies if you wish. However it's not something I can just "show" in a 2 paragraph post. It's easy once you "get" it (it's *made* easy for computers), however "getting it" requires a bit of fundamental understanding of how stress work, and linearization techniques for differential equations.

Solved problems, however still taking multiple years before I understood it.

 

But the whole idea of "parts" does not in any way make it more difficult at all. Fluid dynamics as well as stress calculations you use "parts" anyways (finite element method).

[Guest]

You will understand if we won’t take you on faith on that I hope. The physics bottleneck is one of the more talked-about issues here and what you’re saying goes against the received wisdom — and you’re not the only aerospace engineer on the board. So at least I’m going to file that under “interesting but most likely wrong” unless you can do better.

[paul23]

Well it ultimately doesn't matter, since game developers aren't engineers anyways. I've yet to find a *programmer* let alone a game dev who has a fundamental understanding of mathematics, most act like mathematics are some kind of wizardry that sometimes works, something people fear. So I'm doubtful anything I can say has any relevance.

But in engineering when we simulate things it's all about solving matrix equations. And the *thinking* happens in how we can linearize stuff, how *can* real world be abstracted so that everything is linear. Typically if you have a differential equation of n orders, you make it n-1 by introducing another equation, and another state variable. (IE take another derivative to time). If you do this enough times any n-order differential equation becomes a first order equation, which can be linearized trivially and solved numerically.  (Actually I would write down everything if forums just allowed for latex).

 

Just checking my old textbooks: T. H. G. Megson (2013): Aircraft structures for engineering students, (5th ed): chapter 6, 7 and 23 are describing the problem and how to linearize it.

 

 

But the main idea I put forward is to "ignore" the different parts: first do a proto analysis of the parts and combine them into a "wireframe"/"skeletal" of how the object would look like in reality. This obviously can't be linearized and is mainly a CPU task (it is transforming parts into "plates, beams, hinges and other connections"). However this part only has to be calculated when geometry changes. Then use some of the many tools available to calculate shear flow, stress lines and torsion. Good thing is: you can just say "it breaks" instead of having to include the non linear part where material doesn't behave nice anymore.

 

I know I *wish* I could use the GPU for these calculations during tests. It would allow me to use my own pc instead of having to hire one. The biggest problem is that the floating point calculations on GPU's are often badly implemented/not well defined. Where the calculations are sometime actually incorrect (comparing to IEEE standards), for the sake of speed and in games it won't matter, in simulations it does.

Edited October 15, 2019 by paul23

[Incarnation of Chaos]

Spoiler

54 minutes ago, paul23 said:

Well it ultimately doesn't matter, since game developers aren't engineers anyways. I've yet to find a *programmer* let alone a game dev who has a fundamental understanding of mathematics, most act like mathematics are some kind of wizardry that sometimes works, something people fear. So I'm doubtful anything I can say has any relevance.

But in engineering when we simulate things it's all about solving matrix equations. And the *thinking* happens in how we can linearize stuff, how *can* real world be abstracted so that everything is linear. Typically if you have a differential equation of n orders, you make it n-1 by introducing another equation, and another state variable. (IE take another derivative to time). If you do this enough times any n-order differential equation becomes a first order equation, which can be linearized trivially and solved numerically.  (Actually I would write down everything if forums just allowed for latex).

 

Just checking my old textbooks: T. H. G. Megson (2013): Aircraft structures for engineering students, (5th ed): chapter 6, 7 and 23 are describing the problem and how to linearize it.

 

 

But the main idea I put forward is to "ignore" the different parts: first do a proto analysis of the parts and combine them into a "wireframe"/"skeletal" of how the object would look like in reality. This obviously can't be linearized and is mainly a CPU task (it is transforming parts into "plates, beams, hinges and other connections"). However this part only has to be calculated when geometry changes. Then use some of the many tools available to calculate shear flow, stress lines and torsion. Good thing is: you can just say "it breaks" instead of having to include the non linear part where material doesn't behave nice anymore.

 

I know I *wish* I could use the GPU for these calculations during tests. It would allow me to use my own pc instead of having to hire one. The biggest problem is that the floating point calculations on GPU's are often badly implemented/not well defined. Where the calculations are sometime actually incorrect (comparing to IEEE standards), for the sake of speed and in games it won't matter, in simulations it does.

 

....And i think iv'e realized where the disconnect is here; basically you're talking about something you learned in a Engineering/Aeronautical pathway. While we're only focusing on the application; which won't work because at least from my end i don't really understand the concepts and i fully admit that. I have a programming background, and i have a hobby/enthusiast understanding of physics and aeronautics. 

So to do what you're saying you would basically need Aeronautical Engineers to work with the programmers, so the correct implementation could be derived. I WANT to understand, but it's pretty clear this is something you've studied in depth and can't be imparted in a simple fourm post.

I suppose you could spin up a thread in one of the Science/Spaceflight sections if you really felt determined to outline this stuff. 

[Guest]

@paul23 touché, I’m a programmer with no fundamental understanding of maths - but I work with mathematicians (we do industrial AI stuff) and we do communicate. I am generally able to understand what the mathematics do (and don’t!) even if I don’t understand how they do it. We can communicate meaningfully.

Thing is, the converse is true too. The mathematicians don’t understand software, and sometimes a solved mathematical problem is an unsolved software problem.

What you’re describing now sounds pretty complicated. Correct me if I misunderstood, but you’re proposing to turn the craft model assembled in the VAB into a precomputed model, which includes material strengths and characteristics like tensile strength, rigidity, frangibility, heat tolerance, stress lines, torsion, and so on?

This would be very cool but as a programmer I’ll have to point out that it’s an order of magnitude more complex already at the part level than what we have now. We don’t know any material characteristics: we just know the failure points for individual parts for a small number of stressors. FAR is already remarkable and it only models the aerodynamic shape of the craft as the basis for the simulation, not failure modes.

So while I’m still not entirely convinced it could not be done at all, I’m even less convinced it could be done within the time, budget, and platform constraints used for KSP2: namely, craft physics simulated using Unity’s rigid-body physics API. If it requires turning KSP into something resembling the software Airbus used to design airframes... well, that’s a tall order.

Again, I’d be delighted to be proven wrong as this would be an improvement on so many levels, but... well, not buying it yet.

[Superfluous J]

5 hours ago, paul23 said:

I've yet to find a *programmer* let alone a game dev who has a fundamental understanding of mathematics

To be fair most engineers couldn't code their way out of wet paper bag.

Most professionals in both fields though are able to discuss with professionals in other fields and come to understandings about what can and can't be done. I have to believe either they are all wrong and you're right, or you're right and they are all wrong.

[mcwaffles2003]

9 hours ago, paul23 said:

Honestly I'm going to sound quite "up there" now, but this isn't the topic to discuss this.

 

I can however just start copying all text books in material engineering and flight dynamics I used during my studies if you wish. However it's not something I can just "show" in a 2 paragraph post. It's easy once you "get" it (it's *made* easy for computers), however "getting it" requires a bit of fundamental understanding of how stress work, and linearization techniques for differential equations.

Solved problems, however still taking multiple years before I understood it.

 

But the whole idea of "parts" does not in any way make it more difficult at all. Fluid dynamics as well as stress calculations you use "parts" anyways (finite element method).

Mesh simulations, at least in multiphysics simulators, such as NX or COMSOL take a long time to converge their simulations. Even if you were to only use 200 vertices (locations for each part in a 200 part craft represented by its center in x,y,z coordinates and orientation in u,v,w as 1200 vector components) theres no way you could get a simulation to converge in real time @ 60fps. Though I'll admit I'm not an engineer.

[Xd the great]

If KSP2 can run simulations with high realism and speed on a home computer, all the devs will be recruited by NASA and KSP2 will be a standard tool for aeronautics and aerospace engineering.