Suggestion: An overly verbose examination of "wobbly rockets" and joint simulations

[Skystorm]

@AngryBaer The difference is that an airplane's wings are designed to flex and is completely intentional.  Not so much for rockets.

More information: 

 

[AngryBaer]

37 minutes ago, Skystorm said:

@AngryBaer The difference is that an airplane's wings are designed to flex and is completely intentional.  Not so much for rockets.

"It makes sense because they were built for that purpose, rocket stacks perhaps not so much", that's... literally what I said

[VlonaldKerman]

On 7/6/2023 at 1:30 AM, Kavaeric said:

As a bonus, for advanced players, when compared to spring yjoints the proposed static joint system should be simple enough (at least for my amateur non-programmer brain) where new analysis tools in the VAB can be added.

There could also be an in flight overlay, similar to the drag, hear, and fuel overlays. I also feel like the details of the visual feedback mechanism are very important, and I still feel like there should be simulation of flexing in some way. Especially for large vehicles- for example, skyscrapers, bridges, and other large buildings flex. Massive colony motherships would therefore have some flex too, especially if poorly designed. But maybe it’s not calculated on the joint level. Certainly food for thought.
 

Overall, though, pretty epic suggestion. This is why KSP community is the best.

[VlonaldKerman]

On 7/15/2023 at 11:01 AM, Clóvis said:

Second, the wobble might be a complex programming problem they are not sure is a priority to them or the community, besides an strong vocal minority

I’m pretty sure it would require a substantial rewrite to the whole physics system, as others have alluded to. Also, there’s no guarantee that it would work well and not cause other problems. So they would have to spend a lot of time on a fix that’s impossible to test until after the system is implemented- in other words, they’ll have to spend a lot of man hours before they figure out whether or not it’s feasible or effective.

So I agree that they are likely holding off; I just hope that they do come back to this down the line when there will be the temptation to just say, “Yep, the game is finally done!” That is, unless the performance of the flexible joint system is too poor to support massive colony ships, in which case they will be forced to either consider static joints or change the way that colonies work to disincentivize massive ships, which I’m worried they might do and would be a disaster.

[DancZer]

On 7/6/2023 at 10:58 PM, Kavaeric said:

Hi all, thanks for the feedback. I chatted with @whatsEJstandfor on Discord and while this is jumping ahead, some thoughts on how to integrate strut placement into the static/rigid joints model.

We also briefly mentioned other games to take precedent from: PolyBridge is the most famous contemporary example, but folks might remember playing West Point Bridge Designer or Pontifex. It was what suggested to me that much of the performance overhead of larger vehicles in KSP(2) is from the spring joint simulation, and that moving to a more static physics implementation would accomplish much the same thing while being much more performant.

I like your idea and I would extend it with mine. Players should have direct control over the joins (the lines on your drawing, by selecting the parts) with a weight penalty and we should forget that struct ever existed. I don't like it personally, because it was introduced because of the wobbling rockets. If the player increases the strength of the join it should slightly increase the dry mass of that part. Simple, transparent the player has control over it and visually satisfying too.

Edit: So I think Option B is better, because it does not introduce an invisible join. But I would achieve the same strengthening without struts. 

Edited July 21, 2023 by DancZer

[Lisias]

23 hours ago, DancZer said:

and we should forget that struct ever existed. I don't like it personally, because it was introduced because of the wobbling rockets.

As a matter of fact, I like the struts.

We use it on Real Life™, not rarely it is cheaper (in price and mass) to use a strut than to reinforce the internal structure, like what was done on the (utterly missed) Arecibo Observatory.

Look the cables tying the towers to the ground!

[Kavaeric]

On 7/21/2023 at 3:26 PM, DancZer said:

I like your idea and I would extend it with mine. Players should have direct control over the joins (the lines on your drawing, by selecting the parts) with a weight penalty and we should forget that struct ever existed.

Struts do exist in real life though! The Delta IV Heavy and Ariane rockets have them, as examples:

They're obviously not covered head to toe in trusses, but I'm in agreement with the dev team that there should still be a time and place for struts.

[PicoSpace]

I don't mind some struts or braces (parts?) on a rocket, but I'm still flabbergasted that I can't have 2 sets of seperators (top and bottom) to hold a booster (or whatever) on the rocket. That would solve a LOT of "wobble" problems.

[Lisias]

5 hours ago, PicoSpace said:

I don't mind some struts or braces (parts?) on a rocket, but I'm still flabbergasted that I can't have 2 sets of seperators (top and bottom) to hold a booster (or whatever) on the rocket. That would solve a LOT of "wobble" problems.

