• Advertisement
Sign in to follow this  

Semi-realistic Ocean

This topic is 3580 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm trying to make a fairly realistic looking ocean without using too much processing power. There's a little video of what I'm doing at the moment here: http://www.youtube.com/watch?v=9Et8tTC3JsM It's basically using a sine wave equation to generate the wave movement. I hit a smooth 60fps (fraps dropped the frame rate in the video) doing this over a fairly small area of water. I'm wondering has anyone got better suggestions on wave generation and are there any possible methods for creating waves over large areas of water? Thanks.

Share this post


Link to post
Share on other sites
Advertisement
I'm sure you've heard of perlin noise. Generate textures that hold the perlin noise pattern. (make sure it's tileable perlin noise) and see if that gives what you want. Also I'm just guessing but if you put land points along the shoreline you can perform sine wave offset going towards shore on the water heightmap to get a simple shoreline effect.

Share this post


Link to post
Share on other sites
Yeah I undestand the suggestion of perlin noise but I don't know how you can render such vast amounts of vertices. Here's an example of what I mean:
http://www.inrebellion.com/gamesprog/ocean.jpg
I'm relatively new to this. How do you do something like that?

Share this post


Link to post
Share on other sites
Have you tried breaking the ocean into sub-meshes? If you break them up into smaller pieces you can then calculate a bounding box and test each box against the camera's view. If you get a "collision" then render it otherwise skip that sub-grid. I'm running into a similar problem. The other thought I had is to transform the smaller ocean out in front of the camera as opposed to rendering the entire "map".

Share this post


Link to post
Share on other sites
Well at the moment my ocean only renders what's in the camera's view so unnecessary ocean doesn't get rendered. However if you look at the ocean screenshot from another person's project the amount of triangles that are being rendered and manipulated (moved up and down) is very high. I want to know how it's possible to render and manipulate that many?

Share this post


Link to post
Share on other sites
post the code of how you render the ocean. I don't do 3D programming, but normally you batch the vertices when rendering. Just wanna make sure your not drawing the triangles individually like with some OpenGL GL_TRIANGLES or something. It's been a while since I've used any graphics APIs.

Share this post


Link to post
Share on other sites
Quote:
Original post by PeteD
However if you look at the ocean screenshot from another person's project the amount of triangles that are being rendered and manipulated (moved up and down) is very high. I want to know how it's possible to render and manipulate that many?

To manipulate those huge numbers of triangles it's best to do it using a vertex shader (on the GPU) rather than on the CPU.

Share this post


Link to post
Share on other sites
There is an article in the Gamasutra about Deep-Water Animation and Rendering. Also there are some chapters in the GPU Gems series. You can take a look of them.

Share this post


Link to post
Share on other sites
http://graphics.cs.lth.se/theses/projects/projgrid/ gives some nice results for rendering water with a high vertex count

Share this post


Link to post
Share on other sites
One thing to consider is that you also don't have to actually render all the detail. You can use bumpmapping to add detail to the waves, without actually having to incrase the complexity. I don't think that Ogre screenshot is actually renderng all those small triangles for the waves (if you look, they are uniform like a flat plane along the ground), it looks more like it's animating the larger triangles per vertex (for actual depth in the scene), then applying a bumpmap to add the minute details.

Share this post


Link to post
Share on other sites
There is also an article right here on gamedev :o

I'm using pretty much what it says with very nice results, and I only use a single plane for all of my ocean, but the pixel shader does a lot of work though.

http://www.gamedev.net/reference/articles/article2138.asp

Share this post


Link to post
Share on other sites
Quote:
Original post by PeteD
but I don't know how you can render such vast amounts of vertices. Here's an example of what I mean: http://www.inrebellion.com/gamesprog/ocean.jpg
I'm relatively new to this. How do you do something like that?


First of all, that screenshot`s statistics shows it renders just 150k tris per frame.
That was possible in smooth framerates already in the era of GF2, which is almost 10 years ago.

These days, even with 3-yrs old HW (GF7-series) you can easily have 2M tris per frame, yet still achieve smooth framerates. Yesterday, I`ve been playing with my terrain renderer and when I cranked the detail to full, I`ve had 5.5M tris at 20 fps on GF7 - meaning you can get up to 10M tris per second very easy, even with 5 texture stages/huge textures, variously blended.


Sure, 150k tris could make your computer crawl down. But frankly, does your 10-years old computer (most probably sth like 400 MHz Celeron with TNT2) still work ? I have yet to see a HDD work for more than 4 yrs of daily use.


Back to the issue. So, you want to get maximum out of your renderer ? Basic beginner`s tips could include:

- Use indexed rendering - it`s the only way to get the cache work for you and get vertices for free - i.e. your vertex shader is executed less times then is the amount of vertices to be transformed. But only if you use indexed triangle lists, not triangle strips.
If you`re good with ordering, you can get the ratio of transforms vs number of vertices into range 0.51-0.59, whereas with tri-strips it`ll always be asymptotically close to 1.00

- don`t abuse the Indexing. Using same Vertex Buffer with separate Index Buffers for far-away LOD is ineffective since you`re rendering maybe 5% of triangles of that VB, but actually all get transformed. So, make a compromise and use few sets of VBs and IBs so that you don`t needlessly transform the vertices that aren`t visible in the end.

- don`t abuse vertex streams, try to bend the functionality the other way around and into as little number of streams as possible, preferably 3 or less

- cache alignment - compress your vertex data so they align at multiples of 16/32! Floats are one of the most space-redundant type that could be used for terrain rendering ! 12 Bytes per vertex position or normal ? 3 Bytes are more than enough for most uses and if you`re clever and use bit compression, 2 bytes might be enough for many scenarios, since you can usually find spare bits here and there in other Vertex data. Those few more decompression instructions inside Vertex Shader don`t cut the framerate so much as the cache non-alignment does. Plus, there are many cases, where you can get 50% space compression for free - i.e. no additional instructions - it can get decompressed for free when you`re setting the output registers. And that`s not a bad deal for 50% reduction ;-)

- always profile ! Make sure nothing else is occupying your CPU (AI. game logic/whatever) or GPU. That way you can easily spot if you`re using too much bandwidth for pixel operations or not - meaning make texturing switchable on/off with a press of a single key so you can instantly see if your pixel operations aren`t killing the framerate too early.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement