Zur Zeit experimentiere ich ein wenig mit Landschaften, insbesondere wie man diese mit wenig Daten qualitativ mehr oder weniger hochwertig darstellen kann. OpenGL bietet als Hilfsmittel Evaluatoren an, diese haben aber den Nachteil, dass sie relativ umständlich zu bedienen sind.
Hier nun eine Demonstration, wie man ein Heightfield mit wenigen Daten über Interpolation fein auflösen kann und gleichzeitig über dynamisches LOD große Sichtweiten ermöglicht.

Als Vorlage diente Sacrifice, dessen riesige Level und große Sichtweiten mich ziemlich beeindruckten, als ich es das erste mal anspielte.

Der erste Start des Programms dauert etwas länger, da erst mal eine 3D Noise Textur erstellt wird (ansonsten wäre der Download ziemlich groß), über Tastenkürzel kann man in den Wireframe Modus schalten (dort sieht man das LOD gut) und zwischen verschiedenen Detailstufen, Sichtweiten und Interpolationsalgorithmen umschalten.
Feedback wie schnell das Ganze auf verschiedenen Rechnern läuft, wäre sehr erwünscht (zur Zeit sollte der Algorithmus eher CPU lastig sein, eine Auslagerung in einen Vertex Shader wäre möglich - wenn ich mich allerdings an Saschas Pflanzendemo vor einiger Zeit erinnere, habe ich den Verdacht, dass das Programm dann nicht unbedingt schneller wird).

Hier ein Screenshot:


Und hier kann das Ganze runtergeladen werden (ca. 400kb)
http://basegraph.com/bg/demos/HeightMap.zip

Bei Interesse kann ich auch den Source veröffentlichen, da dieser allerdings ziemlich auf BaseGraph Objekten (und der zugehörigen Mathematik Bibliothek) aufbaut, weiß ich nicht inwiefern der von allgemeinem Nutzen ist.[/url]

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

Ehrlichgesagt gefällt mir es nicht so gut, man sieht sehr Stark den übergang zwischen den LOD Stufen. Aber was mich Interessieren würde wäre die Anzahl der Polygone die man sieht!

Ein Fehler ist mir gleich aufgefallen: Bei weniger FPS bin ich sehr viel schneller unterwegs!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Ich habe das ganze selbst unterbrochen, es ist viel zu langsam. (50 of 256 in etwa 1 min oder so)
amd 1700xp+ - 1466 mhz
256 ddrram
64 mb radeon 7500
winxp sp2

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Die Landschaft sieht irgendwie arg verschimmelt aus und bei mir läuft's trotz GF6800 GT nur mit 50 bzw 30 fps.

Auf höchsten Details (Taste 4) hab ich ca. 5 FPS.
Bei niedersten (Taste 1) habe ich konstante 30 FPS.
(jeweils weiteste Sichtweite)

Mein System: AMD Ahtlon 64, 3000+ | 512 MB DDR-RAM PC400 | Geforce 4 Ti 4200, 64 MB


Das Generieren hat auch ziemlich lange gedauert. Also das macht den Ladezeiten Konkurrenz, welche ich damals mit meinem 400 MHz Rechner mit 64 MB Ram und Gothic I und Gothic II hatte. (Da hat das Laden eines Spielstandes ca. 3 - 5 Minuten gedauert.)

Ansonsten wirkt die Karte etwas unrealistisch, da keine Welt so hügelig und uneben ist. Zumindest keine Grasslandschaft. Wenn man die höchten Details einstellt, sieht das alles doch recht uneben und umgegraben aus. So sieht normalerweise keine normale Natur aus. Aber groß ist es schon, dass kann man ruhig sagen. Du solltest eine Speed-Taste zum Testen einbauen, dass man mal dreifach so schnell über die Landschaft fegen kann, um das volle Ausmaß besser sehen zu können. So dauert das Durchqueren des Gebiets recht lange.

Hier auch so was ähnliches:
http://www.humus.ca/index.php?page=3D&ID=23

Da mich das Thema selbst mal stark interessiert hat und auch zur Zeit noch interessieren würde wenn ich die Zeit dafür hätte, muss ich wohl wieder mal ne etwas längere Antwort schreiben :-).

Also auf meiner GForce 2 funktionieren die Texturen irgendwie nicht, und obwohl es keine Texturen hat, ruckelt es beim niedrigsten Detailgrad mit ~25 FPS herum :-).

Deshalb auch gleich mal eine Frage zu den Texturen. Du erwähnst 3D-Texturen die ja auch entsprechend lang berechnet werden, aber irgendwie stellt sich mir da die Frage wozu überhaupt? Ich mein eine Heighmap ist ja ein 2D-Array mit Höhenwerten, Farbwerten und was auch immer, aber vor allem Texturmäßig wüsst ich nicht was ich da mit 3D mache.

Zu den FPS möcht ich noch gleich anmerken, dass es bei dir so aussieht als ob du 1 Höhenpunkt / Dezimeter^2 hättest. In Spielen ist meistens so 1 Höhenpunkt / Meter^2 üblich, bezogen auf die "normale" Gehhöhe, wenn du einen Flugsimulator machen möchtest verhält es sich aber proportional gesehen ähnlich. D.h. nur jeden 100ertsten Höhenpunkt zeichnen, bzw. ums 10 fache skalieren und du bist ungefähr beim heutigen Standard und hast genug FPS ... vielleicht mittlerweile ein wenig mehr, wie gesagt ich mach noch mit meiner GF2 rum. Aber dass du Vertexgebunden bist sieht man allein dadurch, dass die FPS so gut wie gar nicht rauf gehen wenn du das Ganze in Wireframe zeichnest, wobei bei mir wie gesagt das Ganze ohne Texturen dar gestellt wird, wo das auch nicht weiter verwunderlich ist. Wenn du wirklich 3D Texturen verwendest, dann wäre das eventuell auch noch ein großer Schwachpunkt. Ich für meinen Teil hab bisher nur schlechte Erfahrungen mit 3D Texturen gemacht, und da diese für Spiele üblicherweise nicht allzu relevant sind, wird sich diesbezüglich auch nicht allzu viel geändert haben nehm ich an, kann mich diesbezüglich aber auch irren.

Zur Generierung fiel mir auf, dass das Ganze durch die Beleuchtung sehr Rastermäßig aussieht. Ich nehm an das liegt an deinen Interpolationsverfahren. Bei Cos-Interpolation hast du ja bei jedem gegebenen Punkt eine Tangente mit der Steigung 0 bzw. eine Normale gerade nach oben. D.h. bei diffusen Licht sind alle gegebenen Punkte gleich hell. Bei Cubischer Interpolation weiß ich nicht genau wie du das machst, aber anscheinend sind auch hier die Ergebnisse nicht gerade optimal. Bei Cos-Interpolation dürfte das Problem bestehen bleiben auch wenn du den Detailgrad nach unten schraubst, bei der Cubischen Interpolation könnte sich das dadurch etwas legen, da es nicht mehr so auf fällt.
Meiner Meinung nach sollte jedoch bei einer ungefähr gleichbleibenden Steigung der gegebenen Punkte selbst die Interpolation eine ungefähr gleichbleibende Steigung liefern, was aber selbst bei deiner Cubischen Interpolation anscheinend nicht gewährleistet ist. Mein Ratschlag diesbezüglich: irgendwelche Interpolationsverfahren verwenden die auch die Normalen mit einbeziehen, also entweder Splines die ja die Normalen indirekt verwenden oder den direkteren Weg über Hermite Curves bzw. Surfaces gehen. Wenn du bei einer gleichbleibenden Steigung der gegebenen Punkte irgendwelche unregelmäßigkeiten haben möchtest, dann solltest du dies über eine zusätzliche Noise-Funktion (zB Perlin Noise) lösen.

Aber nun würden mich noch ein paar Dinge von deiner Landschaft interessieren:

In wie weit ist diese Landschaft von einem Grafiker beeinflussbar?
Also ist die Landschaft komplett generiert? Gibst du alle X Meter einen Höhenpunkt vor und generierst die dazwischen liegende Landschaft? Hat man auf die Art und Weise wie sie generiert wird irgend einen Einfluss? Oder hat man vielleicht sogar unterschiedliche Generierungsalgorithmen zur Auswahl als Grafiker, oder kann sich bestimmte Bereiche sogar über eine genaue Highmap erstellen? Und obwohl ich die Texturen nicht sehen kann würde mich auch die Art und Weise Interessieren wie du die Texturen generierst und in wie weit man darauf Einfluss hat.

