Monster Fm's

Deine Kiste ist inwischen zu alt
Inwischen kann man sehr große Texturen verwenden. Manche Autoren wissen nicht, dass z. B. die Texturen aus dem Enhancement Pack nicht optimiert sind und verwenden sie so. Bei anderen Texturen ist es ähnlich.
Auf jeden Fall muß man damit rechnen, dass man im Zuge der NewDark-Entwicklung wesentlich mehr Power braucht, um FMs zu spielen. Denn die Maps können größer sein, wie die Sichtweite, Texturen, Polys (schau mal auf dieses Bild, darauf sind 23000 Polys zu sehen, früher war bei knapp 1000 Schluß) und Backface Checks (also die Gesamtheit der Obj-Polys). Und das braucht Rechenleistung.

Diese angesprochenen neuen Spiele verwenden alle Mipmaps, das ist so Usus. Mipmaps sparen enorm Ressourcen. Deshalb sind alle Autoren aufgerufen, Texturen im DDS-Format mit Dxt-Kompression und Mipmaps zu verwenden. Mipmaps funktionieren so, dass sie erst in ihrere vollen Pracht gerendert werden, wenn man nahe dran ist. In der Entfernung dargestellt brauchen sie weniger Grafikpower. In Kingsbridge sind zwar Texturen im dds-Format (was nichts bedeutet, solange keine Mipmaps drin sind), aber sie sind schlicht zu groß. Z. B. riesige Fenstertexturen (3 MB und mehr), die im Editor heruntergescalt wurden. Das ist nicht klug, denn das braucht alles Rechenleistung, weils die mis enorm aufbläst. Diesselben Texturen, um den Faktor 4 verkleinert, hätten exakt dasselbe Bild ergeben, dafür die Rechenleistung um den Faktor 10 (grob geschätzt) verkleinert. Denn eine 256x256-Textur belastet den Speicher mit max 170kb, anstelle 3MB. Viele Autoren denken momentan halt: Hau rein was geht (denn es geht).

Genau so ist es.
Da aber viele bessere FM Bauer als Spieleentwickler sind können die meisten das nicht so wissen und füllen halt die großen Bitmaps ein die immer voll dargestellt werden und keine verschiedenen Zwischenrender haben.

Wenn man die heutigen Spiele mit AA und AF ebenfalls mot der uralt Taktik bauen würde, kämen kaum Bilder zustande:D

Die Bitmaps haben damit kaum etwas zu tun. Bitmaps werden i.d.R für Effekte gebraucht und sind schon optimiert. Auch die Neuen.

Interessant finde ich, wie ich schon im englischen Forum anmerkte, dass "Kingsbridge" und "KoI: Bad Venture" (v1.1, v1.2) auf meinem Schlepptop mit der Intel-Onboard-Grafik weitgehend flüssig laufen, während Version 1.1 von "Death's Turbid Veil" im Garten sehr langsam lief, die CPU schnell auf die maximal erlaubte Temperatur brachte und den Lüfter zum akustischen Äquivalent des Düsentriebwerks umfunktionierte. Könnte evtl. hilfreich sein, nachzusehen, wo der eigentliche Unterschied ist. Vielleicht könnte man dann ein paar Tipps an Autoren weiterreichen, wie allzu heftige "Bremsklötze" (auch für aktuelle Rechner) in FMs vermieden werden können.

Autoren müssen immer versuchen, Speicher-Peaks zu vermeiden. Die kommen dadurch zustande, dass an einzelnen Stellen Texturen geladen werden, die irrsinnig viel Speicher fressen.
So ein Ort gibts in KoI: Bad Venture in der Kanalisation, hinter einer verschlossenen Tür. Der Spieler kommt zum Glück im Spiel nicht hin, sonst wären die Klagen größer gewesen.

