Parallel access: SSAO, Light Pre Pass

During these days I'm changing many things to Hydra: mainly there is a graphic revamp...then I'll be ready to make some AI/gameplay experiments!
I'm developing the lightmapping/radiosity part...this is far from being complete; the new graphic pipeline is almost ready, even if there are some issues here and there...
But tonight I wanted to develop some useful shaders with Fx Composer...

SSAO

Light Pre-Pass

The power of Hydra is that it has 1to1 Fx Composer/InEngine shader graphics: I'm using CgFx library to parse and create the shaders, I found really easy to use but yet powerful. So creating shaders for Hydra is just a matter of time: open FxComposer, create the project, compile...then simply copy the file onto the shader directory, create a material with it...DONE!

There were two great techniques I was impressed by: Screen Space Ambient Occlusion and Light Pre-Pass renderer.

The first was developed by Crytek in 2007, adding a great realism to the scenes because of the use of the ambient term in the lightning equation (always set to a constant-flat value). This calculation is done entirely in realtime, and even if it is something not much performant on many machines, there are plenty of them that can handle this beautiful effect...

The second technique is a renderer design created by Wolfgang Engel : it is a mid point between forward and deferred rendering...really really impressive! It lets you separate light from geometry affected by it, simply rendering the normals and depth to a buffer, then render all the lights needed, then use the forward rendering paradigm using the light buffer for lightning calculation. Even if I have some problems with it, and I've modeled only the diffuse term of the lightning equation, I'm really satisfied tonight.

Take care...

Radiosity lightmapping and new Renderer design

Hello everybody,
is a long time since my last post. I was busy at work and in some ideas for my engine, that are still in a primordial stage.

After being fascinated by the Radiosity Normal Mapping Technique by Valve, I've decided to try the way of a lightmapper. I know it's something difficult, but being something I've never do, I want to give it a try!

The result is a good bunch of links about radiosity and lightmapping in this thread I've opened (here I am JorenJoestar) on Gamedev:

http://www.gamedev.net/community/forums/topic.asp?topic_id=528414

Also here there are some more informations for radiosity on GPU.

In the meantime I'm designing a new Renderer that it's really flexible. There are still some shadows on the design, so I've came up opening a post on gamedev to receive some critics and some ideas. I've decided to give it a "submission date" after which I'll begin the coding: it's annoying to be stucked with all the things I have to do!

More on that soon...

Culling and scene

Speaking of culling, I've finished frustum culling and rendering using an octree as spatial structure. I've began also working on occlusion culling, and found a very intersting paper:

Coherent Hierarchical Culling Revisited

You can download the paper from there. It seems a very good techniques that uses Hardware Occlusion Queries with many render-state friendly optimizations, and seems also a real improvement to the basic technique.
But before moving to occlusion culling, I'm studying the design of the scene management, so when I've done with it I can create a real scene to test the CHC++ and also some simpler techniques of occlusion culling (using occlusion planes/frustum entierely on CPU). I found very interesting the use of occlusion queries, but if the scene you are about to render uses heavly the GPU it can impact the performances too much.
With the advent of the multicore cpus the old-fashioned-cpu culling can be of great impact on the performances.
In the meantime, I'll attach two simple shots of some random-placed meshes (the same as the previous post) this time entirely culled and rendered:

The first is the scene seen from the camera, the second shows the frustum and the object rendered.

Octree and HydraIO!

Hello again...now that I finally closed the section about the previous engine, it's time to talk about the new one!
The name HydraIO, that means "Hydra2" read as binary code, and is the natural successor of the first one.
This version will be more complete and will have more features than Hydra, but it's still under heavy development. The architecture is totally new, the level of abstraction of the resources is different but let me implement all the resources also with consoles in mind, finally the shaders are totally data driven and uses Cg effects as standard. The old assembly used on the first Hydra is dead!
Actually the engine let me load models from 3d studio max, apply a cgfx effect totally data-driven, and now I'm working on culling.
This is the first shot of HydraIO:


a really simple Octree in a random based set of static meshes, next I'll attact a debug shader that let's me know if an object has been culled or not. In the meantime, I want you to know a simple trick about the criteria to be matched to end dividing the octree. In many papers I've read, there's always mentioned the criteria based on the number of polygons: if you are under a threshold, there's no way to not split the octree.
Another simple critera is to let you decide the aabb minimum size, so if you are slicing too much the octree doesn't divide: this was a real salvation for avoid infinite cycles!
Staticmeshes are meshes that have their points transformed in worldspace directly, thus all their shader will have only the multiplication: view * projection, and that are fitted in the octree.

