Also Felsen und schnee sind dir mit der Methode schon richtig gut gelungen. Beim Sand sit das wohl nur eine Farbfrage, und Gras wirklich realistisch hinzubekommen...Naja...kann man eigentlich vergessen...

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

Gras, hm, mal schauen, ich dachte daran, das ich das bei näheren Hinzoomen tatsächlich rendere, etwas weiter weg massiv Billboarding betreibe, und ganz weit weg garnicht anzeige. Aber das ist alles Neuland für mich Zukunftsmusik.

Besonders froh bin ich darüber, das es Performancemäsig gut geht.

Ich hab jetzt ein paar Maltools (verschiedene Brushes Größen und Formen, sowie Spraydose) drumherumprogrammiert, und man kann jetzt zum Beispiel sowas ins Terrain "malen":

Also mir gefällts.

Das einzige was den realsimus trübt ist der fakt, dass ähnlich hohe erhebungen nicht beschneit sind. Wenn sich der Berg als einzige erhebung im Flachen befindet, siehts wirklich astrein aus.

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

Jetzt pack noch LOD rein und füge Details mit Perlin-Noise hinzu. Dann wird das sowas von ultra

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

Zu dem LOD hab ich ne Frage. Wenn ich das richtig verstanden habe, bedeutet das:

"vermindere die Polygonanzahl je weiter man vom Betrachterstandpunkt entfernt ist."

Momentan speichere ich meine Grafikdaten in Displaylisten. Jeweills für jedes Ende des Octree's eine Liste.
Und das ist IMO sehr performant.

Wenn ich jetzt LOD implementieren würde müsste ich ja das Rendering jedesmal neu machen. Würde dann auf Vertex-Arrays umsteigen.

Also, auf was ich hinauswill: derzeit läuft es mit Displaylisten ala "Brute Force" eigentlich sehr gut, und LOD erfordert ja selbst wieder einiges an Rechenaufwand,
den ich jedesmal neu aufwenden müsste, wenn sich der Betrachterstandpunkt ändert.
Ich frage mich, ob sich das überhaupt lohnt. Ich hab keinen Bock, aufwendig LOD zu implementieren, um dann festzustellen das es nicht wirklich was bringt.

Oder hab ich LOD völlig falsch verstanden?

Nein so funktionierts.

Nachteil der DL ist, dass sie speicher auf der GraKa verbrauchen. LOD nicht. LOD vermindert einfach die Polygonzahl. Ich hab aber auch schon gehört, dass man VertexArrays und LOD irgendwie geschickt miteinander kombinieren kann. Aber frag mich nicht wie...

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

Kann man die größte einer DisplayListe exakt ermitteln? Also nicht nur Vertexdaten, sondern wieviel die compilierte DL am Ende tatsächlich im Speicher der GraKa ablegt inklusive State-Changes etc?

Derzeit weiß ich nicht wirklich, wieviel Speicher ich im GraKaRAM schon verbrauche. Ich hab ein "low-end"-Target, Mobility Radeon m100, 16MB" (also die allererste Revision dieses Chips), sowie eine (für meine Verhältnisse) "high-end" Target, eine Nvidia FX5700, 128MB. Auf beiden soll es vernünftig laufen, das tut es momentan. Das Heightfield ist 256x256 groß, und ich hab nicht vor, es größer zu machen.

Sind alle Octree-Bestandteile im Frustum, komm ich auf etwa 30 fps auf der Nvidia, übelst denkt man erstmal. In der Praxis des Anwendungsfalls kommt diese Situation allerdings kaum vor. Zoome ich näher ran, also etwa wie auf dem Bild oben, habe ich je nach Lage zwischen 50-140 FPS, im Mittel ca. 70 FPS würde ich sagen. Die Radeon schafft etwa die Hälfte davon.

Low-End läuft auf einem P4 1,7
High-End läuft auf einem P4 2,66

Je nachdem wie groß ich die Endelemente des Octree's mache, kann ich das ganze CPU-lastiger oder GPU-lastiger laufen lassen.

Ist das überhaupt "schnell"? Ich hab ja keinen Maßstab, was ich schaffen müsste, damit ich angeben kann

Hab jetzt Backface Culling und Fog aktiviert, komme damit (sozusagen als kleine korrektur) auf
93 FPS, wenn alles im Frustum ist,
ca. 130 FPS durchschnittlich, beim viewen.

auf der Nvidia.

Interresant finde ich, das der Fog etwas ausmacht. Mit Fog wird es um einige FPS schneller, obwohl er ja immer noch die Vertices im Fog zeichnen muss. Ist wohl sehr Treiber-Implementationsabhängig!?