This happens due the data structure they choose to implement the rocket in memory.

They could do a graph (that allows multiple links between a part and its parent(s), and even circular references) but that would made the data traverse more complicated because they need to prevent handling the same part more than once, something that will happen a lot with a part that can link more than one parent and eventually a child may link to a grand-parent. Solving a graph from a 1.000 parts craft can be excessively time consuming and complicated - give a look on a Computer Problem called Travelling Salesman Problem.

Instead they choose a Tree, where each part can have more than a link to another, but the path is always forward and there's never a way to a part to have more than one parent. This making the traversal extremely quick and simple - but, as a side effect, makes impossible to do what you want.

However… There're struts (internally, a CompoundPart in KSP¹ lingo) that can be used to create special parts what could handle what you want - so, instead of adding a Strut to "glue" a part in two points on the upstream, the game could create multiple joints using "invisible parts" directed by you between a "child part" and another part from another subtree directly adjacent to it - saving you the trouble of adding a ugly strut for two parts that are essentially "welded" together. Perhaps this could be the name of the feature, "Welding Points"?  

That would achieve a similar result from what you want, and I'm pretty baffled nobody thought on implementing it on Stock KSP¹.  

Let's hope KSP2's developers would have a better mindset about this problem.

[PDCWolf]

22 hours ago, Kavaeric said:

Struts do exist in real life though!

Neither of those are purely struts, they're stressed members and transmit load yes, but they're first off part of a whole ring structure that goes around the SRB, and then contain pyrotechnics for the separation. Source for Ariane 5 (and it's the same for the Shuttle SRBs), for the Delta IV, those struts are not strong enough to transmit thrust properly, and a lot of other structures exist between the common cores, and the white struts are for separation control purposes. Neither case have anything to do with the magic bits of string we have in KSP that completely weld one piece to another and magically disappear on separation.

19 minutes ago, Lisias said:

so, instead of adding a Strut to "glue" a part in two points on the upstream, the game could create multiple joints using "invisible parts" directed by you between a "child part" and another part from another subtree directly adjacent to it - saving you the trouble of adding a ugly strut for two parts that are essentially "welded" together. Perhaps this could be the name of the feature, "Welding Points"?  

That would achieve a similar result from what you want, and I'm pretty baffled nobody thought on implementing it on Stock KSP¹.

There's no need to be this condescending when explaining autostrut to someone, remember it's an option hidden under advanced tweakables, not everybody's seen it.

Edited July 23, 2023 by PDCWolf

[Lisias]

31 minutes ago, PDCWolf said:

remember it's an option hidden under advanced tweakables, not everybody's seen it.

Autostrut doesn't allow you to cherry-pick the target part, you see, there's only Autostrut to heaviest part (not a nice choice, because this may change as fuel is consumed!), to the grandparent and to root. 

I'm proposing cherry picking an adjacent part from another subtree to strut a given part using the CompountPart module, emulating what the other fellow Kerbonaut wants and still be able to add a bit of mass and cost to the solution, making it somewhat more related to Real Life™.

It's the very reason we use Parts to add Strut: to make it cost Fund and Mass! (and, again, this is my main complain about autostrut)

[VlonaldKerman]

7 hours ago, PicoSpace said:

I don't mind some struts or braces (parts?) on a rocket, but I'm still flabbergasted that I can't have 2 sets of seperators (top and bottom) to hold a booster (or whatever) on the rocket. That would solve a LOT of "wobble" problems.

*Im not an expert on this stuff and I could be wrong but*

Or they could simply increase the rigidity of those connections substantially, given that radial decouples have essentially one use case, and that use case almost always requires struts atm. Currently, radial decouplers are simply dysfunctional, but not in an “interesting  engineering way”, it’s just a tedious way.

19 minutes ago, Lisias said:

It's the very reason we use Parts to add Strut: to make it cost Fund and Mass! (and, again, this is my main complain about autostrut)

Struts cost minimal mass, and there will be no cost/money system in KSP 2 I believe.

[PDCWolf]

1 hour ago, Lisias said:

and, again, this is my main complain about autostrut)

Because it's a bandaid workaround for a bug, not a feature.

[AngryBaer]

5 hours ago, Lisias said:

but, as a side effect, makes impossible to do what you want.

5 hours ago, Lisias said:

saving you the trouble of adding a ugly strut for two parts that are essentially "welded" together.

11 hours ago, PicoSpace said:

I can't have 2 sets of seperators

