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

[Thunder Chicken]

Making a wake:

 

[N_Molson]

I'll make this one, quite a conventional 2 screws + 1 rudder configuration.

 

[Thunder Chicken]

I'll make this one, quite a conventional 2 screws + 1 rudder configuration.

That would be a fun boat! I am sure you would, but make sure that all the exterior hull meshes are separate mesh groups. If possible, if you can limit the number of vertices in the hull to a couple of hundred, that would keep the computational cost sensible.

I could also implement my reciprocating engine and propeller models for this.

 

[Arvil]

I don’t know anything about coding, but in the case of a floating boat, typically, the center of gravity is slightly below the center of buoyancy keeping it upright except for wave action. Any symmetrical object such as a ball, usually, since we can’t build anything perfect, one side will be slightly heavier, so that the ball rotates until the heavy side is down. I wonder if, since your faceted ball is mathematically symmetrical, the math gets confused. Maybe if you introduce a very small mass, let’s say 0.5 %or one % of the total mass a couple millimeters off center so the code slowly turns it heavy side down, if the math would work better. I don’t know, just a thought.

 

[Thunder Chicken]

I don’t know anything about coding, but in the case of a floating boat, typically, the center of gravity is slightly below the center of buoyancy keeping it upright except for wave action. Any symmetrical object such as a ball, usually, since we can’t build anything perfect, one side will be slightly heavier, so that the ball rotates until the heavy side is down. I wonder if, since your faceted ball is mathematically symmetrical, the math gets confused. Maybe if you introduce a very small mass, let’s say 0.5 %or one % of the total mass a couple millimeters off center so the code slowly turns it heavy side down, if the math would work better. I don’t know, just a thought.

The spinning is actually around the vertical axis of the object, both for the ball and the box meshes, and it happens right as the object hits the water, but if it doesn't get sent into orbit, it generally stabilizes and stops. It really isn't a center of buoyancy stability issue.

 

[Thunder Chicken]

Vroom vroom noises intensify:



At 10X time acceleration:

 

[Thunder Chicken]

Going to see if I can make a sailboat that works with atmospheric wind effects enabled:



Going to animate the boom to rotate around the mast, and implement a simple airfoil that will provide lift and drag forces based on relative wind direction.

I threw a deck on the skiff because seeing sea water sloshing in the bottom was disconcerting. Need a bilge pump.

 

[N_Molson]

The 44 feet MLB is taking shape (the 'black' paint coating is a preview thing only. The real waterline should be higher than that) :

 

[Thunder Chicken]

I'm sailing! No motor!



Basically the sail is a triangular flat plate and I determine the angle of attack to the relative wind, and I calculate the lift and drag forces and apply them perpendicular or parallel respectively to the wind direction. I'm applying the force about 1/3rd of the way up the sail near the centroid of the triangular area, seems about right.

It's really hard to set the sail angle without some sort of guidance about wind direction - you don't have the wind blowing in your face to give you that information. But she moves when the wind blows, that's for sure. I've capsized it several times already. Orbiter shifts up the wind direction pretty randomly too which can catch you off guard. It's still pretty fun. Need to think about sailing I/O a bit more.

I had to disable the wake particles because the wind blows them and it looks strange.

 

[Thunder Chicken]

One issue - correcting the hull drag in water by multiplying the drag coefficient by the ratio of water density to air density works great, until you want to go sailing and the wind hits the hull with the density of water too. The wind drag on the hull was much larger than that I calculated for the sails. I need to deconflict the hull drag due to water and the drag due to air in some neat, intuitive way.

EDIT: I think I'll need to roll my own versions of SetCW(), one to set drag coefficients for the wetted hull based on ground speed, and another one to set drag coefficients in air based on relative airspeed.

 

[N_Molson]

The hull itself is pretty much finished, we now have propellers and a rudder that can be animated, plus some progress on the 'superstructures' :

I'll make a separate mesh of the lower hull so that you'll have something not too crazy for the calculations.

That ship isn't build for high speeds, but it sure can handle rough seas!

 

[Thunder Chicken]

