PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : 3d Grafik: Regelmäßiges Gitternetz vs. unregelmäßiges Gitternetz, welches ist besser?


Gast
2007-12-07, 02:45:06
Welcher Ansatz ist besser für eine Terrain Engine,
ein regelmäßiges Gitternetz bei dem die Gitterpunkte gleichmäßig wie bei einem
Schachbrett verteilt sind und sich hauptsächlich nur in der z-Achse (Höhe)
unterscheiden oder ein unregelmäßiges Gitternetz, bei dem jeder Gitterpunkt
durch eine X, Y und Z Koordinate gespeichert sein muß?

Wo sind die Vorteile der beiden Ansätze?
Mir selbst fallen spontan folgende ein:

- = Nachteil
+ = Vorteil

regelmäßiges Gitternetz:
+ eignet sich gut für LOD Berechnungen (Level of Detail)
+ weniger Speicherplatz für die Daten erforderlich, es müssen nur die Daten
der Z-Achse gespeichert werden, während man die anderen Koordinaten aus
einem einzigen Gitterpunkt extrapolieren kann, schließlich sind die Abstände
des Gitternetz gleichmäßig.
+ Es ist einfacher das Gitternetz mit Texturen zu versehen, desweiteren
können die Kanten an den Texturübergängen zu einer anderen Textur einfacher
kaschiert werden, da alle Texturen immer viereckig sind und der Texturgrafiker
die Übergänge entsprechen fließend gestalten kann, so daß die Kante nicht auffällt.
- die notwendige Rechenperformance ist bei flachen Gebieten (z.B. See,
Flachland) größer, da unnötige Gitterpunkte berechnet werden müssen, die
normalerweise bei gleichbleibender Ebene unnötig sind.
- wenn der Detailgrad, also die Abstände des Gitternetzes zu groß sind,
dann fällt das Gitternetz aufgrund der Höhenprofile negativ auf, denn die
regelmäßigkeit des Gitternetz wird dadurch sichtbar.
- um das Auffalen des Gitternetztes zu kaschieren muß der Detailgrad erhöht
bzw. der Abstand des Gitternetztes verringert werden, was wiederum mehr
Rechenleistung erfordert.
- sollte eine Weltkugel realisiert werden, dann kann das Gitternetz nur auf
einem zylindrischen Körper abgebildet werden, da sich das Gitternetz in
Richtung der Pole nämlich verengen müßte, was die Vorteile die man für die
Texturen hat zunichte gemacht

unregelmäßiges Gitternetz:
+ bei flachen Gebieten (z.b. See, Flachland) können unnötige Gitternetzpunkte
eingespart werden, dies steigert die Performance beträchtlich
+ eine Regelmäßigkeit des Gitternetztes ist ausgeschlossen, eine Landschaft
sieht daher (Texturen ausgenommen) naturgetreuer aus.
+ kugelförmige Planeten sind problemlos darstellbar
- LOD Berechnungen sind schwer bis gar nicht zu realisieren
- die Kanten des unregelmäßigen Gitternetztes können kaum bis gar nicht
durch Texturen kaschiert werden. Unterschiedliche Texturen werden hart
abgeschnitten, was stark auffällt.


Habe ich etwas vergessen?
Was habe ich übersehen?
Gibt es sonst noch etwas zu beachten?
Bzw. gibt es noch weitere vor und Nachteile und was ist letzten endes besser?



Beispiele aus der Praxis:

Reguläres Gitternetz:

Microsoft Flight Simulator 2004.
Die Regelmäßigkeit des Gitternetztes ist gut erkennbar, solange der Detailgrad
niedrig ist, dafür können die Texturen dieses wiederum gut kaschieren und die
Übergänge fließend aussehen lassen. Dies ist z.b. gut unten Links zu erkennen,
die kleinen Mini Bergkuppen sind auf einer Linie, auch wenn die Höhe
Unterschiedlich sein mag, so ist die Regelmäßigkeit der Gitterlinien erkennbar.
Auch sieht man das rechts an dem Berg neben dem Flugzeug deutlich, der
Abhang verläuft nicht geradlinig schräg, es sind die Schachbrettmusterartigen
Kerben im Abhang erkennbar, die von der Regelmäßigkeit des
Gitternetztes herrühren.
Desweiteren wird für glatte Ebenen Rechenpower verschwendet:
http://www.flightsimworld.com/gallery/albums/userpics/k2_north_b.JPG



