Alternate building grids for colonies and stations

[Pthigrivi]

Im an architect professionally so this is a topic near and dear to my heart. Im psyched to see the colony building mechanics especially as they relate to bodies with different gravities because it radically alters your relationship to statics and the kinds of things you can build.  There are restrictions on cantilevers here on earth that would not exist on Minmus, and the organizational considerations in orbit are different from both. Colonies on Gilly could and should look much different from ones on Tylo or Eve. We don’t know much about the colony construction UI but Id love to see the ability to build on different types of grids to take advantage of this, especially equilateral, hexagonal, and right-triangle pinwheel grids. I think this could open up a whole world of creative structural engineering solutions and much more diverse architectures for colonies and stations. 

 

 

Edited November 9, 2020 by Pthigrivi

[Lewie]

@Pthigrivi I love this idea! However....I've got a thinking that most player's (including myself) will most likely try to build the largest, most unstable colony possible!

Cheers-

Lewie

[Pthigrivi]

6 minutes ago, Lewie said:

@Pthigrivi I love this idea! However....I've got a thinking that most player's (including myself) will most likely try to build the largest, most unstable colony possible!

Cheers-

Lewie

To (mis)quote an engineer whose name escapes me “engineering isn't the art of making things that stand up, but making things that just barely don’t fall down.”

Edited November 9, 2020 by Pthigrivi

[K^2]

I kind of doubt that KSP2 is going to be accounting for structural stress in colonies and stations. Partially, based on what has been shown so far, and partially because they are still using weld joints on the rockets. If you try to build colonies with weld joints bad things will happen. A lot. You have to take your rigid body simulation seriously if you are going to build stable, physically plausible structures. Restrictions to building out of modules is already going to make it difficult to have variety in structures that are stable even with a good simulation in place, and so far, I have seen no indication that the Intercept is even trying to have that sort of simulation.

The only game I have seen so far to even remotely have something physically plausible, fully simulated, and built on a grid in an open world is Medieval Engineers. It is built on a custom voxel engine, and even there, you can tell that some liberties had to be taken.

I know, I know, the teaser for KSP2 clearly has shown a colony falling apart, but I'm going to venture a guess that this feature has been revised. It certainly can be done. It has been done. But it is a project and I haven't seen any indications of it so far that the team at Intercept are putting in the necessary work to make it happen in any shape that would be contributing positively to the game.

[Pthigrivi]

13 minutes ago, K^2 said:

I kind of doubt that KSP2 is going to be accounting for structural stress in colonies and stations. Partially, based on what has been shown so far, and partially because they are still using weld joints on the rockets. If you try to build colonies with weld joints bad things will happen. A lot. You have to take your rigid body simulation seriously if you are going to build stable, physically plausible structures. Restrictions to building out of modules is already going to make it difficult to have variety in structures that are stable even with a good simulation in place, and so far, I have seen no indication that the Intercept is even trying to have that sort of simulation.

The only game I have seen so far to even remotely have something physically plausible, fully simulated, and built on a grid in an open world is Medieval Engineers. It is built on a custom voxel engine, and even there, you can tell that some liberties had to be taken.

I know, I know, the teaser for KSP2 clearly has shown a colony falling apart, but I'm going to venture a guess that this feature has been revised. It certainly can be done. It has been done. But it is a project and I haven't seen any indications of it so far that the team at Intercept are putting in the necessary work to make it happen in any shape that would be contributing positively to the game.

No Im pretty sure I recall Nate saying something about structural limitations to how colonies are built being a part of the challenge in an interview. Damned if I could find it now though. So far all of the colonies Ive seen seem to be built on orthogonal (all-90-degree) grids but I might be wrong or maybe this is a choice and not baked in. This is in contrast to KSP1 where triangular and hexagonal symmetries allow for different building layouts. How easy or difficult this would be to implement is hard for me to guess, but I’d love to see it in the x + y axis at least. 

Edited November 9, 2020 by Pthigrivi

[K^2]