In Death's Turbid Veil 1.1 wurden zwar Terrain-Texturen zu Mipmaps gemacht, Objekt-Texturen aber so belassen - wahrscheinlich, weil keiner darauf hingewiesen hat. Büsche, Bäume, usw. sind riesige TGA-Texturen. Unnütze Speicherfresser, die auch die Thief2.exe voll auslasten. In der Folge sind langsame Grafikkarten, die womöglich wenig vRam haben, komplett über den Rand ausgelastet.
Was die wenigesten Autoren wissen, ist, dass Mipmaps
1. Meistens weniger Resourcen und Speicher brauchen, sowohl in DromEd, als auch Thief2.exe
2. Transparente Texturen zwar erstmal größer machen können (was sich aber nur in DromEd auswirkt, im Spiel selbst ist der Speicherverbrauch geringer*)
3. *Der letzte Punkt ist besonders wichtig. Während tga und png-Texturen in DromEd genauso viel Speicher brauchen, wie anschließend im Spiel, verbrauchen Mipmaps im Spiel bis zu 2/3 weniger Ressourcen. Deshalb konnte ich Death's Turbid Veil auch auf einem alten Thinkpad spielen, nachdem von mir alle Texturen konsequent zu Mipmaps gemacht wurden. Ums nochmal anschaulich zu sagen: Braucht die DromEd.exe mit TGAs, PNGs, usw. 1GB Speicher, wird es anschließend für die Thief2.exe auch 1GB Speicherverbrauch hinauslaufen (übrigens genau das ist bei Death's Turbid Veil zu beobachten). Braucht die DromEd.exe mit Mipmaps 1GB Speicher, wird die Thief2.exe/das Spiel etwa 350-400MB brauchen. Das heißt, dass eine FM mit Mipmaps auch auf schwächeren Systemen spielbar bleibt.

Zitat von fibanocci

Autoren müssen immer versuchen, Speicher-Peaks zu vermeiden. Die kommen dadurch zustande, dass an einzelnen Stellen Texturen geladen werden, die irrsinnig viel Speicher fressen. [...]

In Death's Turbid Veil 1.1 wurden zwar Terrain-Texturen zu Mipmaps gemacht, Objekt-Texturen aber so belassen - wahrscheinlich, weil keiner darauf hingewiesen hat. Büsche, Bäume, usw. sind riesige TGA-Texturen. Unnütze Speicherfresser, die auch die Thief2.exe voll auslasten. In der Folge sind langsame Grafikkarten, die womöglich wenig vRam haben, komplett über den Rand ausgelastet.

Hmm, ich bin mir nicht so sicher, ob das auch in meinem Falle die Erklärung ist. Wie schon mal erwähnt, hatte ich bei "Death's Turbid Veil 1.1" schon mal die meisten Texturen der Außenfassade des Hauses gelöscht (die Dateien wurden gelöscht, nicht etwa irgendwas in DromEd), dennoch verursachte der Blick von draußen auf's texturenentleerte Gebäude eine deutliche Verlangsamung. Richtete ich den Blick ins bepflanzte Gelände rund um den Startpunkt, dann war das nicht so schlimm. Als nicht allzu informierter Laie würde ich eher auf die durchsichtigen Fenster tippen; in vielen Missionen sind die Fenster ja nicht wirklich transparent, so dass die Spiel-Engine sich da evtl. einiges an Rechen- und Darstellungsarbeit ersparen kann. Weißt Du eigentlich, wie es damit in der Thief-Engine aussieht?

Ich weiß natürlich auch nicht, welche technischen Unterschiede zwischen der Onboardgrafik Deines Thinkpads und meines Schlepptops bestehen. Je nachdem, wie das da aussieht, und welche Funktionen einer Grafikkarte evtl. vom jeweiligen Treiber mangels leistungsfähiger Grafikhardware über die CPU abgewickelt werden, könnte ich mir da sehr unterschiedliche Reaktionen der Rechner auf bestimmte Anforderungen durch eine FM vorstellen. Und dann weiß ich auch nicht, woher die Onboardgrafik bei mir ihren Speicher kriegt: Abgezwackt vom Hauptspeicher? Oder hat die GPU da eigenes RAM, wie bei "richtigen" Grafikkarten? Und wie ist der Speicher an die GPU angebunden? Wieviel Video-RAM kriegt die Onboardgrafik da überhaupt? Ich kann da auch per BIOS/Treiber nix beeinflussen. Andere Leute haben da evtl. bessere Eingriffsmöglichkeiten.

Aber egal. Vom Außengelände abgesehen ging's in "D.T.V. 1.1" ganz gut, und wesentliche Teile der Mission liefen dann mit akzeptabler Geschwindigkeit.

Zitat von fibanocci

Was die wenigesten Autoren wissen, ist, dass Mipmaps
1. Meistens weniger Resourcen und Speicher brauchen, sowohl in DromEd, als auch Thief2.exe