Unregelmäßiges Gitternetz:

FlightGear.
Das unregelmäßige Gitternetz läßt keine Regelmäßigkeit erkennen,
das Gitternetz sieht natürlich aus. Aber, die Texturen bilden harte Übergänge
an den Kanten, so daß diese gut sichtbar werden, weiche Texturübergänge sind nicht realsierbar. (oder etwa doch? mit Shadern on the fly?) Das Detail des Gitternetz kann bei Ebenen
niedriger sein, Rechenzeit wird dadruch nicht verschwendet.
http://www.flightgear.org/Gallery-v0.9.10/Source/longs-peak.jpg

rotalever
2007-12-07, 12:31:11
Wenn man mit einem Mesh (unregelmäßiges Gitternetz) die selben Terrains erstellt wie mit einer normalen Heightmap (regelmäßig) dann würde ich mal sagen, dass die Heightmap besser zu speichern ist und schneller zu rendern ist.
Ein entscheidender Vorteil von einem Mesh ist, dass Überhänge realisiert werden können! Dafür wird alles was Du machst sehr sehr viel schwieriger. Algorithmen auf einer Heightmap kann man oft 2dimensional abbilden, wonach vieles einfach/schneller geht. Deshalb bin ich eigentlich der Meinung, dass man eine Heightmap nehmen sollte und Überhäng, Höhlen etc. durch zusätzliche Meshes realisiert, da diese Teile in vielen Fällen nicht den Hauptinhalt einer Welt darstellen.

Warum meine ich das eine Heightmap schneller ist? Heutige Grafikkarten können sehr effizient große Anzahl Polygone rendern. Eine Heightmap kann man wunderbar in Vertexbuffern auf der Grafikkarte speichern. Sogar ein LOD kann hier sehr effizient implementiert werden (-> Geoclipmaps, Hoppe et al.). Früher war dies nicht so, da hat man oft irgendwelche Meshes generiert, um die Grafikkarte zu entlasten. Der Nachteil ist, dass dies die CPU übernimmt und durch LOD die Meshes ständig neu gebildet werden müssen. Zudem müssen diese dann immer wieder über den Bus zur Graka geschoben werden. Zumindest bei AGP ist das eindeutig zu langsam.

malte.c
2007-12-08, 00:48:01
regelmäßiges Gitternetz:
- sollte eine Weltkugel realisiert werden, dann kann das Gitternetz nur auf
einem zylindrischen Körper abgebildet werden, da sich das Gitternetz in
Richtung der Pole nämlich verengen müßte, was die Vorteile die man für die
Texturen hat zunichte gemacht


Auch dazu gibt's Lösungen, z.B. "Terrain Rendering using Spherical Clipmaps" http://www.zib.de/clasen/download/SphericalClipmaps_Electronic.pdf

Gast
2007-12-08, 01:33:05
Wenn man mit einem Mesh (unregelmäßiges Gitternetz) die selben Terrains erstellt wie mit einer normalen Heightmap (regelmäßig) dann würde ich mal sagen, dass die Heightmap besser zu speichern ist und schneller zu rendern ist.


Warum?
Warum ist das so?

Eine Grafikkarte hat bei der Heighmap mehr Vertexs zu rendern als
bei einem Mesh, wenn z.b. viele der Vertexs in einer Ebene liegen (z.b. Eisfläche) und damit unnötig werden.

Das ist genauso als würde man eine 3d Figur mit 60000 Vertexs mit einer mit 2000 Vertexs vergleichen, erstere ist größer, braucht mehr Resourcen und ist langsammer zu rendern.


EDIT: Sorry, habe weiter unten noch nicht zu Ende gelesen.