Hydra History #3: the twist in the tale

Then it comes the light.
But first, the tangent and bitangent problem...it causes some really annoying (but funny) parallax effects!












After solving this issue, I began fighting with another great effect: the shadows! After a while, and maaaany problems, I've figure out that the road to the demo lead me to a simple shadow map, with the light cast by the player...
This is the scene without the relief, but with the improved water.
Oh yeah, the water!













The other great effect to improve...after some trial, I've ended with a water like that:













I've used a simple environment map to enhance the visual appeal. The noise is terrible by the way, but tweaking it in assembly was a real PAIN!



This shots shows the technique for reflection and refraction, taken from GPU Gems2 Ch19.
Using also the copy of the framebuffer in directx, you can skip the second render of the scene that contains the refraction mask in the alpha channel!






The final set of effects was near completion, but with some problems. Still, this is not a demo that satisfied myself.






































So I ended up writing an importer from quake3 arena bsp maps...














And added some basic physics with Nvidia PhysX.














On august I ended it and in september I began working in the game industry...but still there are many things I want to know and that I'm studying.
This was my first engine from scratch, now I've began a second one (called Hydra IO ) that is different in architecture and more powerful.
Soon I'll post some shots of it, but right now I'm working on the core...

Hydra History #2 and an interesting article

On the path to the new engine, I faced the challange of the resource manager design and this turned in an interesting discussion on gamedev. This is the link:

Engine design and resources

Talking about Hydra, the first release was a great success for me. It was a graphic engine wrote from scratch (int main...) and during its lifetime it teached me much things.

This the second shot of my engine. At the time it was only in wireframe, and I was developing an importer from the 3ds format, due to my previous work with 3d studio max.








After that, I've began coding shaders but using asm shaders...this was actually a pain. The renderer has both Direct3D and OpenGL support, so I had to create both shaders two times.
To solve this problem, I've began coding in Cg and then converting to asm every time. This process was really slow and the shaders I've implemented were not optimized and much time was spent to fine-tune them (code, export in asm, modify gpu registry bindings...).
To support some sort of scene hierarchies, I've implemented Bounding Volume Hierarchy:

Those two models were under the same node, so the resulting volume must contain both the volume of the models.
This screenshot used OpenGL renderer.





Having a simple scene hierarchy system, here comes the time to develop something more interesting.
I have always love water, both in the reality and in 3d rendering (even using max), so the natural choise was to study how to achieve the water.
I've seen what's missing in my renderer, so I create functions for both OpenGL and DirectX to support culling planes and render to texture. I created a tube under max and added some noise to create a cave, exported and then I've tried to create the water.
This was my first attempt:

This image seems like coming from ten years ago, but it was a success at the time. The reflection was done via render to texture and culling plane, and the result for debug purpose can be seen on the lower left.
The refraction was poor, and there were no noise and no light.


After this preliminary water, it comes the time to face another subject I love: shadows. This was the REAL pain. I've passed nights and many posts on gamedev to achieve a simple shadowmap, due to the texture format, due to the poor pipeline: cg->asm->hydra. It takes long time to see the shadow map working, I don't know even how much!

Finally the long waited shadow map! Ugly but hey man...I've learnt many other things!



















And then I wanted to give another touch...using normal maps.
I've noticed a family of graphic effect that derive from normal maps like parallax occlusion mapping, relief mapping, cone step mapping and stuff like that.
So I've began studying them, creating shader for normal, simple parallax and relief with fake soft shadows using FxComposer. It ended up with the overused rockwall:

Another problem here was the lack of informations like Tangent and Bitangents.
So I create a function to fill the vertex buffer with those informations...using the math explained in this article: Tangent Space Calculation



The end of the story will be in part #3...stay tuned!


Demiurge

Hydra history #1

A years ago, I've began coding a graphic engine called Hydra. It was very important for me, because it learned me much things about different fields, like graphics, engines, directx/opengl, cg, hlsl, windows and linux.
After some months of nighttime development, I've created a demo and a video about it:

http://it.youtube.com/watch?v=Bx_WeMigxRA&feature=related

Even if it's not an impressive demo, it is based totally on the renderer made by me. Started from scratch. And this leaded me to continue to study and research about graphic and engines.

And leaded me to finally be a game programmer!