Ocean Renderer

Hi, Id just like to share a ocean rendering project Ive made. Its based on two existing (free) projects written in C/OpenGL and C/DirectX so its more of a port in some ways. Check out this link for project files and more info.

Edit - These projects are no longer available but similar ones can be found here.

It wasnt just a copy-paste exercise though. Some of the code is extremely complex and took quite a bit of work to get working in Unity.

The performance is quite poor at the moment as I'm running the fourier transfer algorithm on the CPU so this project will work for users of Unity free.

I plan on creating a version running it on the GPU for Unity Pro users where performance should make it practical.

This project is not complete and I plan on adding features like 'white cap' waves, foam, under water god rays and caustics. This could take a while though and will be a long term project.

 

Looks interesting, webplayer?

 

Yes, indeed it does look interesting. I will be watching how this progresses.

- Matt.

 

I'll keep my eye on this one, looks amazing so far.

 

Looks amazing! Will be looking out for this in future. Why just GPU for Pro Unity? Compute Shaders work perfectly in Indie.

Keep up the good work

 

Looks great! bookmarked

 

Looks pretty cool!

* subscribed*

 

To be honest i'm not entirely impressed, it rather looks more like blue wet cement..but thats just my opinion of course.
In saying thats its still early days and look forward to seeing the updates, its a great start as i know what a tedious task water development is.

Best of luck!

 

Wow looks good

Norby

 

Ta for feed back. It really helps with motivation to get some positive feed back.

Will try and set up a web player once I get the code optimised and a decent frame rate. Im probably doing everything the slowest possible way at the moment but it made setting the project up easier.

Did not know compute shaders are in indie? Will have to check that out. They require a SM5 GPU so may rule out some users.

Fair enough. It is a bit glossy. Those sorts of things can be adjusted in the material though. Its the movement of the water thats the hard part and I feel I have that correct. There no refraction at the moment and that would help give it a more 'watery' look.

 

Ok so Ive optimised the project and made some changes to the shader.

Ive got the frame rate from 14fps to 70fps on my computer. Mostly done through cutting down on the amount of data passed to the fourier transform function. Most of what was dropped was adding little to the final results. There was 3 textures containing the results, 4 height values in 4 channels and 4 slope values in 8 channels. So thats three RGBA textures. Ive cut that to 2 heights and 3 slopes meaning I cut pack all that into two RGBA textures. Each textuure had to have the fourier performed on it so just cutting out one was a big boost in performance.

The fourier transform has also been spread over 4 frames instead of doing it each frame. All these changes have caused a small drop in quality but its the only way something like this can be done via a script and not using the GPU.

Ive also moved the projection of the grid to the vertex program in the shader and this means I dont have to update the mesh every frame.

Turns out I had some bugs in the shader. Got a bit mixed up with the normals being in world space instead of tangent space. The cube map for the reflections of the sky wasnt being sampled correctly aswell.

The result is a much more realistic ocean.

Updated Project files can be found on blog.

The first image here is with the wireframe turned on but the image is a little to low res to see it correctly

 

Looks good, an FPS indicator would have been nice though.

 

Looks awesome, can't wait to see this when you have finished all the features and functionality .

 

looks cool but feels a little jittery

 

Yes slightly jittery/staggered and something about the motion of the water is not truly realistic - as if there are parts which rise up for no reason... but for an approximation it looks pretty dam nice.

 

Yes, both true. The jitter comes from the fact that the textures are only updated every 4 frame. Ive cut done on the number of textures used for the normals so there maybe a disconnection between the movement and how its looks.

Thats about the best I can do for Unity Indie I think. I think I might move every thing to the GPU.

 

Very nice, will have to give this a try!

 

Been working hard on this project and have made a few changes.

Ive mostly been working on moving everything to the GPU. I am 90% done but have come across a problem I am a bit stuck on so I dont know when this will be finished.

Ive updated the project file and web player for the indie version and links can be found in first post as normal

Changes include but not limited to....

- A general tidy up of code and added more commenting

- I had cut down on the number of textures written into from three to two but I have changed it back to three. This has had a effect on performance but Ive decided that doing the fourier from a script will never be practical for a professional program. I will simply perform the full algorithm so the CPU version is the same as the GPU version. This will make comparisons easy and people can always optimize anyway they see fit. Speaking of performance I get 60 fps on my computer but 40fps on the web player not sure whats up with that.

