Gaming Creating an ocean exploration simulator

OK, I start to believe that a 1° x 1° terrain plot (About 110 x 104 km for Hawaii) is a bit huge. Also its pretty inaccurate since we would need to use custom terrain scale factors for the size of the terrain.

Either we reduce the terrain size, find a way to create our own terrain engine or we might need switch the basic game engine.
 
OK, I start to believe that a 1° x 1° terrain plot (About 110 x 104 km for Hawaii) is a bit huge. Also its pretty inaccurate since we would need to use custom terrain scale factors for the size of the terrain.

Either we reduce the terrain size, find a way to create our own terrain engine or we might need switch the basic game engine.

Can we not dynamically change the terrain under the sub as we move?
 
Also its pretty inaccurate since we would need to use custom terrain scale factors for the size of the terrain.

Could you elaborate on this?

For me, the limiting factors are horizontal resolution (this is 3 arcsec DEM, we can switch to 1 arcsec DEM, but that's the best NOAA has) and vertical resolution (limited by both DEM resolution and the way we encode data in RAW16 --- this is 10cm currently).

I can of course cut the DEMs into tiles of any size, just tell me what you need.

By the way, we should somehow address the fact that the Earth is spherical. I was lazy and just used Mercator projection for now. For Hawaii it's not really a problem, but as we go closer to the poles...

---------- Post added at 11:01 PM ---------- Previous post was at 10:54 PM ----------

Yeah, but what alternative would we have besides handling it ourselves

Potential link of interest:

http://kerbalspace.tumblr.com/post/16228007762/the-story-of-ksp-ksp-0-1

in it Harvester mentions something about the way they implemented dynamic terrains in ksp early on

Also:

http://kerbalspace.tumblr.com/post/16291223741/the-story-of-ksp-ksp-0-2
http://kerbalspace.tumblr.com/post/17827181033/the-story-of-ksp-ksp-0-4
 
Could you elaborate on this?

Right now, a 100 x 100 km terrain is approaching the limits of the Unity engine, a smaller terrain would mean less trouble there.

Also, you are converting polar coordinates into flat Cartesian coordinates in Unity, the projection is distorted anyway.
 
There is a unity export to OBJ script for terrain. One could make the heightmap terrain in unity and and join terrain meshes together in a different program if that is helpful.
 
https://github.com/BruceJohnJennerLawso/Diver/commit/b941c02e2ca986f4447df8aafb4cbb0b388cc0b8
I've implemented the drag equation. Still assuming things are spheres. Also drag is only applied when the object is fully submersed, as that's the conditions for the drag equation.
I also added a backplane to the water in my test scene so you can see the surface from beneath it, and a simple UI for slightly adjusting the ballast tanks in my test sub.
Can anyone think of anything else that needs to be in our MVP physics engine?
 
Urwumpe, I did a little bit of work on the 'test scene' scene in the develop branch, which I think is your area. Is it okay to push that or will it break things on your end?

I got some basic physics working and the DSR1 now collides with the terrain mesh properly. Once I can integrate the buoyancy script that jango implemented, it should be reasonably nice to play with.

I see your shader for the water surface in the project, should it be visible on camera yet?
 
Urwumpe, I did a little bit of work on the 'test scene' scene in the develop branch, which I think is your area. Is it okay to push that or will it break things on your end?

I got some basic physics working and the DSR1 now collides with the terrain mesh properly. Once I can integrate the buoyancy script that jango implemented, it should be reasonably nice to play with.

I see your shader for the water surface in the project, should it be visible on camera yet?

Is no problem. I am not sure if I can ever get the shader working like I want to in Unity Free, since RenderToTexture is not supported. I think I will look at other construction sites first and then return to it, once I have a working solution.

But this weekend, I had other priorities with the release of Medieval Engineers. :lol:
 
Here's a thesis on supercavitation, useful info on drag and the shape of a the cavitation cavity in the literature survey (pgs 3-4).

https://www.aem.umn.edu/research/supercavitation/documents/Schauer%20Thesis.pdf

Here is an excellent compendium on supercavitation by NATO RTO.

http://ftp.rta.nato.int/public//PubFullText/RTO/EN/RTO-EN-010///EN-010-$$ALL.pdf

The drag correlations look relatively easy, assuming you have a blunt object inciting the cavitation. The hard part will be dealing with the loss of buoyancy. The object will be immersed in a vapor bubble, not water, so the buoyant force will be small. Small hydroplanes would need to be extended to provide a lift force.

To simplify things, you might just want to modify the drag force using the cavitation expressions, and just use a buoyant force calculated assuming that the object is in liquid water. That would basically mimic any asymmetric lift forces you would have to exert to stay in the gas bubble without all of the complexity.

Correlations also are available for the size and shape of the bubble cavity which can be fed to the eye-candy generator.
 
Last edited:
Is no problem. I am not sure if I can ever get the shader working like I want to in Unity Free, since RenderToTexture is not supported. I think I will look at other construction sites first and then return to it, once I have a working solution.

But this weekend, I had other priorities with the release of Medieval Engineers. :lol:

I made the push yesterday, can you double check to make sure it doesnt break anything on Your end?
 
I made the push yesterday, can you double check to make sure it doesnt break anything on Your end?

Checked back with the few changes that I had... had a conflict here in a unity file, that I had to fix by ignoring my local changes... had been mostly experimenting here anyway.
 
Checked back with the few changes that I had... had a conflict here in a unity file, that I had to fix by ignoring my local changes... had been mostly experimenting here anyway.

Nothing serious broken though?

I was thinking the next step will be to copy over the buoyancy script and get it to add a force to the vessel in question, at which point the player can then muck about as they see fit. After that, the camera needs to be modified so that it doesnt rotate with the user, and then we will at least have our first steps for the project completed.
 
Nothing serious broken though?

I was thinking the next step will be to copy over the buoyancy script and get it to add a force to the vessel in question, at which point the player can then muck about as they see fit. After that, the camera needs to be modified so that it doesnt rotate with the user, and then we will at least have our first steps for the project completed.

Not yet... but then, we should find a way to avoid conflicts. Like somebody works on the scenes and somebody else creates the scripts.
 
Not yet... but then, we should find a way to avoid conflicts. Like somebody works on the scenes and somebody else creates the scripts.

Ahh... yeah, I honestly dont know. I was able to write some decent stuff fairly quickly in C#, but my actual understanding of the language itself is very limited (everything seems to be an object???). But if you need a script duct taped together to do something fast, like the buoyancy script adding a force, I can do that. Can we take stock of how much C# everyone knows so that we have a rough idea of who should handle what?

Is there some way of jumping between multiple scenes by calling a script command or something?

To be honest... Unity is not bad, but I feel like it lends itself extremely well to certain types of projects, and very poorly to others. KSP seems like it must have been hell to build like this... but its still very early, so I will hold off on passing judgement. The things I am confused about are things like how do we store the position of a ship relative to the entire planet (assuming a unity scene position of an object will be too small to store the precision we need, which I think it will)
 
To be honest... Unity is not bad, but I feel like it lends itself extremely well to certain types of projects, and very poorly to others. KSP seems like it must have been hell to build like this... but its still very early, so I will hold off on passing judgement. The things I am confused about are things like how do we store the position of a ship relative to the entire planet (assuming a unity scene position of an object will be too small to store the precision we need, which I think it will)

I agree there, I am always one inch away from writing my own game engine for such kind of games, especially because of the technical limitations of Unity free.

But then... Its better than nothing at all and nothing is what I have right now.

I just think that the unity files themselves (other than the scripts) are very hard to resolve conflicts in, so getting conflicts there should be a good idea.

But no problem with small conflicts in scripts. But no conflicts at all are the best.
 
Back
Top