Naitrael schrieb:
Hat nichts damit zu tun. Zu frühe Optimierung kostet mehr als späte.
Es sind meiner Erfahrung nach eher die weniger erfahrenen, die von Anfang an alles möglichst effizient machen wollen. Ob es sinnvoll ist oder nicht.
Premature Optimization kannst du vielleicht anbringen wenn einer seinen REST-Client auf 3 Milliarden Anfragen/s skalierbar gestaltet, ohne dass er einen einzigen Nutzer hat - aber nicht, wenn du von vornherein weißt, dass die Software
unausweichlich von der Hardware limitiert wird.
Bleiben wir doch beim Beispiel: Du sollst einen Service implementieren der
durchgehend von der verfügbaren Internet-Bandbreite limitiert werden wird. Baust du dann wirklich zuerst nach Lust und Laune und versuchst dann am Ende zu schauen, wie brauchbar das Ergebnis ist, oder trimmst du von Anfang die Architektur, als auch alle den Traffic betreffenden Teile auf Performance/Größe?
Naitrael schrieb:
Wie soll man die Performance testen, wenn die Models, Texturen oder gar Features noch gar nicht final sind?
Wie soll man denn Entscheidungen bezüglich Anzahl Polygone, Texturauflösung, Beleuchtungssystem, etc. treffen, wenn du keine Ahnung von der Basisperformance hast, und welchen Impact deine Entscheidungen auf diese haben? Du wirbst hier quasi für die Entwicklung auf gut Glück und ins Blaue hinein.
Und wie mans testet ist doch offensichtlich: Die Engine wird sich am Ende wenig darum scheren, ob deine Texturen nun Laminat darstellen oder ein buntes Checkerboard aus Photoshop sind. Gleiches gilt für Geometrie, gleiches gilt für die Beleuchtung. Eine Testszene mit Testressourcen zu erstellen sind was, 1PT-5PT? Jedenfalls nichts, was eine nennenswerte Delle bei einem großen Projekt verursacht.
Und selbst wenn man die Aussagekraft jener anzweifelt, dann muss man halt eine Szene in Gänze bauen, die einen typischen (besser noch anspruchsvollen) Case des Endprodukts (aus technischer Sicht) widerspiegelt. Blöd, aber sicher günstiger als ein Refactoring bei 80% Fertigstellung/die Auslieferung von Grütze zu riskieren.
Naitrael schrieb:
DLSS ist schon seit einiger Zeit keine reine Performance-Maßnahme mehr. Es spart einfach Arbeit ein, die an anderer Stelle vielleicht sinnvoller genutzt werden kann.
Was genau soll es denn sonst sein, außer vielleicht noch AA?
Und der zweite Satz sagt auf gut Deutsch nichts anderes, als das man sich nicht mehr an sauberes Arbeiten gebunden fühlt, weil DLSS am Ende regelt. Das "kann" am Schluss erinnert mich dabei an einen alten Witz:
---"Von dem Geld, das du bisher fürs Rauchen ausgegeben hast, könntest du dir einen Sportwagen kaufen!"
-"Rauchst denn du?"
---"Nein."
-"Und wo ist dein Sportwagen?"
Naitrael schrieb:
Würde beweisen, wie viel tatsächlich optimiert wird. Denn wie viele Beiträge alleine hier zeigen, haben nur wenige irgendeine Vorstellung davon, wie sowas gemacht wird und was es für Auswirkungen hat.
Was an sich ja nicht schlimm ist. Nur die Schlüsse, die aus diesem Unwissen gezogen werden, sind schon wild.
Also dann beantworte folgende Frage ganz konkret: Ist im Beispiel von Outer Worlds 2 das Spiel ein technisch gutes Produkt, mit seinen 45fps unter FullHD mit einer 5090? Vor allem, wenn es Gegenbeispiele wie Forza Horizon 5 gibt, bei dem du schon mit einer 5070 auf ~80fps kommst - in 4K, wohlgemerkt? Oder TLOU2/5070/4K/>50fps? Oder Cyberpunk 2077 PT/5090/FHD/~100fps?
Also wirklich ganz konkret: Ist es in deinen Augen technisch akzeptabel, dass ein Outer Worlds 2 (oder Äquivalent) nicht einmal halb so gut wie Cyberpunk mit vollem Pathtracing läuft? Letzteres kann tatsächlich sagen "Hey, DLSS und FG ermöglichen hier völlig neue Dinge." - Was ist das Gegenstück bei OW2, BL4, etc.?
Da können die den Code auch drei mal hoch und runter optimiert haben - Wenns am Ende trotzdem läuft wie ein Sack Nüsse, war und ist es offenkundig der falsche Ansatz.