Would this not be solved by having more options for strut styles (including a "hide" option)? If you could use struts that look exactly like the separators but are attached like the struts, i.e. by making the connection procedural, you'd have the desired result. I don't see an issue with adding pyrotechnics in that case either.

[PicoSpace]

4 hours ago, VlonaldKerman said:

Struts cost minimal mass, and there will be no cost/money system in KSP 2 I believe.

From what I read KSP2 fully implemented will have resources, so you will build & fuel your rockets using materials you've gathered.

[VlonaldKerman]

1 hour ago, PicoSpace said:

From what I read KSP2 fully implemented will have resources, so you will build & fuel your rockets using materials you've gathered.

Good point, I forgot.

[Lisias]

15 hours ago, VlonaldKerman said:

Or they could simply increase the rigidity of those connections substantially, given that radial decouples have essentially one use case, and that use case almost always requires struts atm.

I don't think this solution would "scale" properly. See the following "example":

}=================\>
}=================|=:*========:*==O>
}=================/>

Where:

} = Engine
= = Fuselage (fuel, cargo, whatever)
| = fuselage, but with radial attachments - to allow easy identification for discussing it
\ and / = radial decouplers
: = stack decouplers
* = shrouded engine
O = Payload
> = Fairing or nose cone

All the stress of 3 engines are being shoved into the part where the radial decouplers (\ and / on the graph above) are attached. You make the decouplers "infinitely" strong, and the part where they are attached will just snap - 3 stress sources into a single part, 2 of them with torque.

Well, let's reengineer the tree data structure a bit. Lets try this one:

}==\==============>
}==|================:*========:*==O>
}==/==============>

I don't think it helped at all, because now the part under stress still have the same 3 sources of stress (including torque, it just happens that the torque spin is different). Additionally, there's more mass to be pushed by that part (and also, more torque as the rocket manoeuvres).

We will have a single part with huge amounts of stress the same.

IMHO, a better solution would be:

}==\============+=>
}==|============|===:*========:*==O>
}==/============+=>

Where:

+ = a "weldeding point" using the CompoundPart module.

Now we have two parts to support the boosters stress, splitting the load. Additionally, we have canceled a huge torque being injected into a single part - to tell the true, the torque injected by the boosters was essentially canceled by the lower attachment points, while the torque induced by the mass of the booster was canceled by the upper "welding point".

Ok, the Struts can be used to do this - but how about a more visually appealing part? Or just an "invisible" part for when the engine cluster are really tied together, without decouples like this:

      |\
      | \
      |  \
}=+===+===|=#
==|===|===|=====00>
}=+===+===|=#
      |  /
      | /
      |/	

Where:

00> = Cockpit
|\ = Wings
| = Part where the nasceles are radially attached
+ = Invisiable "welding points"
# = Air intakes

On this one, both the nacelles as the wings would distribute the stress on multiple parts on the main fuselage.

Again, on KSP¹ this would be achieved by using Struts, but I'm proposing new parts for the job, with different characteristics - perhaps some of them could be automatically applied by the Editor? Or perhaps a U.I. where the user would tell "Weld this part into that one".

 

14 hours ago, PDCWolf said:

Because it's a bandaid workaround for a bug, not a feature.

And that's the whole problem. Because it wasn't introduced as a proper feature?

There's that old adage that says "If life gives you lemons, open a lemonade stand" (or something like that).

Spoiler

 

Edited July 24, 2023 by Lisias
tyops as usulla...

[darthgently]

HarvestR's latest project, Kit-Bash, treats the entire craft as a rigid body with internal physics determining stresses and failures, from what I gather.  So no noodling.  I consider it an authoritative approach to the problem

[PDCWolf]

3 hours ago, darthgently said:

HarvestR's latest project, Kit-Bash, treats the entire craft as a rigid body with internal physics determining stresses and failures, from what I gather.  So no noodling.  I consider it an authoritative approach to the problem

Yep, unlike a multimillionaire company and the studios it funds, a single brazilian man is able to learn from his mistakes and not repeat them.

4 hours ago, Lisias said:

And that's the whole problem. Because it wasn't introduced as a proper feature?

There's that old adage that says "If life gives you lemons, open a lemonade stand" (or something like that).

Life gave me an indie developed game with some very visible flaws, I made a lot of lemonade with what. You'll have to understand that I'm not ready to receive the same or worse lemons from people that call themselves professionals, at a premium price.

