The Triton Ocean SDK is a fairly mature product; there aren’t a whole lot of things people want at this point that it doesn’t already do. But one thing that does come up from time to time is including the effects of ship wakes in height queries. Previously, calls to Triton::Ocean::GetHeight() would return precise results from all of Triton’s simulated wind waves, swell waves, impact waves, and rotor wash waves – but not from ship wakes.

For some customers, this is an important feature – maybe you want to simulate the effect of traveling through a large ship’s wake on a smaller craft. Our answer was always “it can’t be done!” because ship wakes are implemented in Triton via a displacement texture entirely on the GPU, and reading back how that wake displacement was applied to the CPU for height queries isn’t something that can be done quickly enough to maintain interactive framerates.

But, Triton is just software – and with software, anything is possible. I woke up in the middle of the night with an epiphany, which is how these things usually go eventually…

The light bulb that went off is that Triton didn’t always use a displacement texture for simulating ship wakes. The very first version of Triton approximated ship wakes by simulating a series of “impulses” from the ship’s propellers that generated a train of circular waves expanding from the back of the ship. It turns out that if you simulate those waves precisely, you end up with a perfect “Kelvin wake” behind the ship with the perfect angle of 38.94 degrees. From a physical standpoint, that’s what’s happening – if you integrate an infinite number of these waves together.

Computers don’t deal with infinity well however, so that early version of Triton just summed up circular waves emitted every 5 seconds from the back of the ship. It did generate a wake of the correct size, but visually it left a lot to be desired – which is why we ultimately replaced it with a displacement map texture. However, for the purposes of height queries – why not? Circular waves are easily computed on the CPU side, and we were already factoring them in from impacts and rotor washes. All that needed to be done was to bring back some of the original code for ship wakes, but only use it for height queries, not for the visual side.

And, that’s what we’re doing in Triton 4.54. As your ships travel along, they are emitting these virtual waves under the hood in parallel with the visual simulation of Kelvin wakes. When Ocean::GetHeight is called, we sum up the effects of these waves and add them into your final result.

There are some limitations to this approach; one being that the height you get back may not match up exactly with what you see visually within ship wakes. There is also some CPU cost to this. If you wish to disable this feature, we’ve given you the new wakes-affect-height-queries setting in Resources/Triton.config. You can also adjust the fidelity of the simulation with wake-wave-generation-period; smaller values will simulate more waves for more accurate results, but at the cost of increased CPU consumption.

It’s also worth mentioning that just like the visual representation of Kelvin wakes, these simulated waves are also affected by the setting wake-kelvin-wave-scale. And, by default, that is set to 5.0. You may want to consider reducing that for more realistic wakes. We increased it based on customer feedback; they wanted them to be easier to see. But you can make your own tradeoffs there.

What’s next for Triton? Well, we are very, very close to releasing a beta version of Vulkan support for SilverLining. Depending on how that is received, Vulkan support for Triton may be in the cards as well. Stay tuned for more news on that front in 2024.