I wanted to do a piece on the webGL before I forget. Since Flash can’t seem to deliver on the promise of 3D acceleration (Adobe in general I think need to start fresh on several applications rather sooner than later) the Mozilla Foundation stepped in. They made a custom implementation called Canvas which took off and became WebGL, currently supported by both Mozilla and WebKit (Microsoft is late to the party of course). While WebGL isn’t part of any official build yet, both nightly builds of WebKit and Firefox has the functionality. In the case of WebKit you need to compile yourself (easier said than done I might add, but I didn’t bother too much). With Firefox however one only needs to know which buttons to push.

If someone would like to try it out, there are guides for that out there. What I did was I downloaded the nightly build of Firefox (called Mindfield). In the address bar one simply writes about:config and then scrolls down to the WebGL option and makes it true. Too try it out simply visit the WebGL Spore demo by a Mozilla dev.

After looking through the javascript files I came to the conclusion that you have to implement all the GLU functionality yourself since only standard OpenGL (ES i think) calls are availible. A shame but I bet someone will create a JSGLU soon enough. Also loading resources is really convinient since the broweser takes care of loading (in a separate thread I figure).

WebGL is still at its infancy and there is a lot of work to be done. Also the javascript performance is very crucial for any implementation and thankfully WebKit has really driven the development forward in that particular area. Hopefully someone will get around to making Quake 1 in native javascript with WebGL and get everyone else started. I for one would love to be able to integrate 3D graphics with web applications.

Carrying on with the Renderer library,the next function I decided to implement was textures.  To be able to render the scene to texture is a major function, and for this library is a must.  It is also a requirement to also be able to use those textures as part of a scene too.  I had not previously used vertex buffer objects with textures either, so it was also a good time to test this out, and make sure it worked.

I decided to demo a similar function to that previously, but also, adding in textures too.  This demo takes the random triangles, renders them to texture, and then redraws another scene, using the textures.

Renderer: Textures.  This scene is made up of 4 images, using the same texture generated from code very similar to that of the vertex buffer objects demo.

As you can see, the original scene has been manipulated in a way that it would be hard to recreate the scene displayed without first rendering to texture.  The texture size I used was 128 x 128, as was the viewport for when I first rendered the triangles.  This scene however, is of size 512 x 512.  The original texture is seen in the bottom-right hand corner, and all the other textures have been rotated and resized.  The largest of the textures, bottom-left, is slightly fuzzy – this is because it is twice the size of the original.

Renderer API

The way I have implemented the rendering to texture function on the API is not much different to rendering as normal.  It’s a simple case of:

Renderer.RenderToDeviceContext();

or

Renderer.RenderToTexture(..params..);

Technically, rendering to texture will also render to the device context.  The main difference however, is that after rendering to the device context, the render to texture method takes in the parameters given, and will make a simple call to glCopyTexImage2D – as per normal when a client wishes to render to texture using OpenGL.  To save from code duplication, I have used the decorator pattern – the render to texture class “decorates” the original class.  In doing so, it means that I can set up texturing by first binding a texture, make the original call to render to device context, and then finish off by rendering to the bound texture.

I am trying to create some application in Qt Creator with OpenGL rendering. Stadnart example Hello GL, works fine. But there user interface is created in imperative manner. I want to use visual editor.

So I created GUI project with OpenGL support. It worked fine.

Than I add two files:

glwidget.h

#ifndef GLWIDGET_H
#define GLWIDGET_H

#include <QGLWidget>

class myGLWidget : public QGLWidget
{
    Q_OBJECT;
public:
    myGLWidget(QWidget *parent=0);
    ~myGLWidget();
     float rotation;
public slots:
    void setRotation(float a);

protected:
    void initializeGL();
    void resizeGL(int w, int h);
    void PaintGL();
};
#endif // GLWIDGET_H

glwidget.cpp

#ifndef GLWIDGET_CPP
#define GLWIDGET_CPP

#include <QtGui>
#include <QtOpenGL>
#include <GL/glu.h> // I like perspective projection, and gluLookAt

#include "glwidget.h"

myGLWidget::myGLWidget(QWidget *parent)
            : QGLWidget(parent) // I wander what that mean?
{
    rotation=0;
}

myGLWidget::~myGLWidget()
{
    ;
}
void myGLWidget::initializeGL()
{
    glClearColor(0.0,0.0,0.0,0.0);
}

void myGLWidget::resizeGL(int w,int h)
{
    int side = qMin(w, h);
    glViewport((w - side) / 2, (h - side) / 2, side, side);

    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    gluPerspective(45,w/h,0.01,10);
    glMatrixMode(GL_MODELVIEW);
}

void myGLWidget::setRotation(float a)
{
    rotation=a;
}

void myGLWidget::PaintGL()
{
    glBegin(GL_QUADS);
    glVertex3f(0,0,0);
    glVertex3f(1,0,0);
    glVertex3f(1,1,0);
    glVertex3f(0,1,0);
    glEnd();
}
#endif // GLWIDGET_CPP

And when I include glwidget.h in mainwindow.h I get such errors:

mainwindow.o: In function `myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:10: multiple definition of `myGLWidget::myGLWidget(QWidget*)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:10: first defined here
mainwindow.o: In function `myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:10: multiple definition of `myGLWidget::myGLWidget(QWidget*)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:10: first defined here
mainwindow.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
mainwindow.o: In function `non-virtual thunk to myGLWidget::~myGLWidget()':
/home/bunyk/projects/HelloGL/glwidget.cpp:19: multiple definition of `non-virtual thunk to myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:19: first defined here
mainwindow.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
mainwindow.o: In function `non-virtual thunk to myGLWidget::~myGLWidget()':
/home/bunyk/projects/HelloGL/glwidget.cpp:19: multiple definition of `non-virtual thunk to myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:19: first defined here
mainwindow.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
mainwindow.o: In function `myGLWidget::initializeGL()':
/home/bunyk/projects/HelloGL/glwidget.cpp:21: multiple definition of `myGLWidget::initializeGL()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:21: first defined here
mainwindow.o: In function `myGLWidget::resizeGL(int, int)':
/home/bunyk/projects/HelloGL/glwidget.cpp:26: multiple definition of `myGLWidget::resizeGL(int, int)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:26: first defined here
mainwindow.o: In function `myGLWidget::setRotation(float)':
/home/bunyk/projects/HelloGL/glwidget.cpp:37: multiple definition of `myGLWidget::setRotation(float)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:37: first defined here
mainwindow.o: In function `myGLWidget::PaintGL()':
/home/bunyk/projects/HelloGL/glwidget.cpp:42: multiple definition of `myGLWidget::PaintGL()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:42: first defined here
glwidget.o: In function `myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:10: multiple definition of `myGLWidget::myGLWidget(QWidget*)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:10: first defined here
glwidget.o: In function `myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:10: multiple definition of `myGLWidget::myGLWidget(QWidget*)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:10: first defined here
glwidget.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
glwidget.o: In function `non-virtual thunk to myGLWidget::~myGLWidget()':
/home/bunyk/projects/HelloGL/glwidget.cpp:19: multiple definition of `non-virtual thunk to myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:19: first defined here
glwidget.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
glwidget.o: In function `non-virtual thunk to myGLWidget::~myGLWidget()':
/home/bunyk/projects/HelloGL/glwidget.cpp:19: multiple definition of `non-virtual thunk to myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:19: first defined here
glwidget.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
glwidget.o: In function `myGLWidget::initializeGL()':
/home/bunyk/projects/HelloGL/glwidget.cpp:21: multiple definition of `myGLWidget::initializeGL()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:21: first defined here
glwidget.o: In function `myGLWidget::resizeGL(int, int)':
/home/bunyk/projects/HelloGL/glwidget.cpp:26: multiple definition of `myGLWidget::resizeGL(int, int)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:26: first defined here
glwidget.o: In function `myGLWidget::setRotation(float)':
/home/bunyk/projects/HelloGL/glwidget.cpp:37: multiple definition of `myGLWidget::setRotation(float)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:37: first defined here
glwidget.o: In function `myGLWidget::PaintGL()':
/home/bunyk/projects/HelloGL/glwidget.cpp:42: multiple definition of `myGLWidget::PaintGL()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:42: first defined here
moc_mainwindow.o: In function `myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:10: multiple definition of `myGLWidget::myGLWidget(QWidget*)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:10: first defined here
moc_mainwindow.o: In function `myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:10: multiple definition of `myGLWidget::myGLWidget(QWidget*)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:10: first defined here
moc_mainwindow.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
moc_mainwindow.o: In function `non-virtual thunk to myGLWidget::~myGLWidget()':
/home/bunyk/projects/HelloGL/glwidget.cpp:19: multiple definition of `non-virtual thunk to myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:19: first defined here
moc_mainwindow.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
moc_mainwindow.o: In function `non-virtual thunk to myGLWidget::~myGLWidget()':
/home/bunyk/projects/HelloGL/glwidget.cpp:19: multiple definition of `non-virtual thunk to myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:19: first defined here
moc_mainwindow.o: In function `~myGLWidget':
/home/bunyk/projects/HelloGL/glwidget.cpp:16: multiple definition of `myGLWidget::~myGLWidget()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:16: first defined here
moc_mainwindow.o: In function `myGLWidget::initializeGL()':
/home/bunyk/projects/HelloGL/glwidget.cpp:21: multiple definition of `myGLWidget::initializeGL()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:21: first defined here
moc_mainwindow.o: In function `myGLWidget::resizeGL(int, int)':
/home/bunyk/projects/HelloGL/glwidget.cpp:26: multiple definition of `myGLWidget::resizeGL(int, int)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:26: first defined here
moc_mainwindow.o: In function `myGLWidget::setRotation(float)':
/home/bunyk/projects/HelloGL/glwidget.cpp:37: multiple definition of `myGLWidget::setRotation(float)'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:37: first defined here
moc_mainwindow.o: In function `myGLWidget::PaintGL()':
/home/bunyk/projects/HelloGL/glwidget.cpp:42: multiple definition of `myGLWidget::PaintGL()'
main.o:/home/bunyk/projects/HelloGL/glwidget.cpp:42: first defined here
collect2: ld returned 1 exit status
make: *** [HelloGL] Помилка 1
Exited with code 2.
Error while building project HelloGL

write this, and understand that I had included not .h file but .cpp. Asking nobody helps if ask right, doesn’t it?

