Hi,
in letzter Zeit hab ich versucht eine Heightmap mithilfe von TRIANLGE_STRIPS zu rendern. Doch es hat nie gefunzt. Es kamen immer nur so "Rippen" heraus, die die Form der Landschaft hatten. Vielleicht hat von euch das schon jemand gemacht.

MfG HomerS

_________________
"Ich würde ja gern die Welt verändern, aber Gott gibt mir den Quelltext nicht"

da bist du gerade beim Richtigen gelandet
terrain mäßig hab ich schon alles mögliche gemacht und dementsprechend auch alle möglichen Fehler gemacht. Das mit dem Rippen hatte ich auch schon mal, du musst einfach nur aufpassen, dass du die Vertexe in der richtigen Reihenfolge aufrufst, etwas Code von dir würde hier auch nicht schaden.
Ich zeig dir hier einfach mal ne simple Beispiel Bruteforce Implementation:

das glBegin muss wiederholt werden, ansonsten sieht er vom Ende der Spalte bis zum Anfang der nächsten auch nen Triangle, man kanndas aber auch außen vorlassen undvon links nach Rechts, dann eine runter und von rechts nach links und so weiter machen, dann brauch man aber ne if Abfrage und ne zweite z-For schleife.
Schau am besten auch mal hier
<a href='http://www.gametutorials.com/Tutorials/opengl/OpenGL_Pg4.htm' target='_blank'>http://www.gametutorials.com/Tutorials/ope.../OpenGL_Pg4.htm</a>
das zweite terrain tutorial, wobei der nen kleinen Fehler macht und eine z Zeile zuviel schreibt...
Man darf nicht vergessen, dass man für n^2 Felder n^2+1 Punkte braucht!

[Edit] hier gibts doch auch nen gutse Tutorial oder so dafür [/Edit]

_________________
"OpenGL verbindet"<br>- für die Völkerverständigung zwischen Delphi und C++ ^^

Danke, geht alles gut. ich hab nur die glVertex vertauscht. Aber alles sieht trotz 256*256 verticies noch sehr eckig aus. Wie kann ich alles ein bisschen runder machen?

MfG homerS

_________________
"Ich würde ja gern die Welt verändern, aber Gott gibt mir den Quelltext nicht"

du könntest einfach intern neue vertizes aus den umliegenden interpolieren....

interpolieren heißt im prinzip die umliegenden (u. U. auch gewichtet) aufadieren und durch die anzahl teilen.

Beispiel:

Aus zwei Tris deines Terrains

4_ _6
|-----|
3----5

kannst du durch Interpolation vier machen. Was die Sache schon viel Runder erscheinen lassen sollte....

4--- 6
|3,5|
3--- 1

Diese Prozedur kannst du beliebig oft wiederholen.

-lith

_________________
Selber Denken macht klug!

Bei linearer Interpolation liegt der neue Vertex genau auf der Kante des Dreiecks, denn die Eckpunte eines Dreieck werden ja auch linear interpoliert. (gewichteten Durschnitt bilden)

Nach dem Laden der Höhenkarte kannst du ja einfach eine neue erstellen, die z.B. 4 Mal zu groß ist und in der dann die neuen Höhen gesperichert werden.
Eine andere einfache Möglichkeit ist Cosinus Interpolation zu verwenden, um die Höhe zu interpolieren:

Interpoliert von Höhe a nach Höhe b mit dem faktor f;
f liegt im Bereich zwischen 0 und 1.

c:=a+(1-((cos(f*pi )+1)/2))*(b-a);

Es wird dadurch alles schön rund, aber die Landschaft ist an den ursprünglichen Punkten flach. Bessere Ergebnisse errreicht man wenn man die ursprünglichen Punkte als Kontrollpunkte mit Bezier Kurven benutzt. Dann kann man auch schön Steigungen anpassen usw... Und wenn man das einmal beim Laden berechnet, dann wird das auch nicht langsamer dadurch.

Hi,

nochmal auf die Bezier Kurven zurück (noch nie damit beschäftigt):
1. Du meinst sicherlich die Punkte an die GraKa geben, und die macht den Rest? (Ziehe mir gerade das Tut)
2. Ist das halbwegs schnell? Wie meinst du "beim Laden berechnen"?

MfG HomerS

_________________
"Ich würde ja gern die Welt verändern, aber Gott gibt mir den Quelltext nicht"

