Discussion Modeling Boats, Ships, and Other Watercraft in Orbiter? Experiments with Hydrostatics and the Touchdown Model

The hull shape should also be important, since it defines the countering rightening moment. Essentially how much bouyancy on one side of the ship increases by increasing list.
The effects of the hull are only approximated with the touchdown point buoyancy model. It gets the gross buoyant force about right and provides plausible pitching and righting moments, but the magnitudes and locations of those moments aren't perfectly accurate. If anything, this model likely yields hull performance that is more stable than the actual hull. It behaves very much like a boat, and it is computationally very cheap and robust, but to get it to act like a particular hull will require some artistic tweaking.

I was hoping that directly integrating the hydrostatic pressure on the hull mesh would be feasible as that would allow this sort of geometric fidelity, but I fear that it is simply too numerically unstable for general use, as well as being rather computationally intensive.
 
The effects of the hull are only approximated with the touchdown point buoyancy model. It gets the gross buoyant force about right and provides plausible pitching and righting moments, but the magnitudes and locations of those moments aren't perfectly accurate. If anything, this model likely yields hull performance that is more stable than the actual hull. It behaves very much like a boat, and it is computationally very cheap and robust, but to get it to act like a particular hull will require some artistic tweaking.

I was hoping that directly integrating the hydrostatic pressure on the hull mesh would be feasible as that would allow this sort of geometric fidelity, but I fear that it is simply too numerically unstable for general use, as well as being rather computationally intensive.

Maybe your idea still has a place. Like preprocessing a mesh to create lookup tables for Lua or C++. Not sure if a generic ship vessel could work or would be too special. (If anybody wants to code that idea, its free for grabs, I am already on my WIP limit).
 
Maybe your idea still has a place. Like preprocessing a mesh to create lookup tables for Lua or C++. Not sure if a generic ship vessel could work or would be too special. (If anybody wants to code that idea, its free for grabs, I am already on my WIP limit).
Perhaps, but I am not sure if that would remedy the stability issues. Could be a lot of effort for naught. Need to think about it some more.
 
Perhaps, but I am not sure if that would remedy the stability issues. Could be a lot of effort for naught. Need to think about it some more.

Well, already in the real world, the situations that cause the stability issues would be a very chaotic situation. You just make them worse in Orbiter if the model is too simple. In most situations, you actually have a heterogenous water/air mixture surrounding the boat, and not water or air. And this transition region would actually not matter at all in most other cases (Maybe gliding vessels could be more realistic by that)
 
Well, already in the real world, the situations that cause the stability issues would be a very chaotic situation. You just make them worse in Orbiter if the model is too simple. In most situations, you actually have a heterogenous water/air mixture surrounding the boat, and not water or air. And this transition region would actually not matter at all in most other cases (Maybe gliding vessels could be more realistic by that)
Even things like simple vessel drag can be problematic as the forces are 3 orders of magnitude higher in water than in air due to the density, and are proportional to velocity squared. Modest changes in velocity can cause large changes in applied force which can quickly feedback to instability. The simulation time step really was meant for frictionless orbital mechanics and getting such frictional forces to stay stable is a challenge, never mind all the other physics madness.
 
Even things like simple vessel drag can be problematic as the forces are 3 orders of magnitude higher in water than in air due to the density, and are proportional to velocity squared. Modest changes in velocity can cause large changes in applied force which can quickly feedback to instability. The simulation time step really was meant for frictionless orbital mechanics and getting such frictional forces to stay stable is a challenge, never mind all the other physics madness.

Well, you can always use a Runge-Kutta approximation to get more sane forces over the length of one timestep. It just requires more math to be fun.
 
I guess it would be acceptable to 'freeze' the collision/friction model when time acceleration goes beyond a given threshold. That's what they did in KSP.
 
I guess it would be acceptable to 'freeze' the collision/friction model when time acceleration goes beyond a given threshold. That's what they did in KSP.
How do they 'freeze' the collision model? If the touchdown point model is disabled, the vessel will fall to the center of the Earth. And the water drag models would need to be disabled as well. There really wouldn't be a way to do this without getting the vessel to Landed status, which makes time acceleration rather pointless.

Unless there is a way to just move the vessel along the surface in a prescribed direction without using forces to update the motion, time acceleration really is a no-go. I have seen how to specify angular velocity, but I am not aware of a way to specify the linear velocity of a vessel. If there is such a method then I'd love to hear about it.
 
I have seen how to specify angular velocity, but I am not aware of a way to specify the linear velocity of a vessel.
If you mean setting angular velocity in the "Angular velocity" tab in the Scenario Editor, than you can set linear velocity in the same way in the "State vectors" tab in the Scenario Editor. There are dx/dt, dy/dt, dz/dt.
 
I guess it would be acceptable to 'freeze' the collision/friction model when time acceleration goes beyond a given threshold. That's what they did in KSP.
How do they 'freeze' the collision model? If the touchdown point model is disabled, the vessel will fall to the center of the Earth. And the water drag models would need to be disabled as well. There really wouldn't be a way to do this without getting the vessel to Landed status, which makes time acceleration rather pointless.

