Crazy Simulator - Prof. Dr. Henrik Tramberend - Beuth Hochschule ...

BEUTH-HOCHSCHULE FÜR TECHNIK BERLIN
Crazy Simulator
Graphics and Effects & Physical Simulation
s750026 Marc Roßbach; s732633 Birgitt Grundmann
13.07.2009

Inhaltsverzeichnis
1 Spielidee .......................................................................................................................................... 3
2 Softwarearchitektur ........................................................................................................................ 5
3 Synchronisation der Grafik- und Physikobjekte .............................................................................. 6
3.1 Feste Körper ............................................................................................................................ 6
3.2 Elastische Körper ..................................................................................................................... 7
4 Spielbausteine ................................................................................................................................. 8
4.1 Halbröhren .............................................................................................................................. 8
4.2 Jump-Pad ................................................................................................................................. 8
4.3 Bretter-Kette ........................................................................................................................... 9
5 Transformationstool ...................................................................................................................... 10
6 Grafische Benutzeroberfläche ....................................................................................................... 11
7 Shader ............................................................................................................................................ 11
7.1 Rostiges Metall ...................................................................................................................... 11
7.2 Gras und Felsen ..................................................................................................................... 12
7.3 Spiegelndes Wasser ............................................................................................................... 14
7.4 Weitere Shader ...................................................................................................................... 14
8 Technologien und Tools ................................................................................................................ 15
9 Probleme ....................................................................................................................................... 15

1 Spielidee
Bei Crazy-Simulator handelt es sich um ein Strategiespiel. Sinn ist es, möglichst viele Bälle von der
Ausgangsposition zum Ziel zu leiten. Dazu kann der Spieler zwischen vier unterschiedlichen
Hilfsmitteln wählen.
Die Spielumgebung ist eine Hügellandschaft. In der Ferne ist das Ziel in Form eines Brunnens zu
erkennen (siehe Abbildung 1).
Abbildung 1 Crazy-Simulator Ausgangssituation
Wird nun auf den Start- Button geklickt, fällt aus dem Rohr am rechten Bildschirmrand ein Ball. Bei
jedem weiteren Klick, fallen weitere Bälle in das Spielfeld (siehe Abbildung 2).
Abbildung 2 Start-Button lässt Bälle in das Spielfeld fallen.

Über die Programmoberfläche hat man die Möglichkeit verschiedene Bauteile in das Spielfeld zu
setzen, um den Ball in sein Ziel zu steuern (siehe Abbildung 3). Dabei spielt es keine Rolle wie viele
Teile einer Sorte genutzt werden.
Abbildung 3 Die vier Bauteile
Gelingt es dem Spieler einen Ball im Brunnen (siehe Abbildung 4) zu versenken, erhöht sich der
Punktezähler am linken unteren Bildschirmrand.
Abbildung 4 Das Ziel
Der Spieler kann sich mit den Tasten WSAD durch die Welt bewegen. Mit der linken Maustaste
können Gegenstände angeklickt und transformiert werden. Die rechte Maustaste dient dem
Kameraschwenken.

2 Softwarearchitektur
Wie in Abbildung 5 zu sehen ist, besteht die Anwendung aus fünf Hauptkomponenten.
1. InputState und InputManager verwalten die Eingaben von Maus und Tastatur.
2. ComponentManager verwaltet alle Gegenstände des Spiels.
3. PhysicsManager ist für die Physiksimulation zuständig (Bullet-Engine).
4. GraphicsManager rendert die 3D-Szene (Horde3D-Engine).
5. GuiManager verwaltet und rendert die GUI-Elemente (Horde3D-Engine).
Abbildung 5 Crazy-Simulator: Softwarearchitektur (Klassendiagramm)
Abgesehen vom InputManager ruft das Hauptprogramm (Main) in einer Schleife kontinuierlich die
mainloop(…)-Methoden der Manager-Objekte auf (siehe Auflistung 1). Dabei wird jedem
Manager die aktuelle Framerate übergeben, um beispielweise die Geschwindigkeit der
Physiksimulation an die Framerate anpassen zu können. Ohne diese Anpassung würde die Simulation
auf unterschiedlichen Systemen je nach Leistung der Hardware entweder langsamer oder schneller
als gewünscht laufen.