to be continued…

Right. Just a quick post to say that I’ve updated my webpage with an extension of an older programme in OpenGL. The previous programme displayed a cube that could be rotated on its various axis, I made changes so the cube now has a texture on each side. The programme still needs tweaking as three of the sides have a mirrored image of the texture that needs fixing.

The texture class that was created can only take Unsigned TGA files, I knocked up a pretty poor one in GIMP for the purpose of the programme just so I could test that it worked!

You can view the source files and .exe on my webpage Here

And the Video:

Thanks for reading. Comments appreciated.

So I’ve started on the Renderer library, and although this update might be coming a couple of weeks late, there’s a few demos that I’ve managed to produce as the library is slowly being developed. Much of the next few Renderer posts will be short, and will not contain much code – most of the code I am using I have already explained in earlier posts.

The first stage of Renderer I have incorporated is the use of vertex buffer objects. This is because it is pretty much the core drawing function I will be using to create shapes drawn on to the screen. Although this is not clearly shown, the first demo was to initially make sure that these vertex buffer objects work.

Using a blending function to incorporate the alpha values, I have loaded the buffers with several objects – each a triangle of random position and size, with 3 random colours, one for each vertex.  Even more so, the number of triangles is also random.

Renderer: Vertex Buffer Objects.  The screenshots show the results after loading the buffers with random triangles.

It might not be the most exciting demo in the world, but at least it shows that my vertex buffer objects work.  As a result of this, I am able to carry on, knowing that the most fundemental part of the Renderer library is in place.  For now.

So I went into university today, just to say hi to all my friends, and what not, and I managed to get dragged into the Advanced Graphics lecture they had.  And I have to say, I did find it all very interesting.

Although I’m pretty much doing just OpenGL at IGI for now on the graphics side, there is no theory based around the work I am doing.  We (I say that, as if I’m taking the course, but I’m blatently not) learnt about surface reflectance, and 3 different models used to calculate how light interact with a particular object.

Without going into too much detail (because I can’t):

Bidirectional Reflectance Distribution Funtcion: simple reflection from a surface

Bidirectional Surface Scattering Reflectance Distribution Function: subsurface scattering for translucent materials

Bidirectional Texture Function: to simulate self-shadowing/scattering

Very interesting, and very theoretical.

But that’s the problem.

The majority of academic material learnt during university, college, or school, doesn’t become relevant in the working world, unless you are doing, for example, a job such as research.  You don’t need to know the theory, you just need to know how to apply and use it, and the majority of the time, it’s already done for you.

Take OpenGL for example.  I can’t say I’m an expert at OpenGL, and I don’t think I ever will be.  But in this context of theories, OpenGL takes in parameters to describe the light model.  All the theory I learnt during university,  I don’t need to know, for OpenGL does all of it for me – all I need to know is how to use the interface to create the model.  And this annoys me sometimes.

A lot of stuff I learn at university will be very irrelevant when I come to work in a job.  Of what I learn, a lot will be interesting.  Also, a lot, not so.

And I’ve been battling with myself on whether or not to take a PhD after I graduate.  The University of Manchester, School of Computer Science offer very good scholarships for PhDs, and at this current climate in the economic situation, it might definately be something worth considering.  And maybe doing some research into graphics might be rather ideal for myself.  Okay, I can use that research to create a graphical program that uses the theories of my research, but then where does it go from there?  It may be taught in other universities, but the students don’t actually need to know how it’s done – it’s already been done for them.  Like every argument, there’s always a for and an against.

There’s a PhD open day a week next Wednesday – although it’s for entry in September 2010, I guess it wouldn’t hurt to keep my options open.

Hey guys,

a lot of things are going on at the moment. I am working on a few different gaming projects with some really interesting people.

A first version of my Super Koopa War, where the player fights Goombas, Shyguys and Monty Moles and tries to defeat Super Mario, will be released for J2ME phones in the near future. A few things regarding usability, balancing and game fun are still to do, before the Demo will be released on the bolg. This little game shall serve as tutorial on how to implement a mobile game with a nice architecture (entity system, event system, collision detection, physics and a nice animation concept) in J2ME.

Additionally, we are working on a second (top secret) project, either for the iPhone or for the PSP, since we have the PSP DevKit now at University.

To provide you guys with new stuff, I posted a new tutorial at the publications section. It is a simple Solar System in 3D. Also a first person camera has been implemented to show how things work in the source code. This example does not use OpenGL functions. Matrices, vectors and calculations are done manually. This should give an impression on what OpenGL does when someone calls gluLookAt() or glRotate(). So camera, transformations and rotations are calculated and applied by hand. Feel free to download the example and play around with it.

Note texture need to be power of 2.

The following libraries need to be linked to you app:
Ole32.lib

The following headers need to be added:

#include <imaging.h>
#include <initguid.h>
#include <imgguids.h>

Common variables:

IImagingFactory* m_pImgFactory;
IImage* m_pImage;

Initialise the library

bool InitImageFactory()
{
CoInitializeEx(NULL, COINIT_MULTITHREADED);
return (SUCCEEDED(CoCreateInstance (CLSID_ImagingFactory,NULL,CLSCTX_INPROC_SERVER, IID_IImagingFactory,(void **) & m_pImgFactory)))
}

Load the texture

