Externe Libraries:

als extension-loader wird "glew" verwendet		(http://glew.sourceforge.net/)
als sound-library wird "fmod" verwendet 		(www.fmod.org)
zum laden von jpeg bildern wird die "jpeglib" verwendet	(http://www.ijg.org/)


zur rennstrecken-erstellung werden die quake3-tools verwendet


alle im folgenden erwähnten features und techniken (loader, renderer...) wurden von mir selbst implementiert und sind keine 3rd party software.


Texturen können bi und trilinear gefiltert werden, sowie mipmaps ein und ausgeschalten.
Weiters kann zwischen Immediate mode und vertex arrays umgeschalten werden.


Die von den q3-tools generierten files, werden vom loader eingelesen und danach die daten (koordinatensystem, texturkoordinaten, textur-ids...) in die engineinternen daten umgewandelt.
Nicht benötigte Information (z.b. shader) werden ignoriert.


Die Rennstrecken basieren auf BSP-Trees. Geometriedaten werden nur in den Blättern gespeichert.
(durch setzen eines bestimmten preprozessor-flags, per default ausgeschlaten, wird der baum einfach "brute-force" gerendert, dh. sämtliche geometrie wird an die grafikkarte gesendet)

Im Normalfall benutze ich Potentially Visible Sets (PVS) und Frustum Culling um die Geometrie zu minimieren (-> PVS Effekt kann man im Wireframemodus relativ gut beobachten).
Die Position der Camera wird bestimmt und damit wird in den Baum hinabgestiegen bis ein Blatt erreicht wird. Daraus bekommt man Clusterinformationen für das Blatt. Danach werden alle Blätter durchgegangen und verglichen (über die Clusters), ob diese vom "Camera-Blatt" aus sichtbar sind. Wenn ja, wird es mit dem Viewing-Frustum geschnitten um zu sehen ob es außerhalb der Camera liegt, und nicht beachtet werden muß.
Für jedes übrig gebliebene Blatt werden die Faces gerendert.
Weiters wird Backface-Culling benutzt.

Zusätzlich werden Curved Surfaces in Form von Bezier-Patches gerendert. (-> alles was in den Strecken rund oder gebogen ist,.. nicht zu übersehen ;] )


Für die Beleuchtung der Rennstrecken werden über Multitexturing vorberechnete (von den q3-tools) Lightmaps angezeigt (leider gibt es bei den bezier-patches probleme mit den lightmaps, die ursache habe ich noch nicht herausgefunden, da die fehlerhafte anzeige erst seit Kurzem ist).


Modelanimation führen wir keyframe-basiert durch (MD2). Auch hier wird die Datendarstellung sofort nach dem laden in die interne Datendarstellung umgewandelt. Vertices, Normals und Texturcoordinaten werden wieder als Array an die Grafikhardware übergeben.



AI:
die Bots laufen am derzeitigen stand einfach wegpunkte der strecke entlang ab und sind sehr artificial, aber nicht wirklich intelligent.


Physik:
Es gibt "gravitation" ;]
Weiters ist eine Collision-detection eigebaut sowohl zwischen den Objekten also auch zwischn der Rakete und den Objekten und der Rakete und der Rennstrecke.
Leider funktioniert die Collision-Detection nicht allzugut, wobei eher die Collision-Response das Problem ist, nicht die Detection. (Dies fällt einerseits bei der Collision zwischen den Läufern auf, andererseits kann es auch vorkommen, daß eine Rakete nicht explodiert wo sie aufschlägt,.. dies scheint ein Bug in der map zu sein, den ich noch nicht herausgefunden habe).


Beleuchtung:
Für die dynamischen Objekte der Szene (Läufer und Scheibtruhen) werden vertex-lights benutzt (die gleichen, die zur erstellung der lightmaps benutzt wurden).

Eine ist eine weiße directionale Lichtquelle ("sonne") und eine positionale (die rote lampe drinnen).
Wenn eine Lichtquelle vom Objekt aus nicht sichtbar ist, wird sie deaktiviert.

Special Effekts:
Als solche habe ich Partikelsysteme mit Billboards und Alphablending implementiert (man sieht anfangs das feuer, dann den Rauch des Raketenwerfers, und schließlich die Explosionen)
Die quads werden mit der Partikeltextur texturiert, und geblendet, damit nach außen hin die Transparenz zunimmt (-> man sieht nicht, daß es sich um 4-ecke handelt). Je nachdem, was die Partikel darstellen sollen, bekommen sie eine bestimmte Farbe (Feuer = rot, Rauch = weiß,...). Diese Farbe wird mit der Zeit angepaßt, z.b. geht das Feuer von gelb nach dunkelrot, weiters nimmt die Transparenz der Partikel zu, und die Größe verändert sich. Jedes Partikel hat eine Lebenszeit und wird wenn diese abgelaufen ist (oder es aufgrund der Transparenz nicht mehr sichtbar ist) gekillt. es werden immer neue Partikel generiert (außer bei der Explosion wo es nur einen Partikel"burst" gibt), die eine zufällige Position rund um die Partikelsystem-Position erhalten. Farbe, Geschwindigkeit, Größe, größenänderung, Energieänderung,... sind alles Attribute die (in einem gewissen rahmen) zufällige werte erhalten.

Für das Rendern wird der Depthtest aktiviert, jedoch die Depthwrites deaktiviert (und natürlich blending aktiviert)

Bezier-Patches: Auch diese habe ich ohne fremdes "Einwirken" implementiert. Da diese nicht "normale" Bezier-Patches sind sondern von id-software spezielle 3x3 patches in eigentümlicher Weise in der map gespeichert sind, war damit auch einiges an Arbeit verbunden,.. jedoch ist das Ergebnis hübsch. (nähere infos in meinem Tutorial, das daraus entstanden ist auf: http://stud3.tuwien.ac.at/~e9925546/Implementing_the_Q3_Bezier_Patches.pdf)

Sourcecode (C) Severin Ecker 2004