Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Tobiking

1x Rätselkönig

  • »Tobiking« ist der Autor dieses Themas
  • Private Nachricht senden

1

12.08.2003, 12:27

Ego Shooter Theorie

Ich konnte die Nacht nicht schlafen und habe ein bisschen darüber nachgedacht wie man so einen Ego-Shooter weiter macht. Das mit dem BSP Tree und PVS habe ich erstmal ein bisschen nach hinten verschoben da mit da noch ein bisschen das Wissen fehlt und da richtig was mit zu machen. Das einzige was ich aus dem Octree Teil aus dem Buch könnte ist für die Kollision den BSP Tree verwenden. Wobei ich bei einem anderen Problem bin. Wie funktioniert die Kamerabewegung in einem Ego-Shooter? Ich bin alles durchgegangen und habe mir überlegt wie Sinnvoll es ist. Bin dabei zu dem Schluss gekommen das man für den Spieler eine Bounding Box anfertigen könnte oder eine bzw. zwei Linien. Wobei mir die Idee mit den Linien bisher mehr zusagt. Es wird erst getestet ob die Linie die Ebene schneidet und wenn das zutrifft ob das Dreieck geschnitten wird. Wenn ja muss man die Kamera um soviel höher gesetz werden wie der untere Punkt sich unter der Ebene befindet. Bei den Bounding Boxen war ich am überlegen man könnte testen ob der die Normalen schneidet usw. aber wenn man mitten auf einem Dreieck steht wird auch nur wieder mit Linien gerechnet. Das einzige was dann nur stört ist das ich Trianglefans habe und die dann erst in wirkliche Dreiecke verwandeln muss usw. Ich kann mir nie vorstellen das so viel arbeit immer wieder erledigt wird und noch so schnell laufen kann.

Jens

Treue Seele

Beiträge: 117

Wohnort: Dresden

  • Private Nachricht senden

2

12.08.2003, 13:04

wieso eigentlich so kompliziert

Du kennst doch die eingesetzten Modelle.
Zu jedem Modell würde ich eine feste Kameraposition speichern.
Beim Wechsel der Kameras setzt Du einfach die Kameraposition auf die Modellposition + die relative Kameraposition.

...Oder habe ich hier das Thema verfehlt?

Tobiking

1x Rätselkönig

  • »Tobiking« ist der Autor dieses Themas
  • Private Nachricht senden

3

12.08.2003, 13:18

Äh entweder versteh ich jetzt nicht ganz was du meinst oder du hast wirklich das Thema verfehlt. Es geht eigentlich darum das es egal welches Model ich spter nehmen werde die Kamera auf einer bestimmten höhe sein soll. Es ging mir um die Bewegung. Irgendwie zu bewerkstelligen das die Kamera nicht durch den Boden fällt. Ich wollte dann dafür eine Linie mit der Länge die Höhe der Kamera über den Boden ist nehmen und sobald diese ein Dreieck schneidet die Linie wieder nach oben bewegen. Um den Wert den der eine Punkt drüber steht. Ich tu es mir nicht immer leicht mit der Umsetzung von sowas wollte deswegen gerne wissen ob das so vernünftig ist oder ob man doch noch was anders machen sollte.

Jens

Treue Seele

Beiträge: 117

Wohnort: Dresden

  • Private Nachricht senden

4

12.08.2003, 13:31

na ja trotzdem

Also Du willst irgendein Model nehmen und die Kamera irgendwo im oberen Bereich positionieren. Wenn das Model sich vorbewegt, soll auch die Kamera sich vorbewegen, ja?
Das mit der Boundingbox ist schon nicht schlecht. Ich würde zwar trotzdem die relative Kameraposition speichern, aber wenn diese fehlt, kannst Du doch BoundMax abgrafen und dies als relative Kameraposition nutzen.
Bein der Bewegung des Models wird die Kamera immer um die Position des Models mit bewegt.
Oder hab ichs immer noch nicht gefressen?
Anstatt der Linie würde ich BoundMax nehmen, damit die Kamera nicht im Körper steckt und dort die Cullingrechnungen erfordert (wenn Nearplane kleiner 1 ist)

