Danke, sieht interessant aus. Aber wenn ich jetzt auch noch eine Vogelschwarm-Simulation ins Spiel einbaue, dann wird die Framerate in den Keller sinken.
Diese Vögel sind ja nur zur "Verschönerung" da, sollten also die Framerate so wenig wie möglich belasten. Der Vogelflug wird daher nicht in Echtzeit berechnet werden. Und ich werde auch nur einzelne Vögel einbauen, und nicht ganze Schwärme.
Wahrscheinlich werde ich ein animiertes Model benutzen, das aus nur zwei Polygonen besteht, und das einen vorgegebenen Kurs "abfliegt". Und auf diesem flachen Model wird dann eine Textur-Animation abgespielt.
Als Vorlage für die "Flugroute" und für die Skin-Animation verwende ich Videos wie diese hier:
Youtube: Der große Flug der Schwalben
Youtube: Zeitlupenaufnahme einer Schwalbe im Flug



Gute Tipps. Sie gefallen mir. Vor allem deshalb, weil ich es eh fast genauso mache, wie Du es beschrieben hast.

Hier ein paar Infos dazu:

1.) DDS-Texturen:
Im fertigen Level wird es nur noch Models mit DDS-Texturen geben. Und in den wenigen Fällen, bei denen es auf die Bildqualität ankommt, verwende ich TGA-Texturen. In einigen wenigen Fällen werde ich im laufenden Spiel mit Pixelbefehlen auf die Textur malen müssen. Auch dafür verwende ich dann natürlich TGA- oder BMP-Texturen. Bei Verwendung von DDS-Texturen kann ich fast 3mal so viele Texturen benutzen wie bei Verwendung von Bitmap-Texturen.

Beim Designen der Levels mit einfachen Sprites, und einfachen schnell erstellten Models, verwende ich jedoch immer Bitmaps und TGA-Dateien. Einfach deshalb, weil es am schnellsten geht, und weil ich dann auch besser abschätzen kann, wann die Grafikspeicher-Grenzen erreicht sind. Weil das fertig ausmodellierte Model wird ja normalerweise eine größere Textur benötigen als ein einfaches Sprite. Ein Sprite von einer Hauswand stellt ja nur die Vorderseite dar, während beim 3D-Modell dann auch Seitenteile wie z.B. die Seiten von Tür- oder Fensternischen texturiert werden müssen. Man braucht dann zwar für das fertige 3D-Model mehr Speicher als für das Sprite, dafür gewinnt man aber wieder Speicher durch die Verwendung von DDS-Texturen. Wenn ich beim Designen der Levels bereits mit DDS-Texturen arbeiten würde, könnte es passieren, dass mir im fertigen Level dann der Grafikkartenspeicher ausgeht - also dass meine Models mehr Speicher fressen als geplant. Deshalb arbeite ich beim Designen lieber mit größeren Dateien, damit ich dann nachher noch einen Puffer habe.


2.) Der hintere Hintergrund in geringerer Auflösung:
Ich versuche immer, nur die Auflösung zu wählen, die auch wirklich notwendig ist. Objekte, die sich nahe bei der Kamera befinden, haben dann eine höhere Auflösung und Texturgröße als Objekte, die weiter entfernt sind. Bei einem Turm zum Beispiel ist nur der untere Teil des Turmes hochauflösend. Wenn man von unten zum Turm hinaufblickt, hat der obere Teil des Turmes eine wesentlich geringere Auflösung.

Wichtig ist dabei, dass man immer bedenkt, dass ein Pixel von einer Textur bei Betrachtung im Spiel nicht größer sein sollte als ein Pixel vom Monitor. Um das besser abschätzen zu können, arbeite ich auch gerne mit Raster-Texturen. Das heißt, ich gebe meinen Models als Textur ein Pixel-Raster. Dann kann man besser abschätzen, ob die Auflösung passt, bzw. ob ein Kästchen von so einem Raster nicht doch zu groß dargestellt wird, oder auch zu klein (was ja Textur-Verschwendung wäre, wenn die Pixel einer Textur gar nicht alle am Bildschirm zu sehen wären). Bei 3D-Models hat so eine Raster-Textur außerdem den Vorteil, dass man besser erkennen kann, wie stark die Textur verzerrt wird. Optimal ist ein Model dann, wenn es alle Kästchen vom Raster auch wirklich möglichst rechteckig und in möglichst gleicher Größe darstellt. So eine Raster-Textur sieht dann z.B. so aus (ist nur ein Ausschnitt von der gesamten Textur, die vollständig aus solchen Kästchen besteht):



