Bis jetzt habe ich keine Probleme mit dem Nexus (und meine Testlevels laufen sogar meist noch auf der A6, auf der es noch nicht mal eine dynamische Vergrößerung des Nexus gab).

Bei weitem am meisten Speicher verbrauchen die Texturen (und ich arbeite generell immer mit Texturgrößen von 8192 x 8192 Pixel). Zum Testen der Models, zum Leveldesignen, etc., verwende ich immer Bitmap-Texturen. Dann weiß ich, dass ich später noch Nexus-"Reserven" habe, wenn ich dann die Bitmaps in DDS-Dateien konvertiere.

Die Kunst ist es halt, die Levels so zu designen, dass man möglichst wenige Texturen braucht, und dass der Spieler dann trotzdem nicht sofort erkennt, dass viele Texturen mehrmals im Level vorkommen.

Mein Abtei-Level, der eigentlich sehr groß sein wird, ist so aufgebaut, dass es mehrere abgegrenzte Bereiche gibt. Und jeder Bereich hat seine eigenen Texturen, die dann beim Wechseln zu einem anderen Bereich nachgeladen bzw. entladen werden können.
Beispiel: zuerst gelangt der Spieler in das Dorf am Fuße des Felsens. Hier wird es viele Olivenbäume geben, viele Mauern/Einzäunungen, Bauernhäuser, spezielle Bodentexturen für das Tal, und die Kapelle. Dann geht der Spieler durch das Tor einer Befestigung hindurch, und ab diesem Zeitpunkt sieht er dann eine Landschaft, die ganz andere Texturen benutzt. Hier gibt es Bodentexturen, die "steiniger" sind. Hier gibt es dann keine Olivenbäume mehr, und es gibt Häuser, die ganz anders aussehen als die im Tal. Die Tal-Texturen kann ich also beim Durchschreiten des Tores entladen, und die "Berg"-Texturen hinzuladen. Der dritte Bereich ist dann das Innere des Klosters am Berg.

Jeder Bereich wird also ganz anders aussehen, jedoch werden innerhalb eines Bereichs viele Texturen mehrmals vorkommen.
Von manchen Bereichen aus wird man auch ANDERE Bereiche aus der Ferne sehen können. Zum Beispiel wird man vom Kloster aus auch das Dorf mit der Kapelle sehen können. Aber das wird dann gefaked sein. Das gesamte Dorf, das man in der Ferne sehen kann, wird dann nur aus ein oder zwei Models bestehen - ein LOD-Nachbau des gesamten Dorfes sozusagen, mit sehr wenigen Polygonen und sehr wenig Textuenspeicher. Dem Spieler kommt der Level dadurch dann sehr viel größer vor, als er tatsächlich ist. In Wirklichkeit ist jeder einzelne der drei Bereiche soetwas wie ein eigener abgegrenzter Level.


Polygonanzahl:
Mit der Polygonanzahl habe ich generell keine Probleme. Im Gegenteil. Gerade die fotorealistischen Texturen erlauben es, dass man viel weniger Polygone benötigt. Manche Felsen, Mauern, etc., können auch komplett flach sein, wenn man diese im Level immer nur von VORNE sehen kann, und nie von der Seite.

Ich hatte dazu früher schon mal dieses Beispielbild gepostet:


Man sieht darin eine Mauer aus Buckelquader-Steinen. Würde ich diese Mauer in 3D nachmodellieren, dann würde ich zig-tausende Polygone benötigen. Aber mit einem kleinen Trick benötige ich für diese Mauer nur sehr wenige Polygone: ich platziere einfach seitlich und vor der Mauer Objekte (z.B. den Pfeiler und den Felsen), die den Spieler daran hindern, dass er die Mauer direkt von der Seite, oder von unten, betrachten kann. Der Spieler wird sozusagen auf Abstand gehalten, und bemerkt dadurch gar nicht, dass die Buckelquadersteine gar nicht wirklich 3D sind.

Bei der Steinmauer am Wegrand geht das natürlich nicht, da man diese Mauer auch direkt von der Seite sehen wird können. Da muss es dann wirklich 3D sein. Aber man braucht dank Fototextur dafür viel weniger Polygone als man denkt.

Ein gutes Beispiel ist auch mein 3D-Dach mit den vielen 3D-Dachschindeln (siehe Video oben). Die Polygonanzahl ist gar nicht so hoch, wie es beim Anblick des 3D-Models im Video den Anschein hat. Durch die Fototextur wirkt es aber viel detailierter. Mein gesamtes Dach wird nur ungefähr 5.000 Polygone haben. Das ist weniger als man normalerweise für einen NPC benötigt. Und da die meisten Models (Mauern, Häuser, etc.) ja nicht Vertex-animiert sind, hält sich der Speicherverbrauch (Nexus) in Grenzen. Wie gesagt: am meisten verbrauchen die Texturen.