Tscha, das ist mir einst Ende der 90er Jahre schon beim ersten "Tomb Raider" mit 3D-Zusatzgrafikkarte aufgefallen, dass das Umstellen auf Mipmaps da alles etwas flotter laufen ließ.

Zitat von fibanocci

3. [...] Während tga und png-Texturen in DromEd genauso viel Speicher brauchen, wie anschließend im Spiel, verbrauchen Mipmaps im Spiel bis zu 2/3 weniger Ressourcen. [...] Braucht die DromEd.exe mit Mipmaps 1GB Speicher, wird die Thief2.exe/das Spiel etwa 350-400MB brauchen. Das heißt, dass eine FM mit Mipmaps auch auf schwächeren Systemen spielbar bleibt.

...weil die entfernteren Texturen nur als geringer aufgelöste Versionen in den Speicher kommen? (Das ist der Sinn der Mipmaps, oder?)

Ich kann nur von meinem Laptop mit Onboard (Intel 4500) sprechen. Der nutzt den frei verfügbaren Speicher, der automatisch vom Hauptspeicher abgezwackt wird. Das sind etwa 750MB.
Bei einem anderen AMD-Board mit Onboard Videokarte kann ich den Speicher im Bios selbst zuordnen. Der Speicher wird ebenfalls abgezwackt.

Es kommt bei Texturen nicht darauf an, wie häufig sie gebraucht werden, sondern darum, ob sie geladen und gerendert werden oder nicht. Das heißt, eine einzige riesige Textur, die womöglich für den Spieler gar nicht sichtbar ist, kann viel Speicher verbrauchen. Zusammen mit einigen wenigen anderen riesigen Texturen kann schon ein Leistungsknick entstehen. Beide angesprochene FMs beziehen riesige Texturen aus demselben Pool - wie mir scheint - die nicht optimiert wurden. Jedenfalls fand ich diesselben Texturen.

Was den Außenbereich mit Blick auf das Innere des Hauses durch die Fenster in Turbid Veil angeht, sind da halt sehr viele Objekt-Polys durch die Fenster sichtbar. Backface Checks gehen auf über 15000. Dagegen ist das Maisfeld in der Farm ziemlich brav
Die Faustregel gilt: ab 10000 wirds langsam kritisch.

Die Mipmaps werden in der Entfernung sozusagen nicht vollständig gerendert, das spart Rechenkraft. Man könnte auch sagen: Sie sind noch nicht ganz da.

Zitat von fibanocci

Ich kann nur von meinem Laptop mit Onboard (Intel 4500) sprechen. Der nutzt den frei verfügbaren Speicher, der automatisch vom Hauptspeicher abgezwackt wird. Das sind etwa 750MB.
Bei einem anderen AMD-Board mit Onboard Videokarte kann ich den Speicher im Bios selbst zuordnen. Der Speicher wird ebenfalls abgezwackt.

Das "Abzwacken" ist wohl heutzutage der Standard bei Onboard-Grafikkarten, und ich geh' auch davon aus, dass "meine" Intel-Grafik das so macht. Ich weiß es aber eben nicht, und mir sind bislang weder Programme zum Feststellen des jeweiligen RAM-Abzwack-Ausmaßes bekannt, noch habe ich eine Möglichkeit, bei meinem Schlepptop irgendwie einzugreifen. Das macht die Untersuchung von Gründen für Slideshows natürlich nicht einfacher und artet, wie bei "Death's Turbid Veil", dann in ein detektivisches Ratespiel aus.;)

Zitat von fibanocci

Es kommt bei Texturen nicht darauf an, wie häufig sie gebraucht werden, sondern darum, ob sie geladen und gerendert werden oder nicht. Das heißt, eine einzige riesige Textur, die womöglich für den Spieler gar nicht sichtbar ist, kann viel Speicher verbrauchen.

...weil sie in den Speicher geladen wird und ihn damit füllt, aber eventuell nicht mal gerendert (=auf dem Bildschirm sichtbar gemacht) wird? Ist natürlich logisch. Und je nachdem, welche Berechnungen vielleicht schon ausgeführt werden, bevor überhaupt klar ist, ob die entsprechende Fläche auch nur teilweise auf dem Bildschirm erscheinen soll, kann natürlich noch mehr Rechenzeit verbraten werden. Da müsste man wohl genau wissen, wie die jeweilige Spiel-Engine sowie die Grafiktreiber und auch DirectX im jeweiligen Falle genau vorgehen.