Bei der Wahl der korrekten Texturgröße habe ich oft das Problem, dass z.B. die Auflösung "1024 x 1024" zu klein wäre, die Auflösung "2048 x 2048" wäre jedoch zu groß. Zum Beispiel bei der Textur von meinem Himmel und Horizont.
Deshalb verwende ich immer Texturgrößen von 8192 x 8192 Pixel. Egal wie groß das Model ist. Auf so eine riesige Textur passen dann halt die Skins von MEHREREN Models, und diese Models teilen sich dann die Textur. Der Vorteil dabei ist, dass ich dann auch problemlos andere Auflösungen (z.B. 1300 x 1300 für meine Horizont-Textur) verwenden kann. Den Rest des Platzes auf der großen Bitmap benutze ich dann halt für andere Models (z.B. für Bodentexturen).
Dabei achte ich natürlich schon darauf, dass nur jene Models sich eine Textur teilen, die im Level auch nahe beisammen liegen. Weil ich ja dann später eventuell Models auch nachlade bzw. aus dem Speicher lösche. Die große Bitmap, auf der sich auch die Himmels-Textur befindet, die ja die ganze Zeit über im Speicher bleiben muss, enthält dann hauptsächlich Texturen, die ebenfalls ständig im Speicher gehalten werden sollten (z.B. oft verwendete Bodentexturen).


3.) Himmel mit Gradiententextur oder prozedural mit einem Shader:
Mein Himmel verwendet keinen vertikalen Farbverlauf, da das unnatürlich aussehen würde (habe es ausprobiert).
Das heißt, der Übergang vom unteren hellen (bzw. fast weißen Bereich) zum oberen dunkelblauen Bereich entspricht dem natürlichen (ungleichmäßigen) Übergang aus dem Originalfoto.

Zusätzlich blendet der Himmel oben in eine einzige blaue Farbe über. Nur der UNTERE Teil des Himmels hat also einen Farbverlauf, der obere Bereich hat nur noch eine einzige Farbe. Und obwohl der Himmel sehr hoch hinauf geht, ist die Textur für den Himmel nur ein eher schmaler Streifen (gerade so breit wie der sichtbare Farbverlauf über dem Horizont). Der obere Teil des Himmels benötigt als Textur eigentlich theoretisch nur einen einzigen blauen Pixel. Das heißt, meine Himmelstextur ist also in Wirklichkeit sehr viel niedriger als sie im Spiel aussieht. Und weil der dunkelblaube Bereich im oberen Teil des Himmels ja nur eine sehr kleine Skin benötigt (theoretisch nur 1 Pixel), wirkt sich das auch sehr positiv auf die Framerate aus.

Die Wolken am Himmel sind momentan Sprites. Später werde ich dafür ebenfalls Models verwenden, damit die Wolken ein wenig 3-dimensionaler wirken.

Der Himmel ist übrigens nachkoloriert. Weil auf Fotos sieht ein Himmel nie so aus wie in Wirklichkeit. Entweder ist auf den Fotos die Landschaft darunter zu dunkel (dafür ist der Himmel dann schön blau), oder die Landschaft hat eine realistische Farbe, dann ist aber meist der Himmel überbelichtet, und wirkt eher weiß. Daher habe ich im original RAW-Foto die Helligkeit so verändert, dass einmal der Boden korrekt belichtet ist, und einmal der Himmel. Und aus den beiden Bildern habe ich dann ein einziges zusammengesetzt.

Ich hoffe, ich habe das Blau des Himmels gut getroffen?! Weil jetzt im Winter habe ich leider keinen schönen blauen Vergleichs-Himmel in freier Natur, bei dem ich überprüfen könnte, ob die Farbe optimal passt. Hab den Himmel also eher aus dem Bauchgefühl heraus eingefärbt.


4.) Kleines Problem mit dem Farbverlauf des Himmels:
Da der Farbverlauf des Himmels sehr fein ist, und das Auge mehr Blautöne unterscheiden kann als mit 24bit-Farbtiefe möglich ist, sieht man eventuell Abstufungen im Farbverlauf. Vor allem dann, wenn man einen Monitor hat, der nicht so viele Farben darstellen kann. Und auch auf Videos sieht man durch die Kompression dann deutliche Abstufungen bzw. Artefakte.
Wie ich das am besten wegbekomme, weiß ich noch nicht. Aber ich werde es mal mit Dithering probieren.


5.) Die Hügel im Vordergrund:
Momentan verwende ich für die großen Hügel im Vordergrund Texturen mit Alphakanal - damit der Übergang zum Horizont dahinter schön weich ist.
Allerdings sind so große Texturen mit Alphakanal nicht gerade optimal für die Framerate. Daher werde ich hier auch noch etwas optimieren. Die Hügel werden dann als normale Models modelliert, mit einer Textur OHNE Alphakanal. Und nur im schmalen oberen Bereich werde ich ein Model mit Alphakanal überlagern. Sodass der semi-transparente Bereich auf ein Minimum (also einen schmalen Streifen) reduziert wird.