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

[VlonaldKerman]

7 hours ago, Lisias said:

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.

If I understand correctly, you are giving an example where the wiggle of the decouplers act as a sort of shock absorber. In other words, if the decouplers had INFINITE give, no energy would be transferred to the main vehicle. When they have ZERO wiggle, all of the booster energy is transferred. You argue that if all of the energy is transferred then there will be structural problems with the decoupler on the main stage (non-radial). However, if this was the case, then I would just get a decoupler with ZERO wiggle, and out on less powerful boosters. The net energy transferred would be the same. All I want is as much acceleration as the main structure can handle, with as few other variables (eg. wobble) as possible.

With respect to torque, having radial boosters does allow for the imparting of more torque than a single engine alone. But again, I view that problem as separate from the issue of radial decouplers. Whatever the solution to the torque is (eg. limiting engine gimbal, structural reinforcement), it should not be to increase the energy loss associated with the wobbling of radial decouplers to neuter the rockets control capabilities/stability. Moreover, if most or many launches would require this reinforcement, why not make it automatic (increasing joint rigidity across the board)? If I have to add struts to every launch, that is not an interesting engineering/gameplay challenge- that is unnecessary tediousness. Struts should be a special-use-case part, as they are in real life (by struts I mean any method of structural reinforcement). The only exception to this that I would like is if they implemented variable-integrity fuel tanks (like RO), which act as a trade off between structural integrity and mass/unit fuel storage.

In fact, in real life, I do not believe that rockets have this problem- I believe that the attachments of radial boosters are relatively rigid. If the flight parameters of a mission specify X g’s of acceleration, the body of the rocket is designed to handle that force, if reinforcements are necessary, then so be it. But whether that energy comes from radial boosters or the main engine, the problem remains.

[PDCWolf]

1 hour ago, Lisias said:

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

  Reveal hidden contents

 

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?

Here's a list of things that are not wobble, just in case:

• Pressurized tanks imploding.
• Parts detaching.
• Structures collapsing under their own weight after being damaged.

You seem to constantly mention how wobble is supposed to represent structural flexing, yet both run away from numbers, and only present unrelated phenomena as evidence. That's why we can't converge on anything, or anyone else has been able to converge on anything with your argument. Take for example this Atlas Agena rocket video, where the tanks depressurize (as clearly stated in the title), yet somehow this is supposed to justify structural flexing at intertank joints... I hope you can realize the problem.

If what you look for is ignoring posts because they don't present alternatives, I'll just recompile what's been said:

1. The OP in this post.
2. Non-tree building (which other games manage but magically KSP can't because it's a huge performance tax [citation needed])
3. Procedural parts.
4. Situational nonrigid joints.

Edit: As for putting the main habway of the ISS on the pad, I'll do you one better. The Steinway Tower is 435 meters tall by 18 meters wide, a ratio of height to width ratio of 24.1 (ISS is 36.3, a bit thinner). It only sways by 0.9 meters at the top when it's windy. You can stand on the ground and look up, and you won't notice the sway.

The main problem with your argument is the foundational belief that wobble is somehow correct. Wobble is not correct and not realistic, in fact it sacrifices realism by forcing same-vessel ghosting. It doesn't take into account using parts for different purposes, it doesn't promote good design (insofar as adding struts and autostruts is not good design), and thus you end up with parts exploding at random, unintuitive physics behavior (parts bending into each other is ok until it is not, right click to enable same vessel collisions, etc) . This is true for both KSP1 and 2.

1 hour ago, darthgently said:

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

For anyone not wanting to watch the video (even though it is marked as a chapter and you can skip right to it):

Kitbash uses pretty much what the OP of this thread suggests: Turning the entire ship into a single rigid body and calculating part-to-part stresses internally, which then results in parts flying off or exploding as they should, when they should. This also allows 1000+ parts vehicles to meet in multiplayer.

If anything the comments on that video are a testament to what the playerbase wants: a death to the perpetuated lie that is wobble.

Edited July 24, 2023 by PDCWolf

[darthgently]

1 hour ago, PDCWolf said:

Here's a list of things that are not wobble, just in case:

• Pressurized tanks imploding.
• Parts detaching.
• Structures collapsing under their own weight after being damaged.

