Die Reihe der Missverständnisse scheint noch nicht beendet
möglicherweise ist also hier beispielsweise schon die Absturzursache bei der Verwendung von BSAs bei dir zu suchen
Absturz bei mir? Ich habe aktuell keine mit oldSkyrim. Wenn Du Dich auf die Kurve in der Grafik oben beziehst: der Abfall ist bei CTL-TAB aus dem Testspiel raus.
Der VRam-Bedarf bedingt bei Erreichen der physischen VRam-Menge ein Auslagern/Nachladen, und das wird m.E. durch skyrim.ini
bPreemptivelyUnloadCells=1
aktiviert. Kann man auch sehr deutlich ingame sehen. Wenn ich bei meiner Teststrecke via Ebental laufe, wieviel neu reingeholt wird. (Ich habe uGridsToLoad=7 )
Der Unterschied BSA und Loose ist dabei ein anderer: Es sind bei BSA von der CPU bei entsprechedem Ram-Bedarf ja 3 Operationen zu machen: BSA öffnen/dekomprimieren, vergleichen mit vorhandenen Files (weil die Vorrang haben) und Anlegen eines internen MFT, damit das Programm nicht jedesmal pro File erst auf der Platte und in die Master schauen muss (= erneutes Dekompromieren/Einlesen), ob mit Vorrrang da ist. Gleichzeitig werden die benötigten Files (zu denen es keine mit Vorrang auf der Platte gibt) von BSA ins Ram oder VRam geladen. Ist das insgesamt bei VRam mehr, als dessen physische Grösse erlaubt, kann bereits beim Laden ein wiederholtes Entladen/Nachladen erfolgen. (Bei Ram gibt es das so nicht, wenn davon zu wenig, dann CTD) Die gleichzeitig zu ladenden Scripte können dabei weiteres Umschichten bedingen (z.B. Drachenangriff sofort = weitere Grafik mit Animationenen, viele rumrennende NPCs in der Zelle). Alles ist für sich genommen wenig, aber alles zusammen kann die Grenze dann überschritten werden, mit CTD als Folge beim Laden (oder bei Schnellreise, was ich früher bei Open Cities und Schnellreise nach Rifton öfters beobachten konnte, aber nur bei Schnellreise nach Rifton!).
... dass egal ob BSA oder Einzeldateien in dieser Situation schlicht die gleichen Daten in deinem VRAM sein sollten
richtig, aber die vorherig oder gleichzeitig ablaufenden anderen Prozesse sind mit BSA eben anders bzw.mehr.
Deutlich auch testbar bei z.B. Summerset Isles mit BSA und als loose Files. Hier kommt nämlich noch hinzu, dass das BSA hoch komprimiert ist (im Gegensatz zum BSA bei Grey Fox of Nocturnal, das überhaupt nicht komprimiert ist). Bei 3.5 GB BSA-Inhalt also CPU-Leistung und Rambedarf und, weil die Files überwiegend nicht auf der Platte sind, oder in einem Master, auch VRam.
Hoch komprimiert ist z.B. auch HighResTexturePack02.bsa mit 1831 MB als BSA, was als loose Files 5360 MB hat. Also bereits hier Auswahl notwendig, was in der/den zu ladenden Zellen + den dort ablaufenden Ereignissen (scripts u.a.) aktuell gebraucht wird.
D.h., je mehr grosse komprimierte BSA und Scripte, desto mehr Hintergrundopertionen und aktueller Rambedarf. Vorteil bei BSA: einfache Installation/Deinstallaton und flüssigerer Ablauf bei normaler HDD, sofern ausreichend Ram und VRam vorhanden (weniger Ruckeln).
Der Vorteil schwindet bei einer SSD mit Momentum Cache (was wiederum Ram verlangt) und Grafikcache der Graka, wie bei meiner NVIDIA möglich (wobei hier ein Unterschied zwischen oldSkyrim und Skyrim SE ist. Das teste ich gerade). D.h. eine Mod kann als loose Files flüssig laufen, als BSA aber crashen (wie eben bei mir das Summerset Isles). (So laufen z.B. auch Death Mountain 1 + 2, trotz riesigem gleichzeitigen Aufkommen von Drachen und anderen Gegnern, völlig problemlos und praktisch Ruckelfrei mit oldSkyrim. Hab das mit 5 Begleitern gespielt, problemlos)
Dabei ist uGridsToLoad noch ein weiterer Faktor. 5 ist Default, 7 machbar, mehr ist schon kritisch.
uGridsToLoad=7 ; 5
uExteriorCellBuffer=64 ; 36 bei uGridsToLoad=5
iPreloadSizeLimit=51380224 ; 26214400 bei uGridsToLoad=5
bPreemptivelyUnloadCells=1 ; 0 wenn nicht oder 1 wenn geleert werden soll
Das gilt alles für oldSkyrim. Bei Skyrim SE gibt es kein ENBoost, da ist die Verwaltung anders, das Gesagte so nicht voll gültig. Da ich ja beides installiert habe, kann ich das gut vergleichen.
