Carsten Hölscher hat geschrieben:Es wird wohl erst recht unter Zusi 3 ein permanenter Kampf werden, die Textur- und Polygonmengen auf ein vernünftiges Maß herabzudrücken, und ich werde mir damit vermutlich nicht nur Freunde machen, aber da muß man durch...
Michael Poschmann hat geschrieben:Die dadurch gewonnenen Freiheitsgrade sollten aus meiner Sicht nicht durch allzu sorglosen, verschwenderischen Umgang mit Mesh-Zahlen und Bitmap-Größen konterkariert werden.
Michael Poschmann hat geschrieben:Da sekundiert mal der Streckenbauer: Bei der Erstellung der Anlagen sind ebenfalls strenge Selbstdisziplin und Augenmaß bei der Modellierung gefordert
Juppheidi, mein Lieblingsthema...
prinzipiell stimme ich den Aussagen, die hier zum Thema Performance gemacht werden ja zu. Natürlich sind die Ressourcen endlich und sollten nicht verschwendet werden. Ich bin auch vollkommen einverstanden mit dem LOD-Modell, was einige MSTS-Modellbauer trotz hochqualitativer Modelle und offenbar vorhandenem "Handwerkszeug" scheinbar bis heute nicht sind (bei anderen Simulatoren kann ich das nicht beurteilen). Auch wenn ich finde, dass das Aufwandsverhältnis zwischen "Vorwärts-Modellbau" mit allen Details und den anschließenden diversen Durchläufen des "Rückwärts-Modellbaus" für die niedrigeren Detailstufen nicht gerade günstig ist, ziehe ich das durch, damit alle was vom neuen Simulator haben können. Aber jedes Mal, wenn diese Diskussion hier losgeht, werde ich das Gefühl nicht los, dass bisweilen bei der Sparsamkeit übertrieben wird.
Meine eigenen 3D-Programmierungs-Experimente laufen aufgrund meiner beschränkten Zeit-Ressourcen auf ziemlich kleiner Flamme, von daher kann mich Carsten als Profi ja vielleicht korrigieren, wenn ich daneben liege. Ich möchte an dieser Stelle mal meine Meinung zu dem Thema festhalten:
Roland Ziegler hat geschrieben:Künstlerisches Talent ist für die Formengestaltung sicherlich erforderlich, ingenieurmäßige Ressourcenplanung aber für die Nutzbarkeit.
Roland Ziegler hat geschrieben:Aus der Perspektive des Ingenieurs ist mehr Leistung keine Entschuldigung für Ressourcenverschwendung.
Ingenieurmäßiges Arbeiten ist schön und gut, aber bei dieser Arbeitsweise macht man nicht einfach einen Schuss ins blaue, wenn es um die Rahmenbedingungen geht. Man arbeitet nach zum Fachgebiet passenden Normen, vielleicht nicht immer nach der neuesten Ausgabe, aber zumindest nach einem Stand, der im jeweiligen Fachgebiet etabliert ist.
Fakt ist, dass wir hier im 3D-Bereich nicht wirklich eine Norm haben, nach der man arbeiten kann. Ich (und das geht uns wohl allen so) habe schon das Ziel, im Bezug auf den Ressourcenverbrauch
vernünftige Modelle zu bauen, aber, um mal die von Roland verwendete Auto-Analogie zu verwenden, wenn mein Chef morgen ankäme und mir sagen würde, ich könnte mir einen
vernünftigen Firmenwagen auswählen, dann ist völlig offen, was wir beide uns jeweils darunter vorstellen.
Schaut man sich mit dem allwissenden Google um, was bekannte 3D-Engines unserer Zeit so auf den Bildschirm bringen, so fallen die Angaben für die Anzahl Polygone pro gezeichnetem Bild in den Bereich "viele Hunderttausend", auch bei Engines, die schon diverse Jahre auf dem Buckel haben. Mein Favorit hierbei ist die CryEngine, die fällt ja in den Bereich, den man in der HiFi-Welt "Referenzklasse" nennen würde. Ich hab da mal einen Screenshot gemacht:
Wir sehen hier also in 1680x1000 eine Szene, die aus 2,66 Millionen(!) Polygonen besteht, und trotzdem flüssig (25-27 fps) dargestellt wird, und das mit allen erdenklichen Extras. Soweit ich das sehen kann, verwendet Zusi keinen der ganzen tollen DX10- oder DX11-Effekte, die solche Szenerien so rechenintensiv machen. Und wenn ich mir diese Zahlen anschaue, und dabei bedenke, dass ich vor einiger Zeit mal ermittelt hatte, dass eine schräg-von-oben-Ansicht des kompletten Bahnhofs Altenbeken ca. 110.000 Polygone hatte (die Signale kamen bei ausgeblendeter Landschaft und ausgeblendeten Streckenelementen auf ca. 10.000 Polygone), und Zusi wegen keiner rechenintensiven Effekte noch bessere fps-Raten erreichen sollte, dann halte ich 50.000 Polygone für ein Fahrzeug durchaus für vernünftig (für LOD0 wohlgemerkt).
Nun ist die ganze Sache aber halt dummerweise hardware-Abhängig. Zu obigem Screenshot ist anzumerken:
- Der Rechner, auf dem das läuft, ist 1 1/2 Jahre alt.
- Die Grafikkarte in diesem Rechner (Radeon HD5870) kam vor 2 Jahren auf den Markt und kostet inzwischen < 200 Euro.
- Selbige Grafikkarte steckt in einem PCIe 2.0-Slot, eine Erfindung, die seit 5 Jahren am Markt ist.
- Die 3D-Engine ist ebenfalls bereits ein halbes Jahrzehnt alt.
Auch das finde ich eigentlich ganz faire Rahmenbedingungen. Ich sehe ja auch ein, dass man die trotzdem nicht überall vorfinden wird. Wenn ich das ganze Prinzip der Polygondaten- und Texturübertragung zur Grafikkarte richtig verstanden habe, dann werden Speicherbereiche der Grafikkarte in den Prozessraum des Engine-Prozesses eingeblendet. Unter der Annahme, dass jede 29,99 Euro-Grafikkarte inzwischen mindestens 512 MB RAM mitbringt (einige haben auch 1024 MB zu dem Preis, für nen Zehner mehr gibts die auf jeden Fall - habe gerade nochmal nachgeschaut...) und die reine Menge der Daten somit nicht das vordringliche Problem ist, dann müsste der große Flaschenhals ja die Übertragung der Daten über den Bus sein, an den die Grafikkarte angebunden ist. Selbst die billigsten Grafikkarten sind alle PCIe 2.0 x16, haben also eine Bandbreite von 8 GB/s. PCIe 2.0 ist jetzt auch schon 5 Jahre alt, PCIe 1.0 (max. 4 GB/s) gibt es seit 2004 zu kaufen. Bei noch älteren Rechnern kommt dann irgendwann AGP 8x (2 GB/s) und AGP 4x (1 GB/s) - womit wir dann auch im vergangenen Jahrtausend angekommen wären.
Die Landschaft kann auch schneller geladen werden, wenn man sie im Extra-Thread laden lässt, und hier kann eine Dual-Core-CPU mal ganz nützlich sein - ist auch schon seit 2006 populär (Intel Core Duo). Kann man das voraussetzen, oder muss man davon ausgehen, dass sich der Lade-Thread eine CPU mit dem 3D-Thread teilen muss?
Worauf ich hinaus will: alle üben sich hier in Vernunft und Selbstdisziplin, aber es wurde kein Performance-Ziel spezifiziert. Können wir nicht mal den Punkt festlegen, ab dem man im Bezug auf Alt-Hardware ganz klar sagt: von nix kommt halt nix? Ist das ein 4 Jahre altes System, oder 5 Jahre altes, oder 6 Jahre altes? Können wir so ein System nicht mal zusammenstellen, benchmarken und dann mal festlegen, was damit machbar ist und vor allem was damit nicht mehr machbar sein muss? Dann hätte man mal auf einen Nenner gebracht, was "vernünftig" beim Modellbau ist.
In diesem Zusammenhang ein Vorschlag: wäre es nicht möglich in der Demo die Performance-Counter der Grafikkarte einzuschalten und eine fps-über-Zeit Auswertung davon zu erzeugen, die dann an Carsten geschickt oder ins Forum gestellt werden kann, zusammen mit einem definierten Satz Hardware-Daten (CPU #Cores + Takt, RAM Menge + Geschwindigkeit, Chipsatz, Art der Grafikkarten-Anbindung, Modell der Grafikkarte)? Solange alle die selbe Strecke fahren, und die Demo wohl größere Verbreitung finden wird, könnte man damit vielleicht mal einen repräsentativen Hardware Spec-Durchschnitt bilden.
Zumindest wenn ich mir Texturen wie z.B. von der 218 oder dem Stellwerk in Altenbeken ansehe, also Objekte, von denen die Kamera nicht kilometerweit entfernt ist, dann frage ich mich schon, ob man sich mit dem Einsparen einer 2. Textur für diese Objekte oder speziell dieser Texturgröße nun so einen großen Gefallen getan hat.
machen![:]](./images/smilies/pleased.gif "Freude"){kind=small}