Ein entscheidender Vorteil von einem Mesh ist, dass Überhänge realisiert werden können!

Du meinst also z.b. Überhängende Felsen an einem Abgrund?


Dafür wird alles was Du machst sehr sehr viel schwieriger. Algorithmen auf einer Heightmap kann man oft 2dimensional abbilden, wonach vieles einfach/schneller geht. Deshalb bin ich eigentlich der Meinung, dass man eine Heightmap nehmen sollte und Überhäng, Höhlen etc. durch zusätzliche Meshes realisiert, da diese Teile in vielen Fällen nicht den Hauptinhalt einer Welt darstellen.

Ok, nur wie baut man Höhlen in eine Highmap ein?

Nehmen wir mal als Beispiel eine Ebene Fläche die mit grünem Gras durchgehend texturiert ist.
Und jetzt soll ein Loch in diese Ebene gegraben werden,
das an einer anderen Stelle wieder herauskommt?
Wie realisiert man das technisch?
Spätestens am Locheingang würde man doch das grüne Gras sehen das den Zugang zum Loch versperrt.


Dann noch eine Frage, sind Heighmaps nicht = Nurbs?




Warum meine ich das eine Heightmap schneller ist? Heutige Grafikkarten können sehr effizient große Anzahl Polygone rendern. Eine Heightmap kann man wunderbar in Vertexbuffern auf der Grafikkarte speichern. Sogar ein LOD kann hier sehr effizient implementiert werden (-> Geoclipmaps, Hoppe et al.). Früher war dies nicht so, da hat man oft irgendwelche Meshes generiert, um die Grafikkarte zu entlasten. Der Nachteil ist, dass dies die CPU übernimmt und durch LOD die Meshes ständig neu gebildet werden müssen. Zudem müssen diese dann immer wieder über den Bus zur Graka geschoben werden. Zumindest bei AGP ist das eindeutig zu langsam.

Ach so, danke.
Das wollte ich wissen.

Aber wie sieht es bei modernen Grafikkarten mit Unified Shadern aus, bei der man das LOD auf der Grafikkarte bilden kann?

Gast
2007-12-08, 01:42:26
Auch dazu gibt's Lösungen, z.B. "Terrain Rendering using Spherical Clipmaps" http://www.zib.de/clasen/download/SphericalClipmaps_Electronic.pdf

Danke für den Link.

Aber jetzt habe ich doch noch eine Frage.
Die Erde ist nicht 100% kugelförmig, sondern gleicht mehr einem Ei,
wäre mit obiger Technik auch ein Ei realisierbar?

Coda
2007-12-08, 02:10:43
Brauchst doch nur entsprechend skalieren. Wobei diese Abweichung so minimal ist, dass sie eh nicht sichtbar ist.

Oder wo siehst du hier ein Ei? http://upload.wikimedia.org/wikipedia/commons/thumb/9/97/The_Earth_seen_from_Apollo_17.jpg/599px-The_Earth_seen_from_Apollo_17.jpg

Gast
2007-12-08, 04:25:17
Brauchst doch nur entsprechend skalieren. Wobei diese Abweichung so minimal ist, dass sie eh nicht sichtbar ist.

Für einen Flugsimulator ist sie entscheident.

Da hat man dann bei einigen Stunden Flug schnell mal ein paar hundert Meilen Abweichung zusammen.

Auch merkt man das dann bei den Fluginstrumenten,
wenn die Werte die man erhält nicht mehr zum dargestellten Ort passen.

Gast
2007-12-08, 04:25:55
PS:
Für ein Weltraumaction spiel wäre es natürlich egal, da gebe ich dir Recht.

KhanRKerensky
2007-12-08, 11:44:56
Nehmen wir mal als Beispiel eine Ebene Fläche die mit grünem Gras durchgehend texturiert ist.
Und jetzt soll ein Loch in diese Ebene gegraben werden,
das an einer anderen Stelle wieder herauskommt?
Wie realisiert man das technisch?
Spätestens am Locheingang würde man doch das grüne Gras sehen das den Zugang zum Loch versperrt.

