Version vom 4. November 2011, 11:36 Uhr

Kollision anhand von Bildern

Viele Bibliotheken/Frameworks bieten es an, anhand 2 Bilder auf eine Kollision zu überprüfen. Dabei wird unterschieden zwischen der ungenauen Variante, in der die Bilder als Rechtecke betrachtet werden und der pixelgenauen Kollision, bei der die Transparenz von Pixel berücksichtigt wird.

Außerdem sollten 2D-Physik Engines berücksichtigt werden, wie Box2D und dessen Portierungen für Java, .NET und Python. --Sacaldur 22:46, 2. Nov. 2011 (CET)

Beschleunigung mittels räumlicher Datenstrukturen

Hat man N Objekte, die man auf Kollision testen möchte, benötigt man ohne Einsatz einer räumlichen Datenstruktur O(N²) viele Tests, was schlecht ist. In dem Artikel sollte man zumindest erwähnen, dass die Anzahl der benötigten Tests durch Einsatz einer räumlichen Datenstruktur (kd-Baum, Grid, ...) beschleunigt werden kann. Zu dem Thema sollte es dann ggf. einen eigenen Artikel geben. --David Scherfgen 16:52, 3. Nov. 2011 (CET)

Ein-/Ausklappbare Implementierungen

Vielleicht wäre es hier eine gute Idee, die Implementierungen ein-/ausklappbar zu machen. Dann stören sie beim Lesen nicht so. Normalerweise interessiert man sich ja nur für eine Sprache. --David Scherfgen 18:44, 3. Nov. 2011 (CET)

Einheitliche Datenstrukturen/Klassen

Da zu erwarten ist, dass es viele Artikel dieser Art hier geben wird, sollten wir uns vielleicht auf einheitliche Namen für Klassen/Datenstrukturen einigen. Vor allem für Vektoren, Matrizen, Farben, ... schon jetzt gibt's eine Uneinheitlichkeit zwischen C#/C++ und Java, da im Java-Code die Vektor-Klasse ein Generic ist. --David Scherfgen 18:47, 3. Nov. 2011 (CET)

Ich würde folgende Bezeichnungen (für float Daten) vorschlagen: (aus javax.vecmath) Vector2f, Vector3f, Vector4f, Quat4f, Matrix3f (3x3), Matrix4f (4x4), Color3f, Color4f. Komponenten sollten dann über x,y,z,w bzw. m00,m01,m02,...,m33 angesprochen werden. --Chromanoid 20:03, 3. Nov. 2011 (CET)

Damit wäre ich einverstanden! --David Scherfgen 10:49, 4. Nov. 2011 (CET)

javax.vecmath ist nicht Bestandteil der Java Standardbibliothek, weshalb ich auf dessen Einsatz eher verzichten würde. --Sacaldur 11:16, 4. Nov. 2011 (CET)

Ja ich meinte damit auch nicht, dass es gute Bezeichnungen sind, weil sie "Standard" sind, sondern weil ich sie einfach so gut finde. Ich wollte nur meine Quelle angeben. Und javax.vecmath ist Bestandteil von Java3D, was ja schon eine größere Unternehmung von Sun war um 3D Grafik möglichst massentauglich anzubieten. Ansonsten fände ich auch noch an HLSL oder GLSL angelehnte Bezeichnungen sinnvoll. Also Float2/Float3/Float4 Float2x2/Float3x3/Float4x4 oder Vec2/Vec3/Vec4 Mat2/Mat3/Mat4... --Chromanoid 11:33, 4. Nov. 2011 (CET)

Da in Python sowohl eine dynamische Typisierung, als auch Ducktyping verwendet werden, kann man für die Parameter nicht festlegen, welchen Datentyp sie haben sollen. Somit könnte man statt koordinate[0] auch koordinate.x schreiben. Der übergebene Wert muss dann lediglich eine Variable x besitzen, die die entsprechenden Operatoren definiert hat. --Sacaldur 11:16, 4. Nov. 2011 (CET)

Erklärungen auch in natürlicher Sprache

Es sollte darauf geachtet werden, dass die Algorithmen auch mit natürlicher Sprache erklärt werden. Ansonsten kopiert man sich nur den Code, versteht aber gar nicht, wie er funktioniert. --David Scherfgen 18:47, 3. Nov. 2011 (CET)

Ort der Kollision ermitteln?

Optional könnte man für jede Kollisionsabfrage auch noch ermitteln, wo die Objekte sich schneiden. --David Scherfgen 10:49, 4. Nov. 2011 (CET)

Broadphase, Narrowphase, Solving? =

Ich weiß nicht ob man hier darauf eingehen sollte, aber zumindest Broadphase-Algorithmen wie Sweep&Prune sollte man vielleicht hier oder irgendwo allgemein vorstellen. --Chromanoid 11:36, 4. Nov. 2011 (CET)