spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi Loite, ;-)
in allen Dokus und Büchern, die ich bis jetzt überfliegen konnte, ist bei der Terrain-Höhenermittlung immer die Rede vom Strahl-schneidet-Dreieckstest, wenn es darum geht, zu ermitteln, auf welchem Quad sich der Spieler gerade befindet, um dann das betreffende Dreieck und damit auch die Spieler/Kamera-Höhe zu ermitteln.
Dazu wird ein Vertex-, ein Indexbuffer, die Dreiecke und die Quads noch mal extra gespeichert.
Für die Ermittlung des Quads ist ne einfache Multiplikation notwendig und dann für die Ermittlung des Dreiecks eben der StraheSchneidetDreieckstest.
Dazu kommt noch der Sichtbarkeitstest, welche Quads sich hinter der Kamera oder außerhalb des view frustums befinden.

Geht es nicht schneller, alle Dreiecke des Terrains an die RenderPipeline zu schicken und das Dreieck, auf dem der Spieler steht und damit die Spielerposition/Höhe mit der DX-Funktion D3DXIntersect zu ermitteln?
Dann müssen die Dreiecke nicht extra gespeichert werden.
Mir erscheint diese Funktion und der Rendervorgang des gesamten Terrains so rasend schnell, dass ich nicht weiß, was sinnvoll ist.
Offen gesagt habe ich nicht die Möglichkeit, alles so genau auszutesten...
Habt Ihr da Vergleichsgrößen?
Würde jemand von den reinen DirectX-Funktionen abraten oder vom Zeichnen des gesamten Terrains?
Danke nochmal.

stimmt, bei Zahlen über 10.000 Vertices für Terrains bin ich noch nicht ;-)
Ja, ich konnte mir bisher nicht vorstellen, dass es Terrains gibt, die so eine Größe annehmen. Aber eigentlich logisch, wenn man z. B. "return to castel Wolfenstein" von ID sieht. Es ist so genial, wie dort Details in riesigen Terrains aussehen. Kein Ruckeln usw.

Ich selbst hätte mir ein Terrain aus einem einfachen Gitter aus wenigen Vertices gebastelt und dann zusätzliche "statische" Modelle für Gebäude o. a. und Sprites für Bäume, Pflanzen usw. auf das Terrain gestellt.
Für die Modelle gilt natürlich die Ausschlussmethodik...
Übrigens habe ich mich doch für die Ermittlung des Quads entschieden. Das Quad wird, wie Du schon sagtest aus den x- und z-Koordinaten ermittelt und dann werden die zwei enthaltenen Dreiecke dazu mit dem StrahlSchneidetDreieckstest getestet.
Nur dass ich natürlich keine Quads speichere, wozu auch, sondern gleich QuadIndex*2=erstes Dreieck, QuadIndex*2 + 1=zweites Dreieck:
Funzt.
Aber die DX-Funktion DXIntersect prüft z. B. ein Mesh auf StrahlSchneidetDreieck und die läuft recht schnell. Irgendwie könnte ich mir vorstellen, dass intern auch noch ne Menge Optimierungen stattfinden...