View Full Version : Unreal Engine 4 sub sim project: Sub^3
Hi everybody,
I recently started working on a project with a friend of mine we're calling Sub^3. We're going to try to make it into a modern version of 688(I) Hunter/Killer.
This project mostly began out of frustration with current sub sims. Specifically, we’re bothered by the fact that the acoustic models kind of suck. There’s a good reason for that in the case of the earlier ones (computing power), but I think that a modern sub sim should really have accurate acoustics.
We’re going to be using a library called USML (Under Sea Modeling library) for our acoustic modeling. It should be suitable for what we want to do. Here’s an image generated by a similar algorithm to show you how awesome they are. They're really hard on the CPU, unfortunately. I have yet to figure out what the minimum requirements are or if I can take advantage of multiple cores, but I expect you will need a modern desktop to run the game. http://oalib.hlsresearch.com/Rays/TLray.jpg
Another issue with using these libraries is that you need a lot of oceanographic data to take advantage of them, so you should also expect a big download (it's already >2.7gb uncompressed). I really dislike high system requirements so I'll do my best to keep everything under control, but my #1 priority is making the best submarine simulator I can, so if it makes sense these requirements could go up.
The main reason for using Unreal Engine 4 is so that we'll actually be able to finish the project. Ogre3d, SDL/OpenGL and various other options were considered. but we ultimately decided UE4 was the only option that let us link with USML (which is written in C++) and would also give us a chance to finish the project. We wouldn't have a chance without extra help otherwise. A lot of work is done for us thanks to UE4, especially in the graphics and networking areas.
Sub^3 is open-source. Unfortunately it's against the Unreal EULA to GPL your projects so we're using the 2-clause BSD license. Here's a link to what we have so far. (https://github.com/nopoe/Sub3) We'll upload builds when we get something playable.
Right now you can't actually pilot a submarine, but the physics simulations and control loops are working or close to working. In the near future we'll be working on a navigation interface, integrating USML and getting passive sonar working. After that we'll probably start on getting torpedoes working. This project aims to have multiplayer support in the first playable release. The main rationale for that is that writing good submarine AI seems like a really difficult thing to do compared to finding somebody to play with and setting up Hamachi.
One thing we’ll probably need from the community though is the ability to ask questions about submarines so we can understand them well enough to model them in a believable way. Would it be ok to put questions in this thread or is there a better place to do that?
Cheers!
nopoe
Hi, and welcome! :salute:
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++...
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.
nice library and all the best for your project!
tommo8993
09-27-14, 11:23 AM
sounds great, ill keep an aye on this :)
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.
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.
Is that sound engine not more or less a bunch of functions, that is does it really need to be tightly integrated into your application?
In my cold war sub sim project I've currently implemented my own engine, but it is pretty rudimentary...so I might later have a look . It is in .NET, so writing a c++ bridge would be an option....I think there are tools available to autogenerate wrapper.
And concerning .NET....if you have programmed with that framework and its rich set of languages, you do not wanna go back.....it is so 'easy' to write code, running on multi-cores.
Is that sound engine not more or less a bunch of functions, that is does it really need to be tightly integrated into your application?
In my cold war sub sim project I've currently implemented my own engine, but it is pretty rudimentary...so I might later have a look . It is in .NET, so writing a c++ bridge would be an option....I think there are tools available to autogenerate wrapper.
And concerning .NET....if you have programmed with that framework and its rich set of languages, you do not wanna go back.....it is so 'easy' to write code, running on multi-cores.
You should be able to write a wrapper for it pretty easily. If I manage to speed it up at all I'll push it to my github and let you know so you can use my version as well. Also if you have trouble building it on windows that you can't figure out feel free to send me an email (listed on my github page). It's not exactly trivial but definitely possible.
This page should list what you need to know: http://oalib.hlsresearch.com/Rays/USML/usml_frontpage
I'm a fan of C#, but for a game I like having most of the work already done for me, which is why UE4 made the most sense. Unity was the other option, but I if I could choose between having to write a wrapper and not having a source license for my engine or not having to write a wrapper and having a source license for my engine, I'm going to pick the latter. :)
magicstix
09-28-14, 12:12 PM
USML is not designed to run "real-time," though in your case what this means depends on how you're using it.
If you're just using it to control how bright lines are on your sonar display, you should be OK with it producing results every few seconds.
If you're trying to use it to generate actual acoustics (sound), you'll definitely run into problems. For one, it's designed to give more of a qualitative overview of the ocean environment, so it doesn't necessarily provide the kind of detail you'll need to generate the actual sound you'd hear. The fact that it is also slow means it'll be very difficult to generate acoustics without extensive interpolation/extrapolation of the model's output.
Using the eigenrays will pose a big challenge to you as well. Expect the model to generate thousands of eigenrays for a single point-to-point run. How you use those eigenrays will dramatically affect the overall presentation of the ocean, and will be important especially for how multipath effects show up.
Aktungbby
09-28-14, 12:37 PM
nopoe!:Kaleun_Salute:
USML is not designed to run "real-time," though in your case what this means depends on how you're using it.
If you're just using it to control how bright lines are on your sonar display, you should be OK with it producing results every few seconds.
If you're trying to use it to generate actual acoustics (sound), you'll definitely run into problems. For one, it's designed to give more of a qualitative overview of the ocean environment, so it doesn't necessarily provide the kind of detail you'll need to generate the actual sound you'd hear. The fact that it is also slow means it'll be very difficult to generate acoustics without extensive interpolation/extrapolation of the model's output.
Using the eigenrays will pose a big challenge to you as well. Expect the model to generate thousands of eigenrays for a single point-to-point run. How you use those eigenrays will dramatically affect the overall presentation of the ocean, and will be important especially for how multipath effects show up.
Yeah, I know it's not a real-time modeling engine, but I think I'll probably be ok. As far as I can tell from the unit test code, it gives you a bunch of propagation losses for the frequencies you propagate. I'm going to propagate a frequency vector and store the propagation losses and approximate travel times on a per-vessel basis. Then the USML worker thread will move on to modeling another vessel's sound. Meanwhile the sonar display will iterate through all vessels taking the most recent propagation loss and then use that, combined with the amount of sound the contact was making in each frequency band n seconds ago to find the "brightness" of the line on the broadband display, where n is the travel time. So if the other vessel makes a ton of noise for a split second, you'll still hear it even if there was no wave propagation happening during that time.
From my tests on Linux I think this is pretty doable real-time on a fast, modern quad core as long as you don't need to update propagation losses too fast and you have a reasonable number of vessels nearby. I've been testing with the malta-movie unit test as my benchmark, which (I think) uses eigenrays so I should be fine.
On Linux it took 4 seconds or so to finish the malta-movie unit test, which included time to load the bathymetry and temperature data from disk (though I removed the saving of the netcdf data). The test itself propagates a wavefront with 90 individual rays for 60 simulated seconds. If you say the average contact distance is going to be 60 seconds away, that means you can update one contact's propagation losses every 4 seconds using one core. Using multiple independent USML worker threads (assuming I can set that up) you can average an update frequency 1/n where n is the number of vessels.
With 20 vessels, which seems like a lot to me, that's one update every 20 seconds. 20 seconds seems like a very long period of time to go without updating propagation losses, but keep in mind the sonar display will still track the sound they've been making during that time. Additionally, that's for contacts that are almost 50 nautical miles away. Even if the two contacts are racing towards each other at 30 knots each they're barely going to cover 600 meters in that time. To put that in perspective, 600m is 0.6% of the total seperation, roughly. That's not going to change their acoustic situation that much. Sound from contacts closer to the sonar array will require (approximately) proportionally less time to propagate. From what I can tell, the complexity per timestep really depends on what the rays are doing in the ocean, but roughly speaking the closer contacts can be updated more frequently.
I'm by no means an expert on submarines, computational acoustics or anything else that this project involves, but I do think I did the benchmarks and the math right.
Like I said, though, it's too slow on windows. Way too slow. And I think OpenCL is probably the wrong choice because there's a lot of overhead associated with it, so I'm currently looking at Eigen as an alternative.
The current status is that most of the stuff in the "ublas" subdirectory is rewritten to use Eigen and I've started moving the rest of the library over. I'm currently puzzling as to how to best handle the seq_vector class. I know it's a pretty big undertaking and stuff, but the project is dead already otherwise so it's worth a shot. If I do get it working I think performance should be as good or better on windows as it was on linux with uBLAS. That's not a small "if" though. It would be really nice if visual studio had better performance...
Jimbuna
09-29-14, 05:38 AM
Welcome to SubSim nopoe :sunny:
ReallyDedPoet
09-29-14, 07:31 AM
Welcome to SUBSIM nopoe :sunny:
Technical details on what I managed to accomplish:
While poking around in the USML codebase I figured out there are faster but more approximate ways to do some of the things that I was doing, so using those I managed to get the average time between updates down to 0.7 seconds per contact at 20nm spread across all cores. Instead of replacing the linear algebra library, I decided to eliminate one very expensive matrix operation and replace it with a bunch of individual scalar operations. That brought computation time per contact down to 0.5 seconds. I'm thinking that's adequate.
These computation times are calculated based on the average time for 4 separate benchmarks to run to completion divided by 4. There's a little more to it than that, but it's important to note a single computation actually takes around 2 seconds, but there are 4 happening at once so you'll get one update every 0.5 seconds on average.
So now all that remains is creating the actual game. :)
magicstix
10-04-14, 11:12 AM
So now all that remains is creating the actual game. :)
That's a very important point. Usually what I see sinking hobbyist projects like these is focusing on the wrong things too early. Yes, it's good and cool to have a super accurate acoustics model that makes former sub sailors think they're at sea, but if you spend all your time on that early and burn out, where's the rest of the game?
The best thing to do is focus on the fundamentals early on. Get your entity system done, get your network communications done, get a game going before adding the flash and bling. Don't worry about the ocean modeling until you have a sonar display, use 20 log R propagation and get dots stacking on your simulated broadband waterfall first. Playability beats pretty any day.
That's a very important point. Usually what I see sinking hobbyist projects like these is focusing on the wrong things too early. Yes, it's good and cool to have a super accurate acoustics model that makes former sub sailors think they're at sea, but if you spend all your time on that early and burn out, where's the rest of the game?
The best thing to do is focus on the fundamentals early on. Get your entity system done, get your network communications done, get a game going before adding the flash and bling. Don't worry about the ocean modeling until you have a sonar display, use 20 log R propagation and get dots stacking on your simulated broadband waterfall first. Playability beats pretty any day.
All I was doing is making sure my goal was possible. I'd hate to get something playable without an acoustics model and then realize I was going to need to model all the acoustics myself because the libraries out there weren't fast enough. I simply do not know enough math or physics for that, and it would permanently stall release unless somebody else stepped in and did it for me (unlikely, but it's open source so it could happen). I'd hate to get to that point after a few months of work or more. It's much better to assess all risks up front, especially the ones that have the potential to prevent the project from becoming what I want it to.
Like I said in the original post, we're using Unreal Engine so it already has an entity-component system and the networking code is written for me. I just need to use some preprocessor macros before variables and the engine takes care of the rest.
I've properly finished a few hobby projects before, so I totally understand what you're trying to convey, but benchmarking USML made sense for me. I don't want to make something that isn't as good as what's already available, because then nobody would have any reason to play it.
Unfortunately my graphics card died on me today so I'll need to take a break from the project for however long it takes to get it RMA'd. Maybe a week or two. The unreal engine editor doesn't run on integrated graphics.
TheGeoff
12-06-14, 07:51 AM
Very interesting!
When I started implementing sonar / acoustics modelling in my sim, I spoke to a couple of ex-submariners, did some research and basically found that truly accurate simulation of underwater acoustics would be almost impossible - there are just too many factors to consider. The temperature of the water, turbulence, currents, the material of the seabed (rock, sand, silt), the frequencies of the sounds involved, and so on... I coded my own fairly simple, abstracted model in the end.
I'm extremely interested to see what you come up with - you're clearly taking a far more mathematical approach, and making use of some pretty powerful libraries. Best of luck, this is definitely a project to watch!
magicstix
12-09-14, 11:02 PM
Very interesting!
When I started implementing sonar / acoustics modelling in my sim, I spoke to a couple of ex-submariners, did some research and basically found that truly accurate simulation of underwater acoustics would be almost impossible - there are just too many factors to consider. The temperature of the water, turbulence, currents, the material of the seabed (rock, sand, silt), the frequencies of the sounds involved, and so on... I coded my own fairly simple, abstracted model in the end.
I'm extremely interested to see what you come up with - you're clearly taking a far more mathematical approach, and making use of some pretty powerful libraries. Best of luck, this is definitely a project to watch!
It's not impossible; it just takes a lot of computing horsepower. The only model accurate at all frequencies is essentially a finite difference model that marches out in range. A lot of simplifications of acoustic propagation have been made to speed things up, but they only work in certain environments. The biggest problem is low frequencies and high frequencies behave very differently.
zachanscom
12-10-14, 02:48 AM
ocean physics and visuals is far more important. i think the good old feeling of sh3 crashing an rocking in rough seas is a must even in a modern sub sim
magicstix
12-10-14, 08:38 AM
ocean physics and visuals is far more important. i think the good old feeling of sh3 crashing an rocking in rough seas is a must even in a modern sub sim
I disagree. Considering modern subs rarely use visual sensors like the periscope, realistic acoustics and sonar are the most important parts in a modern subsim, IMO.
Julhelm
12-14-14, 07:19 AM
I disagree. Considering modern subs rarely use visual sensors like the periscope, realistic acoustics and sonar are the most important parts in a modern subsim, IMO.
There's a reason the Sonalysts games didn't do very well and that's because they just look boring to anyone who isn't a hardcore nuke enthusiast. If you want to base your game around a waterfall sonar display don't expect it to shift a lot of copies.
magicstix
12-22-14, 05:04 PM
There's a reason the Sonalysts games didn't do very well and that's because they just look boring to anyone who isn't a hardcore nuke enthusiast. If you want to base your game around a waterfall sonar display don't expect it to shift a lot of copies.
Financially, DW was a success, however, I'd say the reason Sonalyst sims did poorly is because:
A.) They didn't do much to advance the state of the art since Jane's 688i and had poor realism.
B.) They all had a terrible mission editor.
C.) They all had lackluster campaigns that did not change at all based on the player's inputs.
D.) They all had terrible multiplayer, even DW, which came out in 2004.
E.) Because of D, it was easy for the player to quickly become overwhelmed with all the stations that had to be managed, even with autocrew.
Julhelm
12-23-14, 11:33 AM
Financially, DW was a success
What do you base that on? I remember there was talk of official Sonalysts addons for the game, but those never materialized. Thus it stands to reason the game didn't do very well.
magicstix
12-23-14, 02:22 PM
What do you base that on? I remember there was talk of official Sonalysts addons for the game, but those never materialized. Thus it stands to reason the game didn't do very well.
The lack of addons doesn't mean it wasn't a success, it just means Sonalysts didn't want to spend the money.
First and foremost, Sonalysts isn't a gaming company; they're a beltway bandit offering analyst services to the US Navy. They probably decided it was better to focus their efforts on their core business than releasing toy games.
zachanscom
01-23-15, 02:46 PM
there's no doubt visuals are important, not just for financial reasons, but for visualizing player sub interaction, as well as interaction with environment. with the ue4, there is a possibility to see pbr lighting bring to life the akula in stunning fidelity as it breaches the surface, water glistening and dripping off the hull.
with the talk of high fidelity acoustics, this combination can revive the sub sim genre like star citizens revived the space sim genre. and then you'll see hanger ons try to capitalize off the new insurgence.
with a dcs-like vehicle detail system, i wouldn't mind if there's only a single playable sub at first.
I've been hammered by school for a while now, but I'm looking at putting some time into this again. USML has been under active development this whole time and they had a 1.0 release. My priorities have changed a bit since I last worked on this though. Frankly, UE4's 2d rendering is really awful, and getting it to play nice with NetCDF and USML was really hard and I'm not sure it even worked (can't remember). UE4 would give us really nice 3d rendering, but I'm wondering if that even matters that much if the 2d rendering is terible and the interface is clunky. We were also having lots of issues with the size of the world since UE4's physics engine was designed for small worlds and small players. My current plan is to abandon UE4 and build something around USML and SFML. The major tradeoff here is that I abandon all physics and networking code that I got with UE4 for free. At first glance that sounds like a huge tradeoff, but honestly I think those two will be way easier than they might sound (and sounded to me when I started this project). Networking won't need any client-side prediction or latency compensation and physics can be "you touch something you die" with everything modeled as a capsule at first. Eventually I'm hoping for something a little better.
So what are the benefits of ditching Unreal? There are a few. Most of them boil down to "UE4 wasn't meant for naval simulations". The physics engine can't handle large worlds, or the curvature of the earth. 2d rendering is lacking, etc. Bottom line is that I don't think it can do everything I'd like. So the vision now is a multiplayer sub/ship sim with high-fidelity acoustics, an arbitrary number of players per vessel and an unlimited world size. USML does all its math in spherical coordinates, so might as well cash in on that and ditch the concept of a fixed battlefield size. I think it would be neat to let people work together to control areas of an ocean or stage large battles.
Also to be clear, this is the biggest project I've ever attempted (though not by too much) and there's a very good chance it won't be finished. It'll depend a lot on work and school schedules, as well as motivation. Hopefully I'll have something neat to show everybody by the end of this summer.
vBulletin® v3.8.11, Copyright ©2000-2024, vBulletin Solutions Inc.