Das bestätigt zumindest schon mal eindeutig, dass Objekte die nicht sichtbar sind, auch nicht unbedingt die Performance des FS belasten. Irgendwann fliegen die Information raus bzw. werden es später geladen.
Den nächsten Test hat Arno mit Sichtbeschränkungen bei den Objektwürfeln gemacht. Es wurden nur die Würfel in der Scenery sichtbar, die nicht weiter als 500 Meter entfernt waren.
Das bedeutet weniger sichtbare Objekte auch wenn man sich mitten in der Scenery befindet.
Arno hatte jetzt relativ konstante 17 Frames. Also besser als die 4 Frames ohne Sichtbeschränkungen bzw. die 10 bis 20 Frames bei Teilsicht auf die unbeschränkte Scenery.
In meinen Augen logisch ein anderes Verhalten wäre in meinen Augen auch tödlich für den FS.
Arnos Test spricht natürlich vom Sachverhalt gegen Vincent seine Feststellung, teilweise auch gegen Aqui seine.
Wir sehen die Problematik ist komplex.
Ich vermute, das Aqui und Vincent Ihre PC Systeme einfach an Ihre Grenzen gefahren haben.
Da ich zwei unterschiedlich leistungsstarke PCs habe, sehe ich es selbst anhand meiner Testscenerien immer wieder, wie unterschiedlich stark die Frames bei identischer Belastung bei beiden PCs zurückgehen.
Beim 3,4GHz Desktop brechen die Frames unter Last wesentlich stärker ein als beim Notebook mit 2,53GHz. Trotzdem liegen die Frames beim 3,4GHz wesentlich höher. Es ist halt ein Unterschied wenn die Frames von 85 auf 20 beim 3,4GHz einbrechen als wenn sie beim Notebook von 22 auf 17 zurückgehen.
Belastet man noch mehr, werden die Unterschiede im Grenzbereich noch geringer.
Ich denke Vincent und Aqui werden genau diesen Effekt der Extrembelastung gehabt haben.
Aqui sagt:
I'm working on a complex scenery with thousand of High Voltage towers and telephone poles.
Vincent spricht bei seiner Theorie von:
When there are thousands just keeping track of the ref points must add an enourmous amount of cpu calculations.
Aufgrund der Anzahl genannter ref points können wir auch bei ihm von Tausenden von Objekten ausgehen.
Normalerweise exitieren solche belastenden Scenerien mit tausenden von Objekten (bei hoher Dichte) im FS überhaupt nicht. Ausser beim reinen Autogencode. Bei den Autogenbäumen und Autogenhäusern handelt es sich aber auch um einen ganz anderen Objektcode. Der ist mit G-Max Objekten vermutlich überhaupt nicht vergleichbar.
Keine Ahnung wie dieser Autogenobjektcode genau definiert ist.
Ich denke aber nicht das es dort so viele Informationen wie bei den G-MAX Modellen mit Vertexlist, Polygonlist, Materialinformationen usw. gibt.
Eine Thematik bleibt, was belastet den FS mehr?
Die reine Anzahl der Objekte?
Die Anzahl der Polygone?
Wäre es überwiegend die Anzahl der Objekte anstatt der Polygone, dann würde das bedeuten, es wäre egal wie komplex die Objekte sind. Wir müssen nur dafür sorgen das es wenig Objekte sind.
In meinen Augen wäre das äußerst unlogisch.
Denn wenn es so wäre, dann würde ich mir doch als Airportdesigner meine Gedanken machen.
Ein Großairport muss aktuell wegen des AI Traffic auf dem Apron usw. eh waagerecht flach sein.
Da würde ich doch jetzt als Designer einfach auf die Idee kommen anstatt zwei einzeln stehenden Terminalkomplexen (ein Gebäude rechts, ein Gebäude links) einfach einen großen zusammenhängenden Terminalkomplex zu programmieren. Die rechte Hälfte ist sichtbar oberirdisch, die Mitte wird unsichtbar ins Mesh abgesenkt, die linke Hälfte ist wieder sichtbar oberirdisch.
So habe ich nur ein einziges Objekt programmiert. Das benötigt jetzt zwar mehr Polygone aber anstatt zwei Objekten existiert nur eines.
Ev. habe ich ja sogar Glück und die Terrainengine erkennt, dass ein Teil des Objektes im Mesh versunken ist. Die Grafikkarte freut sich, denn sie weis das sie mit diesen versunkenen Polygonen nicht arbeiten muss. Es müssen auch keine Texturen gerendert werden.
Tolle Sache. Warum nicht den ganzen Airport als ein einziges Monsterobjekt mit vielen tausenden Polygonen zeichnen.
Das würde die Frames doch theoretisch in die Höhe treiben. Der Super Addon Airport. Detailierter als alles andere was jemals da gewesen ist. Das ganze mit einer Performance die besser ist als jeder Kleinstairport wo nur eine Zapfsäule steht.
Ehrlich gesagt das kann nicht funktionieren.
Bezüglich Frames möchte ich allerdings diese Geschichte:
"Höhere Belastung durch Objektanzahl oder Polygonanzahl?"
nicht ganz von der Hand weisen.
Ich schliesse nicht aus, dass es hin und wieder gewisse Verschiebungen hinsichtlich Framebeeinflussung geben kann.
Das ganze bedingt dadurch wie diese Objekte oder nennen wir es 3D Information geliefert wird.
Mal wirkt sich die Anzahl der Basisinformationen etwas stärker aus, mal liegt der Schwerpunkt bei der Anzahl der Polygone.
Das ganze ev. auch etwas abhängig davon, was beim Anwender besser von der Performance ist. (Grafikkarte, CPU, RAM).
Es kommt hier darauf an wie die Technik der Informationen ausgelegt ist.
Ein Beispiel:
Ich erwähnte in einem anderen Thread wo es um das Thema Mesh geht, dass der FS z.B bei einem LOD 9 Mesh unter Manipulation des Parameter TERRAIN_MAX_VERTEX_LEVEL von 19 auf 21 im Nahbereich das LOD9 Mesh zusätzlich interpoliert. Die Polygonstruktur liegt obwohl das Mesh nur LOD9 hat jetzt wie bei einem LOD11 Mesh vor.
Das bedeutet wir haben bei identischen Mesh im Nahbereich sehr viel mehr darzustellende Polygone als vorher.
Die Performancelast steigt aber trotzdem nicht überdurchschnittlich an.
|