You seem to constantly mention how wobble is supposed to represent structural flexing, yet both run away from numbers, and only present unrelated phenomena as evidence. That's why we can't converge on anything, or anyone else has been able to converge on anything with your argument. Take for example this Atlas Agena rocket video, where the tanks depressurize (as clearly stated in the title), yet somehow this is supposed to justify structural flexing at intertank joints... I hope you can realize the problem.

If what you look for is ignoring posts because they don't present alternatives, I'll just recompile what's been said:

1. The OP in this post.
2. Non-tree building (which other games manage but magically KSP can't because it's a huge performance tax [citation needed])
3. Procedural parts.
4. Situational nonrigid joints.

Edit: As for putting the main habway of the ISS on the pad, I'll do you one better. The Steinway Tower is 435 meters tall by 18 meters wide, a ratio of height to width ratio of 24.1 (ISS is 36.3, a bit thinner). It only sways by 0.9 meters at the top when it's windy. You can stand on the ground and look up, and you won't notice the sway.

The main problem with your argument is the foundational belief that wobble is somehow correct. Wobble is not correct and not realistic, in fact it sacrifices realism by forcing same-vessel ghosting. It doesn't take into account using parts for different purposes, it doesn't promote good design (insofar as adding struts and autostruts is not good design), and thus you end up with parts exploding at random, unintuitive physics behavior (parts bending into each other is ok until it is not, right click to enable same vessel collisions, etc) . This is true for both KSP1 and 2.

For anyone not wanting to watch the video (even though it is marked as a chapter and you can skip right to it):

Kitbash uses pretty much what the OP of this thread suggests: Turning the entire ship into a single rigid body and calculating part-to-part stresses internally, which then results in parts flying off or exploding as they should, when they should. This also allows 1000+ parts vehicles to meet in multiplayer.

If anything the comments on that video are a testament to what the playerbase wants: a death to the perpetuated lie that is wobble.

And to those who may not know, harvestR is the original creator of KSP from way before my time with KSP, so that is why I noted his solution as "authoritative".  He's been there, done all that.  And learned

[Lisias]

28 minutes ago, darthgently said:

And to those who may not know, harvestR is the original creator of KSP from way before my time with KSP, so that is why I noted his solution as "authoritative".  He's been there, done all that.  And learned

However, please remember the context in which he did that.

KSP is launching multi staged, many-tons vessels into space (and into water too), Kit Bash is flying models with only some kilograms of mass - and they not even leave the lower atmosphere.

People are not expecting to fly Balsa made RC planes on Laythe.

That said, I'm not implying this solution is not the way to go. See my previous posts about.

[PDCWolf]

3 hours ago, Lisias said:

However, please remember the context in which he did that.

KSP is launching multi staged, many-tons vessels into space (and into water too), Kit Bash is flying models with only some kilograms of mass - and they not even leave the lower atmosphere.

People are not expecting to fly Balsa made RC planes on Laythe.

That said, I'm not implying this solution is not the way to go. See my previous posts about.

Well, part of the context applies here as well: 1000+ parts ships meeting in multiplayer.

[Lisias]

8 hours ago, VlonaldKerman said:

In fact, in real life, I do not believe that rockets have this problem- I believe that the attachments of radial boosters are relatively rigid. If the flight parameters of a mission specify X g’s of acceleration, the body of the rocket is designed to handle that force, if reinforcements are necessary, then so be it.

They don't.

We have this problem because we decided to replace spars, structural spines and internal reinforcements with attachment nodes glued together by a game physics engine using joints on a Tree Data Structure - but yet, we still want the thingy to behave more or less Real Life™ crafts created with spars, structural spines and internal reinforcements.

We have a serious case of Leaking Abstractions here. Some compromise is unavoidable.

[Lisias]

On 7/24/2023 at 1:15 PM, Lowi_Sace said:

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) 

You misdiagnosed the problem!

There're a bug on KSP where reaction wheels and RCS thrusters ends up fighting each other, gradually increasing the torque forces due resonance (hey, KSP¹ apparently simulates resonance! cool!!) and, as such forces increases over time, they fatally reaches some part's breaking point.

I have a link to a Reddit post somewhere here where an user not only explains how to deterministically reproduce this problem, but also provides a viable workaround! As soon as I find it, I will edit this post with it. The guy deserves the credit.

[Mikki]

