Vitche schrieb:
Das Problem unoptimierter Spiele ist imo ein systematisches und keines, das mit DLSS kam und von DLSS ausgeht.
Wenn ich mich da an früher erinnere? Im Endeffekt gab es die Probleme wirklich schon vor 15 Jahren und 20 Jahren.
Für mich ist da Crysis 1 und Unreal Tournament 3 immer ein gutes Beispiel, wobei es etwas verfälschend ist, weil Crysis 1 damals wirklich die Messlate bei der Grafik höher gelegt hat. Aber Crysis 1 benötigte für die volle Grafikpracht damals PCs, die es nicht gab, währnd Unreal Tournament 3 mit ca. "90%" der grafischen Qualität (ja man kann streiten, es geht mir nur ums Beispiel) - mit deutlich weniger Hardware zurecht kam und dazu auch besser lief.
Es gibt bei der Grafik immer die Option, ob man maximale "Details" will und dafür quasi die Optimierungen "vergisst", oder ob man einfach nur Faul war.
Blood011 schrieb:
Ja,und komischerweise passt da auch oft die Performance zum gelieferten.
Ja und Nein. Bei vielen Indie-Titeln wird oft mit einer "Grundengine" gearbeitet und den oft da hinterlegten Standard-Shadern gearbeitet. Epic, Crytek und Co optimieren ihre Engines relativ gut und verwendet man die grundlegenden Shader, dann muss man sich um weitere Optimierungen kaum Gedanken machen.
Bei größeren Studios kommen aber oft dann Sonderwünsche durch die Designer und Künstler, so dass die Engine- und Game-Entwickler, also die, die den Code schreiben, oft neue Shader schreiben müssen und hier trennt sich die Spreu vom Weizen.
Du hast in diesem Bereich heute viele Entwickler, die von irgendwelchen "Game-Academys" und Co kommen, die zwar ein bisschen Informatik beigebracht bekommen haben, ein Shader und Co programmieren können, aber eigentlich keine richtigen Software-Ingenieure sind, wie du sie bei Epic, Crytek und Co an den Engines hast. Es fehlt dann oft an Grundlagen und schnell mal auch an Kompetenzen in Theoretischer-Informatik und wie man ggf. einen Algorithmus auch umformen muss, damit er besser funktioniert.
Dazu kommt auch, dass du dich mit den Eigenheiten der GPUs befassen musst. Wie hier so schön angedeutet wurde, all zu viele "if-else" und co sollte man in Shadern vermeiden.
franzerich schrieb:
Ich frage mich auch was da falsch läuft. Bis 2018 gabs diese komischen Probleme (wie z.B. Shader Stuttering) bei der UE4 noch nicht.
Ja und Nein zur gleichen Zeit als Antwort. Die Ursachen für diese Probleme gab es damals schon (also Nein, die Probleme gab es auch schon vor 2018). Nur sind diese Probleme nicht aufgefallen, weil viele Spiele damals noch relativ stark einzelne Assets wiederverwendet haben und auch pro Asset auch weniger Shader berechnet wurden.
Die Probleme mit dem Shader Stuttering nimmt seit Jahren zu, weil auch große OpenWorlds mit vielen Details in Engines erstellt werden, die dafür nur bedingt gut geeignet sind. Die Unreal 4 Engine kam 2014 auf den Markt, die Entwicklung der Engine hat früher angefangen.
Epic hat die Engine zwar um neue Funktionen erweitert, aber so Späße wie Photogrammetrie waren damals noch nicht direkt auf den Schirm der Entwickler und kamen erst auf. Mit der Photogrammetrie kam dann auch auf, dass Räume als auch die Landschaft immer individueller gestaltet wurden und damit auch mehr unterschiedliche Objekte und damit Verbunden Texturen und Shader vorhanden sind, die entsprechend benötigt werden.
Jetzt muss man halt verstehen, wie die meisten Engines teilweise auch noch bis heute mit den Assets und den verbunden Shadern umgehen. Viele dieser Shader werden bis heute quasi "on-the-fly" übersetzt - ist ja oft nicht viel Code. Bei wenigen Shadern funktioniert das sehr gut, nur wenn man dann heute in großen Open Worlds spielt, dann sind das halt viel mehr Shader, die übersetzt erden müssen und dann braucht das schon mal länger und das Stottern kommt zum vorschein.
Genauso, wenn das Vorausladen nicht "perfekt" funktioniert und man schneller unterwegs ist, als die Entwickler es angenommen haben.
franzerich schrieb:
Das hat erst irgendwann danach angefangen.
Angefangen hat es schon vorher, nur jetzt kann es nicht mehr kaschiert werden.
Vitche schrieb:
Wobei man bei PS5 und XBSXS natürlich anmerken muss, dass die im Endeffekt auch PC-Technik haben.
Die Softwareinfrastruktur ist heute oft das weitaus größere Problem, als die Hardware. Es ist komplizierter ein Programm von Windows nach Linux oder Mac OS zu schubsen, als innerhalb eines Softwareöko-Systems auf verschiedener Hardware zu programmiereren.
Ich hab schon damals zur PS4 und XBox One darauf hingewiesen, dass, nur weil jetzt PC-Hardware verwendet wird, die Probleme nicht abnehmen werden. Mit einer entsprechenden Hochsprache - und darunter fällt auch bereits ein C und C++ - und wenn auch die passenden Librarys und Frameworks vorhanden sind, muss man heute quasi nicht mehr ISA spezifischen Code schreiben und auch Fragen wie Big und Little Endian können moderne Compiler einem abnehmen, wobei viele Architekturen heute auch beide Modi unterstützen.
MrHeisenberg schrieb:
Indiestudios hauen keine Grafikkracher raus und die Grafik skaliert auch nicht linear mit dem Leistungshunger.
Das ist nicht wirklich der Grund. viele Indistudios und Indientwickler beschränken sich aber auf den Umfang der Grafikegines und programmieren nicht so Effekte und Shader hinein. Entsprechend gut laufen dann auch oft die Spiele, weil sie sich auf die wirklich optimierte Shader der Software-Ingenieure verlassen.
Taxxor schrieb:
Nanite sollte doch eigentlich dafür sorgen, dass der Leistungshunger für die Geometrie bei höheren Auflösungen weniger stark ansteigt, also das genaue Gegenteil bewirken, oder nicht?
Das kann man an der Stelle schwer so beschreiben. Wenn man es "grob" beschreiben will, ist Nanite ein LoD-System auf Steroiden, in dem es nur noch mit einem Asset arbeitet und anhand der Entfernung zur Kamera die unnötigen Polygone verwirft.
Die Stärke von Nanite ist auch nicht, dass der Leistungshunfer bei höheren Auflösungen weniger stark ansteigt, sondern dabei, dass man deutlich detailreichere Geometrie verwenden kann - egal in welcher Auflösung - und ohne dass der Leistungshunger explodiert.
Ein weitere Nebeneffekt ist, dass du dir weitere Modelle für das LOD sparen kannst, was am Ende auch den Speicherplatz zugute kommen kann.
Demon_666 schrieb:
Dauert die Entwicklung jedoch länger, kann es passieren, dass die Entwickler immer mehr Details, neue Techniken und Ideen einbauen wollen.
Das Problem ist viel eher, dass für gut optimierte Engines das entsprechende Know-How benötigst und solche Leute in der Regel weitaus angenehmere Jobs bekommen können, die auch besser bezahlt werden, als in der Spielebranche mit angenehmere Arbeitsbedienungen.
In der Spielebranche verdienst du als Dev zwar "gut" aber nicht so gut. Wenn du hier richtig gut bist, dann bekommst du ein Job bei AMD, NVIDIA oder Intel und wirst Projektweise zu Spielefirmen oder Engine-Entwickler "ausgeliehen". Bist du gut, kannst du bei Epic und Co anfangen, die noch eigene Engines entwicklen und bekommst auch in anderen Bereichen gut ein Job.
Bei den Studios und Co fängst du in der Regel nur an, weil du dann bewusst in diesem Bereich dann arbeiten willst.
Freiheraus schrieb:
Was ist denn mit dem Kombi den Radeons los? Die machen komplett Terroroor:
Ist doch schön, da zeigen die Karten mal, was in ihnen potenziell stecken kann.
![-=[CrysiS]=-](https://pics.computerbase.de/forum/avatars/m/542/542401.jpg?1532349185){kind=avatar}
, Streets of Rage 1-4. Mir fehlen noch genau drei die ich dann vielleicht in 10 Jahren schaffen werde. RE4R, AC:Mirage und Stalker 2