bool LoadTexture(wchar_t* full_name)
{
	bool success = false;
	if (full_name!=NULL)
    {
		if(SUCCEEDED(m_pImgFactory->CreateImageFromFile(full_name, &m_pImage)))
		{
			//get the info
			ImageInfo info = {0};
			m_pImage->GetImageInfo( &info );
			RECT rc = { 0, 0, info.Width, info.Height };
			int new_width = rc.right;
			int new_height = rc.bottom;

			//create a HBITMAP
			IBitmapImage* pBitmapImage = NULL;
				if (SUCCEEDED(m_pImgFactory->CreateBitmapFromImage(m_pImage, 0, 0, info.PixelFormat, InterpolationHintNearestNeighbor , &pBitmapImage)))
				{
					//create the texture
					glGenTextures(1, texture);
					glBindTexture(GL_TEXTURE_2D, texture[0]);

					BitmapData bitmapData;
					if ((info.PixelFormat&PixelFormatAlpha)==PixelFormatAlpha)
					{
						pBitmapImage->LockBits(&rc, ImageLockModeRead, PixelFormat32bppARGB, &bitmapData );
						glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, new_width,new_height, 0, GL_RGBA, GL_UNSIGNED_BYTE, bitmapData.Scan0);
					}
					else
					{
						pBitmapImage->LockBits(&rc, ImageLockModeRead, PixelFormat16bppRGB565, &bitmapData );
						glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, new_width,new_height, 0, GL_RGB, GL_UNSIGNED_SHORT_5_6_5, bitmapData.Scan0);
					}
					glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);//GL_NEAREST);
					glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);//GL_NEAREST);

					pBitmapImage->UnlockBits(&bitmapData);
					pBitmapImage->Release(); 

					success =true;
				}
				m_pImage->Release();
			}
    }
return success;
}

Close the library

bool DestroyImageFactory()
{
        m_pImgFactory->Release();
        CoUninitialize();
}

It has been quite a while since I have worked with 16bit displays.
All my 3D developement for PC has always been done with 32bit colour displays.
This is unfortunately what happens when you try show a 32bit image on a 16 bit display.
Banding!!! Aargh.

Original (32bit image):

Nearest colour (32bit image as shown by 16bit colour scheme):

Fortunately this can be fixed with a bit of image processing (convert the image to 32k colours using error diffusion).

Preprocessed Image shown using nearest colour (32bit image as shown by 16bit colour scheme):

Much better!!

ZiiLABS, subsidiary of Creative, announced its 3rd generation media-rich application processor ZMS-08 that brings 1080p Blu-ray quality H.264 playback to low energy devices.

ZiiLABS's ZMS-08 Processor

The lower power system-on-chip is packed with impressive array of features:

• • Full HD 1080p high-profile H.264 video decode
  • Simultaneous H.264 encode and decode at 720p
  • 1080p 24fps encode
  • Accelerated OpenGL® ES 2.0 3D graphics at up to 1 Gpixels/sec
  • 2D processing, compositing, image processing
  • Advanced Xtreme Fidelity™ X-Fi Audio effects
  • Low-power 1GHz ARM Cortex processor

The ZMS-08 is aimed at small form factor devices that enable content currently accessed via the PC to spread to mobile and low-energy devices.

Imagine that, Blu-ray quality video, crystal clear video conferencing experience and game console-like 3D and sound effects on future tablets, smartphones and set-top boxes.

In Android 1.1 to Androidd 1.6 EGL configuraitons were being read/sorted worng  and thus:

nt[] configSpec = {
        EGL10.EGL_RED_SIZE,      5,
        EGL10.EGL_GREEN_SIZE,    6,
        EGL10.EGL_BLUE_SIZE,     5,
        EGL10.EGL_DEPTH_SIZE,   16,
        EGL10.EGL_NONE
};

would work on Android 1.1 through Android 1.6. However, in Andoroid 2.0 you have to use:

nt[] configSpec = {
        EGL10.EGL_RED_SIZE,      5,
        EGL10.EGL_GREEN_SIZE,    6,
        EGL10.EGL_BLUE_SIZE,     5,
        EGL10.EGL_DEPTH_SIZE,   16,
        EGL10.EGL_DONT_CARE
};

as the higher config beynd 565 was being sorted read first hence the error.

So the term alpha, in computing, has many meanings. There is alpha testing, where a piece of software is tested by giving it out to the internal users of an organisation to tear to pieces – the stage before the public get their betas (I think this is the appropriate time to say that I just got VS2010 beta 2 the other day, and it’s as sexy as hell, but more on that another time). It can also be used to describe the weighting of data in machine learning. But I’m not doing machine learning. Or testing (yet). I’m doing graphics.

The alpha I am referring to is the alpha channel used to represent a colour, and it’s very handy. Although it can be a little misunderstood, as I learnt during my experiments.

The Alpha Channel

To represent a color, you usually have the option of choosing the red, green and blue components of a color, but what if you want it to be slightly translucent?  There is an alpha component – this determines how “full” the color is.  On a scale of 0 to 1, 0 is transparent, and 1 is opaque; anywhere in between is translucent.  So this is fairly easy to declare in OpenGL.  Where red, green, blue and alpha are float values between 0 and 1:

Gl.glColor4f(red, green, blue, alpha);

Of course, OpenGL doesn’t like to make life easy for us, no.  We have to also enable blending.  This allows for the alpha channel to do its magic, and the blend function also determines on how the alpha channel is used.

Gl.glEnable(Gl.GL_BLEND);
Gl.glBlendFunc(Gl.GL_SRC_ALPHA, Gl.GL_ONE_MINUS_SRC_ALPHA);

The 2 parameters of the blend function determine how the alpha channel is used – the parameters I have used in the example are the ones best used for transparency.  These parameters allow you to do lots of different blending techniques, such as blend towards no transparency or full transparency, or reverse blend – I’m not really the one to ask on how these work, because I’m not entirely sure – you’re best looking it up.  Of course, the complexity doesn’t stop there either.

A Trick of Light

When working with transparency, the order of the objects when being drawn is important.  Especially if you are using lighting.

As a general rule, for opaque objects, draw them in the order of front to back (taking the front as the nearest to you), and for transparent or translucent objects, back to front.

For opaque objects, this is because (I believe, but not entirely sure)  OpenGL is clever enough to deduce on if an object at the back needs to drawn or not – it will not be drawn if there is an object in front of it, obscuring the camera view from the object.  Of course, the only way to deduce if there is an object in front of it, is if there is an object already there.

For transparent and translucent objects, drawing them back to front ensures that the lighting algorithm in OpenGL works properly.  As the object is drawn, it OpenGL will always look at what is behind the object, and try to blend the current object being drawn with what is behind it accordingly.  An object at the front with transparency property will not take into account what is behind it, if the object behind it is being drawn after it.  I found this out when I was trying to draw partially transparent boxes.

Transparency Drawing.  This shows how drawing partially transparent objects has to be done in a particular way for OpenGL to display the scen properly.  The top two pictures show the component this cube is made out of: an blue opaque base, and a clear, green front.  The picture in the bottom-left shows what happens when the translucent part, at the front, is drawn before the opaque part, behind it.  It looks exactly the same as the picture in the top-right – this is because it both pictures, the front is blending what was initially behind the it – the black background.  The bottom-right picture shows the drawing when drawn in the correct order, base first, then the translucent front.

Anti-Aliasing

Anti-aliasing is an effect used to make lines and shapes appear smoother, and less discrete, or pixelated.  This effect does this by a slight blurring, and in effect, is using blending.  As a result, the same rule of drawing transparent objects from back to front should be applied to when trying to use an anti-alias effect.

There are 3 types of anti-aliasing that OpenGL offers with easy access.  Any other types of anti-aliasing, you will have to look elsewhere – I am no expert of OpenGL.  Essentially, if you refer back to when I was creating fonts, it uses mip-mapping as a way of keeping detail and quality as images are getting smaller and smaller – you could argue that this is a form of anti-aliasing too.

The 3 OpenGL offers are line, point and polygon anti-aliasing, and unsurprisingly, they refer to lines, points and polygons.

These are easy to switch on with an enable call.  You can then provide OpenGL with a parameter on how you want the anti-aliasing effect to behave.

Gl.glEnable(Gl.GL_LINE_SMOOTH);
Gl.glHint(Gl.GL_LINE_SMOOTH_HINT, Gl.GL_FASTEST);

Gl.glEnable(Gl.GL_POINT_SMOOTH);
Gl.glHint(Gl.GL_POINT_SMOOTH_HINT, Gl.GL_NICEST);

Gl.glEnable(Gl.GL_POLYGON_SMOOTH);
Gl.glHint(Gl.GL_POLYGON_SMOOTH_HINT, Gl.GL_DONT_CARE);

The hints describe how you want OpenGL to do the anti-aliasing – you can either have it as the nicest OpenGL will allow, the fastest to calculate to save on speed, or nor preference.

Anti-Alias Triangles.  The picture on the left is similar to the picture on the right, with the exception that anti-aliasing is on.  You can notice a subtle difference in the smoothness of the edges on the triangles.  OpenGL achieves this effect using blurring and blending techniques.

As a side note, I’ve now finally started the Renderer component!  So the majority, if not all, of what I have covered so far regarding OpenGL will go into this component.  This will mean that I won’t be updating big tutorial-esque posts on OpenGL anymore – there might be something every now and then.  I will however, be posting any revelations I come across!

]]> http://ubuntugenius.wordpress.com/2009/11/05/add-some-really-slick-screensavers-to-ubuntu/ Thu, 05 Nov 2009 13:58:01 +0000 ubuntugenius http://ubuntugenius.wordpress.com/2009/11/05/add-some-really-slick-screensavers-to-ubuntu/

If you want a whole bunch of amazing screensavers to add to the default ones that come with Ubuntu, you can do so by installing one package (you will need the Medibuntu repo for this). rss-glx is a GLX port of the Really Slick Screensavers collection, with several other OpenGL screensavers ported from other platforms included. The screensavers will be integrated into your installed screensaver manager (Gnome-Screensaver, XScreenSaver or KScreenSaver), but can also be run as stand-alone applications.

This how-to concerns, including the functions needed for using Vertex Buffer Objects or VBOs; but in Qt framework. In short, this answers questions like:

“ glGenbuffers : identifier not found error

How do I resolve this (when working in Qt)? “