Guild Wars benutzt für die Landschaft Heightmaps und es gibt an manchen Stellen solche Löcher. Und zwar erstellen die in der Heightmap zuerst eine quadratische Vertiefung, die mindestens so groß ist wie das eigentliche Loch. In diese Vertiefung wird dann ein zusätzliches Model eingepasst, das dann eben dieses Loch darstellt.
Ähnlich werden auch Höhlen erstellt. Zuerst wird eine große Spalte in den Berg gegraben und dort kommt dann per Model ein Deckel drauf.

Beides ist allerdings nicht wirklich schön.

Coda
2007-12-08, 13:27:14
Für einen Flugsimulator ist sie entscheident.

Da hat man dann bei einigen Stunden Flug schnell mal ein paar hundert Meilen Abweichung zusammen.

Auch merkt man das dann bei den Fluginstrumenten,
wenn die Werte die man erhält nicht mehr zum dargestellten Ort passen.
Da würde ich dann vorher anfangen eher die Koordinaten entsprechend anzupassen als die Optik zu verändern. Gut pfuschen ist die Devise...

Gast
2007-12-08, 14:11:52
Da würde ich dann vorher anfangen eher die Koordinaten entsprechend anzupassen als die Optik zu verändern. Gut pfuschen ist die Devise...

Ja, bei einem Spiel, aber nicht bei einem Simulator der diesen Begriff auch verdient!

rotalever
2007-12-08, 14:51:25
Guild Wars benutzt für die Landschaft Heightmaps und es gibt an manchen Stellen solche Löcher. Und zwar erstellen die in der Heightmap zuerst eine quadratische Vertiefung, die mindestens so groß ist wie das eigentliche Loch. In diese Vertiefung wird dann ein zusätzliches Model eingepasst, das dann eben dieses Loch darstellt.
Ähnlich werden auch Höhlen erstellt. Zuerst wird eine große Spalte in den Berg gegraben und dort kommt dann per Model ein Deckel drauf.

Beides ist allerdings nicht wirklich schön.
Das ist eine Möglichkeit. Man kann aber auch zusätzlich zur Höheninformation einen True/False Wert speichern, bzw. diesen irgendwie in der Höhe kodieren, sodass man wirklich Löcher in der Heightmap erstellen kann. Diese können dann durch entsprechende Meshes aufgefüllt werden. Für Überhänge bräuchte man das ja noch nicht mal. Das gute daran ist halt, dass die Heightmap eigentlich mit nahezu den gleichen Algorithmen gerendert werden kann, und die Meshes eben irgendein Standard-LOD bekommen.

Coda
2007-12-08, 15:08:44
Ja, bei einem Spiel, aber nicht bei einem Simulator der diesen Begriff auch verdient!
Natürlich auch bei einem Simulator. Du siehst den Unterschied eh nicht. Nie im Leben. Und wenn die Koordinaten stimmen passt doch alles.

Außerdem ist diese Abweichung wahrscheinlich eh schon in den Höhendaten eingerechnet, anders könnte man diese doch gar nicht erheben.

Gast
2007-12-08, 15:50:16
Das ist eine Möglichkeit. Man kann aber auch zusätzlich zur Höheninformation einen True/False Wert speichern, bzw. diesen irgendwie in der Höhe kodieren, sodass man wirklich Löcher in der Heightmap erstellen kann. Diese können dann durch entsprechende Meshes aufgefüllt werden. Für Überhänge bräuchte man das ja noch nicht mal. Das gute daran ist halt, dass die Heightmap eigentlich mit nahezu den gleichen Algorithmen gerendert werden kann, und die Meshes eben irgendein Standard-LOD bekommen.

Und wie realisiert man einen Tunnel?

z.B. durch einen Berg oder unter den Ärmelkanal ohne dabei die Highmap in ein Loch zu versenken und mit einem Mesh zuzudecken?

Z.b. kann es ja sein, daß man die Highmap behalten will, da das ganze automatisiert werden soll und daher komplexe von Hand erstelle Meshs
nicht geeignet sind.

