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!

Long time...

It is a long time since my last post.
Many things have changed, and many were improved!
First of all...I've done it! I'm working in the game industry! In september I've began working @ Gd-Mind, a small game company located here in Rome. The peoples are great, Tiziano Lena (Lead Prog) and Gabriele Barlocci (Senior Prog) are quite great masters...and day after day they teach me many new things.
The Hydra Engine finished with a small demo, but during the entire process it teached me many stuff about engines and now I'm thinking of starting a new engine from scratch, the old architecture is quite too complex. The engine included NVidia PhysX for physics and lua for scripting, because of the will to expand to a game engine and not a mere graphic engine. But this lead me to think about a new and more simple architecture, and choose to support only a graphic API.
Stay tuned for more info about the next steps...

The power of design...

The step is done. Friday I've done the design of the new architecture, that will allow a multi-platform/multi-render development of my engine, all based on libraries. So I wrote down all the subsystems, the new engine tree, and the code came up from my fingers during friday night.
The result is an SDK, useful to create demos and applications focusing on the apps and not on the renderer or the OS.
I feel very satisfied about it, it is modular and let me concentrate on the next steps: developing an OpenGL renderer and a OpenGL/Linux application, to let the engine be developed with my two main OS.
I'm working also on an embedded version of the engine in WxWidgets, so I can create some useful tools to build shaders, scenes, and stuff like that.

Casper: today he will become Software Engineer. With the max possible rank. Congratulations!


P.S. I'm Demiurge. The second is Casper...and the next?

First milestone!

The time has come to close the first milestone of my little engine.
Some basic features, but still important (like a full math library, geometry and texture importer from 3Ds files,
render to texture and basic shader, basic camera and scene managment).
And now a new need.
The need to move to multiplatform/multirenderer architecture, the need to see it in every way possible.
I'm still confused about the solution to this problem, cause the windows development was fast and easy with visual studio 2005 and DirectX9, but more satisfaction is yet to come.

It's time to design - how to build over different platforms.
It's time to design - how to let my brother work on our dream.

Welcome Caspar!