Unless there is a way to just move the vessel along the surface in a prescribed direction without using forces to update the motion, time acceleration really is a no-go. I have seen how to specify angular velocity, but I am not aware of a way to specify the linear velocity of a vessel. If there is such a method then I'd love to hear about it
If you mean setting angular velocity in the "Angular velocity" tab in the Scenario Editor, than you can set linear velocity in the same way in the "State vectors" tab in the Scenario Editor. There are dx/dt, dy/dt, dz/dt.
No, I mean a method to set it in code. There is a set_angvel() method, but nothing for linear velocity AFAIK.
 
How do they 'freeze' the collision model? If the touchdown point model is disabled, the vessel will fall to the center of the Earth. And the water drag models would need to be disabled as well. There really wouldn't be a way to do this without getting the vessel to Landed status, which makes time acceleration rather pointless.
Yes, I don't think that those settings in the Scenario Editor freeze the collision model. Sorry, I misunderstood you.
No, I mean a method to set it in code. There is a set_angvel() method, but nothing for linear velocity AFAIK.
I guessed you meant something else. Sorry, I just didn't know about setting angular velocity in code. It looks to me, that since water doesn't have elevations, than the movement of a vessel on water could be easy to realize without forces calculations. But I don't know how to do that or if it's possible at all for now.
 
How do they 'freeze' the collision model? If the touchdown point model is disabled, the vessel will fall to the center of the Earth. And the water drag models would need to be disabled as well. There really wouldn't be a way to do this without getting the vessel to Landed status, which makes time acceleration rather pointless.
Well, I think that "freezing" in this case, means literally freezing it, in that sense that no changes are made. This is contrary to how Orbiter handles physics during time acceleration that everything is multiplied by the time acceleration factor, IOW, a 10x time acceleration leads to a 10x increase in the forces. While in a frozen model scenario, the forces would stay at 1x.
 
By the way, we can set/change the position of a vessel on the surface in the Scenario Editor. Obviously, such the displacement is reliezed without forces. So, continuous changes of coordinates this way could be a solution.
 
Well, I think that "freezing" in this case, means literally freezing it, in that sense that no changes are made. This is contrary to how Orbiter handles physics during time acceleration that everything is multiplied by the time acceleration factor, IOW, a 10x time acceleration leads to a 10x increase in the forces. While in a frozen model scenario, the forces would stay at 1x.
The problem in Orbiter is that the acceleration time step is also the time step for propagation. What may be stable at a small time step can become non-physical / unstable at larger time steps. Orbiter was developed for orbital mechanics with minimal frictional or contact forces, and large time steps aren't such a problem for stability for those sorts of position. The timescales for aerodynamic and hydrodynamic forces are much, much shorter, so time resolution is a major problem.

The touchdown model in Orbiter is a spring-damper force model, so it works by applied forces, as do drag, lift, etc.. There isn't a way to shut off or remove the touchdown forces without completely eliminating the touchdown points, and then there would be nothing to support the vessel.

Something like how the scenario editor allows changes of orientation and position kinematically (prescribed motion/displacement), in order to permit time acceleration based on the last velocity would require some means to shut off all of the force models and update the vessel position kinematically. That would also need to be done in a particular frame of reference so the surface vessel doesn't just continue in a straight line into space. If it is a surface vehicle, it would have to be in planetary surface coordinates.
 
I made a rudimentary wind tell and placed it on the deck:

Screenshot at 2024-12-10 16-35-48.png

Seems to do the job, but sailing the thing is still pretty hard. The majority of my actual sea time was in the engine room of a steamship and I've only sailed sunfish and such one or two times ever. I will probably push this out and ask actual canvas sailors whether it doing appropriate things. I need to get a better lifting curve model in for the sail as it is literally just a flat plate model now.
 
Getting there. I seem to be able to get some lift off the sail:

Screenshot at 2024-12-10 19-46-25.png
I keep having to remind myself that, yes, having a negative AOA is fine. It doesn't show in the picture, but the atmospheric wind is pretty gusty and turbulent, and the wind tell really moves around erratically like a real one flapping in the breeze. I want to do some more checking to make sure I have all my relative wind math correct and all my vector triangles are correct.

I gave the skiff a better paint job too:

Screenshot at 2024-12-10 20-02-44.png
For some reason the wind tell meshgroup doesn't appear when it is first loaded from the scenario, but if I exit and restart from the saved scenario it appears. I don't know what is causing that.
 
I forget if I've asked, @Thunder Chicken , but have you tried setting the max substeps to 100 or 1000? to see if that improves numerical stability.
 
I forget if I've asked, @Thunder Chicken , but have you tried setting the max substeps to 100 or 1000? to see if that improves numerical stability.
I can run with 100, but my laptop bogs down when it is at 1000.

It's not really enough to change the number of substeps by 10X if 100X or 1000X time acceleration is engaged. The number of timesteps would have to match the time acceleration.

It may just simply be infeasible to expect these models to be stable during time acceleration. But if that is the case and the models must be shut off, time acceleration only makes sense if you can update the vessel position based on its last velocity. So far as I know we can't directly specify velocity or position like this without using force models.
 
Back
Top