Hi!
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.
GPU:
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.
CPU:
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
- FFT
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).
@al2950
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...
.
Xavi