I'm absolutely sure that was at least part of initial ambition for the game, but there is also real life, and they don't even have handle on Kraken for ships. It's way worse for structures if you want them to be even remotely playable. Nobody wants to try to add an antenna to a tower, only to have it start vibrating, explode, send shrapnel in every direction, and have a chain reaction take out your entire colony. That's the sort of thing that makes an average player close the game and never come back to it.

There's a way to avoid all of that, but you have to be clever about it. Intercept did have an open rec for physics engineer that did get filled or closed some time in the early spring. That could be an indication that they hired someone who knows how to do this sort of sim, but there's a LOT of other work to be done on the physics in this game, and there is only so much time. I sincerely doubt their ability to deliver on simulated structural integrity of colonies without compromising other parts of gameplay at this point.

Essentially, the crux is that they are still using Unity physics for rockets, which you can tweak until it works. But the physics simulation you need for colonies would be completely separate and has to be built from scratch. I don't know a lot of game dev engineers who know how to do this work. I work for a studio that has in-house engine built largely around physics simulation, and even here, there hasn't really been more than one engineer at any given time who specializes in simulation for a while. Currently, that's my responsibility, and the only other person who fully grasps how the simulation works is our CTO. And even that simulation isn't designed to handle structural stress and would need a lot of work to get it to that point.

I don't know how much background you have on civil engineering. A naive implementation of a structure is a collection of rigid bodies with a system of constraints. That's generally good enough for a game. Even if you want individual components to have limits on stress, you can sort of compute an average stress and put limits on that. The problem is now entirely in how you solve the system of constraints. Standard approach used by pretty much every game now is a variant on iterative solution which is going to be at least similar to impulse exchange. The problem with that approach is that number of iterations you need increases with complexity of the structure and some other parameters. For example, it's a lot easier to build a stable structure if all your parts have similar masses. If you have light objects that hold together heavy objects expect trouble. Not getting deep into numerics of it, but it's just not viable for large, complex structures with many parts.

The other approach is trying to solve the linear system directly. Again, that works great on simple systems, and might look promising, until you start getting more and more complex systems that become more and more singular. At that point, adding a new part can suddenly make the solution unstable and there is no way to predict it, so it's a ticking time bomb. No good.

Finally, you can realize that you're not the first person having this problem and look at what's been done to these kinds of systems historically. And fortunately some brilliant mathematicians have come up with good ways of handling such systems of equations. Problem is entirely in adapting the approaches to games. Specifically, you need to build pseudo-inverses by first looking at singular value decomposition of the problem, taking care of singularities, and constructing a pseudo-inverse that doesn't have these problems. The challenge, then, is making sure you can do this in a way that's efficient. If you have no moving parts in your structure, then, theoretically, you only need to run the process once. Of course, any time a part is added or removed, you have to re-do the computations. Probably not a huge problem if you are adding stuff, but good by framerate if your base is being destroyed. So the next step is optimizing the re-computation process to where you don't have to start from the scratch. That's a serious math problem, and fortunately, because it comes up in particle physics, fluid simulations, and even SLAM algorithms, there are known ways of addressing it.

Problem is, if you need something like this in the game, you aren't hiring a generalist engineer who knows a bit about physics. You are hiring someone with deep background in mathematics and simulation and that's a req that's hard to fill and isn't cheap. And unless Intercept lucked out when hiring for their physics engineer, is it really worth it for them to be looking for someone like this just for colonies?

[Pthigrivi]

4 hours ago, K^2 said:

I'm absolutely sure that was at least part of initial ambition for the game, but there is also real life, and they don't even have handle on Kraken for ships. It's way worse for structures if you want them to be even remotely playable. Nobody wants to try to add an antenna to a tower, only to have it start vibrating, explode, send shrapnel in every direction, and have a chain reaction take out your entire colony. That's the sort of thing that makes an average player close the game and never come back to it.

There's a way to avoid all of that, but you have to be clever about it. Intercept did have an open rec for physics engineer that did get filled or closed some time in the early spring. That could be an indication that they hired someone who knows how to do this sort of sim, but there's a LOT of other work to be done on the physics in this game, and there is only so much time. I sincerely doubt their ability to deliver on simulated structural integrity of colonies without compromising other parts of gameplay at this point.

Essentially, the crux is that they are still using Unity physics for rockets, which you can tweak until it works. But the physics simulation you need for colonies would be completely separate and has to be built from scratch. I don't know a lot of game dev engineers who know how to do this work. I work for a studio that has in-house engine built largely around physics simulation, and even here, there hasn't really been more than one engineer at any given time who specializes in simulation for a while. Currently, that's my responsibility, and the only other person who fully grasps how the simulation works is our CTO. And even that simulation isn't designed to handle structural stress and would need a lot of work to get it to that point.

I don't know how much background you have on civil engineering. A naive implementation of a structure is a collection of rigid bodies with a system of constraints. That's generally good enough for a game. Even if you want individual components to have limits on stress, you can sort of compute an average stress and put limits on that. The problem is now entirely in how you solve the system of constraints. Standard approach used by pretty much every game now is a variant on iterative solution which is going to be at least similar to impulse exchange. The problem with that approach is that number of iterations you need increases with complexity of the structure and some other parameters. For example, it's a lot easier to build a stable structure if all your parts have similar masses. If you have light objects that hold together heavy objects expect trouble. Not getting deep into numerics of it, but it's just not viable for large, complex structures with many parts.

The other approach is trying to solve the linear system directly. Again, that works great on simple systems, and might look promising, until you start getting more and more complex systems that become more and more singular. At that point, adding a new part can suddenly make the solution unstable and there is no way to predict it, so it's a ticking time bomb. No good.

Finally, you can realize that you're not the first person having this problem and look at what's been done to these kinds of systems historically. And fortunately some brilliant mathematicians have come up with good ways of handling such systems of equations. Problem is entirely in adapting the approaches to games. Specifically, you need to build pseudo-inverses by first looking at singular value decomposition of the problem, taking care of singularities, and constructing a pseudo-inverse that doesn't have these problems. The challenge, then, is making sure you can do this in a way that's efficient. If you have no moving parts in your structure, then, theoretically, you only need to run the process once. Of course, any time a part is added or removed, you have to re-do the computations. Probably not a huge problem if you are adding stuff, but good by framerate if your base is being destroyed. So the next step is optimizing the re-computation process to where you don't have to start from the scratch. That's a serious math problem, and fortunately, because it comes up in particle physics, fluid simulations, and even SLAM algorithms, there are known ways of addressing it.

Problem is, if you need something like this in the game, you aren't hiring a generalist engineer who knows a bit about physics. You are hiring someone with deep background in mathematics and simulation and that's a req that's hard to fill and isn't cheap. And unless Intercept lucked out when hiring for their physics engineer, is it really worth it for them to be looking for someone like this just for colonies?

Super appreciate the breakdown because from the kind of basic, predictive statics equations I deal with this is a much simpler problem.  I always chalked the sudden, resonant explody situations to reaction wheel tea-cupping and poor terrain interactions. Most things in real life don’t rattle themselves to death without some unexpected resonant external force like wind or seismic movement. Seems simple enough to ignore/remove that kind of thing from the system? The nice thing is these structures dont have hypersonic aerodynamics to deal with, they just have to not fall down. Couldn’t they run a test sim when placing a new part and mark it red if it would result in failure?

Edited November 10, 2020 by Pthigrivi

[K^2]

5 hours ago, Pthigrivi said:

Most things in real life don’t rattle themselves to death without some unexpected resonant external force like wind or seismic movement.

In games, it's almost always a consequence of finite time step or finite precision in numerical integration. Here's an artificial example. Imagine that you're trying to keep an object in place with a simulated spring with stiffness k. That object has mass m and is initially at position x₀ = 0. It got a kick from some external force or collision and has some initial velocity v₀. Every time step you update position based on current velocity, then update velocity based on forces.

F₀ = -kx₀ = 0

a₀ = F₀/m = 0

x₁ = x₀ + v₀t = v₀t

v₁ = v₀ + a₀t = v₀

