Inhaltsverzeichnis 1 Kollision anhand von Bildern 2 Beschleunigung mittels räumlicher Datenstrukturen 3 Ein-/Ausklappbare Implementierungen 4 Einheitliche Datenstrukturen/Klassen 5 Erklärungen auch in natürlicher Sprache 6 Ort der Kollision ermitteln? 7 Broadphase, Narrowphase, Solving? 8 Spoiler

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)

Wie wäre es wenn sich auf eine Bezeichnung geeinigt wird (imo möglichst eine ohne Gebrauch von Generics o.Ä.) und das ganze dann in den Leitfaden für Autoren kommt. Irgendwann kann dann ja auch in jeder Sprache eine Bibliothek entstehen, die die Datentypen mit diesen Bezeichnungen anbietet. --Chromanoid 12:04, 4. Nov. 2011 (CET)

Ich vote mal für Vec* Mat* Quat* Color* (angelehnt an GLSL), ansonsten finde ich wie schon erwähnt Vector*t Quat*t Matrix*t gut (* dimension, t für typ -> f für float d für double i für int b für byte) (angelehnt an javax.vecmath). --Chromanoid 12:07, 4. Nov. 2011 (CET)

Ein normaler Benutzer oder vor allem ein Anfänger will den Code nach Möglichkeit einfach kopieren und testen können, ohne bei sich die Datentypen anpassen zu müssen. Deshalb sollten Datentypen gewählt werden, die auch von Haus aus mitgeliefert werden. Deswegen bin ich auch gegen Vector2f in Java. Darauf spekulieren, welche Datentypen es in Zukunft noch geben könnte, will ich ebenfalls nicht.

Um in Java die Verwendung der generischen Klasse zu sparen, kann man auch Arrays verwenden. Statt Generics an den jeweiligen Typ angepasste Klassen zu verwenden bringt meiner Meinung nach keine Vorteile.

Also: ich bin dagegen, in Sprachen Datentypen anzugeben, die es nicht gibt oder die erst durch eine zusätzliche Bibliothek verfügbar sind. --Sacaldur 12: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)

Spoiler

Für einen C++ Quelltext gibt es offensichtlich bereits zum Testen ein Element, welches den Code verstecken soll. Abgesehen davon, dass es im IE 7 nicht funktioniert (der Quelltext ist permanent sichtbar), sollte dafür eventuell eine Vorlage angelegt werden, der man den Titel und den Inhalt übergeben kann. --Sacaldur 11:57, 4. Nov. 2011 (CET)

Das element funktioniert jetzt auch im IE 7, dennoch finde ich, dass das in eine Vorlage ausgelagert werden sollte.