This article at gamedev explains the process very well. The article is old, but I would recommend reading it since you then understand what the problem is and why is it giving you this error.

After you’re done reading that, you’d know that you are still using openGL v1.1 and need to access VBOs which is a feature of openGL v1.5. This is done by using v1.5 as extensions and interacting with the device drivers(assuming you have the latest drivers and they support v1.5), which is facilitated in code by specific function pointers.

By now, you’d know how to get this fixed if you were on a windows machine. But, I was using Qt and needed a way to get it to work with that. I came across these files:

glextensions.h and

glextensions.cpp

provided by Qt in one of there demos (boxes). These would resolve the functions you need for using VBOs. To get it to work, the code is not trivial.

After including the files in your header, one needs to “resolve()” the associated functions with a “context” (which is provided by the QGLWidget (or a class that you might have derived from it) ).

This is how I resolve them from within my class which derives from QGLWidget:

getGLExtensionFunctions().resolve(this->context() );

Functions like glGenBuffers, glBindBuffer, glBufferData etc are now ready to be used.

Also, I heard a lot of people using GLEW but I did not explore that route, so if you are stuck that might be something worthwile to checkout.

I hope it this article has saved you both, hours and tears. Let me know if you need any help.

(PS: When you call the resolve() function, the context should be available. I am still not 100% clear on how Qt manages the context for you, but I call it within InitializeGL(), since the context would be ready when the control reaches there. Also, take a look at the glextensions files to see they do pretty much the same thing as mentioned in the gamedev article )

Just note for OpenGL installation on Ubuntu 9.04

You can use Synaptic Package Manager to install package name glutg3-dev .  The list of dependency packages , which are automatically installed, are the following packages:  freeglut3-dev libgl1-mesa-dev libglu1-mesa-dev libxt-dev mesa-common-dev xlibmesa-gldev.

Often you have to trun off Log.* statements, Debug.* statements, etc so I sue a simple System.out.print set-up:

public class SystemOutPrint {

	/**
	 *
	 * @param str
	 */
	public SystemOutPrint(String str){
		System.out.print(str);

	}

	/**
	 *
	 * @param obj
	 */
	public SystemOutPrint(Object obj) {
		System.out.print(obj);
	}

