Vigilant schrieb:
Das ist auch schon in vielen Modding-Projekten so. Optimierte 2K-Texturen als Ersatz für grundsätzlich schlechtere Basis-Texturen haben einen wirklich sichtbaren Effekt. Von schon vernünftigen 2K- auf 4K-Texturen zu geben, gibt sich nicht viel und frisst nur Platz auf dem Laufwerk.
da gibts ein grundlegendes verständnisproblem. texturqualität in spielen hat erst einmal nichts mit der absoluten texturauflösung zu tun, sondern mit der größe der darstellung im spiel. 2k, 4k, 256x256 ist alles völlig irrelevant, wenn nicht klar ist, wie groß das objekt hinterher im spiel dargestellt wird.
1024x1024 für irgendein kleines prop-modell weit weg vom spieler? überdimensioniert. 1024x1024 für einen hauptcharakter, an den man sehr nahe rankommt? völlig unzureichend.
absolute und relative auflösung, sprich pixel vs DPI sind auch beim druck immer wieder ein stolperstein.
bei texturen gilt: die auflösung muss für die anwendung hoch genug sein, sprich: wie nah kommt die kamera der textur. aber sollte gleichzeitig natürlich nicht unnötig groß werden.
HighPerf. Gamer schrieb:
Kann mir jemand mit echten Fachkenntnissen erklären, wieso eine höher aufgelöste Textur plötzlich deutlich mehr CPU Perfomamce benötigt ?
dass texturen im allgemeinen nicht mehr resourcen verbrauchen ist ein irrglaube. das entspricht einfach nicht der realität. bei einer unkomprimierten albedo/diffuse texture (reine farbinformationen) kommt das ca hin, aber texturen bestehen nicht nur aus einem einzigen bild.
in modernen spielen bestehen texturen für ein objekt aus 3,4,5 verschiedenen texturen bspw. maps.
albedo/diffuse für die farbe, normal map (bump map auf steroide, relevant für 3d rendering bzw. shading), specular/roughness/phong für reflektionen und glanzeffekte, self illumination für selbstleuchtende texturen und je nach engine noch ein paar andere spezielle shadermaps.
normal maps und andere shadermaps haben einen direkten einfluss auf die grafiklast, weil die maps effekte steuern, die von der gpu berechnet werden müssen. je höher die auflösung der maps, desto höher die grafiklast, da durch mehr informationen die operation insgesamt komplexer wird. die extra-last hält sich in grenzen, weshalb lowpolymodell + normal map generell highpoly modellen vorzuziehen sind, aber umsonst ist eine höhere auflösung nicht.
wo dann die cpu ins spiel kommt, ist bei der komprimierung der texturen bzw. dem entpacken. das ist nämlich auch nicht soooo einfach. albedo/diffuse texturen können in der regel mit einer lossy jpeg artigen kompression komprimiert werden, das spart platz und ist kaum sichtbar, vorallem bei hohen auflösungen.
shadermaps und normal maps sind anfällig für eine lossy jpeg kompression, weil es dann zu unschöner treppenbildung in verläufen kommt, wenn die kompression zu stark ist (sehr auffällig in vanilla half-life 2, das teilweise komprimierte normal maps nutzt), und das produziert dann blöcke wo keine sein sollten - also werden normal maps und andere empfindliche shadermaps in der regel zip-komprimiert, was dann natürlich auch erst wieder entpackt werden muss.
wenn dann das caching und preloadsystem nicht optimiert ist und sowas wie rapid storage nicht zur verfügung steht, kommt es halt zu einer erhöhten cpu last, wenn das ganze on the fly entpackt werden muss - das kann auch zu rucklern führen, wie man das bspw. oft mit der unreal engine hat.
diese ruckler kommen in der regel daher, dass das asset streaming überfordert ist oder nicht anständig vorgeladen wurde und daten direkt aus dem spielarchiv anstatt aus einem cache geladen werden müssen.
