Will we be able to attach parts at multiple points WITHOUT struts?

[Guest]

Does anyone know if we'll be able to attach parts at multiple points [see photo], without having to use struts to attach at multiple points?

[MechBFP]

As far as I recall that hasn't ever been mentioned.  However I do believe they are moving away from the “tree” structure that the vehicles in KSP1 are built around. If that is true then technically this should be possible, although it may still not be do-able for other technical reasons. 

[Missingno200]

57 minutes ago, MechBFP said:

As far as I recall that hasn't ever been mentioned. 

Well, if you count 2019, during ShadowZone's interview he brings up this question(though he used triple docking ports as his example,) and he got the reply back "we can look into it."

[Pthigrivi]

5 minutes ago, Missingno200 said:

Well, if you count 2019, during ShadowZone's interview he brings up this question(though he used triple docking ports as his example,) and he got the reply back "we can look into it."

Yeah thats the last I've heard? It would be awesome.

[darthgently]

4 minutes ago, Pthigrivi said:

Yeah thats the last I've heard? It would be awesome.

The tree structure is a trade-off.  If they move to a structure that allows "cycles" (more than one path between parts) it would be realistic to expect a performance hit in the simulation and bugs that are harder to track down.  It could be worth it, but hard to say in advance.  Just saying that there are costs and benefits. 

One cost could be Kraken 2.0 depending on how well, or poorly, a non-tree structure is implemented and thoughtfully respected in future code changes by both KSP and mod devs. 

 

[tstein]

12 minutes ago, darthgently said:

The tree structure is a trade-off.  If they move to a structure that allows "cycles" (more than one path between parts) it would be realistic to expect a performance hit in the simulation and bugs that are harder to track down.  It could be worth it, but hard to say in advance.  Just saying that there are costs and benefits. 

One cost could be Kraken 2.0 depending on how well, or poorly, a non-tree structure is implemented and thoughtfully respected in future code changes by both KSP and mod devs. 

 

Not really. Most  rigid body  physics  engines are made to handle multiple connection points already. The more compelx part would be on predict what is a stage and how much DV a specific stage coudl have if you  cannot infer what will remain and on what order.

[SolarAdmiral]

2 hours ago, darthgently said:

The tree structure is a trade-off.  If they move to a structure that allows "cycles" (more than one path between parts) it would be realistic to expect a performance hit in the simulation and bugs that are harder to track down.  It could be worth it, but hard to say in advance.  Just saying that there are costs and benefits. 

Actually, I don't think it would be all that bad. Ksp already has struts in it which basically do the same thing, link together two parts not directly connected by the tree. I think the only problem is how to present it in the VAB. 

What about a "weld" button, that works exactly like a strut, except without showing the strut part and the two parts being connected need to be touching, slightly clipped into one another, or very close together.

[K^2]

8 hours ago, tstein said:

Not really. Most  rigid body  physics  engines are made to handle multiple connection points already.

Generally. Though, PhysX, at least the version used by Unity, is probably the worst offender on having issues with it. It all comes down to the solver and how that works. In technical terms, if you have two weld points between two parts, there is no longer a unique solution for constraint forces. You can always add more tension to one joint by relaxing tension on the other and compensating for torques. That means, the constraints matrix is inherently singular. If you do an "honest" analytic solution to such a matrix, you'll have a division by zero. A numerical solver might or might not encounter this as division by a very, very small number, resulting in large numerical error. This could be cause of a sudden Kraken in some configurations, honestly.

If Intercept switched to Havok physics at some point, which we have no indication of so far, this might be a non-issue. The solver used by Havok is much better at handling cases like this.

There are other reasons to do tree structure, however. Consider logic of separating ships, e.g., during staging. Right now KSP can guarantee that when a separation part fires, all of its descendant nodes become a new ship. No additional logic required. If you don't have a tree, and alternative connection points might still exist, you have to check whether you still have one ship or two ships. And that's a more complex problem. Not rocket science, of course - it's basically just an A* search, but we've seen that Squad made a mess of a similar problem doing fuel routing, so it's certainly an added complexity.

[SolarAdmiral]

49 minutes ago, K^2 said:

Generally. Though, PhysX, at least the version used by Unity, is probably the worst offender on having issues with it. 

I'd still ask is there any reason it couldn't be handled the same way struts are? We already have struts and they work fine. Just make the struts invisible if the parts are touching.

[K^2]

4 hours ago, SolarAdmiral said:

