Blog Archives

Shadow Maps on Omnidirectional Lights

Theoretically, using six shadow mapped spot lights to piece up a shadow casting point light is not a big deal. Especially if the light geometry calculation for deferred lighting is correct. Well, in my engine, it was not the case. 🙂

There was a hidden calculation error that resulted in a frustum with incorrect corner points that made it bigger than desired. This error caused no problem so far because projected mask texture on spotlights and “discard” codes in fragment shader prevented the extra pixels from being seen. But once I have used spot lights with no mask to render point light, the result was erroneous. It looked so strange and mysterious that it took few hours to find the root of the problem.

Finally, the shadows on point light are working now, and I proudly present some screenshots here.

Shadow map on omnilight. Shadow map on omnilight. Shadow map on omnilight. Shadow map on omnilight.

Advertisements

Dynamic Daylight

I have made dynamic sunlight and shadow support wired to the UI, so the sun position can be controlled interactively. The engine calculates the sun position by using azimuth and elevation as parameters. Sun and fog color is adjusted according to the elevation by using a color gradient generated with GIMP. The result can be seen here:

Porting Back to Linux II.

This post is the second part of another I posted earlier.

The detection of uninitialized class members is one of  of my recurring problems with C++. The language standard does not guarantee anything about member variables so I should initialize them myself. Unfortunately, VC++ compiler does not warn me if I forget to initialize a class member variable, even if I set the highest warning level. GCC detects this kind of sloppiness and reports them to me keenly, making great improvements in code quality. Furthermore, GCC goes one step beyond and warns me if the initialization order differs from the declaration order (see Effective C++ about this).
Read the rest of this entry

Effects, Passes, Shaders and Parameters

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

Faster Deferred Shading

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

A Good Old Demo Video

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.