Wie groß ist diese Landschaft? Oder besser gesagt wieviele Byte brauchst du durchschnittlich für einen Höhenpunkt bzw. für einen Quadratmeter obwohl dies natürlich erst halbwegs Objektiv ist wenn du Vergleichsobjekte in der Landschaft hast. Also sagen wir mal nach meiner obigen Schätzung, wie viel Byte brauchst du für 100 Höhenpunkte. Nebenbei bemerkt fällt mir gerade auf, dass wenn du nur die tatsächlichen Höhenpunkte verwenden würdest und nicht dazwischen interpolierst (meiner Zählung nach ein 16x16 Feld) dann hättest du in etwa eine typische Landschaft für ein Spiel ... vielleicht ein ganz klein wenig zu grob aufgelöst, aber nicht viel. Und nebenbei bemerkt wird bei mir auch wirklich jeder Höhenpunkt aus verschiedensten Paramteren generiert (zB Perlin Noise) und nie interpoliert, aber das kannst du (vor allem bei einer derart detailierten Landschaft) natürlich auch anders handhaben.

Falls du das schon getestet hast, oder wissen solltest:
Wie groß kann deine Landschaft maximal werden?
Ich für meinen Teil hatte (oder habe, habs noch nicht soo genau getestet) das Problem dass nach ein paar 1000 Höhenpunkten Seitenlänge plötzlich das Perlin Noise schlapp machte, und weil dein Titel ja "Unendliche Weiten" heißt, kommt (um ganz fies zu sein :-) ) noch hinzu, dass die float Genauigkeit bei großen Zahlen ja auch nicht mehr unbedingt toll ist (was sich natürlich erst dann wirklich auswirkt wenn du Objekte auf der Landschaft hast). Wobei das mit der float-Genauigkeit hab ich noch so gut wie gar nicht getestet bei mir.

And last but not least: Was zum Teufel machst du mit 3D Texturen? :-)


Aber da Verbesserungsvorschläge und Fragen häufig ein bissl als negative Kritik wirken, möchte ich zum Schluss noch sagen, dass es schon ganz gut aussieht. In ein Spiel würd ich die Landschaft für meinen Teil zwar in dieser Form noch nicht einbauen, aber du hast schon einigen "profesionellen" Engines, also Engines für die man Geld hin blättert insofern schon was voraus, als das du dir überhaupt Gedanken darüber gemacht hast, wie man den Benutzer ein paar 100 MB Download ersparen könnte, und auch schon Ergebnisse geliefert hast die ich mit ein paar Modifizierungen als ganz gut Brauchbar einstufen würde. Aber aus eigener Erfahrung muss ich leider sagen (ich nehme an das weißt du ohnehin selbst auch) die Landschaft ist nur ein kleiner Teil des Ganzen, es sei denn du legst es wirklich nur auf die Landschaft an und möchtest damit keine Applikation (Spiel?) entwickeln.

Die Landschaftsgröße ist schon beeindruckend. Leider sieht man, dass diese künstlich erzeugt wurde, da diese Landschaft zu weiche Formen hat. Eventuell sollten harte Kanten in die Landschaft eingefügt werden, damit ein natürlichere Darstellung ensteht.

Mein System ist:
- Intel P IV 2.4GhZ
- 786MB Ram
- ATI 9800pro 256MB
- Catalysttreiber 6.14.10.6542
- Windows XP SP2

Die Erstellung der Textur hat ca. 11:45 gedauert. Die Geschwindigkeit liegt bei 1 zwischen 25 und 60 FP, je nach aktueller Sichtweite. Diese variiert ob man vor einem Berg oder vor einer weiten Landschaft steht. Bei 4 habe ich ca. 3-4 FPS.

Gruß
Thomas

_________________
http://www.seban.de