int main(int argc, char** argv)
{
…
// Game loop
while( running )
{
…
// Calc FPS
++frames;
if( frames >= 3 )
{
double t = glfwGetTime();
fps = frames / (float)(t - t0);
frames = 0;
t0 = t;
}
componentManager->mainloop(fps);
physicsManager->mainloop(fps);
graphicsManager->mainloop(fps);
guiManager->mainloop(fps);
}
glfwSwapBuffers();
}
// Quit
glfwTerminate();
return 0;
Auflistung 1 Game-Loop (Main.cpp)
3 Synchronisation der Grafik- und Physikobjekte
Man unterscheidet bei der Bullet-Physikengine zwischen festen und elastischen Körpern. Für beide
Körperarten werden unterschiedliche Synchronisationsverfahren verwendet.
3.1 Feste Körper
Starre Körper sind relativ einfach zu synchronisieren da im Grunde nur die Transformationsmatrix
von dem Physikobjekt auf das Grafikobjekt übertragen werden muss. Bullet erlaubt es, eine Klasse zu
definieren, die von btMotionState abgeleitet wird und später Synchronisation übernimmt. Dabei
müssen folgende virtuelle Methoden überschrieben werden:
virtual void getWorldTransform(btTransform &worldTrans) const;
virtual void setWorldTransform(const btTransform &worldTrans);
Es muss zudem dafür gesorgt werden, dass ein MotionState-Objekt eine Referenz auf das
entsprechende Grafikobjekt besitzt.
Abbildung 6 Synchronisationsarchitektur für feste Körper

Für die Simulation einer Kugel wird zunächst ein Objekt vom Typ btRigidBody erzeugt und mit
einer Masse und einem Kollisionsobjekt (btSphereShape) versehen. Für die grafische
Repräsentation wird ein MotionState-Objekt erzeugt was auf ein Horde-Objekt zeigt. Das
MotionsState-Objekt wird ebenfalls an das RigidBody-Objekt gebunden (siehe Abbildung 6). Immer
wenn sich im Laufe der Physiksimulation die Transformation des RigidBody ändert, wird die Methode
setWorldTransform() (siehe Auflistung 2) des MotionState aufgerufen und die neue Transformation
übergeben.
void MotionState::setWorldTransform(const btTransform &worldTrans)
{
if(NULL == _hordeObj) return;
float m[16];
//Rotation
btMatrix3x3 rm = worldTrans.getBasis();
btVector3 col;
col = rm.getColumn(0); m[0]=col.getX(); m[1]=col.getY(); m[2]=col.getZ();m[3]=0;
col = rm.getColumn(1); m[4]=col.getX(); m[5]=col.getY(); m[6]=col.getZ();m[7]=0;
col = rm.getColumn(2); m[8]=col.getX(); m[9]=col.getY(); m[10]=col.getZ();m[11]=0;
//Translation
btVector3 pos = worldTrans.getOrigin();
m[12]=pos.x(); m[13]=pos.y(); m[14]=pos.z(); m[15]=1;
}
Horde3D::setNodeTransformMatrix(_hordeObj, m);
3.2 Elastische Körper
Auflistung 2 Synchronisationsmethode für feste Körper
Da bei elastischen Körpern die Position jedes einzelnen Vertex synchronisiert werden muss, können
hierbei keine MotionState-Objekte eingesetzt werden. In Bullet sind alle elastischen Körper vom Typ
btSoftBody. Um aus einem Horde-Objekt einen elastischen Körper zu erzeugen, wird die
Geometrie in ihre Dreiecke und Punkte zerlegt. Mit der Funktion btSoftBodyHelpers::
CreateFromTriMesh(…) kann aus den Dreiecken ein Soft-Body erzeugt werden. Für die spätere
Synchronisation wird jeder Soft-Body mit einem Pointer (UserPointer) auf das Grafikobjekt
versehen. Im Laufe der Simulation werden alle Soft-Bodies über eine Schleife durchiteriert und
Vertex für Vertex mit dem Grafikobjekt synchronisiert (siehe Auflistung 3).
void PhysicsManager::mainloop(float fps)
{
_dynamicsWorld->stepSimulation(1.f/fps,0);
//SoftBodies
btSoftBodyArray& sbs=_dynamicsWorld->getSoftBodyArray();
for(int ib=0;ibm_nodes[i].m_x;
}
}
Component* comp = ((UserPointer*)psb->getUserPointer())->_component;
if(comp)
{
comp->updateVertexPos(psb->getUserPointer(), i, v[0], v[1], v[2]);
}
…
Auflistung 3 Synchronisation der Soft-Bodies in der Hauptschleife der Physiksimulation

