Unreal Engine 4 sub sim project: Sub^3

nopoe · 09-26-14, 01:35 PM

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. 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

Krabb · 09-27-14, 06:15 AM

Hi, and welcome!

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.

Hawk66 · 09-27-14, 11:20 AM

nice library and all the best for your project!

tommo8993 · 09-27-14, 11:23 AM

sounds great, ill keep an aye on this

nopoe · 09-27-14, 11:49 AM

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.

Hawk66 · 09-27-14, 12:03 PM

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.

nopoe · 09-27-14, 12:19 PM

Quote:

Originally Posted by Hawk66

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.

09-26-14, 01:35 PM	#1
nopoe Swabbie Join Date: Sep 2014 Posts: 12 Downloads: 2 Uploads: 0	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. 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

09-27-14, 06:15 AM	#2
Krabb Navy Dude Join Date: Apr 2009 Posts: 172 Downloads: 32 Uploads: 0	Hi, and welcome! 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.

09-27-14, 11:20 AM	#3
Hawk66 Commodore Join Date: Sep 2006 Location: Germany Posts: 609 Downloads: 36 Uploads: 0	nice library and all the best for your project!

09-27-14, 11:23 AM	#4
tommo8993 Helmsman Join Date: May 2010 Posts: 104 Downloads: 17 Uploads: 0	sounds great, ill keep an aye on this

09-27-14, 12:03 PM	#6
Hawk66 Commodore Join Date: Sep 2006 Location: Germany Posts: 609 Downloads: 36 Uploads: 0	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.

09-28-14, 12:12 PM	#8
magicstix Captain Join Date: Aug 2011 Location: Nuclear submarine under the North Pole Posts: 481 Downloads: 1 Uploads: 0	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.