Hi ho,
Als erstes hab ich mal für die die nicht so lange auf das generieren warten wollen die 4 files gepackt auf mein server abgelegt, ich werde ihn einige zei drauf lassen. http://e-e.neroneus.de/Heightmap.rar 28,1MB groß

Mein System:
AMD 3000
512MB Ram
Radeon 9800
333MHz FSB

Werte:
LOD 1)
A)27FPS
B)18FPS

2)
A)18FPS
B)11FPS

3)
A)7FPS
B)5FPS

4)
A)3FPS
B)2FPS

Kritik:
Welchen Sinn bezweckst du damit ? Denn für Spiele ist das meines erachtens nicht lohnenswert.
Es ist Zu langsam, zu hochpolygoniert, ermöglicht keine sehr gute optimierung und ich weiss nicht inwiefern du scharfe klippen oder hölen machen kannst ?
Polygonanzahl und geschwindigkeit kann man ja bestimmt noch fixen aber hält es mit alternativen stand.

Ich hatte mal ein terrain mit quadtree und VBO gebaut, die Daten waren ledeglich 4Byte pro höhenwert also bestand z.B. eine 100x100 Höhenpunktemap aus 10KB. Über ein kleinen einzeiler Algo hab ich erstmal alle Felder, die nicht um dem spieler mit dem Abstand von Viewsize lagen, ausgesondert und mit den Frustumculling hab ich die restlichen dan bearbeitet. So hab ich egal welche Sektoranzahl bestand die gleiche zeit gebraucht um zu bestimmen welche felder sichtbar waren, da ja nur alle sektoren in die auswahl kamen die < als der Viewsize abstand waren und nicht jeder Sektor geprüft werden muss ob er drin liegt.
Die Performance war dementsprechen riesig bei einer Detailgrad der ausreichend war.

Ich hab demnächst vor ein streamfähiges Mapformat zu machen um ladezeiten zu ersparen, dabei werden die daten in Sektoren unterteilt(über ein Octree) und als VBO abgelegt. In der realittät ist normalerweise die Landschaft eben und weist wenige huckel auf, wodurch man auf weniger Polys ausweichen kann. Das Mesh ist auch nicht als Gitter angeordnet sondern an die Form des Segments angepasst so kann man viele polygone an unnötigen Stellen einsparen und an anderen wo sie benötigt werden verwenden z.B. Höleneingang, Klippen, Felsspalten oder Felsauftürmungen. In wie weit sich dann noch Occlusion auswirkt ist noch auszutesten, da es ja erst ab GF3 unterstützt wird und somit eine untergrenze darstellen würde. Hier würde dann auch die möglichkeit bestehen ein PVS zu nutzen als alternative. Da muss man dann abschätzen ob Größe der mapdaten oder geschwindigkeit vor geht.

Ähnlich geht Painkiller auch vor, es wird alles in der nähe befindliche geladen und zu laufzeit kommt neues dazu, so haben die diese irre kurzen ladezeiten geschaft. Ich hab selten den Ladebalken länger als ca. 5 Sekunden gesehen.

MfG TAK2k4

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Geht bei mir gar nicht zu starten. Kommen 2 Fehler mit Zugriffsverletzungen direkt hintereinander.

System:
Acer TravelMate 233XV
2GHz
256 MB RAM
Intel OnBoard Grafik

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

@Flash: Ich sag blos Onboard-Grafik

@Landschaft: Also ich finds insgesamt nicht schlecht, und einen Schritt in die richtige Richtung. Natürlich hats noch Ecken und Kanten (am wahrsten Sinne des Wortes), aber ein bisschen Feintuning hier und da kann da glaub ich schon was reissen. So könnte man die Auflösung der Heightmapdaten ja insgesamt um ein paar Stufen senken, das Ganze ist einfach zu detailliert. Werden eigentlich auch Culling oder andere Techniken betrieben, um Rechenzeit zu sparen?

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

System:
AMD Athlon 1,3 GHz
768 MB RAM
GeForce 2 Ti 64 MB

Meine Werte:
LOD 1:
A: 38
B: 25

LOD 2:
A: 20
B: 12

LOD 3:
A: 8
B: 6

LOD 4:
A: 3-4
B: 2-3

Eine Textur bekomme ich allerdings auch nicht zu sehen.