4 Spielbausteine
Um die unterschiedlichen Möglichkeiten der Bullet-Engine in das Spiel zu integrieren, wurden vier
unterschiedliche Spielbausteine implementiert.
4.1 Halbröhren
Die einfachsten Bausteine sind die Halbröhren in denen die Bälle rollen können. Es handelt sich dabei
um Rigid-Bodies mit konkaven Kollisionsobjekten (btGImpactMeshShape). Um diese
Kollisionsobjekte zu erzeugen, musste Geometrie ebenfalls in ein Array aus Dreiecke zerlegt werden
(siehe Abbildung 7). Die Masse der Halbröhren wurde auf null gesetzt, wodurch sie in der
Physikengine zu statischen Objekten werden.
4.2 Jump-Pad
Abbildung 7 Geometrie der Halbröhren
Das Jump-Pad besteht aus drei Teilen (siehe Abbildung 8). Der äußere Ring ist statisch und kann
angeklickt und verschoben werden. Zwischen dem Ring ist ein Soft-Body (Pad) aufgespannt bei dem
die äußersten Vertices statisch sind damit er nicht aus dem Ring fällt. Wenn ein Ball auf das Jump-Pad
fällt, soll auf ihn ein Impuls ausgeübt werden, damit er wieder wegspringt. In der aktuellen Version
von Bullet können allerding noch keine Kollisionen ausgelesen werden, an denen Soft-Bodies
beteiligt sind. Darum befindet sich in der Mitte ein unsichtbarer statischer Körper der für die
Kollisionserkennung mit dem Ball verwendet wird. Damit der Ball den Trigger auch erreichen kann,
wurde in Bullet die Kollision von festen mit elastischen Körpern deaktiviert.
Abbildung 8 Jump-Pad: Schwarz=statisch; Rot=elastisch; Blau=statischer Trigger

Auflistung 4 zeigt wie Kollisionspaare aus Bullet ausgelesen werden können. Über die UserPointer
werden die Callback-Methoden der zugehören Bausteine (Component) aufgerufen und die
UserPointer der an der Kollision beteiligten Bausteine übergeben.
…
//Kollisionen an Komponenten melden
int numManifolds = _dynamicsWorld->getDispatcher()->getNumManifolds();
for (int i=0;igetDispatcher()->getManifoldByIndexInternal(i);
btCollisionObject* obA = static_cast(contactManifold->getBody0());
btCollisionObject* obB = static_cast(contactManifold->getBody1());
int numContacts = contactManifold->getNumContacts();
if(obA->getUserPointer() && obB->getUserPointer())
{
UserPointer* A = (UserPointer*)obA->getUserPointer();
UserPointer* B = (UserPointer*)obB->getUserPointer();
}
…
}
((Component*)A->_component)->collisionCallback(A,B);
((Component*)B->_component)->collisionCallback(B,A);
Auflistung 4 Collision-Callback für feste Körper in der Hauptschleife der Physiksimulation
Weil das Jump-Pad aus mehreren Teilen besteht verfügt es auch über mehrere UserPointer die alle
auf denselben Baustein zeigen. Damit später trotzdem noch zwischen den einzelnen Teilen
unterschieden werden kann, kann jeder UserPointer mit einer Zusatzinformation versehen werden.
In diesem Fall wurde dem Trigger der Integerwert 2 zugeordnet (Ring=0, Pad=1). Auflistung 5 zeigt
die Callbackmethode des Jump-Pad. In der Bedingung wird geprüft, ob das kollidierte Objekt vom Typ
CompBall ist, und ob es den Trigger berührt hat. Wenn das der Fall ist, wird auf den Ball mit
applyImpuse(…) ein Impuls ausgeübt. Damit sich auch das Pad entsprechend bewegt, wird auf
dieses mit addForce(…) ebenfalls eine Kraft in die gleiche Richtung ausgeübt.
void CompJumpPad::collisionCallback(void* ownUserPointer, void* otherUserPointer)
{
UserPointer* ownUP = (UserPointer*)ownUserPointer;
Component* ownComp = ownUP->_component;
UserPointer* otherUP = (UserPointer*)otherUserPointer;
Component* otherComp = otherUP->_component;
if(typeid(*otherComp) == typeid(CompBall) && ownUP->_data == 2) //Trigger hat die 2
{
…
Vec3f dir = Vec3f(0,calcImpulsePower(800, _fps),0);
dir = RotM*dir;
}
}
otherComp->applyImpulse(dir[0],dir[1],dir[2]);
_softBody->addForce(btVector3(dir[0],dir[1],dir[2]));
Auflistung 5 Collision-Callback-Methode des Jump-Pad
4.3 Bretter-Kette
Diese Komponente besteht aus insgesamt fünf Einzelteilen (siehe Abbildung 9). Das oberste Brett ist
Statisch und dient dazu, die dynamischen Teile auf Position zu halten. Die beiden Seile sind Soft-
Bodies, die über die Funktion btSoftBodyHelpers::CreateRope(…) erzeugt wurden. Die
obersten Vertices der Seile sind ebenfalls statisch. Die beiden dynamischen Bretter wurden mit
appendAnchor(…) mit einzelne Vertices der Seile verbunden.

Abbildung 9 Bretter-Kette: Schwarz=statisch;
Rot=elastisch; Grün=dynamisch
5 Transformationstool
Um die statischen Objekte in der Welt positionieren zu können, kann das Transformationstool
verwendet werden. Neben Translation ist damit auch eine Rotation um drei Achsen möglich.
Realisiert wurde die Rotationsfunktion mittels Rotationsebenen (siehe Abbildung 10).
Abbildung 10 Transformationstool: Rotationsfunktion
Wenn mit der Maus geklickt wird, wird zunächst über die Pickingfunktion von Horde3D ermittelt,
welchen Rotationsring der Benutzer ausgewählt hat. Jeder Ring liegt in einer eigenen Ebene und das
Programm berechnet den Schnittpunkt des Pickingstrahls mit dieser Ebene. Der Vektor v wird
zwischen dem Mittelpunkt des Transformationstools und dem geklickten Schnittpunkt aufgespannt.
Wird der Cursor nun bei gedrückter Maustaste bewegt, wird ein weiterer Schnittpunkt mit der
Rotationsebene berechnet und es kann der Vektor w bestimmt werden. Über das Skalarprodukt
beider Vektoren kann nun der Rotationswinkel berechnet werden. Die Rotationsrichtung ergibt sich
aus dem Kreuzprodukt beider Vektoren.

6 Grafische Benutzeroberfläche
Horde3D stellt kein eigenes GUI-Framework zur Verfügung. Aus diesem Grund wurde auf Grundlage
der Horde-Overlays ein eigenes kleines Framework entwickelt.
Abbildung 11 GUI des Crazy-Simulator
GUI-Elemente wie Hintergründe und Buttons bestehen im Wesentlichen aus PNG-Grafiken mit
Alphakanal um auch runde und halbtransparente Elemente darstellen zu können. Um auch auf
Mausevents reagieren zu können, wird in jedem Frame die Position des Cursors ausgelesen und
berechnet, ob er sich über einem GUI-Element befindet. Im Falle eines Klicks wird von jedem GUI-
Element über dem sich der Cursor befindet, die Methode mouseClickEvent() aufgerufen.
Abbildung 11 zeigt die GUI des Crazy Simulator. Abgesehen von der Punkteanzeige, sind alle
Elemente vom Typ GuiElement. Für die Punkteanzeige wurde die Funktion Horde3DUtils::
showText(…) verwendet.
7 Shader
Für die Umgebung und die Spielkomponenten kommen die unterschiedlichsten Shader zum Einsatz.
7.1 Rostiges Metall
Für die Halbröhren wurde ein Shader entwickelt, der die Eigenschaften von rostigem Metall
nachbildet. Dabei kommen vier Texturen zum Einsatz (siehe Abbildung 12). Über eine
Graustufentextur wird bestimmt, ob entweder Metall (dunkle Bereiche) oder Rost (helle Bereiche) zu
sehen ist. Um zusätzlich eine Oberflächenstruktur zu erzeugen, werden die Oberflächennormalen aus
einer Normalmap ausgelesen, die aus der Rosttextur erzeugt wurde.
Abbildung 12 Sampler des Shaders für rostiges Metall

…
#ifdef _F06_RustyMetal
uniform sampler2D rustMap;
uniform sampler2D metalMap;
uniform sampler2D rustyMetalMap;
uniform sampler2D rustNormalMap;
vec3 calcRustyMetal ( vec3 pos, vec3 normal, vec3 newCoords)
{
vec3 light = normalize( lightPos.xyz - pos );
vec3 eye = normalize( viewer - pos );
vec3 rust = texture2D( rustMap, newCoords.st ).rgb;
vec3 metal = texture2D( metalMap, newCoords.st ).rgb;
vec3 map = texture2D( rustyMetalMap, newCoords.st ).rgb;
vec3 rustnormal = texture2D( rustNormalMap, newCoords.st ).rgb;
//Metal
vec3 bumpNormal = normalize(normal + (rustnormal-vec3(0.5,0.5,0.0))*0.3);
float diffuse = max( dot(light , bumpNormal ), 0.0);
float specular = max( dot ( reflect (-light , bumpNormal ), eye ), 0.0);
vec3 metalPart = (1.0-map) * (1.0 * specular * metal + 0.7 * diffuse * metal);
//Rust
bumpNormal = normalize((rustnormal-vec3(0.5,0.5,0.0)));
diffuse = max( dot(light , bumpNormal ), 0.0);
specular = max( dot ( reflect (-light , bumpNormal ), eye ), 0.0);
vec3 rustPart = map * (0.2 * specular * rust + 0.8 * diffuse * rust);
}
#endif
…
return lightColor * (metalPart + rustPart);
Auflistung 6 Fragment-Shader für rostiges Metall
Damit die Stellen mit dem glatten Metall stärker glänzen als die Roststellen, besitzt der Rost einen
viel geringeren spekularen- und dafür einen höheren diffusen Reflexionsanteil als die Metaltextur
(siehe Auflistung 6).
7.2 Gras und Felsen
Der Shader für die Landschaft ist ähnlich dem Vorherigen aufgebaut. Der einzige Unterschied ist, dass
für die Verteilung keine Graustufentextur verwendet wird (siehe Abbildung 13).
Abbildung 13 Sampler des Shaders für Gras und Felsen
Ob die Gras- oder die Felsentextur verwendet wird, hängt davon ab, wie groß der Y-Wert des
jeweiligen Punktes ist. Abbildung 14 illustriert die generierte Verteilungsmap für diesen Shader ohne
Texturen.