I don`t want to revive this thread about wobblyness, but tuning down engine gimbal at launch solves also lots of troubles, just  as reducing/disabeling excess reaction wheels on subsequent stages, lets face the means we have to launch basically everything with a little tweaking...

[VlonaldKerman]

39 minutes ago, Mikki said:

I don`t want to revive this thread about wobblyness, but tuning down engine gimbal at launch solves also lots of troubles, just  as reducing/disabeling excess reaction wheels on subsequent stages, lets face the means we have to launch basically everything with a little tweaking...

Ah, yes, good times. Just reminded me of that time early on in every KSP 1 science/career mode that I played where everything I launched I launched with a twin boar engine.

I would say that it’s okay for things to need tweaking at launch if there are use cases for the extra gimbal. For example, would you ever find yourself increasing gimbal authority shortly after launch, or for short periods of time?

The mere fact that you can make design decisions to reduce wobble doesn’t mean wobble is not a problem. Not saying that’s what you said, but I feel the need to reiterate that, while a lot of people seem to be saying that wobble imposes design constraints and that’s not necessarily bad, even though they aren’t always the right design constraints.

[Mikki]

1 hour ago, VlonaldKerman said:

snip ... I would say that it’s okay for things to need tweaking at launch if there are use cases for the extra gimbal. For example, would you ever find yourself increasing gimbal authority shortly after launch, or for short periods of time? ... snip

Me? I never increased gimbal after launch... Thank god we have "return to VAB"... 

[kdaviper]

2 hours ago, Mikki said:

