Math library; Core Engine development;

Even if I am not coding really fast, I'm studying different topics in which I find really different 'formae mentis': this is really fascinating!

Actually I written a non-template version of my math library, with some basic support for SSE/VMX code: premature optimization is the root of all evil.
So I'm moving forward to implement other core part of Hydra: camera, input and debug output!
Actually the camera is almost done, with all the code (like plane extraction, frustum vertex in world/view-space) working, the input is almost done and I'm writing the implementation of a directx9-based renderer, that will be used right now only for debug graphics to test that everything with maths works!

Also, I bumped in the Function Pointers World...really fascinating, with simple code that can make you skip some branch to choose what to do on different situations and have some performance gains...
I'll try to use them in the core part of the engine, to avoid virtual keyword and to skip some branches; this engine is not a commercial-one, so I am free to experiment everything keep my attention!

Small snippets

There are small snippets that can be used very well...
One is a simple software interrupt:

__asm int 3;

The second is more evolved, but if used correctly can wield to know everything about your code:

#define Stringize( L ) #L
#define MakeString( M, L ) M(L)
#define $Line MakeString( Stringize, __LINE__ )
#define Reminder __FILE__ "(" $Line ") : Reminder: "

so if you use the #pragma comment (Reminder ": TODO/HACK/FIXME") under MSVC compilers you will see the message in the output window, and with a double-click on it, you'll be teleported on where the code is written, so you can keep track of all the stuff you have to change...during compilation time!

Really useful, small and smart ;)

P.S. A really simple profiler is born, now I'm writing my math library from scratch, so to see some eye-candy you have to wait some days!
Next steps include:

• Basic math library (with future support for SSE)
• Input handling (mouse, keyboard)
• Camera and Frustum classes
• Debug draw (lines, spheres, cubes)
• System coherence tests (project/unproject, world/view/screen space tests)

In the meantime I'm designing the structure of the engine with all its new systems/parts, and after those steps I'll began coding all of that!

Stay tuned ;)

Math-o-centric view

One of the thousands of changes I'm doing in the new Hydra is the math system: my math always based on a template math library without any SSE-kind optimization.
I went into a journey that highlighted the lack of centrality of math code and the lack of SSE.
Is it really necessary to use SSE?
The real advantage of SSE is the use of instructions that works on 128-bit registers, and that can contains, for example, a 4d vector.
The BIG advantage of SSE is to use the mentality used when writing shaders to reorganize data in
Structures Of Array and gain a near 4x speedup!
After some study, I've decided so far to eliminate the template aspect of the math library: floating points is the standard de-facto. The real twist is the centrality of math: to use SSE, it is better to create a place in which all math is done; this ensure the possibility to apply different kind of math calculations (better for multiplatform development) without changing code outside the math system.
I think THIS will be the real power of the new design: all math inside the proper system!
After that big change, SSE optimization is a matter of time.
For example, Frustum Culling: imagine a method that performs a Frustum-AABB intersection

int Camera::intersectAABB(const AxisAlignedBox3f* const aabb)

even if it can be cool to let the camera calculate the intersection (by information expert, it can be either the Camera or the AABB), it is smarter to move this method in the math system, like that:

int Math::FrustumAABBIntersection(const AxisAlignedBox3& aabb, const Frustum& frustum)

this assure that if you want to implement different math (SSE/VMX/SPU-like) you can do it using the preprocessor.

I'll try this different approach, and profile the changes from template-based-sparse to float-centric math, and also to float-centric-sse-math.
I am really CURIOUS about the results!

Stay tuned, next time I'll post some timing and talk about the Core of the Engine!

Starting from scratch...again?

One of the most intriguing aspect of the game development is the tendency to hide the knowledge.
This is one of the most stupid thing that we human can do: hide our knowledge.
Why that?
Lack of self-confidence, company ripoff of staffs, and many others...I think it would be very useful to study some System Engineering and Systems in general.
Maybe a lecture like 'The web of life' could be REALLY USEFUL.
Sharing of knowledge let other people to improve what you are working on: think of the open source.
One day...the gaming industry will be more open, and maybe not every company will start its own engine because it has no money to buy one! :P

Sorry for the rant...but I like sharing ALL, because I find that everybody can learn you something, even a 'negative person': it teach you what NOT TO DO!

