Discussion Modeling Boats, Ships, and Other Watercraft in Orbiter? Experiments with Hydrostatics and the Touchdown Model
- Thread starter Thunder Chicken
- Start date
Thunder Chicken
Resident Lua Script Rabble-Rouser
Skiff now has a properly sized Diesel engine and propeller:
Model puts out about 90 hp based on a 4-stroke, 2 L, normally aspirated engine which is in good agreement with engine specs of this size.
Model puts out about 90 hp based on a 4-stroke, 2 L, normally aspirated engine which is in good agreement with engine specs of this size.
Last edited:
Thunder Chicken
Resident Lua Script Rabble-Rouser
The local USCG station does man-overboard training in the canal next to my work. They basically take one of their rookie recruits that looks like this mesh and toss him overboard at some random time and see how long it takes for them to fish him out. Rather funny to watch.
Thunder Chicken
Resident Lua Script Rabble-Rouser
OK, I think I'm legitimately sailing this time.
The sail properties are of a flat board, so it's drag dominated and can't go faster than wind speed, but I think with a better airfoil model that can mimic a fabric sail that can be remedied. I need to verify my wind triangles as I keep forgetting whether the calculated wind speed is coming FROM a direction or heading IN a direction. I am thinking of making an animated weathervane so the user can visually see the direction of the relative wind over the deck to help set the sail angle. I have text output now which helps, but is still rather hard to grok. The Diesel engine is set to idle and does not contribute thrust and the throttle is locked out when the sail is up. I can take down the sail and switch to engine power as desired.
This took more doing than may be apparent. I basically had to eliminate all vessel drag functions in the airfoil definitions in Orbiter as they all assume air is the driving fluid, which creates havoc when atmospheric wind is enabled for the sails. I had to calculate air and water drag forces on the hull independently. I defined a vessel bounding box with its length, beam, draft and freeboard dimensions to estimate projected areas for drag both in the water and in the air, and calculated the drag forces based on those areas, drag coefficients (purely a function of geometry), and using the correct respective density of the fluid (air or water).
I also simplified the touchdown buoyancy model using the bounding box dimensions of the bottom of the hull (area = length x beam). That area was populated with a uniform distribution of touchdown points, with the stiffness of each prescribed by (water density) x (gravity) x area / n_points. I can specify a desired density and the code will automatically generate the touchdown points symmetrically about the center of gravity of the vessel.
I am seeing why the number of touchdown points matters for stability - if only a small number of points are used, their stiffness must be very high to support the vessel, and so applied forces become sensitive to small displacements, causing instability. It seems that 33 touchdown points works nicely for the skiff, and is computationally very light. I applied the correct displacement (weight) of this vessel, and even though the stiffness of the touchdown points is based solely on the hydrostatic model with no information about the vessel weight, when the touchdown points support the vessel, the vessel rests perfectly level and the draft is nearly exactly that specified for the vessel. It's a crude model but it seems to work nicely.
I also realized that I had to take care to not define drag forces in the same axes as the touchdown points or to the keel. The damping of the touchdown points effectively IS the drag force in the Y vessel direction, so setting a drag force in that direction caused conflict and instability. Similarly, I have a "perfect" keel where no side slip is permitted, and so drag in the X vessel direction would not have any effect. I am not satisfied with this keel model as it doesn't allow lateral drift, but it is very stable and allows you to keep direction while moving under sail or power. I am thinking I might have to invoke some "skid" like my VW Thing in order to allow such sideways drifting, but that is a lot of coding for that effect. I'm trying to see if something plausible and stable can be produced with a minimum of code.
The sail properties are of a flat board, so it's drag dominated and can't go faster than wind speed, but I think with a better airfoil model that can mimic a fabric sail that can be remedied. I need to verify my wind triangles as I keep forgetting whether the calculated wind speed is coming FROM a direction or heading IN a direction. I am thinking of making an animated weathervane so the user can visually see the direction of the relative wind over the deck to help set the sail angle. I have text output now which helps, but is still rather hard to grok. The Diesel engine is set to idle and does not contribute thrust and the throttle is locked out when the sail is up. I can take down the sail and switch to engine power as desired.
This took more doing than may be apparent. I basically had to eliminate all vessel drag functions in the airfoil definitions in Orbiter as they all assume air is the driving fluid, which creates havoc when atmospheric wind is enabled for the sails. I had to calculate air and water drag forces on the hull independently. I defined a vessel bounding box with its length, beam, draft and freeboard dimensions to estimate projected areas for drag both in the water and in the air, and calculated the drag forces based on those areas, drag coefficients (purely a function of geometry), and using the correct respective density of the fluid (air or water).
I also simplified the touchdown buoyancy model using the bounding box dimensions of the bottom of the hull (area = length x beam). That area was populated with a uniform distribution of touchdown points, with the stiffness of each prescribed by (water density) x (gravity) x area / n_points. I can specify a desired density and the code will automatically generate the touchdown points symmetrically about the center of gravity of the vessel.
I am seeing why the number of touchdown points matters for stability - if only a small number of points are used, their stiffness must be very high to support the vessel, and so applied forces become sensitive to small displacements, causing instability. It seems that 33 touchdown points works nicely for the skiff, and is computationally very light. I applied the correct displacement (weight) of this vessel, and even though the stiffness of the touchdown points is based solely on the hydrostatic model with no information about the vessel weight, when the touchdown points support the vessel, the vessel rests perfectly level and the draft is nearly exactly that specified for the vessel. It's a crude model but it seems to work nicely.
I also realized that I had to take care to not define drag forces in the same axes as the touchdown points or to the keel. The damping of the touchdown points effectively IS the drag force in the Y vessel direction, so setting a drag force in that direction caused conflict and instability. Similarly, I have a "perfect" keel where no side slip is permitted, and so drag in the X vessel direction would not have any effect. I am not satisfied with this keel model as it doesn't allow lateral drift, but it is very stable and allows you to keep direction while moving under sail or power. I am thinking I might have to invoke some "skid" like my VW Thing in order to allow such sideways drifting, but that is a lot of coding for that effect. I'm trying to see if something plausible and stable can be produced with a minimum of code.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Well, at least you can now do tall ships with that model.
BTW, does your ship model heel when turning rapidly? I just tried a game, where the ship stays perfectly level even in that moment, it feels terribly wrong.
BTW, does your ship model heel when turning rapidly? I just tried a game, where the ship stays perfectly level even in that moment, it feels terribly wrong.
Thunder Chicken
Resident Lua Script Rabble-Rouser
A Black Pearl Orbiter add-on would be something.
It heels wonderfully.
Did you see these?
Vroom vroom noises intensify:
At 10X time acceleration:
At 10X time acceleration:
misha.physics
Well-known member
- Joined
- Dec 22, 2021
- Messages
- 1,480
- Reaction score
- 2,210
- Points
- 128
- Location
- Lviv
- Preferred Pronouns
- he/him
Some random or periodic water elevations (waves) could be a good solution. Just something similar that we have for the ground elevations.
Thunder Chicken
Resident Lua Script Rabble-Rouser
I'll probably get the skiff out as an add-on soon. It's just a technology demonstrator, but it's interesting.
Arvil
Well-known member
- Joined
- Apr 20, 2008
- Messages
- 518
- Reaction score
- 453
- Points
- 78
- Location
- Pennsylvania, USA
- Preferred Pronouns
- he/him
For a visual on the wind direction, instead of a weathervane, perhaps a small pennant sorta like a small version of a commissioning pennant on an old sailing ship, like HMS Victory.
Thunder Chicken
Resident Lua Script Rabble-Rouser
I have my code to a point where I can easily update it with the hull and engine specs of the MLB. The only fiddly bits will be getting the mesh groups and axes for the propeller and rudder animations and tweaking the drag coefficients to match vessel performance.
How would you like to go about merging my code and your mesh?
Thunder Chicken
Resident Lua Script Rabble-Rouser
Thunder Chicken
Resident Lua Script Rabble-Rouser
The 44-ft and 47-ft MLBs can be inverted, are self-righting, etc..
I'm preparing a Lua script for the 44-ft MLB. I have the vessel dimensions, displacement, fuel load, and engine and propeller specifications all in. Two Detroit 2-stroke 6V-53s with a total of about 440 hp and a top speed of 14 knots, right on the numbers.
Last edited:
Thunder Chicken
Resident Lua Script Rabble-Rouser
One thing to note - the 44 MLB was meant to be stable. It doesn't really heel much in flat water, in reality or in this model. Without some big waves and seas it is a rather placid ride.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
It has a similar "delta" hull cross section as the German ones, and likely has a similar CG position, so it shouldn't be a "soft" ship, but as I understand, they are also not too "rigid" for behaving nicer in bad sea states. I'd expect around 5°-10° list at full rudder, which isn't much for Orbiters standards, but quite noticable if you stand on it. Also it should be a yaw-stable ship, as opposed to the yaw-instable ones, which are pretty much all large freighters and tankers (yaw stable = if you center the rudder, the turning motion quickly stops. If you need additional counter rudder to stop a turn, its yaw-instable).
Thunder Chicken
Resident Lua Script Rabble-Rouser
The depth of the rudder relative to the center of gravity will affect the degree of list while turning.
I'd imagine so with the deep keel it has. The model is very yaw stable.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
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.