Zitat von fibanocci

Beide angesprochene FMs beziehen riesige Texturen aus demselben Pool - wie mir scheint - die nicht optimiert wurden. Jedenfalls fand ich diesselben Texturen.

Im englischen Forum gab's wohl schon Denkansätze in die Richtung, das oft verwendete Ressourcen (z.B. eben die Maispflanzen, wie sie in "The Farm" auch vorkamen) mal irgendwie "zentral für alle" optimiert werden sollten. Vielleicht entstehen dann ja "genügsamere" Objekt- und Texturen-Packs, die auch weniger erfahrene Autoren leicht in die Finger kriegen. Ich vergleiche da in Gedanken ein Wenig mit "DromEd Deluxe", das ja wohl auch einige Dinge allgemein zur Verfügung stellte. So könnten sich neue Autoren dann darauf konzentrieren, was sie in ihren Missionen darstellen wollen, ohne schon frühzeitig mit Optimierungen oder Problemen auf schwächeren (aber nicht uralten) Systemen konfrontiert zu sein. Na, mal sehen, das dauert vermutlich eine Weile, falls das dann wirklich mal in Gang kommt.

Zitat von fibanocci

Was den Außenbereich mit Blick auf das Innere des Hauses durch die Fenster in Turbid Veil angeht, sind da halt sehr viele Objekt-Polys durch die Fenster sichtbar. Backface Checks gehen auf über 15000. Dagegen ist das Maisfeld in der Farm ziemlich brav

Ja, das passt auf meine "Erlebnisse". Und das Maisfeld der Farm hat nur sehr wenig geruckelt in meinem Fall, das fand ich ganz okay so. Ich hab' eher den Eindruck, dass auch viele Leute (AIs) meinen Schlepptop bremsen, sowohl beim Herumlaufen der Kranken und des feurigen Kampftrupps auf der Farm wie auch beim Betreten des Schankraums in "KoI: Bad Venture". Das muss dann aber wirklich 'ne ziemliche Menge sein, in den beiden Missionen gibt's ansonsten im Normalfalle keine Ruckler, bei denen ich den Eindruck habe, dass die AIs dafür verantwortlich sind.

Zitat von fibanocci

Die Mipmaps werden in der Entfernung sozusagen nicht vollständig gerendert, das spart Rechenkraft. Man könnte auch sagen: Sie sind noch nicht ganz da.

Wenn ich diesen Wikipedia-Artikel richtig verstehe, wird in der Entfernung eine geringer aufgelöste Textur für's Rendering verwendet, was natürlich Rechenleistung einspart. In den Speicher geladen würden allerdings immer noch alle "Einzelbilder" der Mipmap, wenn das Verfahren so abläuft, wie dort beschrieben. Demnach würde Rechenleistung eingespart, der Speicherbedarf würde aber gleich bleiben, egal wie weit das durch die gemipmappte Textur bedeckte Objekt vom Spieler weg ist.

Es sei denn natürlich, man würde auch beim Übertragen einer Mipmap von der Texturdatei in den Speicher nur das laden, was man in nächster Zeit auch braucht. Also beispielsweise für ein Kilometer weit entferntes Objekt nur die kleinsten zwei Abbildungen der Mipmap, und wenn dann beim Näherkommen des Spielers irgendwann zum tatsächlichen Darstellen auf dem Bildschirm (vulgo: rendern) schon die größere der beiden Abbildungen nötig wäre, könnte man aus der Texturdatei dann die nächste Abbildung nachladen. Wobei dann natürlich die Frage wäre, ob dass dann nicht so viel Festplattenaktivität auslösen würde, dass zwar das Rendern prima läuft, aber die andauernd auf Volllast laufende Platte selbst im DMA-Betrieb noch so viel Rechnerzeit beanspruchen würde, dass nun die Ruckler wegen der Datenschaufelei von Platte zu RAM auftreten würden...

Zitat

