4. Allgemeine Frage zu 3D collision detection

Allgemeine Frage zu 3D collision detection

  • D

    Hi,

    Hm, hat hier schon wer nen collision detector/handler für D3D oder OpenGL programmiert?
    Nicht das ich vor hätte einen zu coden, aber ich frag mich nur grad:
    - Ihr habt objekte, welche über translate/rotate irgendwohin bewegt werden. Woher kriegt der collision detector die Position der Objekte? Ausm Grafik-Speicher?
    - Gäbs ne Möglichkeit die Rechenarbeit an die GPU abzugeben?

    0
  • S

    a) Normalerweise hast Du ein struct oder eine Klasse (z.B. CKrieger), wo u.a. auch die Position und Richtung festgehalten wird.
    b) Kann ich mir nicht vorstellen. Normalerweise ist KI & Kollision noch(*) CPU Sache.

    EDIT: Vergess' das "noch"! Wär' irgendwie unsinnig, KI per GPU zu machen... 😕

    0
  • D

    Achso, dann erkennst Du ne Kollision aufgrund von Teilinformationen eines Objektes (Pos, Richtung, Umfang, etc.)? Ich dachte, da würden wirklich Dreiecke gegeneinander verglichen. Wenn mans ganz genau nehmen würde, dann müsste man ja aber auf die Dreiecke der Grafik zurückkommen, nicht?

    0
  • S

    durito schrieb:

    Achso, dann erkennst Du ne Kollision aufgrund von Teilinformationen eines Objektes (Pos, Richtung, Umfang, etc.)? Ich dachte, da würden wirklich Dreiecke gegeneinander verglichen. Wenn mans ganz genau nehmen würde, dann müsste man ja aber auf die Dreiecke der Grafik zurückkommen, nicht?

    Achso, kannst Du natürlich auch machen... (DooM ]|[)
    Dann hast Du natürlich auch irgendwo die Meshdaten. Aber aus dem Grafikspeicher solltest Du den Kram besser nicht extrahieren, erstens da Du Kollision und Grafik möglichst trennen solltest und zweitens weil die Verbindung GPU-Speicher <-> CPU-Speicher übelst lahm ist...

    0
  • D

    Sgt. Nukem schrieb:

    ... auch irgendwo die Meshdaten.

    Ja aber wo? Ich mein die Mesh-Daten hab ich ja erstmals in ner lokalen Version (d.h. Nullpunkt irgendwo am Model). Wenn ich das Objekt aber irgendwohin beweg (in der Grafik), dann sind die die Koordinaten aus den Meshdaten ja irgendwo in meiner "Grafikwelt". Muss ich die Transformation also zweimal ausführen, einmal in der Grafik und einmal für den collision handler?

    0
  • R
    Mod

    durito schrieb:

    - Gäbs ne Möglichkeit die Rechenarbeit an die GPU abzugeben?

    nvidia hat letztens ein nettes video veröffentlich indem die das mit der 6800 machen. 😃

    aber jeder andere macht das mit der cpu.

    rapso->greets();

    0
  • I

    durito schrieb:

    Sgt. Nukem schrieb:

    ... auch irgendwo die Meshdaten.

    Ja aber wo? Ich mein die Mesh-Daten hab ich ja erstmals in ner lokalen Version (d.h. Nullpunkt irgendwo am Model). Wenn ich das Objekt aber irgendwohin beweg (in der Grafik), dann sind die die Koordinaten aus den Meshdaten ja irgendwo in meiner "Grafikwelt". Muss ich die Transformation also zweimal ausführen, einmal in der Grafik und einmal für den collision handler?

    Nein.

    Nehmen wir mal an du hast eine Mesh, den du transformiert, rotiert irgendwo hin renderst.
    Diesen transformierten Mesh willst du jetzt z.B. mit einem Laserstrahl auf Kollision testen.
    Dazu subtrahierst du vom Ausgangspunkt des Strahls die Position des Meshes und rotierst den Ausgangspunkt des Laserstrahl zusätzlich um den Mesh mit der Rotation des Meshes.
    Dann hast du die Transformation des Meshes sozusagen ruückgangig gemacht und kannst dort immer mit dem Selben Mesh für alle Instanzen des Objektes deinen Kollisionscheck machen.
    Sollte ein Kollision stattfinden müsst du lediglich den Kollisionspunkt wieder mit Rotation und Position der Mesh-Instanz zusammenrechnen und fertig.

    Grundprinzip ist dabei eigentlich nur, das du lediglich die relative Postion der beiden Objekte benutzt. Das klappt alles wunderbar, wenn ein komplexes Objekt (Mesh) und simpleres Objekt (Strahl) hat. Wenn man jedoch zwei komplexe Objekte hat, dann muss eines komplett transformieren auf die relative Position transformieren.
    Aber eventuell gibts ja noch eine besseren Weg.

    0
  • D

    hm, krass.

    thx für die Antworten!

    0

  • IMHO sind Tri-genaue Kollisionen sowieso ganz selten nötig, genau wie pixelgenau.

    Bye, TGGC \-/

    0
  • D

    Bin an nem Projekt beteiligt, wo das nötig ist. Naja, hab (zum Glück :)) nix mit der collision detection zu tun, aber interessiert mich dennoch.

    0
  • S

    TGGC schrieb:

    IMHO sind Tri-genaue Kollisionen sowieso ganz selten nötig, genau wie pixelgenau.

    Bei D]|[ sind trigenaue Kollisionen JAWOHL nötig!!! 👎 😡 *trotz*

    🤡

    P.S.: Was einen mittlerweile nur schlaucht: Das nagelneue Shooter mittlerweile selbst wenn man kurz vorher sich ein nagelneues High-End-System angeschafft hat, auch auf dem nicht in allen Details flüssig laufen lassen kann... 😡 (Oder hat einer FarCry mit vollem AA & Co. _ordentlich_ laufen?!) *ausrast* *rumhüpf*

    😋

    0

  • Spätestens im Multiplayer ist die Tri-Collision Schrott, wenn dann plötzlich keiner mehr Tank Jr. spielt... 😎

    Bye, TGGC \-/

    0
  • S

    TGGC schrieb:

    Spätestens im Multiplayer ist die Tri-Collision Schrott, wenn dann plötzlich keiner mehr Tank Jr. spielt... 😎

    ...und alle das custom Snoopy-Model... 😃

    0
  • 0

    Sgt. Nukem schrieb:

    P.S.: Was einen mittlerweile nur schlaucht: Das nagelneue Shooter mittlerweile selbst wenn man kurz vorher sich ein nagelneues High-End-System angeschafft hat, auch auf dem nicht in allen Details flüssig laufen lassen kann... 😡 (Oder hat einer FarCry mit vollem AA & Co. _ordentlich_ laufen?!) *ausrast* *rumhüpf*

    😋

    Ich glaub nicht dass man von FarCry her auf alle anderen Shooter schließen sollte. Schau Dir DooM³ an: Spielbar noch auf einer Geforce4 MX (die ja bekanntlich absoluter Schrott ist). Natürlich nur in der niedrigsten Auflösung, aber selbst da sieht es schweinegoil aus 🙂 Da war halt der Meister J.C. am Optimieren.

    PS: AA ist sowieso ein Feature das man nicht braucht, bei ausreichend hoher Auflösung sind die Kanten eh glatt.

    0
  • N

    Bei X2 neigen sie angeblich dazu zu flackern ohne aa....

    0
  • I

    Sgt. Nukem schrieb:

    Bei D]|[ sind trigenaue Kollisionen JAWOHL nötig!!! :

    Wieso? (Hab zur Erhöhung der Leserlichkeit die ganzen Smilies entfernt 😉 )

    0
  • O

    weils d]|[ ist, da muss MINDESTENS eine trigenaue kollision genommen werden, die aber 20% schneller ist, als der "standard".
    in doomIV erwarten wir Pixelgenau 😉

    0
  • S

    interpreter schrieb:

    (Hab zur Erhöhung der Leserlichkeit die ganzen Smilies entfernt 😉 )

    IMHO verschlechtert das die Lesbarkeit... 🕶

    (...da man anhand des '🤡' hätte merken können, das ich das ähnlich wie otze sehe) 😃

    interpreter schrieb:

    Wieso?

    Weil Jay-Ci rockt... (oder "felst" wie TGGC als stolzer Deutscher sagen würde 🤡 )

    BTW: Könnt ihr euch noch an "Hundefelsen 4D" erinnern?? Muahaha... 😃

    0
  • O

    Sgt. Nukem schrieb:

    BTW: Könnt ihr euch noch an "Hundefelsen 4D" erinnern?? Muahaha... 😃

    ne, zu der zeit hab ich irgendwie noch nicht gelebt~~

    0
  • T

    Sgt. Nukem schrieb:

    Wär' irgendwie unsinnig, KI per GPU zu machen... 😕

    Oh nein, dann lies mal den Artikel aus Game Programming Gems 4 über neuronale Netze mit Pixel-Shadern...

    0
Anmelden zum Antworten