OSG Ocean - Have you seen!?


25-11-2009 15:39:12

The OpenSceneGraph community have release an an ocean renderer. The author also mentions Hydrax.

http://forum.openscenegraph.org/viewtop ... 89&start=0

Let the Ocean wars begin :lol:


26-11-2009 16:44:12

Wow, very good underwater system!
And good to know that serious people knows about Hydrax :)

I've some surprises for you with Hydrax 0.6(One of them, new underwater rendering system), but it'll have to wait some months!


edit: We'll win the war! ;)


26-11-2009 17:33:48

edit: We'll win the war! ;)

Good to hear it!!

Slightly off topic but....

I really really want to use Hydrax but there are a few things that are stopping me at the moment,
1) performance
2) multiple camera capability

Now i certainly dont expect you to implement/fix any of those because i asked nicely :) But would you mind if i gave those two things a bash?? I have been reading through your code and i am getting to grips with parts of it but not the whole thing... would you mind outlining the steps taken to actually create Hydrax (only the overwater rendering, not bothered about underwater rendering yet!)

I was going to create a new noise module using FFTW, but i am not sure how that should work with a projected grid. i have no idea how i was going to go about doing the multi camera thing, well alteast do with an acceptable framerate :wink:


27-11-2009 17:12:50

Right,performance is necessary,so Xavyiy please consider it,we really need some optimization,
so please do it :)


29-11-2009 02:23:05

As I see a lop of people talk about Hydrax performance, so I'm going to talk about it:

First of all, performance problems in water rendering are basically two: GPU and CPU.

First of all, Hydrax has optimiced shaders: SM 2.0 capable, one pass per material, on-the-fly shader programs generation depending of selected components(so shaders haven't any kind of boolean conditions inside), materials parameters are only updated if needed, etc.
But anyway, a big water surface needs some GPU resources. The big problem here is the need of render the scene for two, three or four times, depending of selected components.
For example: Hydrax will always render the shame scene for two times in order to obtain the Reflection and Refraction texture maps and, this means that if your scene has high-poly meshes, you'll need seriously starting to consider using low-poly models with some kind of normal/parallax mapping instead of high-poly models.
But if you really want beautiful effects, such as depth and caustics, the shame scene must be rendered for another time to create the scene depth map. And... if finally you're underwater and god-rays objects intersections are enabled you'll need another RTT, wich means...:
- Only reflection and refraction effects: 3 renders per frame (Reflection, refraction, main viewport)
- Reflection, refraction and depth/caustics: 3 renders per frame (Reflection, refraction, depth, main viewport)
- Reflection, refraction, depth/caustics, underwater advanced effects: 4 renders per frame (Reflection, refraction, depth, underwater good-rays, main viewport)

So... in a "standar" configuration (Reflection, refraction, depth/caustics) the main scene will be rendered for 3 times for only ONE frame.
Observation: Some engines use additional passes in objets materials in order to write the depth/caustics data in the refraction RTT, but this has two disadvantages: Materials have to be modified(Which is not recomendable for a general solution (an Ogre3D plugin), like Hydrax is, not a only-for-a-specifig-GAME-engine water system) and: Is not possible to have smooth transition with objets/shore.

In conclusion: Hydrax is very optimiced from a GPU point of view, the problem is not from Hydrax here, the problem is from the scene complexity.

This is the "main Hydrax problem", but in fact is not an Hydrax problem.

The CPU problem comes from the Noise and Geometry calculation and is because of it that Hydrax has a very clean geometry and noise modulable interfacte with a lot of examples about how to use them:
3 Examples of Geometry modules(Hydrax::Module):
- SimpleGrid
- RadialGrid
- ProjectedGrid

and 2 examples of Noise modules(Hydrax::Noise):
- Perlin

But... what's the performance problem here?
Performance problems are because of all Hydrax-oficial geometry and noise modules are single-threaded, if you've the opportunity of running any Hydrax oficial example and you open the Windows Task bar, if you've more than one logical processor you'll see that the CPU charge is about 60~65%(or even less if you've more than 2 logical processors).
With multi-threaded modules you'll be using abou the 100% of CPU resources(assuming that the whole system is optimiced for multi-threading), but unafortunately c++ threading is plattform dependent and the unique solution here is to use boost threading because of it's an Ogre3D core dependence.
But due to the fact that threading is something very dependent of the final engine(not only the graphics part, like Ogre is, for example different paradigms can be implemented for multi-threading: micro-threading, one-system-per thread, etc...), I consider the best option is to allow custom user modules, where they can implement the multi-threading part depending of the whole system/threading management.

Any serious engine that will use Hydrax, will have to create its own Noise/Gometry module in order to add multi-threading support, but this is something easy considering that only some changes to original modules are enough.

For example, in the Paradise Engine(My current 'big' project), Hydrax will use custom modules with multithreading implemented through the PThreading library(Paradise Threading). Unafortunately PThreading is closed source and these modules are not going to be released.


About the multi-camera question: yes, this is something Hydrax must support (so... I hope to work in this area for the future 0.6 Hydrax version).

About your question about creating custom Noise modules, you only need to inherit from Hydrax::Noise and fill virtual functions with your code. All noise modules must work with any goometry module. Another topic is creating advanced geometry/noise modules, for example: a geometry module that needs some special information from the noise module in order to update the water mesh vertices, in this case you'll have to retrive the original noise module by a casting in your custom geometry module and work with it as needed... :).



01-12-2009 10:32:49

Thanks for that explanation, it might be worth putting that as a sticky in the Hydrax forum?

I understand that there is nothing that can be done with the GPU.....

As for the CPU.....
I have already loacted the bottle necks as the Noise and Geometry stuff, and i agree the way forward is to multithread them. Infact it will be interesting when Ogre's new threading system is released which i beleive will be based on Job Queues and task etc....

HOWEVER for now can you tell me if the following is wrong;
I am going to multithread Hydrax but the geometry must be updated after the camera is moved. The Noise however can be calculated before hand (ie During other stuff, eg physics buffer swap), so could you seperate the gemoetry and noise upates away from each other in the Hydrax design? Or is this complete rubbish!!