Not a lot is happening yet, but lets look at the energy.

E₀ = mv₀²/2 + kx₀²/2 = mv₀²/2

E₁ = mv₁²/2 + kx₁²/2 = mv₀²/2 + k(v₀t)²/2

So the system gained energy during this time step. What's interesting is that with this particular integration scheme, you'll be gaining energy on every single time step. Yes, you can add damping to try to counteract that, but for any damping coefficient you chose and no matter how small the time step t gets, you can find combination of k and m such that energy gain will be higher and the system WILL shake itself apart.

Now, the problem in this particular example is using forward Euler integration. There are much better integration methods that don't have this problem for this simple case. Unfortunately, as the system gets more and more complex, that doesn't help you anymore. Basically, no matter how careful you are about simulation, if your joints are effectively springs, somebody can come up with a system that's going to shake itself apart at the slightest nudge. And, well, KSP demonstrates it perfectly.

Obviously, there are ways to minimize these problems. Reducing time step is one. That's why things get worse under time warp. And then there are ways in which you apply joints between modules, the ways in which you compute spring coefficients (or, rather, Baumgarte parameters for joint stabilization, but it's the same effect). But things generally get worse as you increase the size, number of contact points, and any additional external forces.

5 hours ago, Pthigrivi said:

Couldn’t they run a test sim when placing a new part and mark it red if it would result in failure?

Sure. But I immediately see two problems. Lets say the simulation is very close to instability. First, when you are placing the part, it might show up red. Then you mouse away, mouse back, and it's green now, because this time simulation didn't explode. And it might be unstable enough that it takes you several tries to place the part. That's bad player experience. Then you start playing. Everything's great until you tried to land a rocket on a pad. Suddenly, game realizes that it needs to check stability with added weight of the rocket, and this time, the simulation explodes and your entire base flies into all possible directions at once. Bad player experience.

I don't think a dynamic simulation of any kind is a solution here. You have to turn it into a statics problem. If you say that modules themselves never move from equilibrium, this becomes entirely a problem about interaction forces. If velocity is always zero, your base can't possibly shake itself apart. Unfortunately, there is still a route for it going bad.

Imagine two modules welded together at 4 points. These 4 weld points make a cross. Now, I tell you that two modules don't move relative to each other, what are the forces on joints? There are infinitely many solutions, technically, providing same net force. If two of the joints are pulling the modules together very, very hard, then two of the others are pushing the modules apart. The net effect is still zero, but forces can get really high. Unfortunately, left to their own devices these forces tend to diverge in simulation due to divisions by nearly zero. (Singularity.) There are number of ways to fix that as well, and the most direct and fool-proof is via singular value decomposition. Which is, honestly, just a fancy math way of saying, "Ok, find solution that minimizes the sum of squares of all forces". And unless you are dealing with materials that are pre-stressed, this tends to give physically sensible results.

But what you arrive at is that the simulation you should be doing for structures is completely different than the way Unity simulates physics. Because Unity is designed for dynamic objects with all sorts of joint types, while for structures you want a static simulation with weld joints only. Different math, different criteria for stability. And, well, custom physics would have to be written from scratch, so there's that.

[Guest]

2 hours ago, K^2 said:

snip

Premise I'm way below your level of understanding of this argument.

That said, I think you're missing a huge opportunity for simplification: ground anchors.

When he talked about this Nate always talked about cliffs, canyons and, generally, of interactions with the ground morphology. I read that as: "the problem arises when you can't directly build a pylon to the ground.

I'm convinced that the structural calculations aren't for the building as a whole but from the last anchored module/structure.

I can also immagine them making explicitly non-structural pressurized tubes/corridors relatively cheap encouraging the players to build multiple structurally indipendent buildings instead of a single monolithic block.

[cfds]

The problem with ground anchors is, that including them naively just introduces another node with an infinite force to the graph.

[Guest]

1 hour ago, cfds said:

The problem with ground anchors is, that including them naively just introduces another node with an infinite force to the graph.

Not player placeable ground anchors, I'm thinking more about automatically placed pylons if the module is close enought to the ground and the ground has the right conditions (type and inclination), that way most modules will just be static root and only the part built "in mid air" will be considered in the structural calculations.

Edited November 10, 2020 by Master39

[starcaptain]

Let's look at a specific example.

This is one of the screenies of a base on a Mun-like object.

Centered in the scene is what appears to be the heart of any colony mission, a self-contained, vacuum-proof, iron-enriched, allegedly portable Exospheric Vehicle Assembly Building. (EVAB?) This building may be invariant apart from color scheme, from level to level.

Attached to it at each of its four sides are "stuff", which each look like they're coming from preset attachment nodes, not unlike the Multi-Point Connector hub.

Out one side are solar panels. They're such simple constructions that I wonder if they're click-and-drag and procedural generated.

Out another side are a handful of modules that I bet are part of the first tech epoch, being roughly analogous to our current level of technology in the real world: with metal tanks and balloonified habitation modules. Or maybe the white things are rigid tanks covered with insulation. Or giant marshmallows. Anything is possible.

Everything is suspended above the ground by little stilts. These stilts are just some sufficient length downwards so that you can't see their bottoms after they intersect the surface.

I get Pthigrivi's issue: the little supporting stilts should have a few different variants (and perhaps the exterior of some modules and the EVAB too) depending on surface gravity (and/or external pressure).

I personally am wondering to what degree we can fiddle with things like rotation or alignment of modules: is everything going to be hard limited to nodes and 90º points of contact, or will we have complete rotation and translation offset tools like in the vehicle editor, where people can build enormously sophisticated facilties that fit inside a single tiny box because of abusing part intersections. Or perhaps we'll have something in-between that's more free than 90º hard points, but less than full 6-axis freedom.

I wonder also if space station colony editors function the same as base editors.

Edited November 10, 2020 by starcaptain

[K^2]

2 hours ago, Master39 said:

Not player placeable ground anchors, I'm thinking more about automatically placed pylons if the module is close enought to the ground and the ground has the right conditions (type and inclination), that way most modules will just be static root and only the part built "in mid air" will be considered in the structural calculations.

Which I think is pretty close to how they'll do this for ground colonies. But we're sort of back to having it where the structure is either complex enough to have stability problems or it's simple enough to where you don't get any benefits of the simulation. All you need is for each module to become an independent physics object if it's been hit with enough force to break it off. It will still look reasonable and requires zero structural simulation.

[Guest]

24 minutes ago, K^2 said:

Which I think is pretty close to how they'll do this for ground colonies. But we're sort of back to having it where the structure is either complex enough to have stability problems or it's simple enough to where you don't get any benefits of the simulation. All you need is for each module to become an independent physics object if it's been hit with enough force to break it off. It will still look reasonable and requires zero structural simulation.

As I said I was considering the "structural simulation" only for modules suspended without direct pylons, like when you're trying to bridge a canyon or build on the rim of a crater (or just love to build tower-colonies)

[K^2]

22 minutes ago, Master39 said:

As I said I was considering the "structural simulation" only for modules suspended without direct pylons, like when you're trying to bridge a canyon or build on the rim of a crater (or just love to build tower-colonies)

You have 3 limiting cases here.

1) Connections are very weak, barely enough to support a single module. So you can't build any complex suspended or free-standing structures. Anything that doesn't collapse immediately is stable.

2) Connections are strong, but you are building with just a few modules. Everything is stable.

3) Connections are strong, and you build complex free-standing or suspended structures. Due to part count, you have stability issues I've outlined. Entire colony occasionally undergoes spontaneous disassociation.

Case 1) isn't fun, because it drastically limits what you can build. Case 3) is unstable regardless of anchors. Case 2) doesn't actually benefit from simulation, because nothing is even close to structural limits.

So the only sensible solution is you either build a custom simulation that can handle case 3) or you don't, pretend you did, and just treat everything as if it was case 2) regardless of complexity without actually running simulation.

[mcwaffles2003]

13 hours ago, K^2 said:

