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.
Tuesday, May 5, 2009
Monday, May 4, 2009
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...
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...
Tuesday, April 28, 2009
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...
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...
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...
Saturday, April 4, 2009
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...
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...
Sunday, February 15, 2009
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.
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.
Friday, February 13, 2009
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.
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.
Monday, February 9, 2009
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...
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...
Subscribe to:
Posts (Atom)