Abbildung 14 Verteilung von Gras und Felsen
Damit an der Grenze von Gras zu Felsen keine harte Kante entsteht, werden im Grenzbereich beide
Texturen mit der smoothstep()-Funktion ineinander übergeblendet (siehe Auflistung 7).
…
#ifdef _F07_Ground
uniform sampler2D grasMap;
uniform sampler2D rockMap;
uniform sampler2D grasNormalMap;
uniform sampler2D rockNormalMap;
vec3 calcGround ( vec3 pos, vec3 normal, vec3 newCoords)
{
…
vec3 gras = texture2D( grasMap, newCoords.st ).rgb;
vec3 rock = texture2D( rockMap, newCoords.st ).rgb;
vec3 grasnormal = texture2D( grasNormalMap, newCoords.st ).rgb;
vec3 rocknormal = texture2D( rockNormalMap, newCoords.st ).rgb;
float map = pos.y/24; //Abhängig von maximaler Höhe der Berge
float border = 0.4; //Grenzgebiet
float borderSize = 0.3; //Breite des Grenzstreifen
vec3 bumpNormal = normalize(normal - (grasnormal-vec3(0.5,0.5,0.0))*0.2);
float diffuse = max( dot(light , bumpNormal ), 0.0);
float specular = max( dot ( reflect (-light , bumpNormal ), eye ), 0.0);
vec3 grasPart = 0.2 * specular * gras + diffuse * gras;
bumpNormal = normalize(normal + (rocknormal-vec3(0.5,0.5,0.0))*0.9);
diffuse = max( dot(light , bumpNormal ), 0.0);
specular = max( dot ( reflect (-light , bumpNormal ), eye ), 0.0);
vec3 rockPart = 0.1 * specular * rock + diffuse * rock;
if(map(border+borderSize/2))
return lightColor * rockPart;
}
#endif
…
float fade = smoothstep(1.0,0.0,(map-border+borderSize/2)/borderSize);
return lightColor * (fade*grasPart+(1.0-fade)*rockPart);
Auflistung 7 Fragment-Shader für Gras und Felsen

7.3 Spiegelndes Wasser
Als ein optisches Highlight wurde noch der Wassershader von Prof. Dr. Tramberend eingebaut (siehe
Abbildung 15). Problematisch hat sich dabei das Rendern in eine Textur erwiesen, da die Horde-
Engine hier vermutlich noch einige Fehler aufweist. Das Problem konnte jedoch durch den Einsatz
direkter OpenGL-Befehlen gelöst werden (siehe Auflistung 8).
Abbildung 15 Spiegelndes Wasser
…
ResHandle _mirrorMat = Horde3D::findResource(ResourceTypes::Material, "models/plane/mirror.material.xml");
ResHandle _mirroredImage = Horde3D::createTexture2D("mirrortex",
ResourceFlags::NoTexCompression |
ResourceFlags::NoTexMipmaps,
mapWidth, mapHeight, false);
unsigned char* _data = new unsigned char[mapWidth*mapHeight*4];
…
glReadBuffer(GL_BACK);
glReadPixels(0, 0, mapWidth, mapHeight, GL_RGBA, GL_UNSIGNED_BYTE, _data);
Horde3D::updateResourceData(_mirroredImage, TextureResParams::PixelData, _data, mapWidth*mapHeight*4);
Horde3D::setMaterialSampler(_mirrorMat, "mirrorMap", _mirroredImage);
…
Auflistung 8 Horde3D Render-To-Texture Workaround
Der Trick besteht darin, mit der Hordekamera nicht direkt in die Textur sondern zunächst ganz
normal in den Framebuffer zu rendern. Anschließend kann mit glReadPixels(…) der
Framebuffer wieder ausgelesen und in die Textur geschrieben werden. Wenn das geschehen ist, wird
die Szene noch einmal für den Betrachter aus der richtigen Position gerendert.
7.4 Weitere Shader
Für die meisten anderen Oberflächen wurde das Parallax-Mapping eingesetzt, was bereits in dem
Model-Shader von Horde enthalten ist. Lediglich die verwendeten Texturen und ihre Normalmaps
wurden entsprechend ausgetauscht.

