Oi, what a pain. NVidia’s DualTV Tuner does not like to play well with the latest nForce 2 drivers. Random restarts occur when trying to use it. Solution: Use the latest DualTV drivers and roll back to version 4.27 of the nForce 2 drivers.
If the GL_ARB_texture_non_power_of_two extension is supported on your system, then you will be able to use textures of any size (within the limits of the system). No functions or constants are added with this extension.
Not exactly the most complicated of extensions.
The GL_EXT_shadow_funcs extension requires GL_ARB_shadow and GL_ARB_depth_texture in order to have any effect. In the GL_ARB_shadow example on this site we use GL_LEQUAL when setting the GL_TEXTURE_COMPARE_FUNC_ARB texture parameter. GL_ARB_shadow allows this comparison function to be GL_GEQUAL as well, but not any of the other comparison functions.
This extension allows us to use GL_GREATER or GL_EQUAL or any of the eight comparison functions given to us by OpenGL. However, these other functions will not show you much difference. GL_LEQUAL and GL_LESS will look very similar, GL_EQUAL will most likely not be worth using, nor would any of the other comparison functions that this extension gives you. The reasons why you won’t see any difference are given in the extension specifications:
Are there issues with GL_EQUAL and GL_NOTEQUAL?
The GL_EQUAL mode (and GL_NOTEQUAL) may be difficult to obtain well-defined behavior from. This is because there is no guarantee that the divide done by the shadow mapping r/q division is going to exactly match the z/w perspective divide and depth range scale & bias used to generate depth values. Perhaps it can work in a well-defined manner in orthographic views or if you can guarantee that the texture hardware’s r/q is computed with the same hardware used to compute z/w (NVIDIA’s NV_texture_shader extension can provide such a guarantee).
Similiarly, GL_LESS and GL_GREATER are only different from GL_LEQUAL and GL_GEQUAL respectively by a single unit of depth precision which may make the difference between these modes very subtle.
So, unless you are using very specific hardware, you will most likely never need these extra functions.
The GL_ARB_shadow extension allows us to create simple shadow maps. It requires the GL_ARB_depth_texture extension. For more information on the theory and implementation of shadow maps see NVidia’s hardware shadow maps document.
The theory behind using shadow maps is very simple and can be summed up in one sentence. Any point that the light can not see is in shadow. To implement this, we take a picture of the scene from the light’s point of view, then compare it to the picture of the scene from the camera’s point of view. Because we never use the color information from the light’s point of view, we can just take the depth information and store it in a texture to compare with later. This is where we need the depth texture. Note that a single depth texture can not cover the entire scene; to do this one would need to use multiple textures. Typically depth textures are used with spotlights, or in games like Guild Wars and Battlefield 2, a depth texture is used on each model that needs a shadow.
In order to speed things up, we break the world into two parts, shadow casters and shadow recievers. When we take the depth texture we make sure to only render the shadow casters. Then we render the entire scene from the camera’s viewpoint, when coloring each pixel, the 3D location of the point in camera space is converted into a 3D point in light space using a well defined method. This, in essence, will give us the distance to the light. If this distance is larger than the distance in the shadow map, then this point is in shadow, and colored appropriatly, otherwise it is colored normally.
In order to convert a point in camera space to a point in light space we simply multiply it by the various matrices that we use to render it to the screen. First, an overview. When we send a vertex into OpenGL using glVertex, it is multiplied by the camera’s modelview matrix MC. In order to get the vertex back, we must multiply by the inverse of the camera’s modelview MC-1. If everything is set up correctly, the result is the same vertex sent into OpenGL when creating the depth texture. The result is then multiplied by the light’s modelview matrix ML and the light’s projection matrix PL. This gives us the exact same result as the depth texture with one caveat. The projected points go from -1 to 1, whereas textures go from 0 to 1. This is easily overcome by scaling the result by half, then translated by 0.5. This is accomplished with the bias matrix B. Now, the point that we are considering is in texture space of the shadow map. If the input was {x, y, z, w} and the output is {s, t, r, q}, then the value of the shadow map at {s, t} is the depth that the light sees, but r is the distance from the point in quiestion to the light. So if we compare the depth in the texture to r, we know whether or not the point is in shadow. This is the reasoning for the texture property added by the extension. We will enable glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_MODE_ARB, GL_COMPARE_R_TO_TEXTURE_ARB). The way we compare is to say a point is not in shadow when the depth is less than or equal to r, it is in shadow otherwise. Hence glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_FUNC_ARB, GL_LEQUAL).
The matrices above are easily found. ML is given as the the matrix from the gluLookAt command, PL is given with whatever you used to set up the projection matrix (in our example, we keep the projection matrix the same between the light and camera views, so we just grab the current projection matrix). The bias matrix B is well defined and set up in the code below. The only tricky part is finding the inverse of the camera’s modelview matrix. It turns out that if we enable texture coordinate generation with GL_EYE_LINEAR, and GL_EYE_PLANE, OpenGL supplies the inverse for us.
Read more about GL_ARB_shadow
I just had to finish a huge project in a relatively short time. It was a PHP driven admin system that had to display various information to users and allow all content to be editable. There was a blog-like section and afew sections that needed to scan a directory. Users could only be added by administrators and you had to login to see any of it. Quite a pain considering that I was told to give an estimate at a time where only a small portion of the work was told to me. Luckily I lied and said it take longer.
So, the question is, what can I conjure up to make my life easier in the future. First, a solid login system is needed. Also, a way to organise sections of the site, including subsections. Each section should provide title text, breadcrumb text, menu text, content, edit content forms, templates and so on. Finally, a site object has to tie everything together.
This needs to be very freeform. First, the login system. EVolt has a good rundown that I think I’ll gut and modify to my liking. In its current form, it has too much involvement with the form object. Next, I need to create a Section class. It needs the following:
The main Site class should be similar to Section, but act more as a wrapper and tell which section is current. That might be able to work.
Using the new javacript canvas element, someone put together a simple ray caster.
OpenGL Extensions allow us to use graphics hardware without delving into many specifics. The first one we will look at is fairly easy to use and understand, and it is a requirement for other extensions that do much more interesting manipulations. GL_ARB_depth_texture allows us to create a texture from the depth component of the scene. This will allow us to do shadow maps later on.
In this example I will be using OglExt, but there are many different extension managers out there and all are easy to use. I like OglExt because it doesn’t require an initialization step like the OpenGL Extension Wrangler requires. I will also be using GLWindow as it is an easy to use OpenGL framework. This example works just as well in GLUT or any other window manager you can find. Here is the main file that we will be working with. Each step is outlined.
#include "GLWindow.h"
#include
#include
#include
#include
#define SIZE 512
class DepthTexture : public GLWindow
{
public:
GLuint texture;
bool init()
{
// Check that extension is supported
// Create texture
// Make texture active
// Fiddle with texture parameters
// Initialize texture memory using DEPTH_TEXTURE for internal format and format
return true;
}
void draw()
{
// clear the depth and color buffers
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
// Set viewpoint
// Draw scene that we will take the depth of
// Copy the current depth buffer to the texture
// clear the depth and color buffers
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
// Set viewpoint
// Draw a quad with the texture attached
}
};
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
DepthTexture* window = new DepthTexture();
// Set Window size
window->starting_width = SIZE;
window->starting_height = SIZE;
window->mainLoop(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}
Read more about GL_ARB_depth_texture
Download it from the NVSG SDK page at NVidia’s website.
Before we do any hardcore OpenGL programming, we need a framework for creating a window. Sure, you could use SDL or GLUT, but I want to play around with Win32. For that, we shall go to the old standard and copy NeHe’s code. Lesson 45 has a very nice example, but that’s C code. Let’s modify that to make it C++ worthy and create a GLWindow class. So, if you download NeHe’s Win32 code, you’ll see a lot of similarities to GLWindow, but I also made my own modifications
The GLWindow class is meant to be an easy to use framework for setting up an OpenGL project in no time. It allows access to most aspects of the code, making it easily expanded. The main workflow consists of subclassing GLWindow and overriding some of it’s virtual methods. Defaults are provided, so there is no need to override all of the methods. Once a subclass is defined, you instantiate it and call mainloop() to run the program. Piece of cake. Here’s the class structure.
class GLWindow
{
public:
GLWindow();
~GLWindow(void);
void redirectIOToConsole();
void terminateApplication();
void toggleFullscreen();
bool changeScreenResolution(int width, int height, int bitsPerPixel);
bool createWindow();
bool destroyWindow();
LRESULT CALLBACK windowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
bool registerWindowClass();
void mainLoop(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow);
virtual bool init();
virtual void deinit();
virtual void update(DWORD elapsedTime);
virtual void draw();
virtual void reshape(int width, int height);
virtual bool handleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam);
virtual void onLMouseDown();
virtual void onLMouseUp();
virtual void onMMouseDown();
virtual void onMMouseUp();
virtual void onRMouseDown();
virtual void onRMouseUp();
virtual void onMouseMove(int x, int y, WPARAM keys);
virtual void onMouseWheel(WPARAM keys, int wheelDelta, int x, int y);
char title[256];
int starting_width, current_width;
int starting_height, current_height;
int bitsPerPixel;
bool isFullScreen;
protected:
HINSTANCE hInstance;
HWND hWnd;
HDC hDC;
HGLRC hRC;
char className[64];
bool isProgramLooping;
bool createFullscreen;
bool isMessagePumpActive;
bool isVisible;
DWORD lastTickCount;
bool keys[256];
private:
void sethWnd(HWND hWND) ;
static LRESULT CALLBACK staticWindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
};
See the rest of GLWindow
A short list of OpenGL extension libraries