The hull itself is pretty much finished, we now have propellers and a rudder that can be animated, plus some progress on the 'superstructures' :

I'll make a separate mesh of the lower hull so that you'll have something not too crazy for the calculations.

That ship isn't build for high speeds, but it sure can handle rough seas!

View attachment 41365

View attachment 41366

View attachment 41367

That looks great! FYI my Zorb mesh has 290 vertices and it handles the touchdown point hydrostatic model fine. I'd reckon if you can keep the exterior hull vertices under 1000 it should run OK. If you can call out the hull up to the main deck as separate mesh groups that should be fine. If possible, if you can get the locations and vectors defining the rotation axes of the rudders and propellers for animations they should be easy enough to animate.

I am working on modularizing my engine and propeller codes so they hopefully can drop in to any vessel with an engine and propeller (ships or aircraft). My engine module can handle spark ignition and Diesel reciprocating engines as well as turboshaft gas turbines. The user just needs to supply an engine specification table with the necessary parameters. The power output of the engine is then applied to a propeller module that translates it into thrust. Again, the user just needs to supply a propeller specification table with diameter, pitch angle, efficiency, and indication of fluid (air, fresh water, or sea water).

I similarly want to modularize the buoyancy models. I have code that will extract the hull vertices and set the touchdown points to the proper stiffness and damping to mimic buoyant forces on the vessel. I want to keep my hydrostatic pressure model as a separate module. Though it is rather computationally expensive and has stability issues, it may have some utility in certain cases. I may be able to refine that going forward. The code is pretty complex and it's currently hard to validate so that is going to be a process.

 

[N_Molson]

This is the part I plan to separate as the 'hull mesh'. It says 127 vertices, you have to multiply that number by 2, because it will be mirrored. So, 254 vertices, we're inside the 'vertices budget'.

I think that the keel should be defined separately as an horizontal stabilizer ? Also maybe the fins-like struts that connect the propeller shafts.

I can also add the propeller shafts as a separate mesh.

 

[Thunder Chicken]

This is the part I plan to separate as the 'hull mesh'. It says 127 vertices, you have to multiply that number by 2, because it will be mirrored. So, 254 vertices, we're inside the 'vertices budget'.

I think that the keel should be defined separately as an horizontal stabilizer ? Also maybe the fins-like struts that connect the propeller shafts.

I can also add the propeller shafts as a separate mesh.


View attachment 41371

That number of hull vertices is quite fine. One concern is the distribution of those vertices. Each touchdown spring essentially is applying a force that is assumed to be average over a small area of the hull around a vertex. If there are large areas of the hull with no vertices like around the midsection where the prop shafts emerge, no forces will be applied there, but if there are a lot of vertices clustered together like at the bow and stern there will be a lot of force concentrated there. It could make for a strange force distribution that won't be physically realistic. Practically you might not be able to do much with the vertices with the mesh. It suggests that maybe I need to decouple the touchdown spring model from the mesh vertices and try to uniformly distribute touchdown points over the hull in some way.

I'd say roll with what you have and just use good modeling practice. If anything needs to change, it should be done in my model. I might need to do more development work on how to apply the buoyant forces. Even my skiff has a relatively flat bottom and the vertices were a bit more uniformly distributed so that might have hid a lot of potential issues, so it might be useful to see how your mesh works with my model as-is.

The keel and prop shafts and supports and rudder don't need to be separate meshes. As long as they are distinct mesh groups in the same mesh file that will be fine.

 

[N_Molson]

OK, I can add an edge loop (under the cockpit) in the mid-section, no problem, just let me know.

Yes, I think that any model that will more or less be drawn after a real hull will have this 'distribution' issue.

 

[Thunder Chicken]

OK, I can add an edge loop (under the cockpit) in the mid-section, no problem, just let me know.

I wouldn't worry about it. I think the physics must be handled in code, not in the mesh.

Yes, I think that any model that will more or less be drawn after a real hull will have this 'distribution' issue.

Yes, that's something I am realizing. I'll have to somehow sample the hull geometry to make a touchdown point "mesh" independent of the visual mesh.

 

[N_Molson]

Things are going fairly well :

 

