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 9 Kollision von parallelen Geraden und Segmenten

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)

Es ist absolut irreführend die Collections-Klasse Vector aus Java für einen Vector als Koordinate zu benutzen. Man stelle sich nur mal vor man würde in C++ std::vector nehmen... Dann wären mir Arrays oder java.awt.geom.Point2D.Float lieber. Da Java kein gutes eingebautes System für lineare Algebra hat, wäre ich an dieser Stelle dann aber wirklich lieber für eine semioffizielle Open Source Bibliothek wie javax.vecmath. --Chromanoid 12:37, 4. Nov. 2011 (CET)

Woher kommt eigentlich in C++ Vector, ist sowas standardmäßig bei C++ dabei? Ich habe bei Java mal auf Arrays umgestellt. --Chromanoid 12:54, 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. --Sacaldur 12:20, 4. Nov. 2011 (CET)

Ja, würdest du das übernehmen? Du kennst dich besser damit aus. --David Scherfgen 12:23, 4. Nov. 2011 (CET)

Zunächst sollten die Panels aber noch etwas flexibler gemacht werden. So wie es jetzt ist, ist im "immer sichtbar"-Teil nur eine Überschrift erlaubt. Wenn man das für Quiz-Fragen nutzen möchte, sollte dort auch Text stehen können. Ich werde das noch einbauen. --David Scherfgen 12:27, 4. Nov. 2011 (CET)

Es können immernoch nur Titel verwendet werden. Fehler ab jetzt bitte in der Vorlage anpassen. (Ich musste mir auch erst Hilfe holen... ^^) --Sacaldur 12:43, 4. Nov. 2011 (CET)

Jetzt sollte alles klappen. Aber ich finde, dass die Überschriften nicht im Inhaltsverzeichnis erscheinen sollten. Das stört doch enorm beim Lesen! Darum hatte ich <xh4> benutzt ... --David Scherfgen 13:05, 4. Nov. 2011 (CET)

Hey, das sieht ja cool aus! Ja das mit den Überschriften finde ich auch doof. --Chromanoid 13:12, 4. Nov. 2011 (CET)

Die Überschriften können noch entsprechend angepasst bzw. entfernt werden. Man sollte auch schauen, ob eine Formatierung als Überschrift notwendig ist oder ob die normale Formatierung reichen würde. --Sacaldur 13:16, 4. Nov. 2011 (CET)

Kollision von parallelen Geraden und Segmenten

Auch parallele Geraden und Segmente können sich schneiden. Nämlich dann, wenn sie gleich sind bzw. in derselben Geraden liegen. Das sollte man vielleicht auch im Code abfangen. Wieder mit Epsilon ... --David Scherfgen 15:20, 4. Nov. 2011 (CET)