Hallo

Also ich bin kein Delpher, aber ihr habt hier einfach die besten Tutorials . Zum Punkt: Ich habe das Tutorial zum Terrain Rendering von Nico in C#.NET programmiert und das funktioniert bis und mit Teil II schon mal sehr gut. Bei den Quadtrees stehe ich allerdings an, d.h. nicht bei den Quadtrees selbst, sondern bei der Triangulation. Könnte mal jemand einen Codeabschnitt posten, bei dem die Vertices und Indices abhängig vom Quadtree berechnet werden (der wird nämlich im Tutorial übersprungen).

mfg Hitman

PS: Muss nicht C# sein, das kann ich dann schon selbst umformulieren, aber für den Ansatz in Delphi wäre ich dankbar.

_________________
Der Klügere gibt nur solange nach, bis er der Dümmere ist...

Meinst du, wie man je nach Rekursionstiefe zu den Koordinaten der Vertices kommt?
Das ist prinzipiell ganz einfach. Wichtig ist nur, dass du in der Prozedur, die das ganze zeichnet, immer die aktuelle Kantenlänge eines Blocks mitführst.

Sieht dann in etwa so aus:



Das einzig wichtige ist also wie gesagt, die Blockgröße mitzuführen, um von den übergebenen x- und z-Werten auf die Ecken des Blocks zu kommen.

Der erste Aufruf der Zeichenprozedur wäre dann wie folgt:


Damit wird genau in der Mitte des QuadTrees mit dem Zeichnen begonnen.

Ich hoffe das ist in etwa das, was du wissen wolltest.

Ich empfehle dir allerdings, für dieses Tutorial den (sehr gut kommentierten) Quelltext von der Seite hier zu ziehen, da du dir dort sehr viele Anregungen holen kannst.

Ansonsten wünsche ich dir noch viel Spaß mit dem Thema! Ich beschäftige mich momentan auch mit diesen Dingen (schau mal hierher), und ich muss sagen es macht wirklich Spaß!

Gruß,
Robert

Danke für die schnelle Antwort. Dein Projekt habe ich mir bereits angeschaut. Sieht sehr gut aus, so etwas hätte ich auch im Sinn, nur eben mit C#. Für diese Programmiersprache ist im Moment aber leider so gut wie nichts zum Thema Terrain Rendering vorhanden... Du meinst, man kann den Quellcode des Tutorialprojekts downloaden? Cool. Werde ich gleich mal suchen.

mfg Hitman

_________________
Der Klügere gibt nur solange nach, bis er der Dümmere ist...

Ja das ist möglich momentan aber noch (saumäßig ) schlecht verlinkt. Du findest die meisten Codes bei den Files, teilweise unter Binarys.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Den Quelltext gibts unter Files -> VCL-Sources -> Terrain CLOD (zweiter Download von unten)

Wie schon gesagt, der Quelltext ist sehr gut kommentiert und hilft zum Verstehen des ganzen wirklich weiter. Was ich auch empfehlen kann ist das Originalskript dazu von Stefan Röttger, der den Algorithmus entwickelt hat. Das gibts hier.

Was zum Quelltext noch zu sagen ist (steht auch ganz am Anfang irgendwo drin), ist dass er noch ziemlich optimiert werden kann und gleichzeitig etwas speziell ist (von wegen Heightmapgröße und so). Ich konnte bisher etwa 20% mehr Leistung aus dem Renderteil rausholen. Also: Nicht einfach abschreiben.

Gruß,
Robert

Hm, hab mich damals darum bemüht, daß der Code überwiegend gut zu verstehen ist. Geschwindigkeit hat erstmal eine stark untergeordnete Rolle gespielt, da das Thema komplex genug war Ich denke sogar, daß noch etwas mehr rauszukitzeln sein müsste, da nicht nur beim rendern sondern auch beim erzeugen der Matrix viel Potential verschenkt wird. Im 2. Terrain Tutorial ist auch eine Stelle, an der wenn man dreht, wird der Algorithmus schrecklich schneller Welche anderen Beispielprogramme sonst noch mit angezogener Handbremse laufen, wird aber nicht verraten

Da hast du recht, es gab zum Beispiel auch einiges, was du recht elegant gelöst hattest, was dann aber trotzdem etwas gebremst hat.
Zum Beispiel dass Dinge wie die Positionen von Nachbarn und Kindern immer in Arrays abgelegt waren. Dadurch konnte man zwar die Vertexgenerierung in einer Schleife machen und hat so Code gespart, aber die ständige Indexberechnung für die Arrays hat doch verblüffend viel Leistung gekostet.
Das eigentliche Zeichnen (also nachdem alle Vertices des aktuellen Blocks errechnet sind) kann ich nicht wirklich vergleichen, da ich den Teil komplett selbst geschrieben habe und da auch was entsprechend verschiedenes rausgekommen ist.
Genauso war es schon erstaunlich, wie viel Leistung es kostet, für jeden Vertex Texturkoordinaten zu übergeben.

Wo wir gerade bei dem Thema sind, hab ich auch mal ne Frage:
Hat jemand eine Idee, wie man die Normalenberechnung im voraus machen könnte? Denn ich kann ja nicht einfach für jedes Vertex im voraus die Normale berechnen und dann darauf zugreifen, da beim Rendern einmal durch den CLOD-Algo ganz andere Normalen gebraucht werden (nämlich welche für Flächen, die viel größer sind als die in der Umgebung eines Vertex), und selbst diese durch Dinge wie das Überspringen von Vertices, um Cracks zu vermeiden, oder Geomorphing wieder verändert werden können.
Ich hatte mir schon überlegt, für jedes LOD eine gesonderte Normalenmatrix anzulegen, für die niedrigste Detailstufe wären das dann eben entsprechend wenig Normalen bis hin zur Mapgröße im Quadrat für die höchste Stufe, aber das Überspringen von Vertices und gerade das Geomorphing spielen da nicht wirklich mit.

Gruß,
Robert

hm, im prinzip muss man glaube ich gar keine texturkoordinaten übergeben, denn terrains sind so organisiert, daß man mithilfe von planarem mapping das zeugs problemlos auf die landschaft bekommen müsste - automatische texturgenerierung.

Das ist gut! Sehr gut sogar!

An so was hatte ich noch gar nicht gedacht. Werd's bei Gelegenheit mal testen.

Danke für den Tipp!

Robert

Den Source habe ich heruntergeladen und werde ihn gleich mal 1:1 in C# umsetzen. Ich brauche zuerst mal ein Gefühl für diese Sachen, da ich erst seit kurzem DirectX (In einem OpenGL-Forum? Judas!!! ) programmiere. Sobald das Ganze mal funktioniert, werde ich entsprechende Schritte zur Leistungsverbesserung in Angriff nehmen. Danke erstmal für die zahlreichen Tipps.

mfg Hitman

_________________
Der Klügere gibt nur solange nach, bis er der Dümmere ist...

Für uns war das bisweilen noch kein Problem. Haben hier mehrere von der Sorte Häufig verstecken sie sich aber und verraten das nicht - aus Scham oder so Und wenns soweit ist: Screenshot nicht vergessen!

Bin doch mal gespannt, wie lang er bauchen wird, bis er bei OpenGL bleibt...

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Für C# gibt's ja hier auch einen OpenGL Header, der wesentlich besser als Tao oder csgl ist.

Eure Bekehrungsversuche werden allesamt scheitern... Nein, im Ernst: C#.NET = Microsoft, Managed DirectX = Microsoft. Wenn man 1 und 1 zusammenzählt wird man zu dem Ergebnis kommen, dass diese beiden Komponenten wohl am besten aufeinander abgestimmt sind. Und im Moment möchte ich mich nicht auch noch mit Kompatibilitätsproblemchen herumärgern, ist schon so schwierig genug.

mfg Hitman

_________________
Der Klügere gibt nur solange nach, bis er der Dümmere ist...

Mit dem C# OpenGL Header gibt's keine Kompatibilitätsprobleme. Das ist alles 100% managed und sicher.