Also ich finde 10 frames mehr bei einer Standardrate von 30 schon viel und erstrebenswert.

Nichtsdestotrotz hat dein Test aber einen Haken: und zwar verwendest du dasselbe Modell und diesselbe Textur. Ein wirklich entscheidener Faktor ist nämlich der Texturoverhead den du da erzeugst, und deshalb ist dieser Test leider auch nicht repräsentativ.

Ich finde, das ist ein enormer Unterschied: Deine Entities verbrauchen im ersten Beispiel (32.7ms) exakt 50% mehr Berechnungszeit als im zweiten (21.1ms).

Großartiger Test der genau das zeigt was ich beschrieben habe Ein Unterschied von 10ms ist gigantisch viel, wenn man bedenkt dass man bei angestrebten 30fps nur 33ms hat, bzw 16ms wenn das Ziel 60fps sind, aber dann müsste man noch mehr Zeugs zusammenfassen und vermutlich noch mehr Engine spezifischen Kram optimieren .

Ich möchte noch Folgendes hinzufügen, was sich aus einem echten Projekt letztens hier ergeben hat: man hat genau dies auch versucht, also Modelle zusammenzufassen, um Geschwindigkeitsvorteile zu erhalten. Die hat man auch bekommen, aber nicht so sehr, wie man wollte. Neben fiesen Fehlern der Grafiker, die aus Mangel an Erfahrung resultierten, ergab sich aber auch folgende Problematik: und zwar hat man, wie eingangs erwähnt, Modelle zusammengefast.

Problematisch war dabei, dass halt auch skins gemergedt wurden, was dann dazu führte, das ein und diesselbe Texture mehrfach als skin vorlag. Selbst wenn man sie als extern markiert, war nicht klar, ob die engine das wegoptimiert oder ob da tatsächlich Zeit "draufgeht", beim rendering die texturen neu zu setzen - das ist kostspielig! Hinzukam, dass wir Modelle aus Modellpacks genommen haben, wo jedes Modell an sich schon (auch ohne Normal- und so weiter -maps) im Durchschnitt 3-5 Texturen hatte. Der ganz große Gau entstand dann, indem durch diesen Prozess sich ein Modell aus 25 (!) Tetxuren ergab, die FPS war echt.. zum Abgewöhnen.

Dafür kann aber die engine nichts, dass muss man klar sagen.

In solchen Fällen bieten sich klar Textur-Atlasse an. Ein gutes Beispiel ist z.B. ein Grassmodell, was ich bei Dexsoft gekauft habe. Dort besteht ein Grassmodell aus Dreiecken und die Textur ist quadratisch, geteilt in 4 Dreiecke mit jeweils unterschiedlichen Grastexturen. Wenn ich jetzt meine Welt mit Grass-Patches beflanze, kann ich wirklich sehr gut unterschiedliche Grasssorten mischen und dabei wirklich nur eine Textur --- in einem Modell! - und nicht z.B. 4 Texturen. Das gleiche gilt für Büsche und Blumen, da geht das auch, wunderbar!

Texturatlasse bieten sich insbesondere für Modelle an, die jedem Polygon einen exklusiven Bereich auf der Textur zuordnen; für gekachelte Texturen geht das auch, da muss man aber ein wneig tricksen und die Anzahl von mipmaps limitieren, um seams zu vermeiden.

@HeelX und Superku: Ich wollte damit ja nur zeigen, dass der Unterschied zwischen 600 Models und 6000 Models nur ca. 11 Frames beträgt. Hätten meine Models weniger Polygone (keine fast 2000 Polygone pro Model), und/oder eine kleinere Textur, dann würde das Ergebnis ganz anders aussehen. Dann hätte ich beispielsweise 200 FPS anstatt 211 FPS, und der Unterschied wäre dann nicht mehr so groß!
Ich hatte ja absichtlich die hohe Polygonanzahl und die hochauflösende Textur ohne Mipmaps gewählt, um die Framerate zu bremsen. Damit die Framerate unter der maximalen Framerate von meinem Monitor liegt (60 FPS).

Damit wollte ich ja nur zeigen, dass die Anzahl von 3000 Models mit sehr wenigen Polygonen (12 Polygone) kaum die Ursache für eine langsame Framerate sein kann. Außer es ist ein PC aus der Steinzeit.

Damit hast Du grundsätzlich recht. Aber bei dem Test ging es mir darum, ein Testbeispiel zu verwenden, das dem von Microtex am ehesten entspricht. Und ich gehe kaum davon aus, dass seine 3000 Würfel-Objekte, die dynamisch erstellt werden, alle unterschiedliche Texturen haben.