Leaving the adage behind, the bug here is wobble, that's why Juno, Balsa, and literally any other "snap stuff together" doesn't have it, save maybe Besiege and it's as much of a problem there as here, though Besiege implements a much more elegant way for parts to break away from one another. Autostrut was the last bandaid the OG team could provide, being unable to fix the real problem.

The solution presented in this thread is a good stopgap, and introduces some interesting concepts that KSP is lacking in regards to structural integrity, without becoming overly cartoony, and actually representing a real life problem. What is needed, however, is for the KSP2 to actually be an evolution instead of a copy paste, and provide proper non-tree building methods, part compounding, or even just make proper joints.

[Lisias]

43 minutes ago, PDCWolf said:

The solution presented in this thread is a good stopgap, and introduces some interesting concepts that KSP is lacking in regards to structural integrity, without becoming overly cartoony, and actually representing a real life problem. What is needed, however, is for the KSP2 to actually be an evolution instead of a copy paste, and provide proper non-tree building methods, part compounding, or even just make proper joints.

But, yet, that evolution will also need Struts and internal structure reinforcements (being it autostruts or anything else) in order to reach that goal.

I would like you to read what I'm writing, instead of criticise what you think I should had wrote and didn't - I'm not defending the wobble as you see on KSP2, I was one of the dudes that suggested implementing bending on rigid bodies for starters.

By implementing a "secondary physics engine" for one given rigid body, you will still have the same problems to solve. So you will still need struts and "welding points" and what else to simulate how things are built in Real Life™, otherwise you will have definitively a cartoonish physic model where nothing bends under stress and just snaps without warning when the limits are reached.

