Das deutsche QBasic- und FreeBASIC-Forum

[Caran]

Hallo Leute,
ich nehme mal an, dass bestimmt schon manche ein 3D Spiel programmiert haben. Ein Problem tut sich bei mir in Sachen Kollisionserkennung auf. Also weis jeand wie man das machen kann ohna auf irgendwelche Bibliotheken (wie newton.dll oder so) zurück zu greifen zu müssen? Da die Welten und Körper schon eher komplex ausfallen, muss da schon ein besseres System her als

[ThePuppetMaster]

Kollisionserkennung ist kein einfaches Thema, im bereich der 3D Programmierung.

Ich hab jezt leider keine Passenden Links für dich da, aber ich kann gerne mal nach einigem suchen. In VB hätt ich einen Code.


MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ]

[MisterD]

deine modele sollten alle ihre "größe" kennen (sowas wie den radius einer kugel der sie umgibt, wo sie ganz reinpassen), damit machst du erstmal einfach ne abstandsberechnung zu allen anderen objekten und schaust ob ne kollision sein könnte, dann gehste hin und prüfst auf speziell angelegte Kollisionsboxen, ungefähr so - und dann musste halt diese ganzen einzelnen boxen kollidieren.

So viel zum grundsätzlichen Vorgehen, das genaue kollidieren von den boxen darf dir jemand anderes erklären. Solltest du allerdings ne extrem präzise kollisionserkennung basteln wollen musst du natürlich alle polygone deines models einzeln testen. ach und nicht zu vergessen - wenn sich dein objekt bewegt reicht es oft nicht aus, nur die position nach der bewegung zu testen, auch hier, wenn du's genau testen willst musst du praktisch die gesamte bewegungsbahn prüfen, entweder über abtasten bei schneller bewegung (ungenau aber reicht eventuell) oder eben über richtig geometrie mit schnitt der bewegungsgeraden und der hitbox-(oder polygon)ebenen. - und sei gewarnt, die komplexität von sowas kann unter umständen sehr schnell explodieren - effektive implementierung solcher sachen bedarf eines durchaus lägeren studiums des Themas.
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[ThePuppetMaster]

[Bimi]

Nach jeder Neuberechnung eines Objektes zu prüfen ob es sich mit irgendeinem andren Objekt schneidet wäre zu aufwändig.

Kollisionserkennung bei 3D Spielen funktioniert nach dem Octree-Verfahren (Quadtree im 2D Raum).

Stell dir einen Zauberwürfel vor. Der virtuelle Spielraum wird in kleine Segmente unterteilt so wie die Segmente bei einem Zauberwürfel. Stelle dir einen Raum mit 10*10*10 m Kantenlänge vor.
Octree grad 0: 1 Teilraum zu 10m kantenlänge
Octree grad 1: 8 Teilräume zu 5m Kantenlänge
Octree grad 3: 64 Teilräume zu 2,5m Kantenlänge
...

Je höher der Grad desto feingranularer ist der Baum. Bei der Berechnung der Position des Objektes nach seiner Bewegung wird diese Position in die entsprechende Zelle im Octree vermerkt. Erst wenn mehr als ein Objekt ganz oder Teilweise diese Zelle belegen, muss zwischen diesen beiden und nur zwischen diesen beiden geprüft werden ob es zu einer Kollision kam.

Die eigentliche Kollision wird bei einfachen Objekten durch eine boolsche Verknüpfuung der konvexen Hülle oder Bounding Box erreicht. Ist die Schnittmenge ungleich 0, hat es gekracht.

Oktrees verhindern dabei das z.B. bei einem Flugsimulator jeder popels Baum auf kollision geprüft werden muss - durch den Octree weiss ich welche unmittelbar in der nähe liegen und muss nur die prüfen.

Der große Nachteil von Octrees ist, das sie bei höherer Granularität Speicher ohne Ende fressen. Die Lösung hierfür nennt sich schwach besetzte Octrees - aber das würde hier zu weit führen...

[Bimi]

[quote="ThePuppetMaster"]

[MisterD]

wie gesagt, wie mans macht kommt immer drauf an wie genau mans haben will so n voxel-engine-mäßiges octtree verfahren ist für das meiste sicher ausreichend (wenn man die richtige auflösung findet), für wirklich genaue simulationsmodelle braucht man dann doch die geometrische lösung mit viel mathe.
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[Bimi]

[PMedia]