I'd still ask is there any reason it couldn't be handled the same way struts are? We already have struts and they work fine. Just make the struts invisible if the parts are touching.

For physics, not really. It seems like early versions of KSP had very different tuning parameters for struts, but that seems to have been improved with some updates to either how all the other joints are tuned or maybe there was an engine update that helped with it. I'm fuzzy on the details. But you still can have problems in KSP if you keep adding struts all over the place, and the same would apply here. There are limits to what you can do if there is an inherent problem with the solver. (Again, might be a non-issue if a different solver is being used.)

In terms of connection logic, though, there are still challenges. When you do a stage separation in KSP, every descendant node is marked as new ship. All you have to do now is go through all the struts and see if they connect the old ship to the new one, and if so, disconnect that strut. If you have multiple attachment points, that no longer works. In the screenshot in the OP, what happens if you detach only the bottom decoupler, but not the top? The logical thing would probably be to do a full walk from decoupler's parent parts to child parts to see if they are all still connected. If they are, do nothing? Do you still apply the ejection force in this case? It's not unsolvable, but it's a non-trivial complication.

[Vl3d]

5 hours ago, K^2 said:

In the screenshot in the OP, what happens if you detach only the bottom decoupler, but not the top? The logical thing would probably be to do a full walk from decoupler's parent parts to child parts to see if they are all still connected. If they are, do nothing? Do you still apply the ejection force in this case? It's not unsolvable, but it's a non-trivial complication.

Let me give you an example of why this is a very useful feature but requires manual decoupling. Let's say you have a craft with two arms that each are connected to the main tank using 1 decoupler above and below a decoupler and a hinge. You don't want automatic separation of all decouplers. You want to decouple the first ones (above), then move the hinge, then decouple the last ones (below).

Edited January 31, 2023 by Vl3d

[tstein]

10 hours ago, K^2 said:

Generally. Though, PhysX, at least the version used by Unity, is probably the worst offender on having issues with it. It all comes down to the solver and how that works. In technical terms, if you have two weld points between two parts, there is no longer a unique solution for constraint forces. You can always add more tension to one joint by relaxing tension on the other and compensating for torques. That means, the constraints matrix is inherently singular. If you do an "honest" analytic solution to such a matrix, you'll have a division by zero. A numerical solver might or might not encounter this as division by a very, very small number, resulting in large numerical error. This could be cause of a sudden Kraken in some configurations, honestly.

If Intercept switched to Havok physics at some point, which we have no indication of so far, this might be a non-issue. The solver used by Havok is much better at handling cases like this.

There are other reasons to do tree structure, however. Consider logic of separating ships, e.g., during staging. Right now KSP can guarantee that when a separation part fires, all of its descendant nodes become a new ship. No additional logic required. If you don't have a tree, and alternative connection points might still exist, you have to check whether you still have one ship or two ships. And that's a more complex problem. Not rocket science, of course - it's basically just an A* search, but we've seen that Squad made a mess of a similar problem doing fuel routing, so it's certainly an added complexity.

Really sad to know PhysX  is still so  much ... limited.   I  left  game industry  before  PhysX became a thing, but I expected them  to  handle things like that since even  a car rolling on asphalt havs more than one constraint when interacting with the ground.

 

The advantages of tree that you  state are the ones I   implied when I said makes easier to know what  is still a ship  after a stage decouples, but as you said, you do not need a genius to solve it, Djkstra already  did that for us.

[SolarAdmiral]

8 hours ago, K^2 said:

For physics, not really. It seems like early versions of KSP had very different tuning parameters for struts, but that seems to have been improved with some updates to either how all the other joints are tuned or maybe there was an engine update that helped with it. I'm fuzzy on the details.

I mean struts work alright for KSP1. All I'm suggesting is something that behaves physically to the game just like the current strut system but is shown to the player a little differently. I still think they should add something like an invisible strut for welding two parts together. Because as we move into the much larger ships, it will be even more necessary. Unless we want all our interstellar ships to be a single long truss with stuff stuck to it, more ways of joining parts would be great to be able to build in different geometries.

[magnemoe]

17 hours ago, K^2 said:

Generally. Though, PhysX, at least the version used by Unity, is probably the worst offender on having issues with it. It all comes down to the solver and how that works. In technical terms, if you have two weld points between two parts, there is no longer a unique solution for constraint forces. You can always add more tension to one joint by relaxing tension on the other and compensating for torques. That means, the constraints matrix is inherently singular. If you do an "honest" analytic solution to such a matrix, you'll have a division by zero. A numerical solver might or might not encounter this as division by a very, very small number, resulting in large numerical error. This could be cause of a sudden Kraken in some configurations, honestly.

