Great news from the QuakeCon 2010. id Softare released the Wolfenstein: Enemy Territory source code under GPL terms.
I’m going to create a new branch called ET-XreaL soon. It will contain the vanilla ET engine with the renderer replaced by the XreaL one.
I already diffed the vanilla Q3A renderer code with the ET one and there aren’t many changes. Most changed lines contain the new skeletal animation code and there is some new foliage and decal rendering code. It is not particular difficult to merge those changes into the XreaL renderer.
I also need to fix a few things. The XreaL renderer is compatible to most Q3A shader keywords but a few are broken because compatibility to old assets had no priority in the original XreaL game project.
And that’s the next point. As some people expected … the original XreaL game project is dead and I won’t waste my resources on dealing with artists again.
The ET-XreaL branch will be an engine project which is interesting for ET mod people.
I haven’t worked on the renderer for almost a year. However I would like to demonstrate a feature that I developed last year.
Parallel Split Shadow Maps (PSSM) for sun shadows.
Imagine. ET could look like that.
It is a demonstration map for testing parallel split shadow maps.
The grass and the trees are animated using the GPU. The scene renders at 60 fps on a Geforce 8800 and each frame contains up to 1 000 000 polygons.
A lot of people were asking for a roadmap and who is working on what. I installed a project management web application at http://redmine.xreal-project.net where you can see what is currently going on and a roadmap based on a ticket system and so on. I still have to add a lot tickets of work that is done and stuff that needs to be worked on. Most of the development has been coordinated with communication via ICQ or IRC until now. There are a lot of people who want to contribute and the new web application is a good way for everybody to see who is working on which tasks and it avoids conflicts effectively. However WordPress and Redmine use different password encryptions so you need to create a new login on the Redmine site to fill bug reports. You can also reach the new site if you click on the Development page of this blog.
Now I want to show you the need of Vertex Buffer Object based rendering. Usually most open source quake based game engines have a similar renderer design to id Tech 3 nowadays. They usually use vertex arrays (VA) or compiled vertex arrays (CVA) that they create every frame by processing the entire scene geometry. You usually find this practice in IOQuake3 (of course), all IOQuake3 based games like Urban Terror or Tremulous, Q2E, QFusion, Overdose (at least an old version) and Alien Arena. This is a design that worked well in 1999 but it is a quite bad practice in 2009.
XreaL follows the advices of GDC papers and uses VBO based rendering for almost everything to avoid this horrible CPU bottleneck. The model geometry is uploaded like textures and don’t have to move over the PCIe bridge every frame.
There is a nice heavy benchmark map called tvy-bench.pk3 for Quake3 by hipshot that could be found at http://www.zfight.com. It is really nice and contains a test scene with really many polygons.
To make it short. Traditional renderers don’t give you more than 30 fps no matter what high-end GFX card you have. The XreaL renderer gives you more than stable 125 fps.
I recently had a look at the Unreal model file format specifications and just thought: Hey it looks very similar to the Doom 3 stuff! So I started to write a .PSK model file loader and even got animations from the .PSA files to work!. My previous .MD5Mesh/.MD5Anim code is stable but I have to admit that it is easier to write importers and exporters for the Unreal format.
EDIT: I removed the screenshots showing player models from UT2004 and UT3 because Epic Games asked me kindly to remove them.
I finished my implementation of a true 64 bit HDR rendering pipeline. Interesting is that Q3Map2 works with HDR values internally. So I changed the map compiler XMap2 to save lightmaps, the light grid and all other light related information in a new XBSP format without the ugly colour normalization that Q3Map2 usually does when it saves the lightmaps as .tga files. Finally I can have lights that are really bright and the camera uses an adaptive tone mapping algorithm that adjusts the scene exposure automatically based on the average scene luminance. I tested really many different global tone mapping operators and the simple exponential tone mapping operator seems to be the best working one for our project.
For a comparison how the camera adjusts dynamically the image result:
And after looking a bit into the very bright sky:
If you would like to know more about this technique then I recommend that you have a look at the HDRLighting Sample from the DirectX SDK.
Only the people in the IRC channels know what’s going on with XreaL’s development. I want to change this so I’m going to use this news oriented blog to show you new features and gimmics that we are working on. We are going to extend the gameplay by some new movement features. One of these features is wall walking similar to Prey. I simply ported the required sourcecode from Tremulous. Now see how it looks like to walk on special wallwalk surfaces.
Welcome to the new XreaL website. We rented a new root server to launch several services that were bad supported or offline. With this server we want you to give a better platform for discussion of XreaL’s engine, the development of its base game and the development of XreaL based game projects.
Join the forum discussion on this post - (37) Posts 