Gast
2007-12-08, 15:53:33
Natürlich auch bei einem Simulator. Du siehst den Unterschied eh nicht. Nie im Leben. Und wenn die Koordinaten stimmen passt doch alles.
Ich schaue auf die Uhr, dann weiß ich das die gemessene Entfernung falsch ist.
Ich schaue auf die Treibstoffanzeige, dann weiß ich, daß das Flugzeug bei Tempo X für diese Zeit zu wenig bzw. zu viel Sprit verbraucht hat usw.



Außerdem ist diese Abweichung wahrscheinlich eh schon in den Höhendaten eingerechnet, anders könnte man diese doch gar nicht erheben.

Wie meinen?
Die Höhendaten entnimmt man in der Regel der STRM und da gibt es keine derartugen Abweichungen, da so etwas für wissenschaftliche Zwecke unerwünscht ist.
http://de.wikipedia.org/wiki/STRM

malte.c
2007-12-08, 22:51:35
Aber jetzt habe ich doch noch eine Frage.
Die Erde ist nicht 100% kugelförmig, sondern gleicht mehr einem Ei,
wäre mit obiger Technik auch ein Ei realisierbar?

Ich würde eine zweite Heightmap nehmen, die die Differenz zwischen der Kugel und dem von Dir verwendeten Geoid enthält. Die kannst Du vermutlich sogar problemlos zur Laufzeit ausrechnen und damit Heightmaps für verschiedene Geoide verwenden. Dann addierst Du die Differenz-Heightmap zu Deinen Daten und verwendest das Ergebnis für die Kugel-basierte Visualisierung.

Zur Datenverwaltung zur Laufzeit: "Clipmap-based Terrain Data Synthesis" http://www.zib.de/clasen/download/ClipmapSynthesis.pdf

malte.c
2007-12-08, 22:53:43
Und wie realisiert man einen Tunnel?
z.B. durch einen Berg oder unter den Ärmelkanal ohne dabei die Highmap in ein Loch zu versenken und mit einem Mesh zuzudecken?

An den Tunnelenden würde ich eine transparente Oberflächentextur für die Heightmap verwenden, die dann via Alphatest nicht gerendert wird. Dann kannst Du jede beliebige Form ausstanzen und mit einem Mesh hinterlegen.

rotalever
2007-12-08, 23:08:14
An den Tunnelenden würde ich eine transparente Oberflächentextur für die Heightmap verwenden, die dann via Alphatest nicht gerendert wird. Dann kannst Du jede beliebige Form ausstanzen und mit einem Mesh hinterlegen.
Hmm.. Transparente Oberflächen zuzulassen macht aber manches schwieriger. Je nach LOD-Technik können dann manche Occlusion Techniken nicht mehr angewendet werden. Zudem verbraucht Transparenzinformation zusätzliche Informationen in den Texturdaten. Zumindest im RAM könnte man diese aber komprimieren. Ich glaube es funktioniert besser, wenn man zum Beispiel sagt
-inf = Loch im Boden
und dann einfach an die Stelle ein Mesh einfügt. Das muss natürlich nicht von Hand erzeugt sein. Sowas kann man auch automatisch generieren. Soweit ich mal mitbekommen hatte, nutzt doch Crysis ähnliches? Überhänge werden über Voxels mit dem Editor erzeugt (genauso könnte dies ein automatischer Vorgang machen) und der Map-Compiler erstellt dann für die nötigen Stellen ein angepasstes Mesh.

Gast
2007-12-09, 14:47:11
Mir ist noch gar nicht aufgefallen, daß es in Crysis Überhänge gibt, das muß ich mir im Spiel mal anschauen.

rotalever
2007-12-09, 21:32:30
Mir ist noch gar nicht aufgefallen, daß es in Crysis Überhänge gibt, das muß ich mir im Spiel mal anschauen.
Also ich kenne das Spiel nicht, aber ich hab solche Videos von dem Editor gesehen, da hat man das gesehen, wie der mit der Maus Überhänge und so graben konnte und da wurde irgendwas von Voxeln gelabert.

