Dimajix Developer Blog

Again I am working on a new demo that will take advantage of the new EXT_framebuffer_object extension in OpenGL. The demo will feature some reflecting spheres which will not only reflect the static cubemap surrounding the scene, but which will also reflect all other spheres in the scene by dynamically generating a cubemap for each sphere.

Although I expected this to be an easy project, the correct order of the matrices needed to render the cubemaps for each sphere drove me almost mad, until I went away from my PC and thought about the whole setting without hurry.

The demo is almost finished, there are only two things missing: The lighting of the spheres in the cubemaps isn't correct (but this should be easy) and I am still thinking about implementing some HDR rendering. The scene would benefit a lot of an extended lighting range, especially the reflections should look much better. But unfortunately I found out that on NVidia FX series graphics cards, there seems to be some crippled support for float buffers in hardware and I do not really want to mess around with HILO textures, which make things complicated and ugly (from a programmers point of view). But maybe I get HDR rendering to work on ATI hardware...

This demo tries to imitate the behaviour of a soapfilm in a flexible wireframe. The enclosing wireframe is modeled by interpolating trigonometric polynomials, while the soapfilm itself uses the same relaxation technique as also used for cloth simulations. The surface is rendered using a GLSL vertex and fragment shader that takes into account one pointlight and the reflectivity of the soapfilm as a function of the angle between the surface normal and the eye vector.

Requirements: This demo requires an OpenGL 2.0 compliant graphics cards with appropriate drivers installed. Currently it is tested on an NVidia Geforce FX, whereas it does not run on ATI hardware due to a driver bug.

Update: I changed the vertex shader, so that the program should run on ATI hardware, too. Even my Radeon 9800 now renders the scene with hardware acceleration.

Download ZIPed executable only demo [3.3MB].
Download ZIPed demo including source [3.3MB].

...even at some points where I didn't expect them: I am still working on the soapfilm demo and I found a very strange and mysterious bug: When I start the demo from within VIsual C++, it runs fine. But as soon as I try to run the executable directly from the Windows explorer, it does not run.

Some investigations brought me to the following very strange explanation: When running the program from Visual C++, the GLSL compiler does its job without complaining. Even if I insert some random characters into the shader program, the compiler does not seem to return any error, but no outpu is produced. But as soon as I start the demo directly from the explorer, the GLSL compiler starts to complain, and the program terminates.

Strange, eh? And how should I debug in such a scenario when the program behaves differently in the IDE?

Update: I found the bug - there was only the string terminating zero missing in the shader source. It seems as if the test program was run from within Visual C++ there has been a valid string terminator at the end of the shader code by incident. Did I ever say that most bugs are trivial?

But concerning the problems with ATI hardware, I suspect that there is a bug in the GLSL part of the drivers (Catalyst 5.4). I am able to reproduce an error by following this simple procedure:
1. Run 3dLabs ShaderGen.
2. Press "Build" - no problem so far.
3. Press "Build" a second time - suddenly the GLSL compiler complains about errors, although the shader code didn't change.

Finally a new demo is almost finished, it tries to simulate a soapfilm in some sort of wire-frame that is animted. The surface simply is generated by the same routines as used for cloth simulations as in one of the last demos. But there is still a small bug, the vertex shader does not compile on ATI hardware for some reason I don not know yet.

As soon as I found this last annoying bug, I will publish the demo together with the current version of the framework.

So after the OpenGL board finally has made up the EXT_framebuffer_object specification, I just found out that both NVidia and ATI both have implemented this extension in their newest drivers (ForceWare 76.41 and Catalyst 5.4). I don't know about the other graphics chip companies out there, but the two biggest players among them now offer ready-to-use solution (hopefully bug free). So the coding can begin!

This long awated extension enables programmers to use textures as render targets in a much easier and more efficient way than before. The Microsoft DirectX API already has such a feature for some years now, that fact made the OpenGL developers especially dissappointed from the slow progress of the Architecture Review Board (ARB) which is responsible for writing the specifications.

Today I have finished a first integration of the OpenGL Shading Language (GLSlang) into Magnum, I hope that I will be able to finish another demo soon featuring some of the new code I have written.

I really like the integration of GLSlang into the OpenGL API is much better than the integration of programmable shaders into DirectX. I especially like the fact that you can access the traditional state variables of the fixed function pipeline from GLSlang shaders - something similar is not possible with DirectX HLSL. This fact makes the integration of new shaders into an existing fixed-function 3d engine much more difficult, if not impossible without a major redesdign of the complete engine.

Another drawback of the DirectX implementation is the missing flexibility of the vertex buffer formats used together with a shader. One has to specify the exact layout of the vertex buffers within the shaders, which implies that for every different vertex buffer configuration a new shader has to be created.

My last caveat concerns the integration of the compiler itself. In OpenGL the GLSL compiler is part of the video driver, whereas in DirectX the HLSL compiler is part of DirectX. Of course this make it easier for driver developers to do their work, as they do not need to worry any more about the compiler. On the other hand this fact also makes it very difficult to include hardware specific optimisations, as the driver has no possibility to interfere with the HLSL compiler. Instead the driver has to try to work with the assembler code generated from HLSL - at this point of time some information of the program is already lost, and thus the driver has to work much harder to perform optimisations.

So I am quite happy that I decided to work with OpenGL instead of DirectX, although this decision was based on the better portability of OpenGL code.