How they will model that internal physics engine? By trees (and so we have again the same problems)? By graphs (and so, how to prevent the traverse's complexity from going trough the roof)? Anything else?

You see, things do wobble under stress:

Quote

Wings wobbling during turbulence is a result of pretty straightforward physics. As the plane encounters higher air density, the wings are lifted and the plane gains altitude. Areas of less air density cause the wings to bend back down as the plane loses altitude.

And this includes rockets (emphasis are mine):

Quote

“Rockets tend to be long and bendy, and when you launch a rocket, the force applied to the structure makes it shake, it pings much like a tuning fork,” explains Dr McKeown. “In addition, the fuel onboard sloshes around, which can throw the rocket off its course and make it harder to control.”

Really, rockets do wobble! (again, emphasis are mine):

Quote

Tie a string around the body tube at the location of the center of gravity. Be sure to have the parachute and the engine installed. Then swing the rocket in a circle around you while holding the other end of the string. After a few revolutions, if the nose points in the direction of the rotation, the rocket is stable and the center of pressure is below the center of gravity. If the rocket wobbles, or the tail points in the direction of rotation, the rocket is unstable.

I completely agree that KSP2's wobbling is completely out of line, but It's my opinion that KSP¹'s wobbling is better than nothing (not to mention the mitigation measures implemented being way insufficient).

And I don't have any objection to any new way of doing things, as long some wobbling/bending/whatever happens and I need to overcome them by using better designs.

There's a reason people are still playing KSP¹ instead of Juno and Kit Bash Balsa, and there's a reason some people prefers to play Juno and Kit Bash Balsa instead of KSP2. Now sum all these players on Steam or any other service that would allow you to infer the size of the playerbase of each one of these games and try to figure out what's the direction that the current KSP players would like things to go.

Edited July 24, 2023 by Lisias
Kit Bash is not available yet, but Balsa was in the past.

[PDCWolf]

1 hour ago, Lisias said:

But, yet, that evolution will also need Struts and internal structure reinforcements (being it autostruts or anything else) in order to reach that goal.

I would like you to read what I'm writing, instead of criticise what you think I should had wrote and didn't - I'm not defending the wobble as you see on KSP2, I was one of the dudes that suggested implementing bending on rigid bodies for starters.

By implementing a "secondary physics engine" for one given rigid body, you will still have the same problems to solve. So you will still need struts and "welding points" and what else to simulate how things are built in Real Life™, otherwise you will have definitively a cartoonish physic model where nothing bends under stress and just snaps without warning when the limits are reached.

How they will model that internal physics engine? By trees (and so we have again the same problems)? By graphs (and so, how to prevent the traverse's complexity from going trough the roof)? Anything else?

You see, things do wobble under stress:

And this includes rockets (emphasis are mine):

Really, rockets do wobble! (again, emphasis are mine):

I completely agree that KSP2's wobbling is completely out of line, but It's my opinion that KSP¹'s wobbling is better than nothing (not to mention the mitigation measures implemented being way insufficient).

And I don't have any objection to any new way of doing things, as long some wobbling/bending/whatever happens and I need to overcome them by using better designs.

There's a reason people are still playing KSP¹ instead of Juno and Kit Bash Balsa, and there's a reason some people prefers to play Juno and Kit Bash Balsa instead of KSP2. Now sum all these players on Steam or any other service that would allow you to infer the size of the playerbase of each one of these games and try to figure out what's the direction that the current KSP players would like things to go.

Regarding rocket wobble, I suggest you take a look at how much a rocket "wobbles", as saying they do to justify spaghetti is not the most honest thing to do. Also, since we're here and we're both past the barrier for accusations of being intellectually dishonest, I'm also expecting you to know that a rocket is not a lego stack of generalist parts, but rather an organized stack of specifically engineered components that are made to work with and translate force to each other. Real rockets do have same-vessel collision enabled, another reason why wobble is not a proper representation of what goes on in real life, as it requires nullifying structural limits so parts don't make others implode, which now only happens when the joint breaks, not the part. Thus, neither KSP1 or 2's wobble is a correct representation of the real life flexing. Once again, I'll bring up the example of the ISS, a structure weaker than a rocket, not built to hold the thrust of a rocket engine, bending 3 millimeters along 109 meters.

For wings, I need nothing more than to ask you to open up KSP1 and make an airliner, with airliner wings (the big ones), and test flex, and then do the same with stacked wing sections, and you'll quickly realize that the game is not representing wing flex, but rather some other buggy joint interaction stuff. That's a problem, and not a good representation, it is also grossly unintuitive and the only lesson it teaches is "use bigger parts".

I don't need to argue about Juno and such, you've been proved wrong plenty there all over the forum and most people know that "argument" is just a snarky comment, people don't choose games over wobble.

 

Edited July 24, 2023 by PDCWolf

[darthgently]

Somewhere in the following entertaining Matt Lowne vid harvestR talks about not having wobble and rigid body with internal physics etc.  For those interested:

https://youtu.be/KbsBtO0UWgk

[Lisias]

1 hour ago, PDCWolf said:

Once again, I'll bring up the example of the ISS, a structure weaker than a rocket, not built to hold the thrust of a rocket engine, bending 3 millimeters along 109 meters.

Now put the ISS on a launch pad and see what happens!

Spoiler

 

I don't think we're converging into something constructive on this monologue (a discussion incurs on each other paying attention about what the other has to say), perhaps we should divert our mutual attention to something else?

[darthgently]

2 minutes ago, Lisias said:

 

  Reveal hidden contents

 

 

That rocket had very thin skinned balloon tanks that require tank pressure for rigidity.  I recall that failure (or similar on same model) occurred because of lack of tank pressure

[Lowi_Sace]

20 hours ago, Lisias said:

They could do a graph (that allows multiple links between a part and its parent(s), and even circular references) but that would made the data traverse more complicated because they need to prevent handling the same part more than once, something that will happen a lot with a part that can link more than one parent and eventually a child may link to a grand-parent. Solving a graph from a 1.000 parts craft can be excessively time consuming and complicated - give a look on a Computer Problem called Travelling Salesman Problem.

Instead they choose a Tree, where each part can have more than a link to another, but the path is always forward and there's never a way to a part to have more than one parent. This making the traversal extremely quick and simple - but, as a side effect, makes impossible to do what you want.

Two fixes for boosterd that they could do in this case (if I understand correct) 

Wings already are connected with differen multiple joints to a vessel. They could make a symetry options for boosters/radial-decouplers so they connect a part with two joints.

Another way to solve the booster problem is by struts that look like a decoupler. Example: you add a booster to vessel with radial decoupler, select decouoler style strut, klick on the booster (on the hight you want the strut) and then select the core to which the strutt should go. The game then automatically adds a strutt that looks just like the decoupler in use or adds a decoupler style like in the picture

 

for a rocked stack they should just drastically increase joint flex of, mostely engine plate and decouplers, parts. A other option is that the joint flex only is active if a certain amount of stress level is surpassed. for a harder game mode joints would break more easy and for a easy game mode they will not break as easely but will wobble with increased stress (like it should already be broken, but the game is kind of tolerant for begining players) 

28 minutes ago, Lisias said:

Now put the ISS on a launch pad and see what happens!

that is why the fysics system should handle joints different in vaccuum then in admosphere. In vaccuum a vehicle should be seen as one parts and only if a certain amount of stress is exceeded some flexing should accur (like strong acceleration, not by small changes by reaction wheels an rcs)