[Removed]

[Guest]

[Removed]

Edited September 16, 2023 by Guest

[Rpatto92]

10 hours ago, Sprocket Creations said:

Adding many physics joints about the edges of the part's connection would work, but a better solution would be to design a physics joint that does not have these problems in the first place.

Hey your thread is well laid out and everything but it's little difficult to grasp your point, especially the proposal part because it's three lines in before you say what is your proposing outside of the title of the section. Seems a little vague too. Do you know for certain the joint type being used by KSP1/2 because you suggest it repurposed rage doll physics. Is your proposed solution an existing Unity feature, some sort of known plug-in or are you proposing a bespoke solution based upon your understanding of collision?

just seeking clarification. 

[Gotmachine]

So, as someone that has a bit of technical knowledge on how things are actually implemented, I thought I could maybe give a bit more insight.

13 hours ago, Sprocket Creations said:

The inline joints binding parts together are not capable of accurately resisting the forces acting on the parts. This is because the joints in question are points.

This isn't the primary reason why things aren't accurate. The primary reason  is that the joint solver isn't designed to be accurate in the first place, and has a core limitation in that the behavior is fundamentally not accurate when connecting parts that have a large difference in mass.
Said otherwise, and to simplify (it's actually a bit more complex than that), a joint with a stiffness value X connecting a 10 tons part and a 0.1 ton part will be a lot less rigid than the same joint connecting two parts of equal mass.
This is why parts like decouplers or reaction wheels are "weak points", because they are usually very light parts used to connect very heavy parts.

13 hours ago, Sprocket Creations said:

This is insufficient, as the actual connection between the two parts is not a point, but rather a disk.

KSP actually does this. For node/stack connections (not surface attach ones), KSP (1 and 2) actually generate multiple physical joints evenly positioned on a circle centered on the node. This is why larger node connections are stronger than smaller node connections, despite all joints using the same stiffness values.

13 hours ago, Sprocket Creations said:

a better solution would be to design a physics joint that does not have these problems in the first place. Unity's built in physics types were not designed with beam interactions in mind. They are meant for ragdolls

You're preaching to the converted.

Unfortunately, given the level of coupling between the builtin Unity PhysX implementations and almost every other subsystem in the game, the chances of them doing such a redesign and refactor are very slim.

[Guest]

[Removed]

Edited September 16, 2023 by Guest

[Gotmachine]

7 hours ago, Sprocket Creations said:

implementing a new joint should not be out of the question.

This isn't really a "type of joint" problem.
The different joint types you see in the Unity documentation aren't different implementations, they are just presets of the "configurable joint", which is what KSP actually uses.
The issue is not really in the "joint", but it's an intrinsic limitation of the type of solver implemented in PhysX, and the same limitation exists in all other similar physics engines (Havoc, Bullet, etc), and although other engines might be better at mitigating that specific issue, it will still be there.
To really get around that issue, there are only two options :

•  Use a solver that doesn't have those issues. For example, PhysX (and Unity since very recently) has an alternative solver based on the Featherstone algorithm, which is specifically designed to have physically accurate joint behavior. Implementation in the context of KSP could pose a few challenges, but that solver have shown impressive results by the the very KSP-like Mars First Logistics
• Get ride of the whole "1 part = 1 function = 1 structural unit" paradigm. That paradigm is mainly a consequence of the original KSP going for the easiest technical solution available for a wanabee solo game dev 15 years ago. It never really was a conscious or intended decision, and while I agree that it is part of the KSP identity, I think the game scope has evolved in such a way that this "feature" is now largely getting in the way of the game achieving its full potential.

Objectively, the 1 part = 1 rigidbody linked by non-rigid joints doesn't lead to a significant or remotely realistic "structural engineering" gameplay, and doesn't even succeed at preventing players from building structurally impossible vehicles, as due to the fundamentally un-physical behavior of the joints, they had to make them virtually indestructible. That paradigm is also responsible in a very large part for the overall jankiness of the game physics, as well as some of its performance issues. If they really wanted to have a "structural engineering" aspect to the game, it could be something like user-configurable connections strength (with a mass penalty to balance it), then have a relatively simple solver that compute cumulated forces/torques applied on each connection, with the connection simply snapping if the forces become greater than the limit. The only thing that bendy joints objectively provide is a visual feedback, which could be replaced by a cool "stress overlay", scary sounds of metal bending and particule effects of things starting to snap. Doing that would add an actually interesting, predictable gameplay element, and would get ride of a good chunk of the core issues the game has.

Edited March 17, 2023 by Gotmachine

[Guest]

[Removed]

Edited September 16, 2023 by Guest