In games, it's almost always a consequence of finite time step or finite precision in numerical integration. Here's an artificial example. Imagine that you're trying to keep an object in place with a simulated spring with stiffness k. That object has mass m and is initially at position x₀ = 0. It got a kick from some external force or collision and has some initial velocity v₀. Every time step you update position based on current velocity, then update velocity based on forces.

F₀ = -kx₀ = 0

a₀ = F₀/m = 0

x₁ = x₀ + v₀t = v₀t

v₁ = v₀ + a₀t = v₀

Not a lot is happening yet, but lets look at the energy.

E₀ = mv₀²/2 + kx₀²/2 = mv₀²/2

E₁ = mv₁²/2 + kx₁²/2 = mv₀²/2 + k(v₀t)²/2

So the system gained energy during this time step. What's interesting is that with this particular integration scheme, you'll be gaining energy on every single time step. Yes, you can add damping to try to counteract that, but for any damping coefficient you choseand no matter how small the time step t gets, you can find combination of k and m such that energy gain will be higher and the system WILL shake itself apart.

 

Is there not a way to implement a potential well that holds the total energy of the system and doesn't allow anything to exceed the region of maximum potential energy to account for errors in timesteps?

[K^2]

14 minutes ago, mcwaffles2003 said:

Is there not a way to implement a potential well that holds the total energy of the system and doesn't allow anything to exceed the region of maximum potential energy to account for errors in timesteps?

It's not about a shape of potential, but rather the discrete points at which you probe it. That said, for a particular type of potential, one can design a conservative integrator that will conserve energy to within numerical errors. Problem is, once you start increasing number of degrees of freedom, you can't build a conservative integrator for a general case. Best you can do is integrators that will be conservative on average in most practical circumstances. (See symplectic integrators.)

In practice, you rarely get even that far. Fancy methods of integration are just too expensive to run for a game. A typical multi-body simulation in a game engine will run at most a few rounds of impulse exchange or equivalent to solve for constraints, then use some variation of Verlet integration to update bodies. It's good enough for most practical cases, including ragdolls, if you set them up correctly.

Truth is, physics sims like the one used in Unity just aren't made for the use case. They are good when the part count is low, and they are at their worst when two massive objects are connected by a very light one. You know, like stack separators. You can probably avoid that last one in base building, but you still have all the other problems.

[mcwaffles2003]

5 hours ago, K^2 said:

It's not about a shape of potential, but rather the discrete points at which you probe it. That said, for a particular type of potential, one can design a conservative integrator that will conserve energy to within numerical errors. Problem is, once you start increasing number of degrees of freedom, you can't build a conservative integrator for a general case. Best you can do is integrators that will be conservative on average in most practical circumstances. (See symplectic integrators.)

Just as it's speculated to be the case with ships I think colonies will also have large segments simply joined without spring- like joints to limit the DOF being simulated

[K^2]

Just now, mcwaffles2003 said:

Just as it's speculated to be the case with ships I think colonies will also have large segments simply joined without spring- like joints to limit the DOF being simulated

That's definitely the correct approach. The question is whether you still want to simulate stress at these not-joints. If the answer is no, you're done. Formula for adding together moment of inertia tensors for two rigid bodies joined together is in high school physics textbook. But if you want to simulate stress in the structure, you still have to jump through all the hoops and look after all the singularities.

There's also a separate note on rockets. One thing that joints give you over simply joining rigid bodies is the flex. Personally, I think KSP could have done without from the start, but now that KSP has had bendy rockets for nearly a decade, it's hard for me to picture KSP2 without it. Some sort of a hybrid approach might be what you want here, however, and if that's what they're going for, great!

 

Unless they really have both the talent and time to do this right, my recommendation would be to not worry about stress. For colonies, surface or orbital, just build the whole thing as a single rigid body. Maybe add some joints for moving bits, like ramps, satellite dishes, etc. If a particular part takes enough of a bonk, it disconnects from its neighbors and possibly explodes. That will still look pretty good if you crash a ship into a colony and won't tax your simulation.

