JLI Spieleprogrammierung

[Jonathan_Klein]

So, ich habe jetzt mal einen PickRay ausgerechnet (was mit gluUnProject wirklich leicht war ) und ne Funktion Kugel/Strahl geschrieben (ist ja auch eher leicht).
Jetzt fehlt eigentlich nur noch Strahl / Dreieck. Das würde bedeuten, aus 3 Punkten Ebene ausrechnen, Punkt auf Ebene ausrechnen und testen ob der Schnittpunkt im Dreieck liegt (entweder Innenseite der Begrenzungsbenen (die man auch noch ausrechnen müsste) oder mit den Winkeln zu allen Eckpunkten, letzteres dürfte schneller sein).
Ebenen kann man natürlich im Voraus berechnen, aber nur bei statischen Modellen.
Will ich jetzt ein Modell mit ~1.000 Dreiecken testen, ist das ja schon ein ziemlicher Aufwand.
Nun, wie würde man das ganze Optimieren? Man könnte ja irgendwie sowas wie einen Octree machen, mit verschachtelten Quadern, auf die die Dreiecke aufgeteilt sind. Nur um einen Quader mit einem Strahl zu testen, müsste man ja auch wieder 6 Ebenen haben und dann gucken ob die Schnittpunkte in den Begrenzungen liegen. Hört sich für mich nach den Aufwand von 6 Dreiecken an.
Außerdem, wenn ich jetzt einen animierten Charakter habe, wie mach ich dann noch einen Octree? Ich müsste ja bei jeder Bewegung neu bestimmen, in welcher Sektion die Dreiecke liegen.

Evtl. könnte ich den Character in Submeshs aufteilen, und die dann mit ner Kugel oder auch nem Quader (obwohl Strahl/Kugel ja schneller als Strahl/Quader sein sollte) umgeben. Aber dann hätte ich wieder mehr Drawcalls.
Ich könnte auch ein Kollisionsobjekt mit weniger Ecken machen, dann würde es ungenauer, ich hätte mehr Aufwand, und ich hätte Performaceverlust, weil ich dieses neue Modell ja auch animieren müsste.

Zur Zeit siehts also so aus, dass statische Modelle zwar einen Octree haben könnten, dieser aber wegen dem Aufwand Quader/Strahl nur wenige Unterteilungen haben sollte, und dass animierte Modelle so oder so doof sind.

Evtl. könnte ich auch für ein Dreieck gucken, ob es überhaupt nah genug am Strahl ist, um geschnitten zu werden, was nichts anderes als eine Kugel um jedes Dreieck wäre. Eine Kugel zu testen geht schneller als ein Dreieck zu testen, aber zusammen mit dem Berechnen der Kugel könnte es doch wieder murks sein.

Irgendwelche Ideen?
_________________
https://jonathank.de/games/

[Fallen]

Entweder du nutzt simple Hüllen die du um dein Modell setzt (Kopf=Kugel, Rest=Boxen oder Kapseln) oder du nutzt eine weniger detailierte Version des Modells, zB eine der LOD Stufen.

Das würde schon einiges erleichtern.

Auch könntest du dir mal die beispiele von PhysX anschauen, oder ähnlichen Physiklösungen.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[LeeDiGer]

Naja, ob du nen Test gegen Bounding Sphere oder OBB zuerst machst, bevor du den Octree durchläufst, bleibt dir überlassen. Ich benutz eine OBB.
Bei einer Kollision wird ein Octree mit vielen OBBs durchlaufen, bis ein Leaf erreicht wird, das keine weiteren Childs hat. Darin ist dann ein Array mit Dreiecken gespeichert, die man dann nur auf Kollision testen braucht. Nur muss man bedenken, dass ein Strahl mehrere OBBs schneiden kann und dann meistens einige Tests mehr absolvieren muss als man vielleicht denken könnte.

Und das mit den 6 Ebenen und einen Aufwand von 6 Dreicken bei 1000 Polygonen seh ich dann natürlich anders....wenn jemand so ne geile Funktion kennt, dann lasst mich es wissen
Ich hab so ne Funktion mal gebaut und u.a. nen Strahl gegen so ein 1000 Polygonobjekt laufen lassen. Eine Rekursionstiefe von etwa 4 sind bei meiner Funktion etwa das Idealmaß (6 oder 7 hatte ich mal bei fetteren Objekten mit bis zu 40000 Faces, aber das nur am Rande). Also in vielen Bereichen wirste so um die 30 OBB Tests haben (kommt immer drauf an, wie dich die Polygone beisammen sind). Wenn der Strahl ganz in der Nähe des Polygons ist, komm ich auf etwa 100 Tests (mal mehr OBBs, mal mehr Dreieckstests). Aber das ist ne funktion, die alle nötigen Dreiecke durchläuft, um die kürzeste Distanz zu ermitteln.
Hab auch ne Funktion, die sofort abbricht, sobald der Strahl ein Dreieck schneidet. Da hasse in der Regel nicht mehr als 20 Tests bei nem 1000 Polygonobjekt. Bei einem 40000er objekt hat man vielleicht so an die 200 Tests, also nur halb so wild.

Also je höher die Rekursionstiefe, umso mehr OBBs wird ein Strahl treffen, aber dafür muss man meistens weniger Dreieckstests machen. OBB Tests sind schneller. Da muss man einfach nur die richtige Balance finden. Außerdem muss man bedenken, dass hohe Rekursionstiefen viel Speicher im RAM belegen und die Ladezeiten beim Erstellen des Octrees erhöhen.

Und frag mich nicht, wie das bei Animierten Meshes gelöst wird....wenn ich mich da schlau gemacht hab, dann sag ich Bescheid
bei Warcraft wird ja anscheinden nur nach dem Feldersystem gearbeitet, aber in einigen Fällen kann ich mir vorstellen, dass eine Dreiecksgenaue Kollisionsabfrage bei animierten Meshes notwendig sein wird.
_________________
Kein Rückzug! Kein Aufgeben!

[Jonathan_Klein]

Ganz klassisch bei nem Egoshooter wenn wer angeschossen wird. Da könnte man schon genau Tests haben wollen.
Aber allgemein sollte doch 1 Box Test langsamer als 1 Dreieckstest sein, oder? Dann könnte man ja ungefähr ausrechnen, wie so das Verhältnis ist und dann dementsprechend die minimale Anzahl an Dreiecken pro Box berechnen (eine Box wird dann nur dann nocheinmal unterteilt, wenn man 2 Boxen erhält, die mindestens so viele Dreiecke hätten).

Wie würde den so theoretisch ein Boxtest ablaufen? Meine Idee wäre jetzt nur dass man 6 Ebenne hat und eine davon muss der Strahl so schneiden, dass der Schnittpunkt innerhalb des Vierecks liegt.
_________________
https://jonathank.de/games/

[LeeDiGer]