Als ich für Carad ein Geosphere Objekt implementierte, kam mir der Gedanke, dass sich die rekursive Struktur einer solchen an sich perfekt für eine sphärische Landschaft eignet. Wahrscheinlich sind weder der Gedanke noch der Algorithmus neu, der Grundgedanke ist jedenfalls dieser:
Bei einer Geosphere wird jedes Dreieck rekursiv in jeweils vier Subdreiecke unterteilt, bis die gewünschte Ordnung erreicht ist. Vom Kugelmittelpunkt aus gesehen, enthält jedes übergeordnete Dreieck sämtliche untergeordneten Dreiecke, solange die Schnittpunkt nur auf bezüglich der Richtung Schnittpunkt- Kugelmittelpunkt verschoben werden. Damit ist sehr leicht ein dreiecksbasierter Quadtree erstellbar, dessen Oberfläche schnell bestimmt ist, da jeder Punkt leicht auf die Oberfläche projiziert werden kann, indem die Gerade definiert durch Punkt- Mittelpunkt den Quadtree entlang mit den Dreiecken verschnitten wird - womit man nach ca. 20 - 30 Triangleintersections (je nach Komplexität der Geosphere) den entsprechenden Schnittpunkt hat.

Bei der Suche nach einem Algorithmus, eine entsprechende Landschaft zu generieren, bin ich hier fündig geworden:
http://freespace.virgin.net/hugo.elias/models/m_landsp.htm

Sphärische Landschaften haben den Vorteil, dass sie quasi "unendlich" sind, außerdem muss man sich um die Sichtbarkeit keine besonderen Sorgen machen, da in gewisser Entfernung ohnehin alles hinter dem Horizont verschwindet.
Die Demonstration braucht beim ersten Start ca. 10-20 Minuten, um die gesamten Daten (ca. 70MB, der Planet besteht aus 1.5 Millionen Dreiecken) anzulegen, danach werden diese gespeichert und das Programm startet in einigen Sekunden.
Interessant ist wahrscheinlich noch der "jump" Knopf, mit dem direkt die Vor- und Nachteile von statischem LOD begutachtet werden können .
Natürlich werden nur die Dreiecke an die Grafikkarte gesandt, die auch tatsächlich im Frustum liegen, für entsprechende Tests eignet sich wiederum der zugrundeliegende Quadtree perfekt.
Das Demo benötigt eine Videokarte mit 3D-Texturenunterstützung (in Hardware!), da diese der einfachste Weg sind, schnell eine gute Texturierung für ein Objekt dieser Komplexität zu bekommen.


Mit Cursortasten wird gesteuert, SHIFT beschleunigt die Bewegung, für eine "Planetenumrundung" benötigt man ca. eine halbe Stunde.
Hier gehts zum Download (ca. 600KB):
http://www.basegraph.com/bg/demos/GeoApp.zip

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

Kannst du Gedanken lesen ?
Genau sowas hab ich grade gesucht.
Danke.

_________________
Wer Ordnung hält, ist zu faul zum Suchen

Schöne Idee mal auf einem wirklichen Kugel mit Landschaft drauf zu laufen. Da fällt die Sache mit dem Horizont wenigstens richtig auf. Leider ist die Texture nicht so detailliert.

@bighead
Schön wenn es dir nützlich ist. Ich finde diese Methode Landschafte zu generieren erzeugt recht ansehnliche Ergebnisse, außerdem kann sie erweitert werden: dem QuadTree könnten auch leicht Vegetation und andere Objekte zugeordnet werden, sodass mehrere tausend oder Millionen Objekte recht performant gerendert werden können. (Bei den LOD-Versionen des Planeten würden diese natürlich weg fallen).