For rockets yeah, replace as many welds as you can with proper unions, and again, don't worry about stress there. You can treat a stack of tanks as a single tank. We've been kind of thinking of them that way logically anyhow. And then things like stack separators and struts can still be done with conventional weld joints. This will allow for construction of much larger rockets without fear of the Kraken, while you still get that classic flex anywhere stages separate, whether stages themselves are large or small. Best of all the worlds.

[Pthigrivi]

8 hours ago, K^2 said:

That's definitely the correct approach. The question is whether you still want to simulate stress at these not-joints. If the answer is no, you're done. Formula for adding together moment of inertia tensors for two rigid bodies joined together is in high school physics textbook. But if you want to simulate stress in the structure, you still have to jump through all the hoops and look after all the singularities.

There's also a separate note on rockets. One thing that joints give you over simply joining rigid bodies is the flex. Personally, I think KSP could have done without from the start, but now that KSP has had bendy rockets for nearly a decade, it's hard for me to picture KSP2 without it. Some sort of a hybrid approach might be what you want here, however, and if that's what they're going for, great!

 

Unless they really have both the talent and time to do this right, my recommendation would be to not worry about stress. For colonies, surface or orbital, just build the whole thing as a single rigid body. Maybe add some joints for moving bits, like ramps, satellite dishes, etc. If a particular part takes enough of a bonk, it disconnects from its neighbors and possibly explodes. That will still look pretty good if you crash a ship into a colony and won't tax your simulation.

For rockets yeah, replace as many welds as you can with proper unions, and again, don't worry about stress there. You can treat a stack of tanks as a single tank. We've been kind of thinking of them that way logically anyhow. And then things like stack separators and struts can still be done with conventional weld joints. This will allow for construction of much larger rockets without fear of the Kraken, while you still get that classic flex anywhere stages separate, whether stages themselves are large or small. Best of all the worlds.

All great info, and though a lot of that is beyond me not being a programmer I think I understand the pitfalls. If Intercept has come up with some clever work-arounds/simplifications, great, but even if not and bases are all rigid I hope like starcaptain says that there’s a good amount of assembly flexibility if for aesthetic reasons alone. 

[K^2]

8 hours ago, Pthigrivi said:

I hope like starcaptain says that there’s a good amount of assembly flexibility if for aesthetic reasons alone. 

Yeah, I sort of hijacked the thread on purely the structural integrity aspect of things, but there's a lot more to it. Regardless of how Intercept solves the other problems, there needs to be a system that's flexible enough to let you build the colony that works for you, and that has both aesthetic and logistical aspects that all have to do with flexibility of layouts. Personally, I think I want to be able to build on a grid, but not be forced into any particular grid. Maybe I'll want to arrange my storage tanks on a hex grid to conserve space and solar panels on a rectangular grid to use the area more effectively. And the way I'm picturing that working is that new placements would snap to a selected grid relative to the nearest structure. Maybe have a key you can hold to lock in the "root" structure, so you can place far away, but keep the grid alignment relative to desired structure? Seems like that would give you all the flexibility you need, but maybe I'm missing something.

[mcwaffles2003]

16 hours ago, K^2 said:

The question is whether you still want to simulate stress at these not-joints

Isn't that the point of making them non joints?

16 hours ago, K^2 said:

There's also a separate note on rockets. One thing that joints give you over simply joining rigid bodies is the flex. Personally, I think KSP could have done without from the start, but now that KSP has had bendy rockets for nearly a decade, it's hard for me to picture KSP2 without it. Some sort of a hybrid approach might be what you want here, however, and if that's what they're going for, great!

I don't think it would be kerbal without bendy rockets. Without it aerodynamic stresses wouldn't behave correctly at all, though less bending would be nice as the extents of bending we see in game can get extreme.

16 hours ago, K^2 said:

Unless they really have both the talent and time to do this right, my recommendation would be to not worry about stress. For colonies, surface or orbital, just build the whole thing as a single rigid body. Maybe add some joints for moving bits, like ramps, satellite dishes, etc. If a particular part takes enough of a bonk, it disconnects from its neighbors and possibly explodes. That will still look pretty good if you crash a ship into a colony and won't tax your simulation.