Ich meinte eigentlich die Bezier Kurve selber ausrechnen, und aus diesen Daten dann eine detaillierte Heightmap erstellen. Der Programtext zum Rendern kann dann ja gleich bleiben außer das man die Höhenkarte anders skaliert. Wenn man das beim Laden des Levels also am Anfang macht, dann kostet das keine Rechenzeit während des Renderns.
Für die Berechnung von Bezier Kurven gibt es hier auch ein Tutorial.
Man könnte auch die Kurven direkt. z.B. als N-Patch an die HW geben, aber man braucht ja die Daten noch für die Kollisionserkennung.

Am Geschicktesten ist es, beide Vorschläge von Lars zu kombinieren: Also einmal die Bezierpatches selbst zu berechnen (eben für Kollisionserkennung), zum Rendern aber die OpenGL Evaluatoren zu benutzen (die ja, bei einem guten OpenGL Treiber, die T&L Fähigkeiten der Grafikkarte ausnützen sollten).

Ich habe übrigens gute Erfahrungen damit gemacht, die einzelnen Patches in Displaylisten abzulegen (und diese natürlich nur aufzurufen, wenn sie tatsächlich sichtbar wären). Leider lässt sich auf diese Weise kein LOD integrieren, OpenGL Evaluatoren sind aber dennoch sehr schnell.

Erstens werden dann nicht so viele Vertices an den OpenGL Renderer gesendet, andererseits muss man selbst auch nicht so viele Schnittpunkte speichern (die Position auf einer interpolierten Heightmap lässt sich ohne Probleme auch für sehr viele Objekte in Echtzeit ausrechnen - und ist sicher schneller, als wenn du tausende (oder sogar Millionen) von Dreiecken in einen BSP Baum bringen musst und diesen jedes mal durchläufst) - bei rechteckigen Patches weist du ja ohnehin sofort, auf welchem sich ein Objekt befindet, und kannst dann leicht die Position des Objektes auf diesem Patch ausrechnen. Übrigens sind hier bei geschickter Wahl der Kontrollpunkte sogar "überhängende" Bergspitzen möglich (was bei einem "normalen" Heightfield ja eine wahre Seuche ist), allerdings müsstest du dann einen eigenen Editor dafür schreiben (einfaches Importieren von Höhendaten reicht da nicht mehr aus), was so ganz ohne nicht ist ...

Ausserdem hast du dann die Freiheit jederzeit die gewünschte Auflösung der Bezierpatches bestimmen zu können, ohne irgendwelche Schnittpunkte neu berechnen zu müssen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Also das ganze von der GraKa machen zulassen ist nicht so gut:
1. Nur max. 8 Kontrollpunkte
2. Optimierung schwer/kein LOD
Die andere Methode werd ich nochmal ausprobieren, denke aber ist brauchbar.

_________________
"Ich würde ja gern die Welt verändern, aber Gott gibt mir den Quelltext nicht"

