Its now been over a year that DoomIII has been released. In meantime I got many requests on when the new Engine will be released. To be honest, most of the engine was already done when Doom3 came out. Of course, I had to do some changes, mainly because of file format changes, but the rendering backend itself proved to be rather stable. I didnīt release anything yet, because Iīm rather lazy and also I had the feeling, I should wait until I made everything "perfect" :-) In meantime I implemented many new things, most notable vp/fp support in the shaders so you can see now heat haze and glass-warping effects. The map viewer is still not perfect but already rather close to how Doom 3 looks. I finally kicked myself in the butt and posted some screenshots that can be seen here
I ported the current version to Linux. It was quite a painful experience, as Iīm used to Microsoftīs convenient development tools. After trying out a number of more or less useful IDEīs on Linux I finally settled down with Anjuta. Its still at the beginning of the development, but shows great potential for the future. What I like most about it is, that it creates autoconf compatible makefiles and it doesnīt enforce a too restricted filestructure. Anjuta still has to grow much more to meet the usability and feature set of Visual Studio, but its on the way :-).
Just another small update. I finally persuaded myself do do a R200 backend (using ATI_fragment_shader). So from now on Radeon8500 / 9000 users can also enjoy realtime per pixel lighting :) It runs (for some reason I donīt know) a bit slower than the ARB_fragment_program path on my R9800... but hey it works!
Happy new year! ;-)
Well, to be short, this site is not (yet) dead. Iīm still working on my new engine, but had some other important thing to finish before. In meantime I included Milkshape3D-Model support to Diesel (it was an interesting experiment and gave me some hints on how to do animation in the new engine). I updated source and binaries to the newest version. MS3D support is not yet fully useful (and probably never will be), but it already allows you to place those models into the map (have them being lit) and animate them via an arbitrary number of blended animations. Also, Q3 shaders on those models are possible - just let the MS3D material refer to a texture that is named like the shader you want to apply.
The first version with multistaged lights is has been done. Projective lights also seem to work. Somehow a very strange bug crept into the attenuation code. I need to fix that bug and clean up the projection code. One major improvement still needs to be done in order to get more performance. Besides that I implemented a basic collision detection for camera and walls.
The GF3/4 backend is almost done. It looks quite good and is faster than I thought it could be. Most surfaces can be done in 2 passes (diffuse,specular,bumpmap,attenuation, selfshadow term, lightcolor and lighttexture included) The bumps look not as good as they do on my R300, but I hope to get it a bit better next days. I tried to get the GF1/2 path working again, but it seems to be a useless enterprise... Next things to be done: multistage lights and projected lights (those rotating fans... yeah!)
Well, after months of no updates to my site I want to tell a bit about the new project and how it is progressing. As you can guess, its a Doom3 map- and models viewer. It is using the same application framework (DXShell) as Diesel did, but everything else is completely re-written to optimally suit the needs of per-pixel-lit and stencil shadowed environments. What it already can do:
A first version of the viewer ran on a usual GF1/2, fast enough to view animated MD5 models at relative high framerates and maps at moderate framerates. But I decided to go for vertex programs, which automatically moves a fast implementation for GF1/2 out of sight. There will be a GF3/4 backend (it is currently being made) and ARB_fragment_program backend (Radeon9700/GeforceFX). Earlier Radeon (8500/9000) cards will have a hard time, though... Maybe I can find someone that can help me here later. I will upload some screenshots soon...
I ported some code from my new engine back to Diesel, improving the rendering of portals and mirrors. This optimization is using a scissor rect to reduce overdraw for portals.
Hello everybody. Sorry, no update for Diesel this time. I just wanted to point out that Iīm still alive :-) I am working on a Diesel-Sequel, but this time featuring per-pixel lighting, bumpmapping, stencilshadows and skeletal animations. Please be patient. I probably wonīt release anything new for some months now.
Have a nice christmas, see you next year!
I finally released the source code to my little renderer and named it the
"Diesel Engine". Ok its not the best name in the universe, but its at least
better than "OpenGLTest". The source contains everything to compile the full
executable. In fact its even more than needed. But I am too lazy to sort out all
unneeded stuff of my DXShell framework library. There are workspace files for
both, VC7 and VC6. VC6 users should get a copy of
STLPort, since I use std::auto_ptr in one
place which seems to have an incomplete implementation in VC6ī STL.
Ok then, happy compiling, thanks for the patience many of you had. (I promised a release already at the beginning of the year - shame on me)
Again a small update. Vic pointed out that some blended faces were flickering in some cases. The reason for this is that Iīm using quicksort to sort all faces for their sortkey. Since quicksort is not a stable sorting algorithm, it may change the order of equal keyed elements. As result you sometimes noticed "flickering" faces which seemed to change the draworder in every frame. What you could do about it is to use a stable sorting algo, like insertion sort. But I knew none that were as fast as quicksort, so I would spend more time sorting faces. Finally I decided to take a different approach, holding two batches. One batch for solid faces and one for blended. The "solid" batch is sorted using good old quicksort, while the "blended" batch is sorted with insertion sort (may still change). The result is quite satisfying. What I forgot to mention last time was that Iīve added support for "deformVertex normal", which was the last unsupported shader keyword. It does not look like original, but comes quite close to it.
I have uploaded a new executable. This time I fixed some fog-related stuff. Entity-in-fog is now recognized 100% and I could get rid of some clumsy codeparts when rendering the bsp leaves. Also reworked the way you create new shaders codewise. Its much simpler and safer now. Btw, if you have flaky framerates, try "r_fixfirstunit 1" and "app_boostpriority 1".
I finally fixed some long-known-never-fixed bug. It regards to some func_train and func_bobbing entities. If their movement was too big, they sometimes vanished. This is due to the way the bsp tree is used to cull away invisible entities.
Thanks to Vic I found a RoQ specification and demo decoder, made by Tim Ferguson. It did not take long to integrate it into my renderer. So - tadaa! - .roq videotextures are now visible. Unfortunately the demodecoder can only decode from real files, not out of the pk3 files and is not able to loop the animation. The major disadvantage for you is, that you have to decompress the VIDEO directory out of your pk3 files into BASEQ3/ . And the animations will be played only once. When I have enough time, I certainly will improve it one day.
I stumbled across Q3MAP2
and found a cel-shaded map there. In the beginning it
didnīt work properly, but then I got it to work. Actually it was a
misunderstanding of the shadermanual regarding the "cull" keyword. Id has a very
strange defintion of backface/frontface culling :-)
Iīve put a new screenshot, showing a cel-shaded map.
I added support for WGL_ARB_multisample. It basically allows Full Scene Antialisasing to be enabled/finetuned at runtime. To use it, your card must support WGL_ARB_pixel_format, too. Choose a proper sampling level at the screenmode requester (left position means "off"). Then type "r_FSAA 1" into the console. You should notice the effect. nVidia users also can try "r_FSAA 2", which enables an even nicer sampling mode. I donīt know, how much WGL_ARB_multisample is spreaded among the current cards. At least GF3+ users can use this feature.
other small improvements:
Iīve made some small enhancements. First, fogged skyshaders are now allowed,
that means, skyshaded polygons maybe included inside fog. I needed this, because
a special map, called "sacrifice" ("Ruskullīs Domain") used that
feature to emulate a castle in the clouds (see screenshots). Iīve also completed
the list of supported Items - Team Arena items will be loaded from now on. The
last faulty tcgen vector mode is also repaired - the only maps, that
supported this feature until now (AFAIK), are "pjw3dm3" ("Jumping
to Contusions") and "pjw3dm4" ("Beneath a distant Sun"), both
available at ::lvl . Another
bug that is gone now are some flickering flags in some maps.
Additionally FMOD is now loaded dynamically at runtime - that means the exe is now able to run without fmod.dll and sound disabled.
(thanks go to: Aaron 'Serac' Hill )
Hurray! I think, I got it now. It seems, Iīve found a way for getting a (relative) fast and robust sky. Variable cloudheight is still not supported - since my cloudlayer-texturecoordinates are precalculated. I either find a way to use the texturemtraix to do the trick (chances are small - the calculations involved are not linear) or I have to precalculate at map load (what about maps that have different skies in different parts of the part with different cloudheights?) or I calculate the texturecoordinates at runtime (performance loss)... Anyway its great to finally have a working sky (I fixed the problems with farboxes, q3dm10 shows farbox and cloudlayer together).
Again a small update. The sky is almost working now. The renderer will automatically decide which parts of the skybox can be seen and will only render those. It isnīt working perfectly... but I hope, it will become better. Unfortunately the sky is still killing peformance and somehow the farbox/neabox got broken :-( I get a fps drop of about 1/3 - way too much! I couldnīt identify the reason for it yet.
Only a small update: I finally made it to get the sky working. Its still far
from perfect, because all sides of the skybox are currently rendered regardless
of how much of the sky really can bee seen. This is still in progress. The
sky currently fully supports farbox, cloudlayers and the nearbox (untested
though). The skyheight param is not supported. The current version will run very
slow with some maps, because of the huge overdraw the skybox currently causes.
It is interesting how I came to the formula that calculates the texturcoordinates of the skybox for the cloudlayer. All my attempts to achieve a good looking mapping via usual trigonometry failed. So I decided to do it brute force (its a precalculation anyway) and utilize a full blown ray-sphere-intersection test. Luckily much of the formula vanishes if you use a sphere centered at (0,0,0) and a ray that can only start at (0, H, 0) (the skybox may come closer to the edge of the surrounding sphere in order to let the sky look more flat. Surprisingly I ended up with a formula very similar to Aftershocksī. Now thats an AHA-effect - I always wondered what magic Aftershock performs there :-)
Iīve added a new screenshot to the gallery. It proudly presents the sky in a map called Japan Castle.
I reworked big parts of the code, mainly the scene management. It is much cleaner now, what parts of the code do which task. "Q3Scene" has now means to relink Entities that have changed their position. It the next release func_train or func_bobbing entities can no longer disappear. I also dropped the idea that the core rendering should not know anything more than bare pointers to geometry. The renderer now accepts only pointers to vertexbuffers. This simplifies the scene capturing a bit and reduces unneccessary copying of pointers. It will also ease the introduction of new features and types of geometry by just deriving from CVertexBuffer. A great new enhancement is the GeometryMemManager singleton. It manages all memeory that is needed for geometry storage. It supports three managed memory types: static, dynamic and system memory. The GMM transparently handles a Vertex Array Range (VAR) or just pure system memory, in case only CVA is supported by OpenGL. Unfortunately VAR requieres a more clever managing of batch-buffering and synchronisation for the rendererīs temporarily memory. This one of the todoīs for the next weeks.
I looked into the use of a decent memory manager to find leaks and unused memory. I found Paul Nettleīs memory manager to be very useful. Itīs small, easy to integrate and merciless to memory allocation/deallocation errors/mistakes. A rather annoying problem,though, was that after closing the program it took ages to write out the memory leak file. I found out that Microsoftīs STL seemed to be the reason. So I switched to STLport, a free STL implementation, which reduced the write-time to almost zero.
I found two serious bugs that prevented me from getting a "Final" (optimized
without any debug symbols) version running and that caused crashes when loading
.DOF files with multiple "bursts".
The first bug is really a mystery, since I could not run the final-exe for ages and wasnīt able to find the reason for it. The solution was that I didnīt initialize a member variable inside the CVertexBuffer class. When running in debug-mode (or at least a version that included debug-symbols) this variable contained a value very similar to the one that was supposed to be there. But when running a "Final" version this variable accidently was initialized to 0, what caused crashes when two vertexbuffers where combined.
Such bugs are hard to find since there are no debug symbols and you only see some disassembly. Fortunately the disassembly showed a very distinct code so I could at least identify the source where the crash was caused.
Again the filemanager has been reworked. Arbitrary searchpaths are now allowed. You can use "addPaks xxx" to add new searchpaths. The command name is a bit misleading - you can even specifiy a path where there are no pk3 files at all. Additionally these paths can be absolute. This way you can easily try other gamesī (and mods!) maps and models. For instance you could type "addPaks g:\return_to_castle_wolfenstein\main" in order to include all pk3īs there. Afterwards you can use "dir maps" to browse all available maps. Wolfenstein and Star Trek Elite Force maps can finally be loaded as promised in the features.
Collision detection is still broken, turn it off with "noclip 1".
Some parts of the filemanager were changed. Iīve tested another method for collision detection of boxes against the static map geometry. Thatīs why it doesnīt work very reliably at the moment.
Two days ago I found a project on the net called "Racer". Its a racing simulation made by Ruud van Gaal. Some people have been producing high quality car models for it. I decided that my viewer should be able to load and view those cars (maybe Iīm writing some racing sim one day, too.... :-). Theyīre given in the DOF fileformat which is similar to 3ds. With the help of Ruud I was able to write a loader which also forced me to also support .bmp textures files from now on (24/32bit, not compressed). I am not supporting the car.ini files at the moment, which means you can only load for instance the car bodies, but the tyres wonīt be loaded and placed correctly.
You wonīt notice any other visual differences to the old version of the viewer, I left the Quake3 part untouched.
I have reworked most of the windows-framework. But the most important thing is that now mirrors and portals work in most places. I changed the way how portal-surfaces near portal-entity the were determined. Now it should find the surfaces in any case. I also had a bug that caused those weird camera-settings when looking through a portal.
Some small improvements: