LoD optimieren
- Ersteller FusRoDah
- Erstellt am
E
Ehemaliger Benutzer
Gast
uGrids, davon sollte man aber besser die Finger lassen. Kostet Leistung und Spiel wird unstabil, zudem setzen Skripte eher ein, was so nicht geplant ist.
Also kurz und gut, es ist es einfach nicht wert, an dem Wert rumzuschrauben, für die Probleme die das macht.
Bleiben nur LOD-Texturen, die dann halt Details vorgaukeln. Da gibts einige, muss man sich angucken, was einem da was bringt.
Also kurz und gut, es ist es einfach nicht wert, an dem Wert rumzuschrauben, für die Probleme die das macht.
Bleiben nur LOD-Texturen, die dann halt Details vorgaukeln. Da gibts einige, muss man sich angucken, was einem da was bringt.
Das stimmt.
Das stimmt nicht. Zum einen kann man in der Skyrimprefs.ini an einigen Werten rumschrauben, so daß Objekte eher eingeblendet werden (welche das sind bin ich nur gerade zu faul zu schreiben). Desweiteren gibt es auch LOD-Mods, die nicht nur detaillierte Texturen beinhalten, sondern die auch bestimmte Objekte (meshes) so geflagged haben, daß sie immer angezeigt werden (Felsen, Brücken, Lagerfeuer von Riesen etc.). Dies ist z.B. so ein Mod:
http://www.nexusmods.com/skyrim/mods/19446/?
Da ist nix mit einfach nur bessere Texturen!
E
Ehemaliger Benutzer
Gast
Die Hauptänderung wäre uGrids, die anderen Ini-Spielereien sind mehr oder weniger Makulatur.
Auf das Glücksspiel uGrids würde sich sonst ja keiner einlassen, wenn andere harmlosere Ini-Änderungen das selbe bringen würden.
Auf das Glücksspiel uGrids würde sich sonst ja keiner einlassen, wenn andere harmlosere Ini-Änderungen das selbe bringen würden.
Ich habe nicht gesagt, daß ini-Änderungen das gleiche Ergbenis bringen, wie an den uGrids zu schrauben. Aber zu behaupten, das die wenigen ini-Änderungen, die immerhin möglich sind, nichts als "Makulatur" darstellen, ist auch irgendwie ziemlich primitiv.
E
Ehemaliger Benutzer
Gast
Viele sind Makulatur und das ist nicht primitiv, sondern von Bethesda in ihrem eigenen Forum so gesagt worden, dass viele Ini-Spielereien nichts bringen, außer Ressourcenverschwendung, weil die Engine sie gar nicht, oder mit irgendwelchen Fantasiewerten so nicht nutzt.
Man kann sicher jede Menge mit der Engine anstellen, nur muss man sich mal klar machen, dass sie wie sie in Skyrim vorliegt, für die alte Konsolen eingestellt/optimiert ist, oder wie immer man es nennen will und eben nicht für dicke High-End PCs.
Das sollte man immer im Hinterkopf haben, wenn man seine Modliste meint massenhaft mit vorallem auch leistungshungrigen Mods zukleistern zu wollen - gibt hinterher weniger Probleme.
Xgf
Bürger
Ich spiele mit uGrid 7 und mehr Grass. Das bring mit Abstand am meisten.
Mit der skse_steam_loader.dll (0.1.6.16, 19.01.2014, 107 KB (110'080 Bytes)) sowie der aktuellen SKSE Version läuft einwandfrei. Ich weiss leider nur nicht mehr, wo ich die DLL her habe.
Skyrim.ini
-------------
[General]
uExterior Cell Buffer=64
uGridsToLoad=7
[Grass]
iGrassCellRadius=3
SkyrimPrefs.ini
------------------
[Grass]
fGrassStartFadeDistance=10500.0000
fGrassMaxStartFadeDistance=10500.0000
Das Problem ist, daß du es kaum merken würdest, wenn es nicht mehr einwandfrei läuft.
Xgf
Bürger
hmm also wenn ichs ned merke ist es ja wurscht :-D .. nei im ernst.. wie meinst du das? Mein Char ist LvL 58 der Save 25Mb und ich hatte von Anfang an uGrid 7. Nur ohne das DLL gibt es ab und an einen CTD bei uGrid 7. Seit ich das DLL habe, ist das Geschichte.
Der Klassiker:
Du hast also keine Probleme iSv Abstürzen, sondern mit zu früh einsetzenden Skripten etc.
Du hast also keine Probleme iSv Abstürzen, sondern mit zu früh einsetzenden Skripten etc.
Xgf
Bürger
Das stimmt einfach ned. Solche Ereignisse werden durch Triggerboxen ausgelöst und nicht duch Cell Load Events's
Hier noch ein Bild mit uGrid 9 alle Zellen geladen. Der Riese steht da es wird jedoch nicht gekämpft. Mit uGrid 5 steht er übrigens auch schon da, nur ist die Zelle nicht geladen.
... Es ist wirklich erschreckend, wie sich im Internet pseudo weisheiten verbreiten ........
Zuletzt bearbeitet:
Puh...da bin ich baff. Also diese Weisheit ist ziemlich weit verbreitet. Andererseits, Screenshots lügen ja nicht. Also sagst du, daß durch höhere uGrids man sich nichts Skriptmäßiges zerschießt?
edit:
Also ich hab nochmal ein bißchen nachgeforscht und im beliebten Skyrim Stability Guide steht das:
Natürlich ist auch dieser Guide nicht der Weisheit letzter Schluß, aber...ach ich weiß ja auch nicht!
edit:
Also ich hab nochmal ein bißchen nachgeforscht und im beliebten Skyrim Stability Guide steht das:
Natürlich ist auch dieser Guide nicht der Weisheit letzter Schluß, aber...ach ich weiß ja auch nicht!
Zuletzt bearbeitet:
Xgf
Bürger
Ich weiss, und nicht nur diese und nicht nur was Skyrim betrifft, darum habe ich den Satz am Schluss geschrieben. Ich könnte auch aus meinem Berufsleben oder Privatleben, teils schon fast tragische Geschichten erzählen. Das Internet ist aus dieser Sicht ein Fluch und es ist allerhöchste Vorsicht geraten, beim Umgang mit Infos aus dem Netz.
Ich fahre auf meinem Auto BBS Felgen die von BBS so für mein Fahrzeug mit Zertifikat angeboten werden. Von meiner Garage (Offizieller Markenvertreter) wurden sie verbaut ohne Karosserieänderungen, vom Strassenverkehrsamt geprüft und im Ausweis eingetragen. Ich war nun den ganzen Sommer damit unterweges und es fährt sich Spitzenmässig. Trozdem behaupten die selbsternannten Spezialisten im vermutlich grössten Forum zu dem Wagen, diese Felgen Breite mit dieser Einpresstiefe würde nicht gehen.
Ich weiss sicher nicht alles über Skyrim, aber alles was ich weiss, spricht deutlich eine andere Sprache. Diese Boxen lösen solche Match entscheidende Ereignisse aus, soviel ist mir klar. Es ist aber sicher so, dass man einen höheren durchschnittlichen Script Load hat, weil mehr Objekte gleichzeitig geladenen sind. Es laufen ja viele Scripte, die einfach die Welt zum leben erwecken. Aber das soll ja so sein. Darum macht man es ja, damit ein grösserer Teil der Welt um einem herum lebt, geladen ist und nicht nur eine Theaterbühne darstellt.
Was den durchschnittlichen Script Load angeht, kann man den auch ganz gut verringern, durch einen tieferen Timescale. Sehr viele Scripte laufen in einer Schleife inGameZeit gesteuert. (Event OnUpdateGameTime()).
Bei Asky zum Beispiel wird alle InGame Stunde ihr Status neu gerechnet (Leben, Ausdauer, Ernährung, loyalität etc.) Also je höher dein Timescale desto öfter laufen solche Scripte.
Klar ist, mehr uGrid gleich ganz generell mehr Load auf der Kiste 🙂.
Das ist wieder so eine Sache, wo es unterschiedliche Ansichten im Netz gibt. Ich zitiere nur mal aus der ERSO Mod, die ein Timescale-Plugin mitbringt (welches dazu da ist, damit der Spieler den Timescale Wert nicht in der Konsole eingeben muss):
ERSO 15 – Timescalechanges in-game timescale. 7 options.
(ATTENTION! Every timescale different from vanilla 20:1 could break some quests. If you have problem, try to disable it)
Danke übrigens für die Antworten bisher.
Man sollte wohl noch erwähnen, dass man nicht beliebig mit den uGrid-Werten rumspielen kann. Ein Spielstand lässt sich, laut diesem Guide, nicht mehr mit einem geringeren uGrid-Wert laden.
Zuletzt bearbeitet:
mditsch
Bürger
Also ich spiele mittlerweile seit vielen Monaten mit ugrids=9 (seit es den Sheson Fix gibt), einer Menge Hires (2k/4k) und Parallax mods drinnen und dank dem Sheson habe ich KEINE Probs mit Abstürzen und Instabilitäten. Also das ist für mich widerlegt.
Auch das mit den zu früh einsetzenden Ereignissen hat bisher NICHTS an Problemen verursacht, bzw wurden evtl gar nicht bemerkt. Ist für mich also auch widerlegt, dass dieses IMMER GROSSE oder auch sogar überhaupt Probleme macht.
Aktueller Char Level 68, 420 Stunden und Save 21MB ohne Bloat.
Achso:
253 ESM/ESP in der Loadorder, auch extrem skriptlastige Dinge. Skript Latenztest bei Convenient Horses konsequent bei 50-60ms
Auch daß sich uGrid-Werte nicht mehr zurücksetzen lassen (in einem Save) stimmt nicht: mit der entsprechende Prozedur über die Konsole ist das absolut kein Problem von 9 auf 7 oder 5 oder 3 oder 1 🙂 zurückzugehen
Auch das mit den zu früh einsetzenden Ereignissen hat bisher NICHTS an Problemen verursacht, bzw wurden evtl gar nicht bemerkt. Ist für mich also auch widerlegt, dass dieses IMMER GROSSE oder auch sogar überhaupt Probleme macht.
Aktueller Char Level 68, 420 Stunden und Save 21MB ohne Bloat.
Achso:
253 ESM/ESP in der Loadorder, auch extrem skriptlastige Dinge. Skript Latenztest bei Convenient Horses konsequent bei 50-60ms
Auch daß sich uGrid-Werte nicht mehr zurücksetzen lassen (in einem Save) stimmt nicht: mit der entsprechende Prozedur über die Konsole ist das absolut kein Problem von 9 auf 7 oder 5 oder 3 oder 1 🙂 zurückzugehen
Decreasing:
1. Spielstand mit dem aktuellen uGrid-Wert laden. Skyrim lässt eh nichts anderes zu, da der Wert im Save enthalten ist und Skyrim nur Saves lädt, in denen der Wert mit dem aus der ini-Datei übereinstimmt
2. Konsole öffnen
3. setini "ugridstoload:general" 5
4. aktuelles Spiel speichern
5. Skyrim beenden
6. in Skyrim.ini die folgenden Werte setzen:
1. Spielstand mit dem aktuellen uGrid-Wert laden. Skyrim lässt eh nichts anderes zu, da der Wert im Save enthalten ist und Skyrim nur Saves lädt, in denen der Wert mit dem aus der ini-Datei übereinstimmt
2. Konsole öffnen
3. setini "ugridstoload:general" 5
4. aktuelles Spiel speichern
5. Skyrim beenden
6. in Skyrim.ini die folgenden Werte setzen:
o [General]
o uGridsToLoad=5
o uExterior Cell Buffer=36
o [Grass]
o iGrassCellRadius=2
3. Skyrim starten und letzten Spielstand ladeno uGridsToLoad=5
o uExterior Cell Buffer=36
o [Grass]
o iGrassCellRadius=2
Zuletzt bearbeitet:
Hm...also an dem optischen Gewinn eines höheren uGrids-Wertes wäre ich schon interessiert und ich glaube auch, daß meine Hardware das eine erhöhte Anzahl an gleichzeitig laufenden Scripts mitmachen würde. Bin aber immer noch ein wenig unschlüssig, auch wenn ich an euren Worten/Erfahrungen keinerlei Zweifel habe.
Xgf
Bürger
Ich stütze mich lieber auf meiner eigenen Erfahrung. Ich habe es 2x durchgespielt mit Timescale zwischen 6 und 10. Ich hatte nie diese prognostizierten Probleme.
Ohne würde ich gar nicht mehr spielen wollen. Es ist super so. Morgens muss ich was essen, den Hund füttern, dann gehts los, nach ca einer Realtime Stunde ist Mittag. Pause machen, essen trinken, dann gehts weiter und nach einer weiteren Stunde wird es Abend. Bis da bin ich zurück im Camp, jagen kochen essen Hund füttern schlafen :-D.. Zeit auch, für eine RL Pause. Passt wunderbar zu den Mods die mich sowie denHund, "zwingen" zum essen, trinken und schlafen.
Bei allem was ich über Skyrim weiss, erscheint es mir geradezu unlogisch. Ein höherer Timescale in Verbindung mit einem SubOptimal geschriebenen Script (RegisterForUpdate anstatt RegisterForSingleUpdate) kann jedoch zu Problemen führen
Gerade eben weil alles Event, InGameTime und mit Physichen Trigger (der Spieler läuft hinein) gesteuert ist, erlaubt es eine variable Timescale. Ich denke, sogar mit 1:1 läuft es einwandfrei, würde das aber nicht mit Blut unterschreiben :-D
Bitte 🙂 Ja aber auch das geht. Man startet erst ein Spiel/Save mit uGrid 7, editiert dann bei laufendem Spiel die InI auf uGrid 5, danach öffnet man die Konsole und gibt refini (für refresh ini) ein. Dann Spiel speichern und man hat sein save auf uGrid 5. Oder man kopiert sich die CellStabilizer.dll (zu finden auf Nexus) ins ".\Skyrim\Data\SKSE\Plugins", editiert die InI von 7 auf 5, dann einfach Spiel/Save laden, neu speichern und die DLL wieder weg machen oder eben nicht wie man will.
Zuletzt bearbeitet:
Donni632001
Abenteurer
Vieles was früher als Weisheit letzter Schluß galt hat sich inzwischen als überholt herausgestellt.
Ich spiele inzwischen auch mit höheren uGridsToLoad-Werten und habe noch keine Probleme feststellen können.
Das einzige was ich niemanden empfehlen kann ist V-Sync auszuschalten,da spielt bei mir die Engine verrückt (umherfliegende Gegenstände wenn man Häuser betritt,
Datumswechsel morgens um 04.00Uhr statt um 12.00Uhr).
Ich spiele inzwischen auch mit höheren uGridsToLoad-Werten und habe noch keine Probleme feststellen können.
Das einzige was ich niemanden empfehlen kann ist V-Sync auszuschalten,da spielt bei mir die Engine verrückt (umherfliegende Gegenstände wenn man Häuser betritt,
Datumswechsel morgens um 04.00Uhr statt um 12.00Uhr).
E
Ehemaliger Benutzer
Gast
Problem war bis zum "Fix" für den Absturz bei 3.1GB RAM natürlich größer, dass heißt aber keineswegs das es weg ist.
Schon von 5 auf 7 merkt man das das einiges an Leistung kostet.
Und auch mit den Skripten ist kein Quatsch, da Bethesda es auch selber waren, die abraten diesen Wert zu ändern, auch nicht von 5 auf 3 um bessere Performance zu bekommen.
Letztlich kommt es natürlich auch immer drauf an, wie quäle ich dich Engine ansonsten noch, dass es bei dem einen stabiler als bei dem anderen ist.
Schon von 5 auf 7 merkt man das das einiges an Leistung kostet.
Und auch mit den Skripten ist kein Quatsch, da Bethesda es auch selber waren, die abraten diesen Wert zu ändern, auch nicht von 5 auf 3 um bessere Performance zu bekommen.
Letztlich kommt es natürlich auch immer drauf an, wie quäle ich dich Engine ansonsten noch, dass es bei dem einen stabiler als bei dem anderen ist.
