Tag Archives: openGL

A tale of two vectors (normal reconstruction and driver differences)

If you’re playing around with deferred rendering or post-process techniques, you’ve probably come across the concept that you can recover camera-space surface normals from camera space position like so:

vec3 reconstructCameraSpaceFaceNormal(vec3 CameraSpacePosition) {
    vec3 res = normalize(cross(dFdy(CameraSpacePosition), dFdx(CameraSpacePosition)));
    return res;
}

where C is the camera-space position.

What you might not realise is that you’re accidentally setting yourself up for confusion depending on your graphics driver. For the longest time, I was using this technique to try to implement SSAO without having to bother with storing screen space normals. After fiddling about a bit I noticed that on my desktop with an NVIDIA GTX680 everything looked OK, while on my laptop with intel HD integrated graphics everything looked inverted. I then tried reversing the normal I was getting out of this function. Success! The laptop is now displaying correctly. Failure! The desktop is now screwed up.

Continue reading A tale of two vectors (normal reconstruction and driver differences)

Simple billboard orientation in world space

I had a great deal of difficulty in working out how to do billboards properly, simply because I don’t have the mental agility to handle the descriptions usually given in 3D programming tutorials. The method I’ve managed to figure out is related to gluLookAt: and uses a similar method to work out the rotation matrix needed to map one vector to another.

Here’s how the process works:
Continue reading Simple billboard orientation in world space

LOD

More LOD than you can shake a STICK at
Procedurally generated terrain

I think I’ve come up with a new definition for “optimisation” in the context of writing a 3D engine, where it means “to painstakingly claw back some of your frame budget, and then immediately blow it on a new engine feature”. Hence the above looks pretty but currently runs at 10 frames per second on a SNB Core i5 MacBook Air.

New features include LOD-heavy instanced grass rendering, deferred lighting, cloud shadows and BLOOOOOOOOOOOM. Once I’ve “optimised” those features as well, I’ll do some write-ups – the instanced rendering method using matrix buffers which I picked up here is particularly cool.

Two dimensional C arrays – care and feeding

C arrays are a little hard to grasp by those of us raised on the Cocoa API, because most of the really convenient stuff (like an array object being able to keep track of its own size) just isn’t there in straight C.  I went into using C arrays, in order to interact with OpenGL, with absolutely no knowledge whatsoever (a common theme of this site!) of how to even use malloc.

Why would you want to use two-dimensional arrays anyway?  In my case, although I’ve written a fair few functions where e.g. a two-dimensional grid of points is mapped to a long one-dimensional array, and I’ve simply remembered what the dimensions of the grid were when accessing the information, sometimes this is simply too much for my poor brain to understand. In this situation I’m forced to represent things as a multidimensional array in order to get the concepts down in a way which works.  I might, therefore, have one array which represents all of the values of the x dimension, containing a series of arrays which represent the y dimension; so the point in the grid at (5, 13) is retrieved by getting the 13th value from the 5th subarray in the parent array.

Fortunately there are people who are much cleverer than me who have come up with a way of handling two-dimensional C-arrays.  Unfortunately I have forgotten the attribution.  However, I had to go forum-diving to find this and I think that it might be helpful for us inexperienced types to have a more easily-searched solution.  If I find the original source again, I will provide a link.

One similar implementation was found here

//make a 2d array of floats
 
float** Make2DFloatArray(long lengthMainArray, long lengthSubArray) {
    float **newArray = (float **) malloc(lengthMainArray * sizeof(float *));
    *newArray = malloc(lengthMainArray * lengthSubArray * sizeof(float));
    for (int i = 0; i < lengthMainArray; i++) {
        newArray[i] = *newArray + i * lengthSubArray;
    }
    return newArray;
}
 
//release a 2d array of floats
 
void free2DFloatArray (float **arrayToFree) {
    free(*arrayToFree);
    free(arrayToFree);
}
 
//access a value in the 2d array
 
float theFloatIWant = my2DFloatArray[indexInMainArray][indexInSubArray];

Hello world!

Those (few) of us who got our start in graphics coding in OS X have probably noticed a few wrinkles in the process:

  • Apple’s OpenGL/GLSL implementation is always a year or two out of date
  • OpenGL tutorials on the internet are always 5 years out of date, and actually written for DirectX anyway
  • Books on the subject cost £50 for a hard-to-search collection of stuff you already knew which is inevitably dependant on some library or other (which they don’t explain) to do all of the magic
  • GLSL is, as Shamus Young so rightly pointed out, folk knowledge
  • As soon as you want to interact with OpenGL, you have to leave your cosy Cocoa haven and delve into straight C – which is moon language to those of us raised on NSExtremelyVerboseFunctionNameWithAttributes:

Hence I’ve made this site to put up some of the more obscure – or so obvious nobody has ever bothered to put up a working implementation for us newbies to pore over – code which took me hours of googling to figure out.  It’s so much easier to learm by breaking a working implementation than to mess about with something originally written in a different language which might not even work in the first place.

In the process, I’m going to build one of those procedural environment things.  This was going to be a simple 2D Artificial Stupidity project, but the graphics sort of took over.

There will be bugs.  There will definitely be memory leaks.  Much of this stuff will be apocryphal, or at least wildly inaccurate.  Your video card will probably crash at some point, and I’m definitely not going to buy you a new one.

Enjoy!