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 erwhnten features und techniken (loader, renderer...) wurden von mir selbst implementiert und sind keine 3rd party software.


Texturen knnen 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 bentigte Information (z.b. shader) werden ignoriert.


Die Rennstrecken basieren auf BSP-Trees. Geometriedaten werden nur in den Blttern gespeichert.
(durch setzen eines bestimmten preprozessor-flags, per default ausgeschlaten, wird der baum einfach "brute-force" gerendert, dh. smtliche 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 fr das Blatt. Danach werden alle Bltter 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 auerhalb der Camera liegt, und nicht beachtet werden mu.
Fr jedes brig gebliebene Blatt werden die Faces gerendert.
Weiters wird Backface-Culling benutzt.

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


Fr 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 fhren 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 fllt einerseits bei der Collision zwischen den Lufern auf, andererseits kann es auch vorkommen, da eine Rakete nicht explodiert wo sie aufschlgt,.. dies scheint ein Bug in der map zu sein, den ich noch nicht herausgefunden habe).


Beleuchtung:
Fr die dynamischen Objekte der Szene (Lufer und Scheibtruhen) werden vertex-lights benutzt (die gleichen, die zur erstellung der lightmaps benutzt wurden).

Eine ist eine weie 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 schlielich die Explosionen)
Die quads werden mit der Partikeltextur texturiert, und geblendet, damit nach auen 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 angepat, z.b. geht das Feuer von gelb nach dunkelrot, weiters nimmt die Transparenz der Partikel zu, und die Gre verndert 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 (auer bei der Explosion wo es nur einen Partikel"burst" gibt), die eine zufllige Position rund um die Partikelsystem-Position erhalten. Farbe, Geschwindigkeit, Gre, grennderung, Energienderung,... sind alles Attribute die (in einem gewissen rahmen) zufllige werte erhalten.

Fr das Rendern wird der Depthtest aktiviert, jedoch die Depthwrites deaktiviert (und natrlich 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 eigentmlicher Weise in der map gespeichert sind, war damit auch einiges an Arbeit verbunden,.. jedoch ist das Ergebnis hbsch. (nhere 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