@Lars
Die 3D-Texur ist nur eine ad-hoc Lösung (über meinen 3D-Texturgenerator mit Zufallswerten generiert), damit es zumindest ein wenig Struktur drinnen ist.
Über ein Vertexprogramm könnte das Wasser leicht animiert werden (entsprechende Parameter wären schnell erzeugt), es könnten auch verschiedene Texturen übergeblendet werden, anstatt einfach die Farbe und den Alphakanal einer einzigen Textur zu variieren.
Schwieriger sind dann schon komplexere Oberflächenstrukturen (v.a. ein Straßennetz, abwechslungsreiche Vegetation), da man dann mit vier Textureinheiten (von mehr sollte man wahrscheinlich nicht ausgehen) recht bald ans Ende kommt. Der Algorithmus ist allerdings schnell genug, um auch mehrere Passes zu rechtfertigen.

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

Ist das nur bei mir so, oder ist es normal das ich so wenig FPS habe.
(Schätze auf 3 FPS bei mir)
Ich habe aber gar kein so schlechten Rechner(1600 Mhz,GF 2 Ti,256 MB DDR)

_________________
Wer Ordnung hält, ist zu faul zum Suchen

Die GF2 kann keine 3D Texturen und daher ist das vermutlich Software Rendering.

Wenn du in GeoForm.pas die Zeile 104 auskommentierst (Tex3D.Display) sollte es auch bei dir flüssig laufen - die 3D-Textur wird dann nicht gebunden (die "Struktur" fällt dann weg).
Theoretisch könnte man auch 2D-Texturen nehmen - dazu müsste man aber die Texturkoordinaten auf die Ebenen der Polygone projizieren, was bei so vielen Dreiecken aber leicht aufwendig ist (zumal wenn die Koordinaten an den Ecken soweit möglich auch noch zusammenhängen sollen).

P.S. Seit der Installation des letzten Treibers, fällt mir auf, dass dass OpenGL ewig lange braucht, wenn ich ein OpenGL Fenster (wie etwa bei dieser Landschaft) maximiere (mehrere Sekunden).

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

das sieht mal nach was wirklich brauchbarem aus

Habs zwar noch nicht probiert (er erstellt noch Dreiecke ) aber mir fällt da gleich mal ne Frage ein. Wie werden die Dreiecks daten dann geladen? Schmeißt der die kompletten 70MB in den RAM?
Und wie funktioniert hier die Sichtbarkeitsprüfung der Dreicke? (Irgendwas besonders?)

endlich ist er fertig
Wie wärs noch mit der Möglichkeit die Kugel nicht nur von außen zu sehen sondern noch schnell von außen zu drehen? Oder etwas höher über der Oberfläche zu schweben?


Aber mir ist da gerade noch was anderes eingefallen. Irgendwo hab ich letztens gelesen das es die kompletten Geometriedaten der Erde als 4 CD Version zum kostenlosen bestellen oder Download gibt.
Den rest kannst du dir sicherlich denken
Das wär aber sicherlich ziemlich cool

Ja, die Dreiecke werden in den RAM geladen und als OpenGL Arrays gesendet. Displaylisten und VBOs sind bei sehr großen Datenmenge nicht mehr tragbar (schon bei meiner Videokarte (64 MB Radeon 9000) fing der OpenGL Treiber an wie verrückt auf der Festplatte auszulagern, anstelle in den Systemspeicher, in dem genügend Platz gewesen wäre - an sich ein Treiberschwachstelle, aber das nützt dem geplagten Programmierer auch nix ).
Im Systemspeicher ist aber genügend Platz für eine bis um zwei Größenordungen größere Sphere, und da man inzwischen von mindestens 256MB ausgehen kann, habe ich es mir gespart entsprechende Daten dynamisch nachzuladen.
Da die Sichtbarkeitsprüfung recht gut greift (die Dreiecke der Geosphere werden anhand der Bounding Spheres ihrer Inhalte durchlaufen, dank der rekursiven Struktur sind das gar nicht so viele Tests) werden nie so viele Dreiecksdaten gesendet, dass die an sich etwas langsameren OpenGL Arrays stören würden - außer wenn der "jump" Befehl verwendet wird und am Anfang wirklich viele Dreiecke im Blickfeld liegen, bis die ersten LOD Modelle greifen. Übrigens verwendet das Ganze nicht mal Backface Culling (wenn ich in GeoForm.pas nach Tex3D.Display glEnable(GL_CULL_FACE); einfüge, bekomme ich nochmal ca. 20 FpS mehr...).