	/**
	 *
	 * @param obj
	 * @param str
	 */
	public SystemOutPrint(Object obj, String str) {
		System.out.print(obj);
		System.out.print(str);
	}

Lighting and Materials. Theoretically, it’s one of the first things you should really learn when you’re getting into graphics – it’s usually within the first 10 tutorials that you’ll pick up from anywhere. In theory, no one should have much of a problem with it. In theory, theorists should have done their research before making these theories. But then again, I am no theorist.

This carries on from my last post.  So we’re going to touch up on how I made the planets glow like they do in the picture, and how lighting and materials have been an absolute pain (that is, until I finally decided to do a little reading).

Dim Lighting

The first time I touched lighting and materials was in university during an examples class – and it was easy.  All I had to do as change a couple of numbers, and voila, the lighting changed.  It’s a little bit more difficult when I was trying it out for myself.  The first thing I tried to demo was a rotating diamond, with a static light shining on it.  As the diamond rotated, the light was moving up and down.  How, and why, I have no idea, and I still don’t.  Second thing I tried was to have the light in the middle of the scene, and 2 gluSpheres either side, so each would have only the side facing the light shining, and the other dark as night.  Nope.  As I drew the second sphere, it would look exactly the same as the first – light shining on the same side.  And no idea still as to why.  Maybe I’m missing something really important, that not many people have encountered before (by the way, quite a few people have had the problem with the light moving up and down as the object rotates), or maybe I’m just unlucky.

It could be seen as a bad thing that I still don’t know why the lights weren’t working the way I wanted them to – I’ve managed to get over it.  Because now I know how lights work, and I don’t really see why I would want to replicate the problems again.

Lighting & Materials

The calls to create lighting and materials are very short and simple.  Initially, you need to enable lighting, and also, enable the lights – OpenGL allows you to use 8 lights in total, and say that you should really reconsider your model if you need any more.   So apart from the enable call, there are only 3 calls that you really need to consider. The first describes the general light model, and the other two each describe either the lighting or the materials.  These are, respectively:

Gl.glLightModelfv(pName, params);

Gl.glLightfv(light, pname, param);
where light is the light number, from Gl.GL_LIGHT0 to Gl.GL_LIGHT7.
and pName is either Gl.GL_POSITION, Gl.GL_AMBIENT, Gl.GL_DIFFUSE or Gl.GL_SPECULAR.*

Gl.glMaterialfv(face, pname, param);
where the face is either Gl.GL_FRONT, or Gl.GL_BACK.
and pName is either Gl.GL_AMBIENT, Gl.GL_DIFFUSE, Gl.GL_SPECULAR, Gl.GL_SHININESS or Gl.GL_EMISSION.*

(bearing in mind that the suffix fv applies to float arrays only – this needs to be changed if you were to use any other, say double – this would be dv).

*For now, I will only be looking at the specific parameters I have enlisted.  For further information, you can find it in the OpenGL Documentation.

Placing A Light

Where you place a light in the scene is very important – this is where the light source is, and will be used to calculate how light bounces and reflects off materials.  In order for you to be able to place your light in a desired position, you need to understand how it is set up.  To set up a light, you use the glLight() call, with parameter GL_POSITION.  Obvious right?  The params should be a vector, indicating x, y, z and w.  x, y and z are your co-ordinates of the light, and I’ve a feeling that w should always be 1.0f in order for it to work this way.  However, despite making this call, the light is not necessarily in the place you have specified in world space.  The call will always look at what is the current modelview matrix at the time of the call, and will always place the light specific to the matrix.  Therefore if the entire scene is to be translated backwards so it will fit into a frustum view volume, make a call to set the light position after the translation.

Lighting and Material Properties

The properties I have outlined, you will see everywhere in material and lighting.  The properties describe how the light reacts to surfaces.

Ambient
Describes the general lighting of an object – it has brilliantly been quoted from my 2nd year course as, “it just hangs there”.  As a result, it does not take into account how light reflects off a particular object – it is the general lighting – and as a result, it will not help to define the contours of any shape.

Diffuse
This property describes the diffuse reflection of a material.  This takes into account of how the light will reflect off a particular surface, and how some of the light will also be absorbed.  Using the ambient property will describe the general color of an object, whereas to define how the object looks in light, use the diffuse property.

Specular
Lighting will sometimes reflect entirely off an object – this depends on the angle the light is reflecting off the surface at.  Specular reflection reflects the light shining onto an object and makes it appear shiny; the scale is determined by the shininess property.

Shininess
The describes the sharpness of the light reflected due to specular lighting.  The higher the value, the more shiny it is, and therefore the sharper the image of the light reflecting off the object.

Emission
This property describes the amount of light that is emitted off an object.  In OpenGL, the property makes the object appear as if it is emitting light, however, in the model, this light does not affect any other objects – you will need to use an actual light for this.

Setting the material properties will affect how light reacts to an object – the light properties also need to be set for this to happen.  All of the above properties take a float array, representing red, green, blue and alpha, with the exception of shininess, which takes a number between 0 and 128.

Light Properties.  This depicts how, from left to right, ambient, diffuse and specular lighting can be used together to represent a 3-D sphere, far right.

Solar System

So now you know how it is done, it’s time to put it all together.  In my solar system model, I used two lights: one to represent the sun; and the other, to add a little extra.

To set up, we describe the light model, and then the lights we’re going to use – do this at the start so it doesn’t get called millions of times in the render loop. As we are simulating outer space, the light model is set at very low, near black.  The ambient and diffuse settings for the lights are also set up.

Gl.glLightModelfv(Gl.GL_LIGHT_MODEL_AMBIENT, new float[] { 0.05f, 0.05f, 0.05f, 1.0f });

Gl.glLightfv(Gl.GL_LIGHT0, Gl.GL_AMBIENT, new float[] { 0.0f, 0.0f, 0.0f, 1.0f });
Gl.glLightfv(Gl.GL_LIGHT0, Gl.GL_DIFFUSE, new float[] { 1.0f, 1.0f, 1.0f, 1.0f });
Gl.glLightfv(Gl.GL_LIGHT1, Gl.GL_AMBIENT, new float[] { 0.0f, 0.0f, 0.0f, 1.0f });
Gl.glLightfv(Gl.GL_LIGHT1, Gl.GL_DIFFUSE, new float[] { 1.0f, 1.0f, 1.0f, 1.0f });

Gl.glEnable(Gl.GL_LIGHTING);
Gl.glEnable(Gl.GL_LIGHT0);

You will have noticed that I have also enabled lighting, and Light0, but not Light1.  Using light0 as my main light to represent the sun, this will be constantly on, and therefore we do not need to call this in the render loop, as it only needs to be called once.  I am using Light1 as an effect on the sun, to make it appear 3-D, and therefore should only be turned on when I render the sun, but turned off when I render everything else.  The reason behind using the light as an effect on the sun is because I am setting the sun to have an emission property.  The makes the sun appear as if it is giving out light.  Not only this, but the light source representing the sun is inside the sun sphere, and will not affect the outside, making the sphere look flat.  Turning a light onto the sun, and using a diffuse property, will make the sun appear 3-D.  Now to render the scene.

First we translate the scene into view, it is here, where we place the light representing the sun.  Note that I am placing the light position after the translation so the light is also in view.  The light is not, however, affected by the rotation after the position call, nor any other call after regarding the matrix stacks.

Gl.glMatrixMode(Gl.GL_MODELVIEW);
Gl.glLoadIdentity();

Gl.glTranslatef(-2000.0f, 0.0f, -4000.0f);
Gl.glLightfv(Gl.GL_LIGHT0, Gl.GL_POSITION, new float[] { 0f, 0f, 0f, 1.0f });
Gl.glRotatef(30, 1, 0, 0);

We want to draw the sun, with a radius of about 140.0f, and to have a light shining onto it so it appears 3-D.  This is where Light1 comes in.  It is placed just outside of the sun so it is able to hint the sphere with a bit of light.

Gl.glLightfv(Gl.GL_LIGHT1, Gl.GL_POSITION, new float[] { 150.0f, 150.0f, 150.0f, 1.0f });
Gl.glEnable(Gl.GL_LIGHT1);
Gl.glMaterialfv(Gl.GL_FRONT, Gl.GL_AMBIENT_AND_DIFFUSE, new float[] {1.0f, 1.0f, 0.5f, 1.0f });
Gl.glMaterialfv(Gl.GL_FRONT, Gl.GL_EMISSION, new float[] { 1.0f, 1.0f, 0.5f, 1.0f });
// Draw GluSphere here
Gl.glDisable(Gl.GL_LIGHT1);

I have used a little shortcut here, declaring the ambient and diffuse property at the same time.  This is very useful, as the cahnces are, these will be the same values for the majority of basic objects anyway.  Enabling the light before and after drawing the sun makes sure that the light only affects the sun and no other object that is being rendered.  Now we are free to draw the other planets.  Using a similar approach, we set the position, and material, and draw.  We only need to set the material once if the following objects use the same material.  Similar to glColor() – you only set the color if the next vertex to be drawn is a different color to that of the current one being drawn.  Therefore when we draw the other planets, we have to make sure we set the emission to black, otherwise it will appear all the planets are giving off light!

Do bear in mind that in order for your lighting and materials to work properly, enable lighting.  The material settings will automatically override the color settings you have, so if you want to draw an object without the material lighting, just remember to disable it first!

I know this post has been very long, slightly overdue, and may seem like it’s been cut short, and to be fair, it could be a lot longer and more well covered.  I’ll try to keep the next one shorter, I promise!

]]> http://codelab.wordpress.com/2009/10/30/opengl-stereoscopic-anaglyphs/ Fri, 30 Oct 2009 01:27:51 +0000 Nuclear http://codelab.wordpress.com/2009/10/30/opengl-stereoscopic-anaglyphs/