Apart from that...I've started rewritting the engine, to go multithreading and to apply all the knowledge I'm building now. Nothing more than an engine to understand the base of all the game development and to experiment new things...
The third iteration of Hydra (codenamed 'Turgid') will be available also on SourceForge.
I'm pretty excited about it, because I can concentrate on different aspects every time!
The first iteration was about...EVERYTHING! Two years ago, I've know nothing about game engine programming. So I studied all from scratch, trying to create a base renderer.
The second was about shaders: I wanted to develop and to investigate the beautiful world of shaders! It ended in a Light-PrePass renderer with shadow maps, screen space ambient occlusion, lightshafts, hdr...many interesting things!
What about the third? I want to enter the multithreading world, I'm really fascinated about it. Also, I want to extend the engine to became a more robust and complete framework, including also a small editor, some physics, AI and sound! And...continue studying special effects, shaders, DirectX11...
The last thought about the third iteration is about the multi-platform development: the actual design had taken in account the possibility to use OpenGL and to run under Linux and MacOS; about this...time will tell!
I want to update this blog more frequently and take many screenshot of the work in progress...

Stay tuned!

Moving forward: Portals, DX10, Multithreading!

REALLY busy time, luckly!
We are working hard and beautifully in my company...we are experimenting and learning new things, so it is a great time!
In my spare time, apart from learning playing flamenco and jazz, going gym, reading many books (Robbins, Dills, Dyer...) , I'm studying some interesting things: Portals, Dx10 and Multithreading!
Currently I'm implementing a simple Portal System, and designing a completely rewritten game engine that takes in account the multithreading as the base brick of all the structure...this is really fascinating, because nowadays most applications are single threaded and the multithreading is added AFTER the creation of the project.
I've installed Windows 7 on my laptop, and I have to admit that it seems a good operative system: vista-eye-candy, nearxp performance. That unlocked the doors to Directx10, with all the goodies that cames from...the Directx11 also can be used, but on a Geforce8600m gt there is no room for that!
So basically...time to study. Hope to post some screenshots of the portal system soon!

SSAO!

After some fights...here comes the SSAO!


This is the beauty of the 'waterfall effect' of the deferred/lightprepass/z-based rendering: one you have coherence between different spaces (world, view, projection, texture...) and you switch between them rather easily, you can begin working on many interesting effects :)
This is a real basic implementation, based on various post on gamedev (thanks guys!!!)

Finally a new connection!

Long time no see guys!
This is the first day I have an internet connection in my new house. After 3 months actually!
I was really busy at work, but I continued programming.
My new challange is the Deferred Rendering...a real cute rendering architecture!
After many reads (mainly gamedev) I moved to my first implementation: I found really useful to do all the calculations in view space, the view space pixel position reconstruction became really simple.
Also, the G-Buffer is actually composed of only 2 render target, rendered with a MRT: normal and linear depth. The result is a Light-Pre-Pass-Like renderer...I'll show a little result:

10 pointlights on the screen with the known rockwall normal map.
I'm also working on the ScreenSpaceAmbientOcclusion so I can move to create a little demo.
Stay tuned!

Actual State; Near future; Future;

Some changes have happened in the last month.
I changed city, company, life.
I moved 700km away from my home, in a more prolific environment and with cool guys.
This is the main reason of the slowdown of the blog!

I'm actually coding hard, because I want to study some topics in which I'm weak, and then I want to merge all of them in the new Hydra!
During these days I'm creating some really small demos that covers different aspects of game programming:

- GUI and Font handling;
- Animation;
- Collada import;
- New graphic pipeline;
- Lightmapping;

These different topics are really interesting, and I'm quite happy of the results.
GUI and Font handling it is something simple, but can give you satisfaction and OUTPUT.
Animation is a really tricky topic, I've done a small exporter in maxscript and all sounds good,
but then I've read this article (link) and found that an importing pipeline is a good choice, even if more difficult for some aspects! Then I began using Collada...really good and FREE.

New graphic pipeline. I wanted something more shader-oriented than before, so I switched to Cg...really COOL! The rendering is organized in pipelines...each one has its own stages. Every stages can specify one or more render target and all the textures produced are specified in a common pool of texture of the pipeline. The next step will be involving a node-based editor for the creation of the rendering phase...I found it very easy and powerful, something that can istantaneously change the appearence of the game to see different pipelines and render, to study the feel of the game and tune it up!
With that in mind I begun my lightmapper. Through I started only some days ago, now it output a simple lightmap with a really simple phong shading: actually I'm spending time in creating a good unwrap and to create the radiosity normal mapping brick that I need to complete this step!