I don`t want to revive this thread about wobblyness, but tuning down engine gimbal at launch solves also lots of troubles, just  as reducing/disabeling excess reaction wheels on subsequent stages, lets face the means we have to launch basically everything with a little tweaking...

I think adjusting the aggressiveness of SAS response go a long way in reducing the oscillations. This would help planes as well as we have seen how SAS is overcorrecting compared to ksp 1

[Barrackar]

On 10/7/2023 at 8:50 AM, kdaviper said:

I think adjusting the aggressiveness of SAS response go a long way in reducing the oscillations. This would help planes as well as we have seen how SAS is overcorrecting compared to ksp 1

"Wobbly rocket"poll results: In a poll recently conducted the vast majority of responses (80+%) said they wanted completely rigid vehicles, but also indicated it should break apart under strain/shear and break apart under aerodynamic pressure.

However, the primary roll bending/wobbly of parts has in the game is to visually indicate stress/strain and other forces acting on the parts. If joint physics is entirely removed this would (a) be a major change from KSP1 which was successful and thus represents a major risk; (2) SOMETHING else needs to indicate stress/strain/shear and other forces which could result in the vehicle breaking apart.  Missing thus far from the conversation are suggestions for: if not bending , how should forces be visually displayed? Some people including OP have suggested using auditory cues but I think this fails on several levels. (1) Auditory cues could potentially mess-up existing sound design of the game - which most agree the sound design is fantastic. Adding screeching noises or similar could be very annoying. (2) auditory cues alone are too subtle to indicate important information on critical failure modes.

Because nobody has suggested any alternative visual indicators for stress/strain/shear/forces on parts, I continue to argue for mitigating the problems associated with "wobbly rockets" rather than going entirely rigid. Here, I suggest a fix for SAS-related "wobbly rockets."

Joint Physics: I suggest existing implementation should mostly remain unchanged except tuning default values on certain parts. In particular, stiffness of stack decouplers (inline) should be increased a lot over v1.4 values. Similarly, docking port connections should be less wobbly.  No other changes.

SAS overcompensation/oscillation: A key source of wobble is oscillations cause by SAS both in KSP1 and KSP2.  I propose that if SAS-overcompensation and SAS related oscillation is fixed then the majority of "wobbly rocket" problems go away. That is, with SAS-oscillation fixed then rockets that players agree should not wobble, won't - and those rockets that still wobble most people would agree the wobble is the result of a design flaw (rather than a game bug).

SAS-oscillations are commonly the result of final stage command modules being tiny and at the very top while the bulk of the mass is the lower stages. Therefore, while the mass and aerodynamics may be oriented one direction, the command module can be tilted and give an incorrect orientation for rocket control. Any wobble which goes away when SAS is turned off is SAS-related.

I suggest compensating the "control from here" part orientation with a mass-weighted average orientation of all parts connected by nodes inline along the control orientation. This excludes radial attachment of all forms.  The vehicles overall orientation would be V = (mV +mV +...+mV)/{total mass} for those aligned parts, where V is the orientation vectors [subscripts omitted].  This calculation is only done from a single "control from here" part and should be a very fast calculation.

The intended effect is for tilting oscillations to cancel out when averaged because the front of the vehicle is tilted one direction and the rear of the vehicle is tilted the opposite direction. The result is a more consistent vehicle orientation for both pilot and SAS control purposes. Note: To deal with symmetric parts attached "backwards" the orientation of all parts except the "control from here" part should be half-spheres. I.e. no negative z-values, and use reflection for any orientation vector which is in the wrong half-sphere.

Pros: Aerodynamically stable rockets will have stable vehicle control while still being responsive to overall vehicle dynamics. SAS would be more reliable. Prevent feedback loops from amplifying into SAS-related "wobbly rockets."

Cons: (a) Some additional calculation needed, including a part-tree traversal from the "control from here" part to determine which parts to include in the calculation. (b) some types of SAS over-correction are still possible.

Edited October 9, 2023 by Barrackar

[kdaviper]

3 hours ago, Barrackar said:

"Wobbly rocket"poll results: In a poll recently conducted the vast majority of responses (80+%) said they wanted completely rigid vehicles, but also indicated it should break apart under strain/shear and break apart under aerodynamic pressure.

However, the primary roll bending/wobbly of parts has in the game is to visually indicate stress/strain and other forces acting on the parts. If joint physics is entirely removed this would (a) be a major change from KSP1 which was successful and thus represents a major risk; (2) SOMETHING else needs to indicate stress/strain/shear and other forces which could result in the vehicle breaking apart.  Missing thus far from the conversation are suggestions for: if not bending , how should forces be visually displayed? Some people including OP have suggested using auditory cues but I think this fails on several levels. (1) Auditory cues could potentially mess-up existing sound design of the game - which most agree the sound design is fantastic. Adding screeching noises or similar could be very annoying. (2) auditory cues alone are too subtle to indicate important information on critical failure modes.

Because nobody has suggested any alternative visual indicators for stress/strain/shear/forces on parts, I continue to argue for mitigating the problems associated with "wobbly rockets" rather than going entirely rigid. Here, I suggest a fix for SAS-related "wobbly rockets."

Joint Physics: I suggest existing implementation should mostly remain unchanged except tuning default values on certain parts. In particular, stiffness of stack decouplers (inline) should be increased a lot over v1.4 values. Similarly, docking port connections should be less wobbly.  No other changes.

SAS overcompensation/oscillation: A key source of wobble is oscillations cause by SAS both in KSP1 and KSP2.  I propose that if SAS-overcompensation and SAS related oscillation is fixed then the majority of "wobbly rocket" problems go away. That is, with SAS-oscillation fixed then rockets that players agree should not wobble, won't - and those rockets that still wobble most people would agree the wobble is the result of a design flaw (rather than a game bug).

SAS-oscillations are commonly the result of final stage command modules being tiny and at the very top while the bulk of the mass is the lower stages. Therefore, while the mass and aerodynamics may be oriented one direction, the command module can be tilted and give an incorrect orientation for rocket control. Any wobble which goes away when SAS is turned off is SAS-related.

I suggest compensating the "control from here" part orientation with a mass-weighted average orientation of all parts connected by nodes inline along the control orientation. This excludes radial attachment of all forms.  The vehicles overall orientation would be V = (mV +mV +...+mV)/{total mass} for those aligned parts, where V is the orientation vectors [subscripts omitted].  This calculation is only done from a single "control from here" part and should be a very fast calculation.

The intended effect is for tilting oscillations to cancel out when averaged because the front of the vehicle is tilted one direction and the rear of the vehicle is tilted the opposite direction. The result is a more consistent vehicle orientation for both pilot and SAS control purposes. Note: To deal with symmetric parts attached "backwards" the orientation of all parts except the "control from here" part should be half-spheres. I.e. no negative z-values, and use reflection for any orientation vector which is in the wrong half-sphere.

Pros: Aerodynamically stable rockets will have stable vehicle control while still being responsive to overall vehicle dynamics. SAS would be more reliable. Prevent feedback loops from amplifying into SAS-related "wobbly rockets."

Cons: (a) Some additional calculation needed, including a part-tree traversal from the "control from here" part to determine which parts to include in the calculation. (b) some types of SAS over-correction are still possible.

A realistic solution would be to have command modules that sent control to the next stage at the moment of separation, so you could have a small core in each stage. Not sure how feasible it would be to implement but iirc this is somewhat how real rockets operate.