[Urwumpe]

I wouldn't worry about it. I think the physics must be handled in code, not in the mesh.

Yes, that's something I am realizing. I'll have to somehow sample the hull geometry to make a touchdown point "mesh" independent of the visual mesh.

How about the cheapest solution of just scaling an ideal hull model to the mesh? You would then just require length, beam and weight. Maybe also freeboard, if you want to simulate sinking. With an displacement vector, you could also model metacentric height and rightening moment.

Maybe the behaviour is then even reduced to just the forces, no longer needing a FEM.

 

[Thunder Chicken]

How about the cheapest solution of just scaling an ideal hull model to the mesh? You would then just require length, beam and weight. Maybe also freeboard, if you want to simulate sinking. With an displacement vector, you could also model metacentric height and rightening moment.

Maybe the behaviour is then even reduced to just the forces, no longer needing a FEM.

Certainly there are many ways to abstract the situation into a model. I'm working on a couple different ones. This method of just modeling the vessel as a basic box and calculating metacenters and moments would certainly work for basic boat-like vessels, and indeed it might be the computationally simplest. But is a 44-ft USCG vessel realistically modeled by a box? If the vessel is very dynamic, determining the metacenters and righting moments of a box is basically the same as integrating the hydrostatic equations on the crudest hull mesh possible. I may try this, but I would have to believe it would suffer from the same stability issues as my more general hydrostatic model (something of a boundary element method vs. FEM).

In theory integrating the hydrostatic pressures on all the hull triangles would deliver the best fidelity and would be the most generalizable method to get correct buoyant distribution on any generic hull, but it is very computationally expensive and suffers from stability issues.

The use of the touchdown points model to mimic buoyancy is actually pretty computationally cheap and very stable, but it is approximate. And the reasonableness of the results is very dependent on the touchdown point distribution. For some vessel models using the mesh vertices might be convenient if they are evenly distributed, but for some vessels that won't be the case. A touchdown point cloud separate from the visual mesh might remedy that.

I think these are all methods worthy of exploration and understanding. If we can get a plausible buoyancy model that plays well with Orbiter it might open up some more environments for exploration. I'm afraid that one finding is that the simulation timestep in Orbiter puts a hard limit on the stability of many of these methods.

 

[Urwumpe]

It definitly shouldn't be a box, since the difference in bouyancy of bow and stern is quite important for the seakeeping.

Also, the 27.5 m SAR cruiser of Germany, that I currently build as brick model, surely has no box shape or rectangular cross section.

The German SAR ships (including the 46m long Hermann Marwede) are also capable of capsizing and uprighting themselves again like the 44-ft USCG, which looks absolutely mad in wharf trials:

Here is also a video of the test:

If you want to have a good run-down of the hull design of these ships, this museum piece shows really everything:

Its has more of a "glider" type of stern, like used for racing boats and German Schnellboote, for having low drag at high speeds, the center hull is rather hemispherical for stability, and the bow is pretty close to the "Atlantic bow" designs of german warships.

And in case of capsizing, the ships hull is actually almost perfect watertight from above and has a rounded shape below the decks around it, with a very robust and light super-structure, that keeps the air trapped inside and makes it act as bouyancy aid when upside down, giving it a pretty submarine-like look.

None of these ships EVER sunk, even though in one disaster in 1967, the whole crew and all rescued seamen were killed, and in another capsizing in 1995 two crewmembers had been washed off the ship and lost at sea. In both cases, this happened during strong storms and were caused by a freak or "monster wave" of unusual height, both in relatively shallow waters close to the safe shore. The first ship was almost undamaged, returned into service and later served for the Finnish coast guard. The second ship in now in Uruguyan service, its regular crew even managed to cross the Atlantic with it under its own power.

(You can use english subtitles, the translation is not AI generated and of good quality)

And this is my current mental health program : https://www.bluebrixx.com/de/ships/107004/Seenotrettungskreuzer-BlueBrixx-Pro

(But the model shows the pre-1996 condition of the ships - after the accident, they all received a fully enclosed bridge on top, before they had an enclosed bridge below and a open cockpit above)