[OT]
Bimi, warum stellst du dich nicht mal vor? Würd mich mal intressiern wer du bist, so.... und sicher nicht nur mich, hier stürzt so ne gewaltige Ladung KnowHow auf einmal rein, und keiner weiß wo vorn und Hinten ist
[/ot]

[Bimi]

[MisterD]

svg
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[atari]

[Caran]

Hallo erstmal,
da hat sich ja schon ganz schön was angehäuft. Also ich danke euch allen und noch eine Frage am Rande:
Wie kann man mit ogl gucken ob vor einem bestimmten Punkt etwas gezeichnet wurde oder nicht? Geht das?

MfG Caran
_________________
Eine Erkenntnis von heute kann die Tochter eines Irrtums von gestern sein.

[atari]

das geht.
bei opengl hat ja eine fläche zb die länge 1 und die breite 1 oder die länge ist 10 und die breite ist 10. da bringst du ja deine texture unter. dann bestimmst du ja wie oft die texture in der länge 1 und in der breite 1 erscheinen soll, ist es mehr als 1mal, hast du sogenannte kachel, das macht man nur wenn der übergang nicht so gut erkennbar ist als trennstelle.
also kannst du in der länge 1 zb 10mal deine texture unterbringen.
lassen wir es mal bei länge 1.
wenn die texture 1mal in der fläche erscheint , teils du die länge 1 durch die anzahl der pixel in der länge und 1 durch die anzahl der pixel in der breite.
eine textur-bmp 512*512pixel :
wenn du jetzt auf der opengl-textur langmarschierst, gehst du zb 25*1/512 einheiten (also 0,0488281 auf der opengl-fläche, so macht man es ja auch bei translate)), das sind dann 25 pixel auf deiner bmp-texture und da fragst du ab, welche farbe jetzt der punkt hat.

du hast sozusagen deine pixel-bmp-fläche genau unter deiner opengltexture-fläche liegen und produzierst deinen weg auf deine bmp-fläche.

das musst du jetzt programmrieren.

[Caran]

na also ich weis nicht so recht ob das mir dabei hilft...ich hatte da eher so an DepthBuffer gedacht, um zu kontrollieren ob vor einer Position im Raum ein Polygon gezeichnet wurde, sprich, ob man es sieht. Vielleicht habe ich mich einfach nur falsch ausgedrückt, trotzdem danke.
MfG Caran
_________________
Eine Erkenntnis von heute kann die Tochter eines Irrtums von gestern sein.

[atari]

...ich hatte da eher so an DepthBuffer gedacht....

kannste bei opengl vergessen.



...ob vor einem bestimmten Punkt etwas gezeichnet ....

das kontrollierst du dann auf der bmp-datei.

[marzec]

[Caran]

Nee also das mit dem Kotrollieren ob vor einem bestimmten Punkt schon etwas gezeichnet wurde, war eigentlich eone Frage für sich und hat nichts mehr mit Kollisionserkennung zu tun (wollt halt keinen neuen Thread deswegen anfangen). Also ich habe in einem Spiel gesehen, dass wenn man auf die Sonne sieht auch noch Lichtstrahlen gezeichnet werden und wenn etwas vor der Sonne war, waren die Lichtstrahlen nicht mehr sichtbar. Also wenn etwas einen Punkt (hier die Sonne)verdeckt, wird etwas gemacht oder nicht (hier das Zeichnen der Strahlen). Mich hat halt mal interessiert wie das funktioniert.
_________________
Eine Erkenntnis von heute kann die Tochter eines Irrtums von gestern sein.

[marzec]

wenn du von einer lichtquelle wie der sonne ausgehst, ist das gar nicht so schwer. nimm an sie ist unendlich weit entfernt, d.h jedes andere objekt kann sie verdecken. schritt 1: winkel zwischen vektor vom betrachter zur sonne und dem richtungsvektor des betrachters errechnen > vektoren normalisieren und punktprodukt. gilt min winkel < winkel < max winkel zeige die strahlen. das wäre eine abart des lensflares. min und max winkel kannst du selbst wählen, bispielwerte 0, 20. mach das selb anstatt mit der sonnen mit allen bjekten die die sonne verdecken können. siehst du mindestens ein objekt unter dem winkel schalte die strahlen aus. dieser ansatz ignoriert objektgrößen.

willst du übertrahleffekte solltest du dir hdr rendering anschaun. is aber ein weni komplexer

hth
_________________
Yagl - yet another gameprogramming library