Also erstmal Danke für die vielen Antworten.

Bezüglich der Qualität der Grafik möchte ich gleich anmerken, dass die Ästhetik erst mal hinten an gestellt wurde - es geht wirklich nur um die Technik, nicht aber um die tatsächlich dargestellte Landschaft. Dieseist ein Heightmap, das übrigens auch über Perlin Noise erstellt wurde - anstelle der Heightmap könnte genausogut die Funktion direkt die Daten liefern (die Klasse ist bereits diesbezüglich ausgelegt) und es würde geschwindigkeitsmäßig wenig Unterschied machen.
Bei den FpS bekomme ich auch etwas wirre Werte, das Ganze wird im Idle Ereignis gerendert - aber auf meinem Laptop macht es überhaupt keinen Unterschied, ob er im langsamen Energiesparmodus ist oder mit voller Geschwindigkeit läuft - ich bekomme immer um die 30 bis 50 FpS (Geforce 6800) - auf einem an sich langsameren Rechner im Büro läuft es sogar schneller (ATI 9200, 2,4 Ghz), bin mir jetzt auch nicht sicher woran das liegt. Jedenfalls wird alles auf der CPU berechnet und nur die resultierenden Dreiecke (Triangle Strips bzw. Fans) gerendert.

Die LOD Stufen sind tatsächlich unschön - zur Zeit wird die Auflösung eines Patches einfach nur pro Stufe halbiert - fließende Übergänge wären durchaus möglich, da die Interpolationsfunktionen ja kontinuierlich sind (die Übergänge zwischen Patches sind dann aber eine Seuche, weswegen ich das erstmal aufgeschoben habe - irgendwie muss man ja Dreiecke zusammenbekommen und kann nicht nur einfach irgendwelche Punkte rendern ).

An sich sollte die Demo ab OpenGL 1.2 Unterstützung laufen - 3D-Texturen mit einer Größe von 256x256x256 vorausgesetzt (die Geforce 2 bzw. 4 Mx Karten können meines Wissens nach keine 3D Texturen in Hardware und haben deswegen auch nur die Mindestauflösung von 64x64x64, die für die Mindestanforderungen von OpenGL 1.2 Voraussetzung ist).

Das Ganze ist natürlich auch deswegen langsam, weil die Auflösung wirklich sehr hoch ist - nachdem aber außer dem Heightfield nichts gerendert wird, wollte ich die benötigte Rechenleistung durchaus etwas nach oben schrauben. Selbstverständlich ist auch noch Optimierungspotential vorhanden.

Zu Lyrs Fragen:


Es ist eine exakte Heightmap, die aber über eine Noise Funktion generiert wurde (es könnten aber genausogut echte Höhendaten sein). Die Klasse könnte die Höhendaten aber auch von einer beliebigen Funktion übernehmen. Die Textur wird über mathematische Funktionen für die RGBA Werte berechnet - diese sind in der .3dsrc Datei zu finden, die man übrigens auch editieren kann (oder im 3D-Texturgenerator, den ich vor Kurztem vorgestellt habe, ganz selbst erstellen). Es werden also tatsächlich alle X Meter Höhenpunkte vorgegeben, die aber "irgendwoher" stammen können.


Ein Höhenpunkt braucht zur Zeit 4 Byte (ein float), die echten Schnittpunktdaten mit Normalen werden dann berechnet. Es ist aber wirklich egal - es könnten genausogut 1 oder 2 Byte sein oder irgendeine Funktion die Werte zurückliefert. Die Heightmap hat übrigens eine Auflösung von 256x256. Wenn die Y-Koordinate in die 3D-Textur variiert wird braucht man dementsprechend 2 Heightmaps - oder aber zwei Funktionen.


Prinzipiell beliebig groß - ein Quadtree wird sozusagen in Echtzeit berechnet, als über die Ausdehnung der gesamten "Landschaft" (die Ausdehnung und die Anzahl der "Höhenstufen" pro Ausdehnung werden angegeben) so lange Vierecke halbiert (also eigentlich geviertelt) werden, bis halt mal ein paar im Frustum liegen, und die werden dann gerendert. Das Ganze ist insofern praktisch als es sehr dynamisch ist - das ganze Zeugs könnte sich die ganze Zeit auch ohne großen Zeitverlust verändern, da nichts im Voraus berechnet wird.
Die float Genauigkeit würde aber tatsächlich irgendwann zum Problem - aber es gibt ja auch doubles