Tobiking

1x Rätselkönig

  • »Tobiking« ist der Autor dieses Themas
  • Private Nachricht senden

5

12.08.2003, 13:39

Es stimmt schon was du sagst soweit war ich aber auch schon. Das Problem ist die Kollisionserkennung. Woher weiß ich ob man auf dem Boden steht ? Mir fällt nichts ein wie man eine Bounding Box mit einem Dreieck auf Kollision prüfen kann. Deswegen viel mir ein eine Linie zu nehmen von Kopf des Models bis zu den Füßen und diese auf Kollision zu prüfen. Ich wollte nur wissen ob das vielleicht später noch Probleme bereiten könnte oder ob man vielleicht 4 Linien nimmt (Die äußeren senkrechten Seiten der Bounding Box) zu testen da ja bei einer Linie wenn die direkt in der Mitte ist schnell irgendwo halb durch ein Dreieck fällt.

Jens

Treue Seele

Beiträge: 117

Wohnort: Dresden

  • Private Nachricht senden

6

12.08.2003, 14:07

achsooo

gut, also das mit der Kamera hätten wir, die ist nämlich undabhängig vom Kollisionstest. Einfach relativ zur ModPos setzen und mitbewegen...

Ob ein Modell den Boden berührt, kannst Du z. B. mit der Funktion ModelHitsModel prüfen, wenn auch der Boden aus Modellen, wie z. B. Gebäude, Kisten usw besteht.
Tja, das ist wirklich nicht einfach, denn schon kommst Du um den OcTree nicht mehr drum herum. Ohne ViewFrustum-Culling und die Einteilung Deines Umfeldes hast Du leider keine Chance, eine vernünftige Darstellung hinzubekommen. Gerade, wenn bei jedem Schritt geprüft werden soll, ob der unterste Punkt des Modells den Boden berührt.

Wenn Du nur einen Boden hast und das Model soll nicht auf Gebäude herumspazieren können, dann kannst Du doch die Z-Koordinate Deines Bodens abfragen und BoundMin darauf ausrichten.

Ja, Du könntest vier Linien nehmen. Genau die vertikalen Boundingbox-Linien.
Evtl so hier:

Zitat


return (IntersectLine(&vPointTrans[0], &vPointTrans[1], pvPointCol) || // Linie unten vorn
IntersectLine(&vPointTrans[0], &vPointTrans[2], pvPointCol) || // Linie links vorn
IntersectLine(&vPointTrans[1], &vPointTrans[3], pvPointCol) || // Linie rechts vorn
IntersectLine(&vPointTrans[2], &vPointTrans[3], pvPointCol) || // Linie oben vorn

IntersectLine(&vPointTrans[0], &vPointTrans[4], pvPointCol) || // Linie links unten vorn/hinten
IntersectLine(&vPointTrans[1], &vPointTrans[5], pvPointCol) || // Linie rechts unten vorn/hinten
IntersectLine(&vPointTrans[2], &vPointTrans[6], pvPointCol) || // Linie links oben vorn/hinten
IntersectLine(&vPointTrans[3], &vPointTrans[7], pvPointCol) || // Linie rechts oben vorn/hinten

IntersectLine(&vPointTrans[4], &vPointTrans[5], pvPointCol) || // Linie unten hinten
IntersectLine(&vPointTrans[4], &vPointTrans[6], pvPointCol) || // Linie links hinten
IntersectLine(&vPointTrans[5], &vPointTrans[7], pvPointCol) || // Linie rechts hinten
IntersectLine(&vPointTrans[6], &vPointTrans[7], pvPointCol) // Linie oben hinten

verstehst Du PointTrans sind die transformierten Eckpunkte der Boundingbox.

Werbeanzeige