#some maya plugin

Recently I spent most of my time finishing up my small Maya-Plugin. To support my group project I decided in december to do a small static mesh exporter for Three.js' JSON-Format. After finishing the prototype using Mayas Command API and xform, I noticed that these tools are simply not suitable for a processing and computing intense task. Every export of an average-poly model took over 2 minutes, so I was looking for another way to implement the exporter. Since the coursework was intended for python scripting or animation, I decided not to write a C-Plugin for Maya, but noticed that the C API is exposed to Python as well. After rewriting the plugin using the Maya API I was finally able to debug the last leftover bugs and polished the plugin.

#some news on server technology

The Server Design Summit was recently and Partha Ranganathan was talking about HP Labs Nanostore technology. It's an approach to layer processors and add memory to them as well, basically this means hopefully better memory access times, but also less Watts. For the memory in Nanostores they wan't to use HP's Memristors. A processor with this technology would need 60% less energy for the same performance.
The plan is to be able to plug-in multiple Nanostores into a board to get more performance if needed. HP is on a good track with their research project, if they succeed it hopefully means less cpu cache and memory problems in high performance applications.

#News Article by EETimes
#2011 Paper on Nanostores
#Video guide on memristor technology by Stan Williams

#some research on parallel opengl

After finishing the basic classes for an ingame-GUI-system, I started looking at how I want to multi-thread my program. In general with older OpenGL specifications, it is not easily possible to parallelise the drawing process, but there are certain things, that can be done.
The OpenGL context is bound to a single thread, so the context is inaccessible for other threads, but it is possible to access data at the same time, if for example VBO-data is mapped, this data can be accessed from other threads (useful for optimising CPU-side skinning). Another possibility is to create another context and let the contexts share ressources.
Anyway in the end the best thing is to simply have a drawing thread and handle all the other stuff (like physics, networking etc.) in other threads, so the drawing thread is simply drawing the last state, while the other threads are calculating the next state of the game.

#Parallel OpenGL FAQ
#Intel: Designing the Framework of a Parallel Game Engine

#some tutorial on FBOs

The final render target of OpenGL is a framebuffer. External framebuffers can be used to render to textures. OpenGL provides an interface to create these framebuffers, also known as Frame Buffer Objects (FBO).

To illustrate how FBOs are used and what they can do, here is an approach to implement rendered textures:

You start by creating the texture and setting the parameters of the texture.

 
GLuint texture = 0; 
glGenTextures(1, &texture); 
glBindTexture(GL_TEXTURE_2D, texture); 
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, width, height, 
             0, GL_RGBA, GL_UNSIGNED_BYTE, NULL); 
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, 
                GL_NEAREST); 
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 
                GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, 
                GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, 
                GL_CLAMP_TO_EDGE);
glBindTexture(GL_TEXTURE_2D, 0);

This is straight-forward and similar to the usual way, you set up a texture using OpenGL, but something people don't notice is, that the last line, which is unbinding the texture is really important!

To be able to attach a texture to an FBO it needs to be unbinded at that time, as well as when something is rendered into the FBO.

The next step is to setup a depthbuffer for depth-testing, may wonder at this point why setup the texture and depthbuffer before the FBO, there is no real reason, but what is important is that textures, buffers attached to a FBO have the same size as the FBO!

 
glGenRenderbuffersEXT(1, &depth);
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, depth);
glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, 
                         GL_DEPTH_COMPONENT, 
                         width, height);
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, 0);

Again it is important to unbind before attaching something to the FBO.
Now finally create the FBO:

 
glGenFramebuffersEXT(1, &fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, 
                          GL_COLOR_ATTACHMENT0_EXT, 
                          GL_TEXTURE_2D, texture, 0);
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, 
                             GL_DEPTH_ATTACHMENT, 
                             GL_RENDERBUFFER_EXT, 
                             depth); 

After creating the FBO the only last thing left to do is, checking if everything worked fine and then unbind the framebuffer:

 
GLenum err = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if (GL_FRAMEBUFFER_COMPLETE != err) 
    std::cout << glewGetErrorString(err) << endl;
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

The depth-buffer is optional for a rendered texture, but it is quite useful to know about it for other applications. Now everything is setup to render to the texture simply bind the fbo and then render what should be in the texture, but it is important, that the viewport is not bigger than the buffer, so if you want to render to the full size of the texture you would do it like this:

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo); 
glPushAttrib(GL_VIEWPORT_BIT); 
glViewport(0,0,width,height); 
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
// RENDER STUFF IN THE TEXTURE...
glPopAttrib();
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

If you want to use the texture now you can do it the usual way, nothing special about that...


Some more references:
#more infos and speccs on FBOs
#interesting question on how to utilize FBOs

#some research on quadtrees

I just did some research on QuadTrees, because I am thinking about using them for an efficient in-game event system, that would be suitable for big MMOs to be able to process the vast amount of events on the server-side.

The most interesting advanced QuadTree implementation I came across is a so called Skip-QuadTree, which has several advantages, but do the reading yourself if you are interested:

#Skip-QuadTree publication
#Presentation of the same group
#Another paper dealing with quadtree and more
#Presentation of quadtree utilized in distribution system

#some project

After the x-mas break and the coursework time I started a new small personal project again. My personal goal now is to build a simple framework I can work with for further coursework or small games.

I decided to use the SFML-library for cross-platform window creation and input handling et cetera and use glew for drawing. Both libraries integrate seemlessly and SFML even allows a lightweight window creation perfectly suitable for game purposes.
The makefile I wrote is currently just working on OSX, but other operating system will be added in the future. The cross-platform capabilities are available and will be used later on.

The major concern I have at the moment is that OSX Lion is still not supporting a newer version of OpenGL and I would love to work with 3.3+ (and the new GLSL version) but unfortunately I have to live with that.

I will update on my progress later and also publish my git repository. After finishing the basic framework I am planning to implement an skip-quadtree based event system to do some research on event systems suitable for big interactive game-worlds (e.g. MMOs).

#some review of skyrim and some research on water

I am wasn't really posting anything. Right now I am focusing on finishing the coursework for this semester, where some informations and git repositories are coming up.

Anyway in my spare time I started playing Skyrim.

Skyrim is brilliant!

Gameplaywise it's still the same, but if the gameplay is fine why do big changes. For me as a hopefully soon to be graphics programmer some of the graphics are pretty impressive.

First of the general graphics are good. As far as I know they were sticking to DX9, which is quite interesting. They did an awesome job on the terrain engine, which has great viewing range and great look. 

The nicest details although in my opinion are the water effects:

1. Water dropping from the ceiling

2. Flowing rivers (although not as nice as the FlowMaps presented by Valve at SIGGRAPH)

3. Waterfalls, White-Water-Effects

All this supports the natural look of skyrim and underlines the great work they did on the detailed world.

So there is loads of material to get an impression of Skyrim effects on the internet, but to save you some time, here are some links on flow maps. 

#The original valve presentation

#and a really good in depth article about it