Until september I've no connection at home...so updates will be randomic! :(

But...stay tuned!

Secret of Mana

Yes...I want to know the Secret of Mana.
Long time ago...there was two special games. One was The Legend of Zelda: A Link to the Past, and another one was Secret of Mana (I don't want to mention Chrono Trigger...I'll do it in another post).
What's about SoM? I really enjoyed it, playing with my best friend and sometimes with my sister...all in realtime? What?
Great story, great ambientation...and great gameplay. The weapons you found and the spell you learn grow with the usage. The fights are in realtime, the AI can control the other in the party or you can play together.
One of my greatest dream is to create a game like that for some console one day...with the beautiful music and all the magic that Secret of Mana has.





But now the mana is weak...and later games fail in public reception.
One day, I'll forge a new Mana and all will be good for the Universe...

Updates, ideas, thoughts

Finally I'm finishing the animation demo I've scheduled. After some research I found a good way to handle animations with blending and transitions. The results are good, the code is simple and I've both CPU and GPU skinning implementations.
Next will be the 2D demo...sure I want to develop something simple yet powerful!

On the other way I'm researching on both toolset development and multithreading. The latter is a difficult and big subject to study, but also so fascinating! I've not found many resources around, I think not so many people use multithreading in a correct way...
On the toolset research, I'm creating an architecture that is both GUI and Engine indipendent.
Why so? Is it possible? Yes yes...it is possible. I wanted to create something that can grow with me: I've always believed the power of toolset, but I know also that much time is needed to create something robust and useful. This little/big idea let me create my own editor and develop it during time...I'm really excited about this software design!

Last but not least...the last guardian (sorry for the repetitions :P). Amazing. Wonderful. I want to make games with such magic...the real state of the art. If you haven't seen it...click here .

Stay tuned!

Plans

The best way to create something is to actually DO it.
Because of this, I began planning some smalls tech-demos for my always-in-development engine Hydra: these demos will give me knowledge about different topics, and incrementally give Hydra more features.
The first, small demo I've done was about culling and the new shader oriented pipeline...I've posted some screens not too much time ago (see this and this) and that debug lines are a giant step towards engine's features development. This is something known to many, but the separation between code and data, and the need of data to be displayed, can be overwhelmed by using debug methods (draw 3d lines, 2d lines, circles, spheres, boxes, cylinders).

Also the use of custom exporter (my case is maxscript) lead to another problem: how to export data in a cross-platform manner and in an efficient way. The solution is simple: Collada. It is the perfect intermediate format that can be translated in platform-dependent code, and that exports almost everything graphical thus physics objects. The use of Collada was suggested by the problem of exporting animation (SRT, biped, skinning) data from 3d studio max...what if I found a model created in Maya? And the old release of 3d studio? Using custom-made scripts it is great, maxscript is very simple yet powerful (creating a custom exporter need a small amount of time, personal experience), but when I was developing the script I had to create something adapted to Hydra...abstracting, introducing a new layer was the answer.

The second demo, as you can imagine, is about animations exported using Collada. I'm thinking of doing first CPU accelerated skinning, I've got a bunch of GPU-accelerated shaders that performs skinning, even if I'm not so confident about the real power of GPU...it becamed too much used, and cores are multiplying!

Third demo will see a simple 2d framework with menus, font management and console.

The fourth and the fifth will be the harder part...radiosity lightmapping and scene management. Lightmapping will be only an algorithmic problem, scene management will be a design problem.
The question about how to describe scene, and let different subsystems (graphic, AI, sound) interacts is way too bit complicated to be explained in this post. Also, there are many design flaws in every different implementation...just Keep It Simple and Stupid.

Hatching love

Some years ago I began cultivating a passion for drawing (now possible only in my sparetime) that evolved in some 3d modeling...one of my favourite technique was "hatching", in which volumes are "described" by simultaneous lines that intersect creating grey-scaled images and giving the idea of volume. Even now I'm not a great modeler/drawer, but I find this fantastic shader to be linked to my vision about drawings (see comics like Berserk or Hokuto no Ken to see it in action).
So based on my first and only semi-serious 3d model, Zoddo from Berserk, I finally came up with this fantastic shader, even if the model has serious normals problem (that affects lightning :( ):


I wander what can be the feeling with a 3d world shaded in this way...

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!