... in jeder Richtung- und die brauchst du garantiert nie. Um eine glatte Landschaft darzustellen, brauchst du nur Patches mit drei Kontrollpunkten in jeder Richtung. Evaluatoren sind nicht dazu gedacht, ein ganzes Objekt mit einem Patch darzustellen, vielmehr setzt man komplexe Objekte aus vielen Patches zusammen. LOD ist schon integrierbar (einfache entferntere Patches mit geringerer Auflösung darstellen lassen) - allerdings etwas aufwendig, da du zwischen Patches mit unterschiedlicher Auflösung evtl. weitere Geometrie berechnen musst, um einen nahtlosen Übergang zu erhalten (OpenGL verlangt strikt, dass Polygone, die sich in der Darstellung eine Kante teilen, auch die selben Schnittpunkten an dieser Kante teilen müssen, ansonsten gibt's unschöne Löcher).

Ich hab's so gelöst, dass Patches, die ohnehin flach sind, als Trianglestrip mit zwei Dreiecken dargestellt werden können - sind sie Nachbarn von Patches höherer Auflösung, berechne ich einen Trianglefan (der den Vorteil hat, dass jede Seite des Rechtecks mit unterschiedlicher Auflösung gesampelt werden kann). Da die einzelnen Patches ohnehin jeweils in einer Displayliste abgelegt werden, ist dieser Zusatzaufwand auch nur bei der Erstellung derselben notwendig - die Darstellung geht dann ohne zusätzlichen Rechenaufwand über die Bühne.
Wie gesagt, gibt's dafür kein LOD in Abhängigkeit von der Entfernung, Vorteil ist jedoch, dass die Samplingrate sofort an die Geschwindigkeit des jeweiligen Rechners angepasst werden kann.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

... in jeder Richtung. Häh?

_________________
"Ich würde ja gern die Welt verändern, aber Gott gibt mir den Quelltext nicht"

Ich hab dafür den Röttger ( <a href='http://wwwvis.informatik.uni-stuttgart.de/~roettger/html/Menu/menu2.html' target='_blank'>http://wwwvis.informatik.uni-stuttgart.de/...Menu/menu2.html</a> ) genommen, sieht toll aus und geht gut. Nur schätze ich mal, dass das für die neusten Graka und CPU Generationen nicht mehr allzu schnell ist.

_________________
"OpenGL verbindet"<br>- für die Völkerverständigung zwischen Delphi und C++ ^^

Für einen 2D-Evaluator benötigst du auch mehrere Sätze von Kontrollpunkten. Wenn du also ein Patch Gleichungen zweiter Ordnung zeichnest (drei Kontrollpunkte) übergibst du OpenGL in Wirklichkeit ein Arraymit 9 Kontrollpunkten, damit das 2D-Feld definiert ist.
Mit Gleichungen achter Ordnung wären es bereits 64 Kontrollpunkte - allerdings sind Gleichungen achter Ordnung ohnehin schon viel zu chaotisch, um für eine Landschaftsdarstellung wirklich noch von Nutzen zu sein.


Guter Link, sind Verweise auf schöne Satellitendaten dabei! Das sind halt völlig unterschiedliche Ansätze zum Terrain rendern. Mit Evaluatoren versucht man aus wenigen Schnittpunkten hochauflösende und glatte Maps (oder auch andere Objekte) zu generieren (kennt jemand noch Sacrifice? Da wurde dies recht exzessiv betrieben) - und man kann in Echtzeit die Landschaft verändern (es sieht dort recht eindrucksvoll aus, wenn man mit einem Zauberspruch ein Loch in den Boden stampft). Morrowind sieht übrigens auch so aus, als ob dort eher mit Evaluatoren gearbeitet wurde.
Die andere Methode ist, sehr sehr viele Höhendaten bei jedem Frame möglichst so zu reduzieren, dass es überall flüssig läuft, man die Datenreduktion aber dennoch nicht merkt.
Ich denke aber inzwischen ist man auch hier fast schneller, wenn man die Map in rechteckige Untereinheiten, die vielleicht einige hundert oder tausend Dreiecke (in Strips) enthalten, aufteilt und diese lokal auf der GraKa ablegt (Displaylisten oder VBOs) und zur gegebenen Zeit (wenn sie sichtbar sind) darstellen lässt.

Bei modernen Grafikkarten ist es oftmals die Übertragung von Schnittpunktdaten, die bremst, und gar nicht mal so sehr die tatsächliche Darstellung.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Die normalen OpenGL Evaluatoren werden nicht über die HW berechnet. Es gab mal so eine Extension für GF3 Karten die rechteckige udn dreieckige Bezier Flächen mit stufenloser Tesselierung gezeichnet hat. Man konnte für jede Kante und für die Mitte der Fläche eine Gleitkommazahl angeben. Damit eine Landschaft zu zeichnen, bei der die Detail dann langsam ausgeblendet wurden war recht einfach. Leider gibt es die Extension nicht mehr. Daher ist am Schnellsten die Landschaft in Blöcke zu unterteilen und jeden Block in einer Display Liste oder noch besser einem Buffer Object zu speichern.
Verschiedene Detailstufen müssen nicht unbedingt an der gleichen Kante enden. Man kann auch einfach die Randbereiche doppelt mit beiden Detailstufen zeichnen. Die Dreiecke schneiden sich dann so daß keine Löcher in der Lanschaft entstehen.

Was denkt ihr, ist am schnellsten bzw. am schönsten:

1. Aus Heightmap eine neue Heightmap mit höhre Auflösung durch Bezier-Kurven erstellen --> per LOD u. Octrees optimieren
2. Immer kleine Patches berechnen, die in DisplayLists und nur aufrufen, wenn gebraucht
3. Kleine Patches, keine DL sondern je nach Entfernung mit unterschiedlichen Details rendern.

Ich bin gerade dabei 2. mit 4*4 Patches zu proggen. Das mit dem vergrößern ist eine gute Idee. Wie würdest du vergrößern

1. An jede Seite einen Punkt vom anliegendem Patch dranmachen oder
2. Einfach 4*4 benutzen, nur die Äußersten Punkte ein bisschen verschieben.

Ich glaube 2. ist besser.

_________________
"Ich würde ja gern die Welt verändern, aber Gott gibt mir den Quelltext nicht"