Abgesehen davon ist es sowieso technisch unmöglich, 6000 Models mit UNTERSCHIEDLICHEN HOCHAUFLÖSENDEN TEXTUREN zu 600 Models zusammenzufassen. Weil dann müssten die zusammengefassten Models eine gigantische Texturgröße haben, die technisch (noch) nicht möglich ist.

Aber natürlich sollte man, wo immer es geht, die Anzahl der Models so gering wie möglich halten, und falls möglich, mehrere Models zu einem einzigen zusammenfassen. Auch wenn man die Anzahl der dadurch eingesparten Frames auf einer Hand abzählen kann. Da habt ihr schon recht. Aber die hohe Anzahl der Models ist bestimmt kein Grund, warum aus einem sehr flüssig laufenden Spiel plötzlich ein kaum spielbares Spiel wird. Dafür müssen dann andere Dinge verantwortlich sein.

@ Harry Troller

Ich habe selber mit Microtex geredet und er hat mir erklärt wie er das Beispiel meinte.

Auserdem gibt es einen Unterschied wenn man einfach schreibt "leider werden Voxel-Modells nicht von der Atari engine unterstützt"
Oder Arogant und Sakastisch sagt "Wo bitte steht das im Hantbuch bla bla bla"

Desweiteren sehe ich über meinem Post 3 User die laut ihrer anzahl an Posts so wie Regestrierungs datum sehr viel Erfahrung haben und dir wiedersprechen also glaube ich mal den drei Usern.

Harry Potter, es wäre ziemlich cool wenn du deinen Test nochmal mit Modellen mit weniger Polygonen wiederholen würdest, denn dann würde das Ergebniss entgegen deiner oben geposteten Meinung nämlich noch VIEL deutlicher ausfallen.

Ich weiß nicht, ob dir das klar ist, aber ein Sprung von 200fps auf 210fps ist etwas ganz anders als von 30fps auf 40fps.

Um dein Spiel bei 200fps auf 210fps (beschränken wir uns nur auf Entities) zu beschleunigen, musst du deren Rendering von 5ms auf 4,76ms reduzieren. Da könnte es bspw. schon genügen, ein einziges Modell zu entfernen.
Wenn du nun aber aus 30fps 40fps machen möchtest, musst du das Rendering von 33,3ms auf 25ms reduzieren. Da musst du schon einen großen Teil der Modelle löschen, um den scheinbar gleichen Geschwindigkeitsboost zu erhalten.

Demnach hat die FPS Zahl kaum eine Bedeutung in Geschwindigkeitstest, betrachtet stattdessen die ms-Zahl des jeweiligen Bereiches (Modell-Rendering, Code, usw).

@TazTheDevil: Sorry, aber Deine Aussage war einfach so absurd, da konnte ich nicht widerstehen.
Das ist ungefähr so, als ob jemand sich beklagt, dass sein Auto nur maximal 140 km/h schafft, und Du gibst ihm dann den Rat, dass er sein Auto rot lackieren soll. Weil rote Ferraris sind ja schließlich auch sehr schnell. Und das hast Du dann offensichtlich auch noch ernst gemeint?! Mir war zunächst auch selbst nicht klar, ob Deine Antwort ernst gemeint war, oder nicht. Jedenfalls löste sie jede Menge Reaktionen aus ... angefangen mit "na das ist mal ne grundsolide Antwort", und viele weitere, ebenso absurde Aussagen.

Aber Du hast natürlich recht. Es war sarkastisch, und nicht nett von mir.
Also möchte ich mich bei Dir dafür entschuldigen. Tut mir leid.
Und jetzt Schluss mit trollen und spammen.

Naja, die fps Zahl hat schon die gleiche bedeutung wie die gesamt ms Zahl eines frames, man sollte dann aber wissen dass 1 fps unterschied bei 200 fps einen zeitlichen unterschied von nur 1/200 sec bedeutet, bei 10 fps dagegen einen von 1/10 sec. Entsprechend ist es in der Regel einfacher die Zeit statt die fps anzugucken.

Was übrigens die voxel angeht, ist das Problem dabei für Boxen einerseits überflüssiger Datenoverhead und andererseits löst es das Problem mit dem Rendern nicht, denn die Hardware ist auf Polygone ausgelegt und nicht auf irgendeine Form von Voxeldaten, was bedeutet, dass der effektivste Weg Voxel zu rendern mal abgesehen von vielleicht noch volumetrischen Texturen in einem Fullscreeneffekt über Polygone geht, so dass Voxel das eigentliche Problem nicht ändern würden und stattdessen nur weitere Probleme mitbringen.