Monthly Archives: August 2011
I can proudly announce that I have successfully added the CHC++ algorithm to the engine, so it supports hardware accelerated occlusion culling now. With this new feature the engine can exclude most of the objects those are not visible in the final image from rendering. Without getting too deep in details, the method uses occlusion queries supported by the hardware in conjunction with the space partitioning tree to efficiently cull invisible elements within the view frustum. It needs no any scene preprocessing, so dynamic scenes are fully supported.
Read the rest of this entry
As I promised in an earlier post, this is a short overview about shader support in the engine. Currently Merlin3D supports OpenGL and GLSL. DirectX support is not implemented yet.
Merlin3D uses its own effect files, that describes a particular shader set for the different rendering passes (it has some similarities to .fx files in DirectX, but in OpenGL world there is no effect file support at all). Effect files are in XML format. Each visible scene object has exactly one effect required to render the object in different rendering passes. Multiple scene objects can use the same effect. Anyway, it is the recommended way of effect usage, because the engine tries to group objects by the associated effects to reduce OpenGL state changes.
Read the rest of this entry
In the last two late evenings I have worked on the elimination of the 3D position from the geometry buffer, making some improvements on shader parameter passing and not surprisingly, hunting bugs down. The results are the following: Read the rest of this entry
Just to make the “web presence” of the engine more complete, I have registered Merlin3D on Gamedev.net. The profile can be reached here. Further contents will be available soon. 🙂
I have moved an old demo video about the engine to the dedicated YouTube channel. This was a project at the university, showing the new capabilities of the shader support just added to the engine.
Now I’m working on the renderer and just added deferred shading to it. The implementation is far from optimal but the results are promising. The G-buffer is too “thick”, it is definitively not too effective to store the 3D eye coordinate position for each pixel, but I wanted to make it work first. The second problem is the fill rate that goes high when many visible lights are covering large areas of the rendered image. I think I will try to skip unlit pixels from the light pass by using some stencil buffer tricks or something similar.
There are multiple local omnidirectional lights and one big directional light (the sun) with ambient term for the whole scene. The bouncing projectiles are also emit light.