Apr/040
Reality Dysfunction
I just finished reading the Nights Dawn trilogy by Peter F. Hamlinton. It was really a remarkable book, and I had to buy the second book in the series because I could not wait for the library to get it from the guy who had it borrowed. If you are in need of some really high class science fiction I really recommend these books totalling in more than 3000 pages.
I have had some fun at work these past days where I have implementet a cloth renderer. I started out using a fairly simple spring system but I started implementing a more physically realistic model where the spring forces are calculated via Hooks law for springs and velocity and position is found using integrati
on. The result was fairly chaotic since I used Eulers integration method which is a highly inaccurate approximation of the real integral. Tomorrow I plan to move to verlet integration as explained in Thomas Jacobsens (of Hitman fame) article. The application is written using the OpenGL Performer graphics engine by SGI (which is used only for displaying the mesh) and the virtual reality framework vrJuggler, it is written to work with our GNU/Linux rendering cluster counting 4 machines (one machine for each of three projectors, and a controlling workstation). I am looking forward to see it in stereo in the Panorama.
Apr/040
Engine Scripting
I am thinking about how to incorporate a scripting language into my engine. Luckily aveng, gimpster and me implemented a compiler from a scheme-like language to a bytecode format interpreted by a lean VM written in C. I plan to make that VM the core of the scripting functionality, which would enable me to have a compiled scripting language. How to actually use it is the hardest part. I'm thinking about enabling the user of the scene graph to specify a script that will execute during the application stage of the rendering loop, that way animation scripts can be written in scheme and just inserted appropriate places in the scenegraph. For instance a script controlling the movement of a door can be writtens once in scheme and attached the scene-graph at leafs representing doors. Of course, one could write many different door scripts, all in scheme, and use them all as they see fit.
Another feature which could be cool and prove priceless for people scripting for the engine would be to enable the engine to track changes in the scripts and automatically reload them. That way you can code many interesting aspects of the scene graph - and debug them - without even restarting the main binary! All this comes at the price of running the scripts, which will be fast since the scripts are compiled into compact bytecode running on a VM complete with garbage collection.
Mar/040
VBO’s
The meshes in the scenegraph are now moved to VBO's. It did not raise the framerate when rendering a typical Quake3 level that much, but there is still room for experimenting with the number of VBO's and how they are used.
Mar/040
Vacation
This week has been free of lectures for me, as will the next, giving me some time to relax and work no my engine. I have added a text renderer for the OpenGL backend which enables me to (finally) have a FPS counter. Support for interleaved vertex data for mesh objects was also added and I started preparing the mesh objects for use with the all-so-popular VBO's for OpenGL. I'm thinking of compiling the scenegraph at load time into some intermediate format before rendering, where all the static meshes is moved to a vertex buffer local to the GPU. I am still considering how to do it without breaking API independence. At work the integration of our new cluster is moving along nicely, I am looking forward to playing with it, vrJuggler takes some getting used to.
In other - not so geeky - news, I have spent my weekend relaxing with my girlfriend, and enjoying my newest toy, an iRiver 380 portable Ogg Vorbis player with radio and mp3 support aswell :). I have also been ordered to use Microsoft Messenger by my girlfriend. So if you want to say hi, you can reach me there with the email address tho_i_hate_spam_ooms@bananus.dk
.
Feb/040
Multitexture and Lightmaps
I added multitexture support to the generic mesh object in the engine and added the lightmaps from the imported Quake 3 level, the result can be seen in this post. The shot was rendered in a single rendering pass using the multitexture extension.
Feb/040
Another Week
I had a quiet weekend, I went to visit my parents and my girlfriend. The hours in the train was spent coding on my engine. I refactored the code some and was able to remove two components and moving their limited functionality to other components. Specifically it is now the responsibility of the application framework to swap the backbuffer in double buffered scenarious. The renderer will just draw on the active context and not worry about anything else. This makes sence conceptually also, the application should be able to control the buffers. All needed to move the engine to a new platform now is to fill in the OS specific bits in the application framework. If another renderer needs to be written a new version of the renderer class has to be written. As of now I have written an OpenGL renderer and a GLUT and a SDL application backend. I would like very much to write some more but that does not have top priority.
The engine also saw some new functionality added, a renderstate representing a light of some sort. When the light is added to the renderstates of a node it is regarded as "turned on" for that node itself and for all children. Conceptually there are no limits for what kind of light it could be, but it is currently limited to a simple directional light source with ambient, diffuse and specular components. In the OpenGL renderer the light is implemented using a normal OpenGL light but in the future it could also be used in a preprocessing step for lightmap calculation using some sort of global illumination/raytracing technique, the sky is the limit.
At work I am currently workning on a program which extracts frames from a DV camera using the ieee1394 (firewire) port of the host computer. To do that I choose the dv1394 high level kernel module for firewire input and the libdv codec for interpretation of the DV frames. Only problem is that the latter is horribly undocumented so using it is very hard without looking through the obscure source of programs accomplishing tasks similar to what I'm doing.
Well, that was another morning spent rambling, I'm leaving for uni now, see ya.
Jan/040
The Blobs are Coming
So another semester is upon me. I've been coding some on my Engine lately. I've added an algorithm to polygonize scalar fields using the marching cubes algorithm. The algorithm also generates normals for each vertex using interpolated gradient vectors calculated at lattice points. The resulting mesh is enviroment mapped producing a fairly cool look. I added metaballs to make some eyecandy and the result is nice. It might need optimizing but I might just skip that and move on to other aspects off the engine.
Dec/020
Supertunnel
Got an email from Lee containing a small list of things needed to be done to my good old supertunnel (check project page) in order to get the damn thing to compile on Linux. He even added a simple Makefile. I've applied the changes and added it to the supertunnel part of the project page. Enjoy :) (Oh, and don't mind the compiler warnings, if they aren't there it ain't funny :) )
Jun/021
Quake 2 MD2 Model Loader
Well, we failed to beat Senegal, but since France drawed against Uruguay we still have a pretty good position in the group.
I've uploaded the source code to my MD2 model loader, it supports:
- Loading of .md2 files
- Texturing of the models
- Smooth animation using linear interpolation across keyframes
Besides from that it integrates nicely to my scene graph library which I will release when It's more mature.I agree on the fact that making an MD2 loader is a fairly easy task, I did it mainly to test my lib and I was tired of testing with simple primitives only :) (yeah yeah, I know that the models is built of triangles which is simple but you get my point!). If I were to continue working on the MD2 loader I might consider supporting tristrips and trifans since I would speed up rendering a great deal.
Anyways, the source is four files in total,
- ThMD2Object.cpp: The actual loader, it is a class derived from a generic "Geometry" class in my scene graph.
- ThMD2Object.h: The header file for the loader class, contains the struct for the MD2 file as well. The rendering code is seperated from the actual MD2 object to allow me to code several different renderes based on different API's, for now I've only coded a bit of the Glut/OpenGL renderer, but you should be able to derive from my virtual "Renderer" class and code the MD2 renderer yourself.
- ThGlutRenderer.cpp:The code responsible for the rendering of the model (and other varius things, except for the MD2 code it is mostly incomplete).
- ThGlutRenderer.h: Header file for the renderer.
Jun/020
World Cup and MD2 Model Loader
So, France lost again Senegal, not quite what I had expected and I'm not sure It's a good thing for Denmark, which is facing the Uruguay in a few hours in a game we simply _must_ win.
I passed my belt-test, wee! I climbed two degrees and earned the right to wear the orange belt!
I might upload some new source one of these days, I've had a MD2 model loader finished for quite some time now it does interpolated keyframe animation and loads them with textures and all. I'm not quite sure how much of the code I'm ready to release at this stage since it uses my new (and very untested) scene-graph engine which is quite heavy on code and not ready for you guys yet. But I'll definetly upload the code to the loader itself and the actual render, which is seperated from the loader since the scene-graph uses a visitor-pattern approach to rendering.
Well, the match starts in an hour or so and I' haven't had breakfast yet, see ya. AND CROSS YOU FINGERS FOR DENMARK!