Wenn ich diesen Wikipedia-Artikel richtig verstehe, wird in der Entfernung eine geringer aufgelöste Textur für's Rendering verwendet, was natürlich Rechenleistung einspart. In den Speicher geladen würden allerdings immer noch alle "Einzelbilder" der Mipmap, wenn das Verfahren so abläuft, wie dort beschrieben. Demnach würde Rechenleistung eingespart, der Speicherbedarf würde aber gleich bleiben, egal wie weit das durch die gemipmappte Textur bedeckte Objekt vom Spieler weg ist.

Wohlmöglich nicht!

Zitat

MIP-Maps haben einen höchstens um 1/3 höheren Speicherbedarf als das größte Bild alleine.

Quelle:

Vom Prinzip her logisch, oder nicht?

Mit Mipmaps ist es möglich in FM's hochauflösende Texturen zu verwenden bei ca. 1/3 des herkömmlichen Speicherbedarfs.

Edit:
Habe ich schon wieder Traffic geklaut, sorry.

Zitat von baeuchlein

Im englischen Forum gab's wohl schon Denkansätze in die Richtung, das oft verwendete Ressourcen (z.B. eben die Maispflanzen, wie sie in "The Farm" auch vorkamen) mal irgendwie "zentral für alle" optimiert werden sollten.

Das wäre schonmal ein Ansatz. Momentan liegen die Texturen z. B. vom Enhancement Pack 2.0 oder Necro Age nur im png/tga-Format vor. Viele Leute haben das installiert, was denkbar schlecht ist. Denn diese Leute schleppen die gewaltige 'Last' in jeder FM mit, wenn ep2, usw nicht deaktiviert wird. Sagt man den Leuten sie sollen das Zeugs deaktivieren, gibts Gemaule ohne Ende. Die meisten Texturen davon können ohne Einbußen zu Mipmaps gemacht werden. Aber auf den Einzelfall kommts an.
Die Texturen der Maispflanzen sind längst von mir optimiert worden. Anfangs waren es sehr große Texturen. Wieso auch immer.

Zitat von Quit pro Quo

Zitat


MIP-Maps haben einen höchstens um 1/3 höheren Speicherbedarf als das größte Bild alleine [...]
Quelle:

Vom Prinzip her logisch, oder nicht?

Nein, da ist keine für mich verständliche Logik zu erkennen. Da steht einfach nur die Behauptung, es wäre so. Da ist kein Beweis zu sehen, und ich kann auch nicht erkennen, woher diese mathematische Formel denn kommt, und wie sie anzuwenden ist. Damit kann ich im Prinzip trotz naturwissenschaftlicher Bildung nichts anfangen. Das heißt nicht, dass das richtig oder falsch ist, sondern nur: Ich kann damit nix anfangen, weil mir dazu Informationen fehlen.

(P.S.: Ich habe gerade nochmal den erklärenden Abschnitt in der Wikipedia oberhalb des Abschnitts mit der Formel überflogen. Möglicherweise kann man daraus tatsächlich die Formel ableiten. Ob allerdings in der Realität exakt so vorgegangen wird wie im Wikipedia-Artikel, das weiß ich nicht.)

Auch die aus der Physik bekannte Formel F=m*a ("Kraft gleich Masse mal Beschleunigung") bedeutet ja zunächst mal gar nichts. Erst, wenn man erklärt, was da F, m und a sind, kann man überhaupt etwas mit dieser Formel anfangen. Und erst wenn man mal sieht, wie diese Formel erarbeitet wurde, kann man überlegen, ob diese Formel stimmt oder nicht. Hätte ja auch F=m/a sein können...

Also ließ ich diese Formel erst mal beiseite und beschäftigte mich mit dem Raumstations- oder Satelliten-Bild. Wenn man von dem erst mal nur die kleineren Einzelabbildungen von der Platte in den Speicher (RAM; ob auch Video-RAM oder nur PC-Speicher, das müsste man ggf. auch noch überlegen) laden würde, bräuchte man im RAM keinen Platz für die größeren Einzelabbilder. Ob diese Herangehensweise sinnvoll ist, und ob sie in der Realität für gewöhnlich überhaupt angewendet wird, ist eine andere Frage - da ich mich nicht nennenswert mit Spieleprogrammierung oder dreidimensionaler Darstellung texturierter Körper befasst habe, kann ich da nur herumvermuten, aber nichts Definitives aussagen.