- I have fixed the issue with the waves in the distance 'wiggling' as the player moves. This is because the waves in the distance are sampled less often and results in a large difference in heights between adjacent verts. I fixed this by sampling at lower mipmap levels based on distance from camera. There is still some wiggling and I will work on this but you can adjust the settings to get the result you want.

- Added a fps indicator in the web player.

- Adjusted some of the settings for the waves to give a more visually pleasing result.

- Added specular highlights from the sun.

below is a image that some the suns specular reflection.

 

Looks OK i suppose, but its very heavy and drops my machine to 50 FPS (latest MBP from apple), and makes the controls/camera feel sluggish.

 

Just very jittery.

 

Impressive, very impressive. I'd love to see if you could par this down enough to work as part of a general package it would be outstanding.

Have you considered trying to lower the number of Tris? Pro Water for example doesn't seem to run nearly that dense.

 

Thanks for the feed back. Actually the grid is quite small. Its only 128 by 128 verts. It appears very dense by using a bit of a mathematical trick. This is what the projected grid concept is all about. Its not the reason for the poor performance. Thats due to the fourier transform being done via scripts on the CPU.

Speaking of which I have just got the code to run 100% on the GPU. Yay! Performance is much better, between 80 and 100 fps on my laptop and has solved most of the issues with jittering.

The bug I had was from the sqrt function in the shader. Looks like the GPU does not quite produce the same results as the CPU. Ive found I dont really need that part to be calculated every frame and can be precomputed into a look up table.

No web player for the Pro version at the moment. Cant seem to get it to work for some reason. The render textures are not being written into for some reason. Hopefully will solve that soon.

In the mean time you can download the project files for the Pro version from the link in the first post.

Next I think I will sort out some issues with the projected grid, add the ability for objects to float on the surface and start adding under water effects.

 

Wow, really impressive what you're accomplishing. Definitely will want to see your next update. What are your plans re: compatibility, will it be 4.x Pro only or will it work on Free and 3.x also?

 

Looking great, what are your plans for integrating support for waves?

 

Looking really nice, but performance wise there seems to be a discrepency - the webplayer is showing 30fps on my machine, but the actual motion of the waves seems to be running at about a quarter of that.

 

I was hoping to make a indie and pro version but its looking like the indie version will never be practical due to performance reasons. From here on I will only really be focusing on the Pro version and just leave the indie version as more of a demo as I havnt got the Pro working with the web player yet.

Not to sure what you mean but there are some settings that can be adjusted to give different sorts of waves. Theres wind speed, wave amp and wave decay factor. Adjusting these you can have calm lakes to rough ocean style waves.

The FPS is right its just that the wave generation for the indie version is spread over 4 frames to try and get it to run at a acceptable frame rate. So yes your right the waves are only running at a quarter of the frame rate. Hopefully I will have the Pro version running in the web player soon so people with only the indie version can get a feel for how its meant to look.

Thanks.

 

I can't seem to find any settings either. I assume they are not exposed in the editor then... I haven't dug through the code yet. None of the editor options actually seem to work though. Resolution doesn't do anything, Pressing F1 for Wireframe doesn't do anything. The Sun does work though.

The performance is way better than I was expecting. The example scene reports over 400FPS, but the stats say 2000-3000FPS, on a GTX 680 4GB.

With that said I am getting some kind of projection issue. It's not the near clipping of the camera, as its nowhere close to the water. Sometimes, the part of the wave closest to the camera will start appearing as if it's clipping on the bottom of the frame, and comes and goes as the wave swells. The same issue occurs on the sides of the screen, but only ever a pixel wide.

Are you going to work in buoyancy at some point? I think other implementations involve updating a collision layer for buoyancy, like a dampened form of the ocean waves.

Anyway, looks amazing so far. Great work!


Edit: It doesn't seem to work in Linear Space, under either Deferred/Forward or D3D9/D3D11.


Edit2: I uploaded a video to highlight some issues. Namely the clipping I discussed previously, but also the black specular artifacts when looking in the direction the waves are moving. The clipping is independent of camera height.

 

@jonwd7 -Thanks, you found a bug. Its F2 to toggle wireframe. I changed it from F1 for the the web player as I found that F1 opens up some menu in IE. I forgot to change the GUIText though. ta.

The resolution changes the mesh resoultion but it can be hard to see if you dont turn on the wireframe. Just make sure use max resolution is not enabled as it will override the resolution setting.

The wave settings are in the WaveSpectrumGPU.cs script. They are not exposed at the moment because they have a certain range of values and setting the wrong numbers will cause problems.

The clipping occurs when a large wave goes by and moves up into the cameras frustrum. As there is nothing under the water you see sky but when I add the under water effects this will go away. The clipping at the side is just a bit of noise, not sure whats causing at the moment.

Really? Thats amazing. Im guessing your using the pro version.

Buoyancy is on my to do list.

EDIT - just saw your edit , will look into that. What version are you talking about?

EDIT2 - OK, your right linear color space is not working. I have no idea why. I never even considered that. Will look into it. In the video I can see the black areas. Im not getting that on my card. Not sure way. I might know what that is though. As for the waves rising up into the clipping plane that is intended behaviour.

 

Regarding the other stuff, thanks for the info.

Ah, OK. I guess I will have to look a little more closely at the frustum. I just kept raising and raising the camera height, and it kept occurring, which told me it shouldn't be a clipping issue. I feel like the issue is that the mesh is getting generated on screen, but when the wave swells, additional geometry is not created to start filling up the gap between the frame and where the wave has moved to (if that makes any sense). Because as I understand it, there is not an actual mesh that exists off-screen, and thus when you project the geometry into the scene, and then deform it, it's going to create a gap. Because all the original vertices were determined from the screen position and shape, and when a wave moves up too high there is no actual geometry to fill in the wave that was off-screen before the swelling began.

Sorry if that's a rambly explanation, but I hope you get the gist. It seems to be the case to me.


Edit: Or, more simply, maybe however you project the surface into the scene is a bit "farsighted" if you will, in relation to the camera. Meaning it *should* be seeing some more geometry closest to the camera, but it's not for whatever reason.

Again I don't have a complete grasp on the details of the implementation. I had attempted messing with the near/far clip, the FOV, the position of the camera, and it always seems to crop up.

Edit: OK, so if I look at the frustum side-on, the camera can be nowhere near the surface, and there just seems to be a lack of "padding" to the geometry outside of the frustum. Because the wave would reach its peak, the padding geometry would be all "used up", continue raising, and expose the underneath of the water surface, even though from looking at the scene this would be impossible.

 

Sorry you lost me a little.

If I use the default near plane of 0.3 I only see the waves rising up into the camera when the player y pos is less than about 8. Any higher and I never see it which is how its meant to be. If you set the player y pos to a really high value (say 100) and you still see it its definitely a bug but Im just not seeing it my computer. I think I will make a video so we can compare results.

There is a setting on the ocean prefab called border that adds a border around the mesh to help prevent these issues. You should still see it when the near plane gets to close to the ocean so I wouldn't set it to high.

Ive still yet to finish the projected grid so it may well be a bug and there are some other issues Ive yet to solve.

Thanks anyway, I will look into it.

 

(Edit: See below) Yeah, like I said in my first post, neither border or resolution options actually do anything. I haven't yet delved in to see why. It's possible since the options aren't working, the value is becoming lower than it should be, hence seeing it so often. Anyway, it's definitely some kind of issue, regardless of Border options.

I put a cube directly in front of the camera, such that the top of the cube was in line with the horizon, I put it nearly completely in front of the frame, but left enough room as to see the ocean behind it. I took video:

As you can see the camera is far, far above the water, even when it swells. The cube is much closer to the camera than the water, yet when you see underneath the water, the water surface isn't even close to intersecting/submerging the cube. This means the camera is above the water at all times.

I increased the FOV to a more reasonable 75 for my aspect ratio, which does seem to make it occur far less often. I could take a screenshot from the editor, showing the cube, the frustum, and the water surface, to show you how incredibly far the camera is away from the water, but I think the video suffices.

TL;DR - To see under the water, you'd have to see the water surface intersect the cube, and also see water surface between the camera and the cube.


Edit: OK, so changes I had been making to resolution and border were not working because I was trying in real-time. And the values I set before playing were not noticeably different. For the most part it seems for any given border value, way more border is added to the sides of the frustum than the bottom, where the border is actually most important. Setting the border to a much higher value of 1-2 make the near-surface behave correctly under most circumstances. The default border had all kinds of issues when looking straight down while close to the water too.

Basically, you would assume at Border = 0, there would be no noticeable projection errors, anything higher would just be bonus padding.

 

Yer dont change the border or resolution when playing. That mesh is made on start and wont be updated. The border will always have less effect at the bottom because the waves lift up into the bottom of the screen. Dont set the border higher than about .2 as it stretches out the mesh and wastes resolution.

You can decrease the heights of the waves by decreasing the wind speed in the WaveSpectrumGP.cs script. Ocean waves are wind driven so a lower speed will make smaller waves.

Not true. The border setting is there for a reason. There needs to be at least some border or else you will have more issues with lifting.

Sorry but from what I see you are not that far form the ocean surface and the waves swell up to a high enough height to touch the bottom of the near plane every now and again. This is expected behaviour and to be honest I dont think I will be changing that.

 

I didn't say no border. I said that border = 0 should still cover the screen correctly under most circumstances. Any additional border would just be "padding". I was simply saying there isn't enough geometry being created underneath the frustum (bottom of screen) at any border value. Too much geometry is padded on the sides of the frustum, and not enough below.

Like I said, you can see clearly the water never intersects with the cube. The water is far below the camera. If the water surface was actually coming up high enough to see underwater, the cube would look submerged.

Anyway, I won't bother to argue the matter any further, but I still want to illustrate the issue more clearly because I don't think you're getting my point:

http://imgur.com/a/EKZil

- First image shows that height 5 (the default height) is in fact far above the water, yet the edge of the ocean geom comes into the frustum.
- Height 3 image shows that it cannot be a near clipping issue, because the box is both closer to the camera and closer to the edge of the frustum.
- The Height 1 images show what truly seeing underwater looks like.

You seem to be saying that the clipping in the other images is both normal and perfectly logical; that the camera would in fact see underwater in these situations, when it isn't the case. Again, you already gave the solution: Increase the border value. But at the same time you said anything higher than 0.2 is bad, when at Height 3 I still get incorrect clipping with border 0.2. So, my point: There is not enough geometry being created underneath the frustum.

 

Ahh ok. My apologies. Those images really make it easy to see the issue. I wasnt really sure what you were trying to do with the cube at first.

I was expecting some clipping but looks like its occurring when it should not be.

Im not 100% sure what the issue is and I will look into it. Ive still yet to implement some of the code for the projected grid and it may go away when I do that.

The border was only really designed to stop that happening around the sides. I dont think increasing it will solve the issue at the bottom of the screen and it maybe caused by other reasons.

You've spent quite I lot of time looking into this and it is appreciated.

Sorry for being so stubborn

 

This looks awesome, shame about it not performing too well on the indie version..

Saying that im getting a 50fps and my work PC only have an AMD Firepro V4800.. so its not that bad.

 

Ok, so some small but important changes.

I started adding the full implementation of the projected grid but the more I looked into it the more concerns I had. There are some camera angles that it does not handle well and I was worried that I would forever be plagued but issues if I stuck to this approach. There are pros and cons with every technique but the cons started to become a issue.

As a result I have switched with a more conventional radial grid. The quality of the waves are not quite as good but still look nice.
A radial grid also has a nice side effect of concentrating the verts close to the center. I have added a bias factor that can be used to control the distribution of the verts, pushing more towards the center if needed. At the moment its just one mesh so the number of verts is limited to 65000. This is not really a problem at the moment but I may add a feature to create a series of concentric radial grids for extra resolution.

I have also made some improvements to the performance of the indie version. I have simply cut done the fourier grid size to 64 from 128. I had tried this before but thought the quality of the results was not that good. That must have been with a previous shader though because the results look fine now.

I have also mentioned that the calculations for the indie version were staged over 4 frames but this isnt really need at a grid size of 64 so I have added the ability to enable and disable this. You can have better performance and a jittery look or no jittery and less performance. Choice is yours. Is disabled by default.

I have also exposed some of the settings in the ocean game object so they are easier to change instead of having to dig through the scripts. You can adjust the mesh resolution, mesh bias, wind speed, wave amp, wave decay factor and fourier grid size.

All these settings are used to initialized certain things on start so dont try and change them while the program is running as it will have no effect. In the future I will add the ability for the ocean conditions to change dynamically as weather conditions change but it requires that some calculations but recomputed and I need to look into the most optimal way to do this.

Below is a image of the radial grid as a wire frame (that may not show up)

EDIT - I just realized that changing wind speed, wave amp, wave decay factor settings for the Indie version may create waves that have a height outside the range of -1 or 1 and as the heights are packed into a 8 bit texture this will result in the waves height being clamped.

I recommend only changing these values slightly from there defaults.

 

Looking great, dynamic waves sound good. Look forward to trying out the changes.

 

I have added support form floating objects. The objects will rise and fall along the ocean surface as well tilt at a angle as waves go by. The indie and pro version handle it differently though.

For the indie version the data is all calculated on the CPU so getting access to the heights was easy. However once the data is packed of to the GPU in a 8 bit texture the heights can be clamp if the waves are to large meaning the heights calculated for floating objects may not match the drawn wave heights.
To solve this I simple restricted the size of the waves that can be created. The default settings I have been using are still the same so the project should still look the same and I think the waves are of decent size.

For the Pro version the data is calculated on the GPU and there is no good way to get it back to calculate the heights for floating objects on the CPU so Ive created a shader that displaces the verts by sampling the textures directly. This works fine but my not be suitable for all programs. The mesh will be displaced and tilted around its origin so you will to make sure the objects origin is the point where you want it to float on the ocean. This is the best way I can think of at the moment.

Ive updated the project files but not the web player. For some reason the web player has decided it does not want to build the project correctly any more, even when using the previous version that built fine before and hasnt been changed. Strange.

 

Nice, will try it out.

 

I want to be able to enter the water as realistically as possible, with a transition that looks something like the attached photo. Any way to do this?

http://www.hdwallpapersarena.com/wp-content/uploads/2012/07/ocean_life_wallpapers_001.jpg

 

Ive never tried to do this but I have a few ideas. I was thinking of doing the under water effect in a post effect shader. I will hopefully start work on under water effects such as scattering of light, caustics and god rays some time soon.

In the mean time Ive decided that I was a little unhappy with the quality of the ocean shader. I mentioned that this project was based on a openGL project by Eric Bruneton. In his project he used a BRDF lighting model. Ive decided to make a separate project that has this same BRDF lighting as well as his atmospheric scattering for the sky.

The quality of this shader is much better but it requires Unity Pro and a dx11 card. As usually links in the first post. Enjoy.

 

wow looks goooood
keep up de good work

Norby

 

Wow. Awesome work! I will play with it soon.

Regarding the previous black specularity issue, I just noticed the other day you had PMed me. The notifications on this forum are not very... noticeable. If you ever need me to try stuff out, look for bugs, etc. I'm more than happy to.

 

Thats ok. Thanks for pointing out the bugs. Some times when I spend so long working on a project I stop noticing some obvious issues.

 

Really awesome stuff, I stop by your blog from time to time to see what you're up to. I really admire people like yourself who are always learning and testing these things and sharing it with the rest of us, so just wanted to say thanks!

If I were to try this on a mobile device, would the CPU or GPU version likely run better (I'm getting a device to test on soon enough but was curious if you had any thoughts about which ought to perform better on a modern mobile device). Awesome work.

 

Is there any way to get a height of the water at a particular position in world space? If so maybe we can fake the buoyancy.

 

Check his other projects from his blog, he's already done this.

 

Thanks . I dont recommend trying to run either version on a mobile device. The device will probably slap you and then explode.
The CPU and GPU version would not run at a decent frame rate and the GPU version uses feature that are unlikely supported on mobile devices.

Yes, this has been address in the ocean surface effects project. Getting the height for the CPU version is simple as the data can be easily accessed but there is a issue will the heights not always matching the drawn height of the waves as there is some loss of precision when packing into a 8 bit texture.

Getting the heights on the GPU version is easy in a shader as they are in a texture but there is no practical way to get the heights from the CPU which is a bit of a problem. Any displacement for buoyancy is done in the vertex program of a shader which may not be practical for all situations. Its the best idea I have at the moment though.

 

Yeah I did see an example of buoyancy but what I saw was that he was just manipulating the buoyant objects mesh and not the actual rigidbody of an object. I'd like to try and use a buoyancy scrip found in the forums to apply a physics buoyancy model to a boat.

 

For some reasons it bugs heavily as soon as you get under 2.7 for wind speed
2.7:

Just under 2.7:

Way under :