An anaglyph is a combination of two images into one, in such a way that they can later be separated by viewing the image through appropriately colored transparent filters. The objective is to present slightly shifted views of the same 3D environment to each eye, in order to achieve depth perception (i.e. really perceive the 3rd dimension).

I’ve never dealt with anaglyphs in the past, but during my recent week-old obsession with stereoscopy, I’ve stumbled upon a pair of free anaglyph viewing glasses (made out of cardboard and cellophane of course). So I couldn’t help but try to find out how I can use them with my own programs.

I dug up a small dungeon editor I’ve written some time ago, and hacked stereoscopic rendering into it. I implemented various stereo rendering modes including cross-eyed (side-by side images), quad-buffered (the native OpenGL stereo mode), and anaglyphs.

Quad-buffering is of course the ideal method to present stereo views in OpenGL, but it requires support from the graphics driver and expensive hardware such as shutter glasses or a pair of polarized projectors and polarized glasses.

The problem with the glasses that I’ve got is that all articles regarding anaglyphs I’ve found on the internet talked about either red/blue or red/cyan glasses, while mine was obviously neither. It turns out my glasses are for a new variety of anaglyphs which go by the name ColorCode3D and are supposed to be able to keep more color information than previous red/blue and red/cyan methods (which generally only work for grayscale images).

This color-code thing is apparently patented and there’s no mention anywhere on how to combine stereo images for viewing with color-code glasses. The company who owns the patent has released a program for converting stereo pairs of images to colorcode anaglyphs, which is of course proprietary and doesn’t come with source code, ergo useless.

Then I remembered that there’s an upside to a patented algorithm if you choose to completely disregard patent law, which I definitely do. In order for an algorithm to become patented, it must be described in detail in a patent application which must be filed at the patent office. All such patent documents are publicly available at the web site of the US patent office. So I just got the patent document, and implemented the algorithm from that description.

It turns out the process is extremely simple, although just outside the reach of the OpenGL fixed function pipeline, which can be used to handle red/blue and red/cyan anaglyphs easily by employing additive blending and color masks. To combine the left/right stereo pair into a single color-code compatible image:

• The red channel of the left image is used as the red channel of the output image.
• The green channel of the left image is used as the green channel of the output image.
• All three color channels of the right image are converted to grayscale as follows: , and are used as the blue channel of the output image.

Here’s the small GLSL program I used to combine the two left and right images, previously rendered into two textures:

uniform sampler2D tex_left, tex_right;

void main()
{
	vec3 left = texture2D(tex_left, gl_TexCoord[0].st).rgb;
	vec3 right = texture2D(tex_right, gl_TexCoord[0].st).rgb;

	vec3 col, coeff = vec3(0.15, 0.15, 0.7);
	col.r = left.r;
	col.g = left.g;
	col.b = dot(right, coeff);

	gl_FragColor = vec4(col, 1.0);
}

The result is fantastic, I’m using the space navigator to navigate in the 3D dungeon without taking my eyes off the screen, and the stereoscopic effect is very evident indeed, creating the illusion of depth quite effectively.

Here are a few of screenshots in both color-code and the more common red/cyan anaglyph variety (note that I don’t have red/cyan glasses, so I can only assume that the red/cyan rendering works correctly, I haven’t tested it).

The second one with the jutting pillar is particularly nice. The geometry crosses the zero-parallax plane into the negative subspace, making the pillar seem to “come out of the screen”.

References

1. Paul Bourke, Calculating Stereo Pairs
2. Paul Bourke, Creating Anaglyphs using OpenGL
3. US Patent #6,687,003: Method for recording and viewing stereoscopic images in color using multichrome filters