8 Technologien und Tools
Die entwickelte Anwendung nutzt die Horde3D-Grafikengine 1 für das OpenGL-Rendering und die
Bullet-Physikengine 2 . Als Mathematikbibliothek für Matrizen und Vektorrechnungen wurde die
Graphics Math Template Library (GMTL 3 ) eingesetzt.
Als Entwicklungsumgebung ist Visual Studio 2008 (C++) 4 zum Einsatz gekommen. Für die Erstellung
der Landschaft wurde mit Terragen 5 eine Highmap erzeugt, die dann mit 3ds Max 2009 6 in eine
Geometrie konvertiert wurde. 3ds Max ist auch für die Modellierung sämtlicher anderen 3D-Objekte
verwendet worden. Der Export aus 3ds Max erfolgte über das Collada-Format was über das
ColladaMax-Plugin 7 generiert werden konnte. Anschließend mussten die Collada-Dateien mit der
ColladaConv.exe der Horde-Engine in ein Horde-Format konvertiert werden.
Die für die Shaderprogrammierung benötigten Normalmaps wurden mit dem Tool CrazyBump 8
erzeugt. Das Tool ist in der Lage, auch ohne Tiefeninformationen aus den Helligkeitswerten einer
Textur realistische Normalmaps zu erzeugen.
Für die Bearbeitung der Skybox (DDS-Format) wurde das Tool CubeMapGen von AMD verwendet.
9 Probleme
1. Statische Objekte in Bullet können nachträglich nicht mehr korrekt transformiert werden.
Lösung: Objekt aus Physiksimulation entfernen Objekt transformieren Objekt wieder in
Simulation einfügen.
2. SoftBodies in Bullet kollidieren nicht mit konkaven Objekten.
3. Keine Möglichkeit für ein Collision-Callback von SoftBodies gefunden.
4. Stärke des Impulses des Jump-Pad ist abhängig von der Framerate. Je höher die Framerate,
desto schwächer der Impuls. Die Beziehung ist jedoch nicht wirklich umgekehrt proportional.
Bisherige Näherung für Impulsstärke: power = power/(100-sqrt(fps))
5. Clippingplanes funktionieren nicht auf Nvidia-Karten (getestet auf GTX280 und GTX260 unter
Vista x64). Auch Far- und Near Clipping Plane der Kamera funktionieren nicht. Auf ATI-Karten
(getestet auf HD4870 unter Vista x64) arbeitet Clipping fehlerfrei.
6. Übergabe von Uniform-Variablen an Shader funktioniert nicht.
Lösung: Shadercontext explizit in der Renderpipeline aufrufen.
7. Render-To-Texture funktioniert nicht über Horde-API.
Lösung: siehe Shader: Spiegelndes Wasser
8. Die aktuelle Version der Horde-Engine unterstützt keine dynamische Geometrie.
Lösung: Die Vertices elastischer Körper wurden daher in Horde von vielen kleinen Kugeln
repräsentiert (siehe Jump-Pad).
1 http://www.horde3d.org/
2 http://www.bulletphysics.com/
3 http://ggt.sourceforge.net/
4 http://www.microsoft.com/germany/express/download/default.aspx
5 http://www.planetside.co.uk/terragen/productmain.shtml
6 http://www.autodesk.de/adsk/servlet/index?siteID=403786&id=12340933
7 https://collada.org/mediawiki/index.php/ColladaMax_NextGen
8 http://www.crazybump.com/