News Atom Feed

News index. Browse and read old stuff; you may rapidly find french posts.

The SCEngine now has a deferred renderer!


I've been working on a deferred renderer for the SCEngine these months, and here are the first results! For those who don't know what a deferred renderer is, I recommand you these nice articles:

Deferred render with shadows

In short, it consists of rendering the scene geometry into a G-buffer (for geometry buffer). The G-buffer is made of textures that allows to reconstruct the visible geometry of the scene; one texture is used for pixels' normal, another for pixels' depth and one for pixels' color from texturing (this one hasn't been shown in my screenshot because there is no texturing). Then, to shade the scene with our lights, we just have to apply the following algorithm:

    setBlending (additive);
    foreach (light in scene.lights) {
      use (gbuffer);
      use (light.shader);
      renderFullScreenQuad ();

Visualization of the G-buffers with deferred shading Though specific for each type of light (spot lights, point lights, ...) the shader basically consists of fetching the G-buffer to reconstruct the 3D world position of the pixel being rendered, and then apply some lighting on it using eg. phong shading and the information from the light being rendered. 3D reconstruction consists of a simple unprojection, using pixel's coordinates and depth. The additive blending makes lighting from different lights to be mixed up properly.

With the SCEngine you may now choose to use the basic forward renderer or the deferred one. I also implemented shadow mapping for each type of light. I'm doing a simple cubemap rendering for point lights and I use Cascaded Shadow Maps for "sun-like" lights that enlighten all the scene. Once again if you're interested in knowing what this technique is, I suggest you to take a look at these:

The deferred renderer is still being developed and lacks optimizations:

There are also a lot of features that wait to be implemented:

  • light maps;
  • decals;
  • transparency;
  • and more!

Hope you enjoyed the post!

Posted by Yno on 2011-10-27 13:57 — last updated by Ban on 2011-10-27 18:05

Khronos has released OpenGL 4.2!

Today (August 8), Khronos has released the OpenGL 4.2 specifications. They came with few new extensions but most of them have been chosen so that they are compatible with old hardware (GL2 and/or GL3). So there's not really any new kill feature. nVidia has already released an OpenGL 4.2 capable driver and a short changelog of the added extensions is available here:

The extension which most caught my attention is GL_ARB_texture_storage. According to the specs, current GL textures are defined in such a way that they force implementations to perform useless checks at draw time. Basically, any part of any level of mipmap can be specified in any format at any moment, etc. This extension allow to upload texture data just as the usual routines but assuming that the texture properties wont change in the future. This fact suggests that current textures are "slow", though I don't think that the performance gain will be noticeable, but I'm not experienced at all with drivers implementation details.

Posted by Yno on 2011-08-08 23:12 — last updated by Yno on 2011-08-08 23:13

Discovering geometry shaders: first steps

Yesterday I've been working on implementing geometry shaders into SCEngine. It was quite easy but I had to deal with the shader code of the engine. What a mess. Let your code rot for 3 years and when you come back you may explore a jungle. The geometry shaders thus came with a little update of the API; SCE_Shader_Load() now only accepts a single source file which must contain all the shaders code. Apart from this little feature loss, resulting in a SLOC smaller than before, two new functions have been added: Shader_InputPrimitive() and Shader_OutputPrimitive(). Though deprecated in the 3.2 and newer GL specs, these allow to specify the input and output primitive type for the geometry shader, respectively. In modern GL this is now specified in the shader source directly.

Subdivision geometry shader
I've added a new demo that shows a very basic use of the geometry shaders with the SCEngine. You may edit the shader source to modify the value of the MODE macro in the geometry shader to change its effect. There is one problem I've encountered during the development of this demo so far: backface culling. I was experiencing triangles being culled though facing the camera. The point is, when backface culling is proceeded, each face's normal is computed on the fly by doing a cross product between two edges of the face. These edges depend on the order of the face vertices, you must therefore control it in the geometry shader. Also don't forget to increase the maximum number of output vertices if needed, I had this little "problem" along with the culling one; mixed issues always give you the best headache.

I'm looking forward to do some work on the engine this summer, and hope to implement some cool features.

Posted by Yno on 2011-06-19 04:29 — last updated by Yno on 2011-06-20 17:05
| 1 | 2 | 3 | 4 | 5 | ... | 19 | 20 | older