Quote:
|
Looks interesting. But why UE4 and USML? UE4 is very limited for a simulator, the area is limited to 20x20 km (if I'm not mistaken), it is slow, and I just don't like dotnet , and moreover, you have to link it with C++...
|
UE4's usual way of dealing with the fact that their world size is, quite frankly, tiny (5km by 5km or something) is world origin rebasing. But that doesn't help when you need to keep the entire world in memory because an anti-ship missile launched 100km away is still a threat. Additionally it gets really complicated when you are doing a multiplayer game.
The simplest way to deal with this issue, scaling down everything except the world, happened to work. I have the luxury of not having to simulate anything remotely small so I managed to scale everything down by 100x. I can now simulate worlds 500km by 500km across, which is much less limiting. I've tested the physics stability at the world edges and it seems exactly the same as the center, so I'm pleased with this solution.
I'm not sure what you mean by not liking .NET though. UE4 uses C# for its build system but that's about it. And linking with C++ is the primary advantage because it lets us use USML.
Regarding slowness, you're basically correct. UE4 is a heavyweight engine, but it made the most sense.
Quote:
|
And, in my opinion, USML is too heavy for a game (or perhaps I should say "real-time simulation" ). Also, consider the oceanographic data, I doubt you will find it for every point of every ocean, sea, etc. The whole idea of such perfect precision is questionable without it. I'm not even talking that acoustic equations are not perfect themselves. Add classified data on submarines, sensors, etc. to that.
|
Regarding USML's speed, you're also correct depending on the platform. It's really slow on windows, but it runs about 20x faster than realtime on Linux using a single core. If I gave USML 3 cores, it should theoretically be able to propagate 60 waves at once. It's not necessary to update the propagation losses for far away contacts as often, so that could potentially mean a lot of vessels. I'm working this weekend, but starting around Wednesday I'm going to look at changing the linear algebra backend to something that will let me take advantage of OpenCL devices. Hopefully that will let me get the bulk of the processing onto a GPU or at the very least allow me to use multiple cores with minimal work.
It currently uses uBLAS, which is apparently known for being slow, so even if it doesn't work on a GPU I'd expect the windows performance to meet or exceed the linux performance after I switch. If it
does work on the GPU it has the potential to make it all a non-issue.
The oceanographic data I have seems pretty solid, but USML has a built in way of interpolating between nearby data points if there's missing data.
As for why to use USML, the main reason is that it's one of the only pre-existing options out there that isn't in fortran. The alternative is writing my own sorta-correct-but-faster acoustic modeling library or not modeling acoustics at all and just basing detectability on distance, which I'm not interested in. I know for a fact I would never finish my own acoustics modelling project. I don't know enough math or physics.
In addition to that, I think having good acoustic modeling will make the game more fun. The aim isn't to make it extremely true-to-life necessarily, since as you said that's problematic due to classified information. I want a fun game and accurate acoustics is a part of that I think.