If Intercept switched to Havok physics at some point, which we have no indication of so far, this might be a non-issue. The solver used by Havok is much better at handling cases like this.

There are other reasons to do tree structure, however. Consider logic of separating ships, e.g., during staging. Right now KSP can guarantee that when a separation part fires, all of its descendant nodes become a new ship. No additional logic required. If you don't have a tree, and alternative connection points might still exist, you have to check whether you still have one ship or two ships. And that's a more complex problem. Not rocket science, of course - it's basically just an A* search, but we've seen that Squad made a mess of a similar problem doing fuel routing, so it's certainly an added complexity.

This is true, unless an separation event don't break all connections who has some relevance but mostly in moving parts as in robotic. If you stage an booster and it only unlock on the top say an Soyuz its an mission fail, so checking your staging become more important. 
 

6 hours ago, tstein said:

Really sad to know PhysX  is still so  much ... limited.   I  left  game industry  before  PhysX became a thing, but I expected them  to  handle things like that since even  a car rolling on asphalt havs more than one constraint when interacting with the ground.

The advantages of tree that you  state are the ones I   implied when I said makes easier to know what  is still a ship  after a stage decouples, but as you said, you do not need a genius to solve it, Djkstra already  did that for us.

Pretty sure car to ground physic is handled totally different as in not in the physic engine, the surface is critical for one and if one tire is on wet asphalt and the other is on ice who is realistic acceleration will be impacted  

[Xwing000]

By the way i have never seen any struts on a ksp 2 Kraft....

[magnemoe]

3 hours ago, Xwing000 said:

By the way i have never seen any struts on a ksp 2 Kraft....

Saw them on an large plane connecting the body wings and the engines who was halfway down the wings SR-71 style before the outer wings. 
 

[K^2]

6 hours ago, magnemoe said:

Pretty sure car to ground physic is handled totally different as in not in the physic engine

I have no idea how KSP handles it. For general information, there are three typical ways this is handled, and I've personally implemented each type for different games, and there are pros and cons to each strategy.

1. Have the physics engine take care of everything. You can literally build out a wheel and suspension system and just apply torques to wheels. Traction on different materials can still work, because you need both restitution and sliding friction for physics objects in contact with the ground anyways, and there are usually material checks during collision, which can both influence friction forces and be used for any additional FX. That's usually used for things like impact sounds which can vary with material, but you can also use these for applying tire track decals. The biggest downside is that the wheel ends up being a rigid body, which means it will bounce a lot at high speeds reducing effective traction, and this has to be accounted for. But there are games where this hardly comes up, making it the easiest way to add vehicles.
2. Custom system. This can be very simple or extremely sophisticated. This is the approach where you compute the tire-ground contact points, do all of the math on the dynamics of suspension and wheels, and then apply net forces to the vehicle body at the suspension contact points - that can be done directly through impulses or by creating virtual joints. The most sophisticated of such systems will compute tire deformation and how much rubber is being scraped off by the asphalt. They will update the tire and suspension physics at about 1kHz, and sync it with the rest of the physics on something more manageable, like 60Hz or even just during frame updates. This is very precise, but computationally expensive and is hard work to implement.
3. Hybrid. You do a ray or shape cast to  the ground to find wheel contact points. These become joints with custom constraints which provide side-to-side stability, engine torque and braking forces for forward movement, and a hard limit for the suspension bottoming out. You then compute suspension forces for the given displacement of the wheels and apply it to the vehicle body as impulses. Unless the suspension bottoms out, the "wheel" joints only constrain motion along the surface with the suspension impulses giving the vehicle a smooth ride over whatever surface. With this setup, you get all of your basic handling properties, you can handle both rough terrain and asphalt, and you can even do fancier things like drifting without having to fake it, while still utilizing engine's native solver for everything but suspension (which doesn't need one, because we handle bottoming out separately) and you can usually tune it to feel like whatever type of car that you want to within a limit where a casual player won't know it's not precise.

My personal preference is to use that last approach for anything that isn't a hard racing sim. If you create a vehicle in Unreal using built-in vehicle class, that's the approach used there as well. I have complaints about how they handle traction, but it's acceptable overall and is fine for most games that need basic vehicles. This can be implemented in Unity, and it's what I would recommend for wheeled vehicles for KSP/KSP2.