Gast
2007-12-11, 17:32:55
Wie macht man eigentlich bei einem unregelmäßigen Gitternetz (Mesh)
die Übergänge bei Texturen so, daß die Kanten an den Übergängen nicht auffallen?


Ein Beispiel wäre hier z.B. X-Plane, dieser Flugsimulator verwendet
genau wie FlightGear auch ein unregelmäßiges Mesh, aber die Übergänge an den Texturen
sind mit bloßen Auge nicht erkennbar.
Harte Kanten gibt es auch nicht.

Wie geht das?




Hier ein Beispielscreenshot:
Harte Texturübergänge sind überhaupt nicht erkennbar.
http://www.x-plane.com/pictures/v9pix/v9-8.jpg

http://www.global-scenery.org/germany/pictures/Schwarzwald_Schluchsee.jpg

http://www.global-scenery.org/germany/pictures/Berlin_04.png


Falls man auf den Screenshot nicht genug erkennt um darüber eine genaue
Aussage zu treffen, wie das gemacht wird, gibt es auch eine 10 Minuten Demo
der neuen Version 9.0 Beta:
http://www.x-plane.com/beta.html

Gast
2007-12-11, 17:34:09
Auch hier sehen die Übergänge fließend ohne störende Kanten aus:

http://www.global-scenery.org/italy1/pictures/Monviso_1.jpg

rotalever
2007-12-11, 20:30:09
Du musst einfach die Texturkoordinaten korrekt berechnen. Viel mehr kann man da wohl nicht sagen. Du kannst schließlich für jedes Dreieck die Koordinaten richtig bestimmen.

Gast
2007-12-11, 20:43:14
Du musst einfach die Texturkoordinaten korrekt berechnen. Viel mehr kann man da wohl nicht sagen. Du kannst schließlich für jedes Dreieck die Koordinaten richtig bestimmen.

Ich dachte man kann nur eine Textur (Multitexturing ausgenommen) an eine Dreiecksebene binden.

Würde so etwa also gehen, oder wie meinst du das mit Texturkoordinaten korrekt berechnen?

http://img48.imageshack.us/img48/443/dreieckkf4.png


Wenn das gehen sollte, dann ist es natürlich kein Problem, viereckige Texturen
mit unterschiedlichem Motiv korrekt aneinanderzulegen obwohl die Dreiecke eine völlig andere Form haben.

rotalever
2007-12-12, 17:08:29
Ich dachte man kann nur eine Textur (Multitexturing ausgenommen) an eine Dreiecksebene binden.

Würde so etwa also gehen, oder wie meinst du das mit Texturkoordinaten korrekt berechnen?

http://img48.imageshack.us/img48/443/dreieckkf4.png


Wenn das gehen sollte, dann ist es natürlich kein Problem, viereckige Texturen
mit unterschiedlichem Motiv korrekt aneinanderzulegen obwohl die Dreiecke eine völlig andere Form haben.
Ich denke in solchen Fällen, wo eine Landschaft abgebildet wird, benutzt man ja gar nicht viele Texturen, sondern eine Einzelne. Wenn man natürlich durch ein Textur-LOD gezwungen ist, nicht immer alles im Speicher zu halten, dann könnte es in Randbereichen Probleme geben. Mit ein paar Fragmentshadern sollte das aber leicht zu bewerkstelligen sein.

Gast
2007-12-12, 17:33:51
Ich denke in solchen Fällen, wo eine Landschaft abgebildet wird, benutzt man ja gar nicht viele Texturen, sondern eine Einzelne.

Also in den oben genannten Beispielprogrammen ist es essentiell wichtig
verschiedene generische Texturen für bestimmte Landschaftstypen zu verwenden.

Da man hier kaum die ganze Erde auf einer Textur in diesem Detailgrad abbilden kann, ganz davon abgesehen das das mehrere Terrabyte an Daten dann währen.


Also meine Frage bezieht sich also schon auf solche Generische Texturen, bei der man nicht einfach nur eine einzige Textur benutzen kann, sondern
diese vielen Texturen geschickt aneinanderlegen muß, ohne das es auffällt.