Bis jetzt habe ich für "weiche" Landschaften immer Bernstein Polynome verwendet - allerdings wollte ich diesmal Interpolationsverfahren verwenden, die ganz ohne Stützpunkte (für Tangenten) auskommen - diese kann man zwar auch aus den Höhendaten berechnen, ich wollte aber einen Algorithmus den man direkt mit Höhendaten "füttern" kann - wie man sieht, haben diese aber auch Nachteile.


An den 3D-Texturen solltet ihr euch nicht aufhängen - das war nur der einfachste Weg schnell die Landschaft einzufärbeln (egal wie die Polygone ausgerichtet sind - irgendwie passt es immer). Nachdem die Textur selbst aber nichts Aufwändiges ist (die Berechnungsformeln sind übrigens in der t3dsrc Datei als Text hinterlegt) hätte es eine normale 2D-Strukturtextur gemeinsam mit einer 1D-Farbextur für die Farben genauso getan - ich habe aber eigentlich ein anderes Programm im Hinterkopf, bei dem sowohl Landschaften als auch deren Texturen synthetisch erzeugt werden (dann passt der Titel auch eher ), dort sollten die 3D-Texturen dann mehr Sinn machen. Der Hintergrund ist, dass verschiedene Materialschichten sowohl farblich als auch strukturmäßig in einer Textur abgelegt werden können - die X- und Z- Texturkoordinaten kann man sich dann aus der aktuellen Position holen, die Y-Koordinate eventuell auch - oder aber aus einem weiteren Heightfield (oder einer weiteren Funktion) die dann für den "Landschaftstyp" zuständig ist. Ich probiere da aber selbst nur herum und kann jetzt auch nicht sagen, ob sich so wirklich tolle Ergebnisse erzielen lassen.


Zu Tak2004:

Sinn? Was ist das?
Im Ernst, das ist nur eine Spielewiese , mit der ich auch mit synthetisch generierter (oder zumindest platzierter) Vegetation und/oder Gebäuden virtuelle Landschaften erstellen möchte. Ein Spiel oder sonstige konkrete Absichten habe ich damit nicht vor (obwohl mich z.B. das erwähnte Sacrifice mit seiner dynamischen Landschaft ziemlich faszinierte, obwohl die Grafik an sich ziemlich abgedreht war).

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

Das geht nicht so gut, weil man das Mipmapping nicht in eine bestimmte Richtung ausschalten kann und die Landschaftstypen dann ineinander blenden auf Entfernung.

Das ist richtig - die Idee ist aber nicht so sehr, dass die 3D-Textur jetzt aus sehr vielen verschiedenen übereinandergelegten 2D-Texturen besteht (das wäre zwar sehr praktisch, weil man immer auf eine von fast beliebigen viele 2D Texturen umschalten könnte, aber nur eine Textureinheit verbrät) sondern eher aus übereinandergelegten "Schichten", die auch in der dritten Dimension ausgedehnt sind und auch in der 3D-Textur selbst einen Übergangsbereich haben. Diese Schichten können dann sowohl strukturell als auch farblich völlig voneinander abweichen (vom Übergangsbereich abgesehen)
Die im Demo verwendete 3D-Textur (die zugegebenermaßen wirklich nicht sehr beeindruckend aussieht) soll dies mit zwei solcher Schichten demonstrieren.
Ein zweites Heightfield (oder eine entsprechende Funktion - oder einfach eine "Störung" der Y-Koordinate) kann dann dafür sorgen, dass die Grenzen zwischen Schichten nicht wie mit dem Lineal gezogen aussehen.

Wem die Erstellung der 3D-Textur zu lange dauert - oder wenn sie zu groß für die OpenGL Implementation sein sollte - kann die snowgrass.t3dsrc einfach im Editor öffnen und die ersten drei Zeilen von 256 auf 64 setzen - dann wird eine entsprechend kleinere Textur generiert.

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