Dimajix Developer Blog

A very hot and interesting topic in 3d graphics is multithreading. I am thinking for a long time about seperating rendering and simulation by using two threads - the advantage would be that the simulation could take place while the graphics card is busy. Plus the system would take advantage of modern computers that offer Hyperthreading, dual core CPUs or simply two or more CPUs.

On the other hand a lot of problems concerning integrity and synchronisation arise in multithreaded systems which rise the complexity of the overall design by a magnidude. That's just the reason why I did not implement this feature yet, but currently I am thinking about preparing some core components of the 3d graphics and scenegraph module of Magnum for multithreaded usage.

Of course there are already 3d libraries which offer such features, one of the very advanced renderers is OpenSG which in turn is the API I am currently working with at my current client. A very nice feature of OpenSG is the ability of clustering, that is you can render the same scene on more than one computer in a rather transparent way. This feature is extremly useful for driving powerwalls or caves. Multithreading might be a first step in this direction, I'd really love to see Magnum supporting clustering. That would be something very outstanding and special, although only useful in some special scenarios.

Don't expect results within the next days, but stay tuned anyway. I will work on that idea in my spare time.

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].

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.