It's already confirmed colonies will not be single rigid bodies though, so there can be failures to stop people from making completely crazy builds like a long plank base over a pit and it hopefully can add fun to the process.

I'd wager a lot of the stress and unevenness will be solved with the posts that join the bases to the ground and the very bottom layer of the base will act like a single rigid body. Hopefully if the building have multiple locations to join to the foundation to increase rigidity we can see similar for rockets as well (the whole tree structure of how they're built) and we can get some more variety in the way we build.

[K^2]

2 minutes ago, mcwaffles2003 said:

Isn't that the point of making them non joints?

You can still do the math for stress in both scenarios. Here's the super simple example. Imagine that we're looking at two objects of masses m₁ and m₂ that can only move in one dimension (like, attached to a rail, or something), and their centers are located at positions x₁ and x₂. We also say that they are attached together by a joint so that the centers are L apart. In other words, we have joint constraint x₂ - x₁ = L. We say that there is a constraint force λ between the two. And lets say a force F is applied to the first body. Equations of motion can be written for accelerations of these bodies.

m₁a₁ = F - λ

m₂a₂ = λ

a₂ - a₁ = 0

If you solve these as a system, you'll know both accelerations and the "stress" λ at the joint. This is basically the approach taken by Unity to solve for all of the joints in the simulation. Well, there's a correction. You'll note that we are only solving for accelerations. After updates, we aren't guaranteed that initial constraint x₂ - x₁ = L is satisfied. This is called a drift and you'll get more of it as you increase complexity of the system. I won't get into the math of fixing it, but we effectively replace a strict constraint with a stiff spring. The result will be that a₁ is not strictly equal to a₂ and you can get various oscillations. Most of the time, it isn't a problem, but as the system grows in complexity, chances for instability increase.

It might seem like a silly way to do things, but you need to keep in mind that Unity supports a lot of joint types, and the above method can be generalized to anything you can write constraint equations for, which makes it easy to address fairly complex systems without having to worry about all the special cases.

 

But if we decided that we'll only have welds, then alternatively, you treat the two objects welded together as a single rigid body. We know from constraint that a₁ = a₂ = a, where a is acceleration of center of mass. We also know that Σm_ia_i = ΣF_i. So we have a new equation of motion.

(m₁ + m₂)a = F

And, well, we don't really need to solve anything, we just have our answer. There is no drift, because we just simulate center of mass position and then we place all the components relative to it. However, what we lost is information about λ. We can recover it. What we do is we go to the original equations that have λ in them and substitute information we have about acceleration.

m₁a = F - λ

m₂a = λ

Technically, we don't need both of these equations, since we have only one unknown. For this simple case, we can pick either one, and unless we've done something horribly wrong, we should get the same answer to within numerical error. But imagine that we did make a miscalculation of the value for a. In that case, the two results can disagree. The way to minimize the error is to look for the pseudo-inverse, and again, skipping the hairier math, the correct expression for lambda that minimizes the errors is the following.

λ = (1/2) (F + (m₂ - m₁)a)

It happens to be the average of the results of the two expressions in this simple case, but if you were to try and solve a problem with multiple constraints, you will encounter numerical singularities - division by zero or numbers very close to zero - which will wreck havoc on your results and can lead to exceptionally high estimates of stress when there is no reason for it.

So in short, whether you simulated a joint constraint, or you simply joined the bodies together, you can get the estimates for stress at the point the two objects are joined, but you will have to do some math gymnastics to get there either way.

[mcwaffles2003]

@K^2 Is the point of preserving lamda to still allow sheering events to still occur where the two parts of the welded pair join? I would just figure not allowing fractures at all at any of these points to keep it simple and reduce the total calculations.

[K^2]

Yes, and yes, that's the simple solution. Simply let people build whatever they build and don't worry about the stress for the colonies. Or as some people here have mentioned, limit the number of places where you use the simulated joints, so that you only have a few potential failure points.