@Drehen und Schweben:
Also da hört sich doch alles auf . Wozu ist denn der ganze Source dabei - öffne das Projekt und ändere die Routine bJumpClick gefälligst selbst so ab, wie du sie haben willst. (Mit GetASyncKeyState kannst du jederzeit den Tastaturstatus abfragen, in DrawGeo ist alles Wichtige der aktuellen Steuerung drinne - weitere Controls sollten an sich schnell eingebaut sein) .

@Erdgeometriedaten:
Wenn ich die Daten hätte, könnte das Format eventuell in was Brauchbares konvertiert werden, und die Geosphere so abgeändert, dass nur sehr kleine Teile davon zur Laufzeit (zu)geladen werden (müsste ich ohnehin, da die ich generell mit single-Genauigkeit arbeite, die für Objekte dieser Größe aber nicht mehr mit zufriedenstellender Auflösung funktioniert). Möglich wäre es aber, da der zugrundeliegende Algorithmus nicht nur mit einer Kugel funktioniert, sondern auch mit jedem beliebigen Teil einer Kugeloberfläche.
Wenn du den Link irgendwo hast, wäre (wahrscheinlich nicht nur) ich jedenfalls interessiert daran, da man sowas an sich für alles Mögliche gebrauchen kann (ich glaube Braveheart (hab's das Spiel aber nie gespielt oder auch nur gesehen) verwendete Satellitendaten für die Spielumgebung).

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

uh, ich glaub das war in der Readme zu dem 3D Stellarium erwähnt was ich auf der Naturewizard Seite aus der Link Sektion deiner HP gefunde habe.
Ich schau mal nach

Noch eine andere Idee:
Man kann ja maximal nur eine halbe Kugel sehen. Könntest du nicht in den entsprechenden Quad Tree Nodes in einer bestimmten Tiefe noch eine Ebene speichern, die als Sichtebene für den ganzen Block gilt?
Denn dann könnten auch beim Sprung vielleicht 40% der Kugel ausgeschlossen werden ohne an OpenGL gesendet zu werden und die Vertex Daten für einen Frame würden immer auf die Karte passen. Man kann ja selber eine gewisse Menge an VBO's belegen und die jeweils im Frame sichtbaren Datenblöcke dann immer hineinkopieren. Da man sich nicht schnell um die Kugel bewegen kann würde sich die Menge der jeweils neu sichtbaren Punkte in Grenzen halten.

hm, als ich da vor ner Woche war ging der Link noch.
Über ein wenig URL Änderung hab ich nu aber folgendes gefunden(Ist irgendwie Teil eines Plugzeugsimulator Projekts) :
http://www.flightgear.org/Downloads/scenery-0.9.2.html

Hier in der Mitte in den Links gibts auch ne Menge Links zu den Thema :
http://www.flightgear.org/links.html

ich zieh mit gerade mal so ne Daten von http://www.flightgear.org/Downloads/scenery-0.9.2.html . Mal sehen was da drin steckt

Oh je,
hier nochwas :
http://edcdaac.usgs.gov/gtopo30/gtopo30.html
es gibt ne Menge für die Geometriedaten der Erde...

einfach hier in den Links : http://www.flightgear.org/links.html unter Geographical Data and Maps schauen...

ich saug mal ein bissel mehr und schau mir mal an wie das aufgebaut ist

man schaue sich dieses Bild an...
http://www.geocities.com/drgportugal/dgtv/europa_d.jpg

hier gibts ein Programm was die Geometriedaten anzeigt bin noch am downloaden )
http://www.geocities.com/drgportugal/dgtv/

unten gibts noch Links zu Geometriedaten.

Oh je,
wenn ich das sehe bekomme ich echt lust da selbst was zu machen