Ich bin nun mal grundsätzlich misstrauisch, wenn jemand mir irgendwas vor den Latz knallt und behauptet, das sei nun die allein selig machende Wahrheit, ohne mir zu sagen, woher dieser geistige Erguss denn stammt, oder ohne zumindest mal etwas über die Anwendung der Formel o.ä. zu sagen. Dabei muss der Vordenlatzknaller gar nicht erst ein Kirchenmann sein, da diskriminiere ich wenig.;)

Nutzlose Hotlinks aus Geltungssucht. Er lernts nie.

Zumindest die erste Formel scheint richtig zu sein. Wenn man die Summenformel auseinander nimmt, dann erhält man

1 + 1/4 + 1/16 + 1/64 + ...

Die originale Textur benötigt 1 Speicher, die nächst kleinere Textur hat nurnoch die Hälfte an Seitenlänge, also 1/4 der Fläche und benötigt somit nur 1/4 Speicher und so weiter und so fort.
Auf die Summenformel lässt sich die geometrische Reihe anwenden und nach bissle Umformen kommen wir auf 1 + 1/3. Heißt also mit Mip Mapping benötigen wir 1/3 zusätzlichen Speicher.

Das ist aber nur rein theoretisch, mit Optimierungen wie Kompression und sonstigem Gedöns sieht der Speicherverbrauch in der Realität ganz anders aus.

Nachtrag: Mip-Mapping wird sehr häufig für die Optimierung im 3D-Anwendungen verwendet. Vereinfacht gesagt geht es dabei weniger um das Einsparen von Speicher, als um die zu verarbeitende Datenmenge. Die GPU wird entlastet und das Ergebnis sieht besser aus.
Hilft also kaum bei eurer Problematik weiter, im Gegenteil.

Wie auch immer, wenn ich eine FM nicht störungsfrei und/oder flüssig spielen kann, landet sie im Bit-Mülleimer ... letztlich ist es mir wurscht, wie weit der Autor die Grenzen der ND-Engine ausreizen konnte, für mich ist die Handlung der FM wichtig, nicht ihre technischen Hintergründe. Wird auch im Ami-Forum diskutiert:

Zitat von davidsung

Nachtrag: Mip-Mapping wird sehr häufig für die Optimierung im 3D-Anwendungen verwendet. Vereinfacht gesagt geht es dabei weniger um das Einsparen von Speicher, als um die zu verarbeitende Datenmenge. Die GPU wird entlastet und das Ergebnis sieht besser aus.

Mipmaps werden halt schon vorgerendert. Das gibt regelmäßig einige FPS dazu. Man siehts in DromEd. Man sieht auch, dass der Speicherverbrauch erheblich sinkt.

Zitat

Hilft also kaum bei eurer Problematik weiter, im Gegenteil.

Das ist nun die komplett falsche Schlußfolgerung

Ich bekam in der Entwicklungszeit der HD mods in der Praxis faktische Beweise, dass Mipmaps in Zusamnenarbeit mit der Newdark Engine sehr wohl Speicherplatz einspart. Als ich anfangs kein .DDS Format sondern .PNG genutzt habe, brachte dies die Engine zum Absturz. Dies konnte ich mit der Umstellung auf mipmaps verhindern. Auch der Ladevorgang einer Mission verkürzte sich nach der Verwendung von DDS mitmap Texturen.

Ich mag "multum in parvo".
Im Vergleich beinhalten herkömmliche Texturen keine MipMaps und müssen oft erst dekromprimiert (PNG/JPG) werden, bevor sie in den VRAM gelangen, oder sind von vornherein schon groß (TGA).

Gecko
Könnte man nachträglich z.B. im Beta-Test Optimierungen vornehmen oder ist das zu aufwendig. Wie gehst du vor?

zappenduster
Finde es immer wieder erstaunlich, wieviel World/Action in eine handvoll Bytes passt, wenn ich mir alte Fanmissionen anschaue.

@Bäuchlein
Vielleicht irre ich mich, doch auf diese Weise gelangen hochauflösende Texturen (all inclusive) direkt in den VRAM und das mit einen maximal 1/3 höheren Speicherbedarf. Geht`s noch kleiner? Für mich steht die Formel für Performance. Hinzukommen feste Datenkompressionsrate (logisch) und 1 Speicherzugriff pro Texel. Richtig angewendet wird Speicher und Rechenleistung gespart.

Wieviel Detailstufen (LOD) sind in NewDark möglich?