Framerate

Hallo,

mir ist aufgefallen das immer wenn die Engine über 2000 Modells anzeigen soll die Framerate abstürzt. Die Modells haben 12 Polygone, welche Möglichkeiten gibt es das zu optimieren?

MFG

Die Anzahl der Polygone ist gar nicht soooo entscheidend für die Framerate. Eine viel größere Auswirkung hat die Größe(Auflösung) der verwendeten Textur. Mipmaps können da die Framerate deutlich erhöhen.

Edit: Zum besseren Verständnis:
Nehmen wir an, Du hast ein würfelförmiges Model, auf dessen 6 Seiten sich eine Textur befindet, die 4096x4096 Pixel groß ist. Die Engine (oder besser gesagt DirextX bzw. die Grafikkarte) muss dann also 4096 mal 4096 Pixel zeichnen, das ergibt über 16 Millionen Pixel, und das mal 6, da der Würfel ja 6 Seiten hat. Und das ganze dann noch multipliziert mit der Anzahl der Models, die auf dem Bildschirm zu sehen sind.

Wenn Du Mipmaps verwendest, dann werden Models, die weiter entfernt sind, nicht mit der maximalen Texturauflösung gerendert, sondern mit der kleineren Mipmap. Je nach Entfernung mit einer Auflösung von jeweils einem Viertel der Pixel. Also 2048x2048, bei noch größerer Entfernung dann 1024x1024, 512x512, usw. usf.! Mipmaps haben außerdem den Vorteil, dass die Textur von weit entfernten Objekten nicht flimmert (da die kleineren Mipmaps ja immer unschärfer werden).

Die Anzahl der Entities spielt aber eine große Rolle.

Wenn Du Dein Projekt etwas genauer schilderst, kann man eher Vorschläge machen wie und wo es sich optimieren lässt.

So, ohne Dein Projekt zu kennen, würde ich vorschlagen, die Modelle, die weiter entfernt sind, zu wenigeren Modellen zusammenzufassen.

ich bin noch Gamestudio Neuling und man sieht es ganz gut wenn man im Physics Sample mehr Würfel und Kugeln erzeugen lässt die ja nichtmal einen Skin haben.

Da hast Du doch die Lösung.
Wenn jeder dieser Würfel physikalische Eigenschaften zugewiesen bekommt, stößt das wahrscheinlich den Rechner schlicht an seine Grenzen.
Drück mal die Taste F11, da werden die einzelnen Kompenenten aufgelistet und angezeigt, für was die Engine jeweils wieviel Rechenzeit benötigt.

Öhm, nee...
Es müssen nur die Pixel gezeichnet werden die auch von dem gerenderten Objekt im Rendertarget eingenommen werden plus noch Overdraw bei manchen sich eigentlich verdeckenden Polygonen, den es im Fall des Würfels dank Backface Culling aber nicht gibt. Für die nun tatsächlich zu zeichnenden Pixel kennt die Grafikkarte die entsprechende Position auf der Textur (die ja beim Modellieren in der UV Map landen sollte). Hier kann nun die entsprechende Farbe aus der Textur herausgelesen werden. Je nach Einstellung wird dabei immer die Farbe des entsprechenden Pixels genommen, oder zwischen den Pixeln interpoliert. Wenn nun Mipmaps genutzt werden, dann ermöglicht es der Grafikkarte einfach nur die Texturdaten effizienter in den Speicher zu packen, was wiederum das samplen (das "auslesen der Pixelfarbe") beschleunigt.

Das Problem in diesem Fall ist dagegen wie Achim schon geschrieben hat, die hohe Anzahl an Objekten plus vermutlich noch die Physik. Von daher ist davon auszugehen, dass einfach nur die CPU nicht schnell genug ist um mehr Objekte zu handlen. Hier müsste man jetzt profilen um herauszubekommen ob das Problem die Drawcalls oder etwas anderes sind und davonabhängig könnte man dann optimieren, wenn man denn den Engine Sourcecode hätte... Bzw je nach ergebniss dann auch ein einzelnes großes Mesh aus den einzelnen Objekten generieren, was dynamisch aber eher zu langsam ist.

Von daher ist die Lösung hier wohl einfach akzeptieren und sich mit den Grenzen zu arrangieren .

Ich möchte noch hinzufügen, dass es generell nützlich ist, keine großen Texturen zu verwenden, wenn möglich... unkomprimierte 4096x4096 RGBA Texturen sind ja schon alleine 64MB groß und dann muss man das jeden frame den Flaschenhals hinunterstopfen... ist doch klar, dass da die framerate flöten geht.

Eine gute Faustregel ist es, mal zu gucken, wie groß ein Objekt in der Standardauflösung (nicht die Höchste!) auf dem Bildschirm überhaupt werden kann und dann davon abzuleiten, wie groß man die Textur wählt. Dann als DDS verpacken, das macht sie kleiner im Speicher und ist schneller zu laden. Wenn man weiß, dass eine Textur nicht weniger als so-und-so-viele Pixel einnimmt, dann kann man sich sogar Mipmaps sparen im DDS-Generierungsprozess.

[EDIT] Beispiel: wenn meine Standardauflösung 1280x1024 ist und ich feststelle, das ein Character z.B. nie mehr als 1/8 des Bildschirms einnimmt, dann sind das in etwa (1280x1024)/8 = 163840, mal 2 weil ich den ja von vorne und hinten sehen kann, macht dann 327680 Pixel, geteilit durch ne 2er Potenz macht dass dann in etwa 512x640 Pixel, da kann man sich dann aussuchen ob man 512x512 oder 512x1024 nimmt, je nachdem ob man es schafft, gleiche Texturteile mehrfach zu verwenden oder nicht.

Guter Test für das von Christian beschriebene, ist einfach mal eine einfarbige 4096x4096 Textur mit Mipmaps in jeweils einer anderen Farbe zu nehmen und diese über alles zu legen. Davon abhängig wo man dann welche Farbe sieht kann man dann die Texturauflösungen wählen.

Ja, stimmt, wobei du dich dabei dann aber auf quadratische Texturen festlegst, ich würde auch 1:2 Texturen testen

Man kann Texturen mit unterschiedlich gefärbten Mipmaps gut mit den NVidia DDS Tools herstellen, da die des gestatten mehrere DDS Dateien als Mipmaps zu einer Textur zusammenzufügen.

Hi

also bei dem problem mit den frames hilft dir vielleicht ein Voxel model
habe mal gelesen das diese insovern sie nicht all zu komplex sind wesendlich weniger belastung für den rechner darstellen aber dafür ein wenig mehr arbeitsspecher brauchen.

mfg

na das ist mal ne grundsolide Antwort.

@TazTheDevil: Hmmm ... auf welcher Seite im Gamestudio-Handbuch sind die "Voxel models" beschrieben?

har har har.
was ist hier jetzt ironie und was nicht? -.-

Aber ein Voxel hat doch genauso viele Pixel wie ein 3D Modell?

Die Frage ist: an welcher Stelle hatte die Ironie begonnen?
(möglicherweise schon gestern um 19:06? Aber wenn man sich das Registrierungsdatum und die Anzahl Posts der User ansieht, dann höchstwahrscheinlich erst heute um 10:34 ).

Anstatt eines Voxel-Models könnte man aber auch ein Pixel-Model verwenden. Das hat dann nur einen Pixel.

Edit: Das würde dann im Spiel so aussehen:

Aber es gibt doch 16,7 Millionen Pixel pro Bildschirm. Mein Rechner kann in C# nur innerhalb von 20sekunden bis 1 Million zählen, dann hätten wir doch ne viel zu hohe Framerate? o.O

Ne viel zu hohe Framerate wär doch cool wäre auch nen guter Spruch fürs Marketing ^^

Crysis 3 - Jetzt mit einer viel zu hohen framerate!

Daher am besten nur meine oben erwähnten 1-Pixel-Models in Spielen verwenden. Diese Spiele laufen dann sogar auf Bildschirmen, die nur eine Auflösung von 1x1 Pixel haben. Dafür aber dann extrem flüssig mit einer gigantischen Framerate von über 16 Millionen FPS!!!

Aber das menschliche Auge kann doch sowieso nur bis 1080 FullHD Frames unterscheiden, alles andere ist doch zu schnell?!

Kann man nicht noch was mit 3D Machen?

16700000 / 1080 = ca.15462

Kann man nicht 15462 3D Ebenen machen, Die auf einen zufliegen? Alle in unterschiedlichen Farben, sonst verliert man doch die Orientierung. Und alle random(1)-10 Sekunden sollte jede Ebene einmal im Vordergrund sein, sonst vergisst man die ja.

Trolls trolling trolls trolling trolls... Sind wir hier auf 4chan oder was ist auf einmal los?! oO

Nein das ist nicht zufällig genug. Du musst so rechnen:

var meineZufallszahl = sqrt(pow(random(random(125+random(1)*896)) - (sin(random(360)) + cos(random(360))) * random(360), (int)random(512)));

@JustSid: Bitte hier nicht spammen! Hier geht es um Frameraten!!!
Zumindest das Wort "Framerate" hättest Du in Deinen Satz einbinden können.

Warum so kompliziert?
Reicht es denn nicht aus, wenn man random(1) mit 2 mulitpliziert? Dann hat man zumindest den DOPPELTEN Zufall.
Oder man könnte den Zufall mit dem Zufall multiplizieren ( random(1) * random(1); ). Dann hätte man WAHNSINNIG VIEL Zufall. Das müsste dann eigentlich ausreichen?!
Schade nur, dass es keine Variable für Unendlichkeit gibt. Weil dann hätte man einen unendlichen Zufall.

var unendlich = unendlich + 1;

Damit ist unendlich immer eins größer als davor und weil Das nie aufhört, ist es Unendlich (bitte in anderen Thread auslagern!)

Übrigens könnte man um zum Ausgangspost zurück zu kommen, wenn jedes Modell eine Box gleicher größe ist, das einfach als einen Voxel definieren, der jeweils eine Position und Rotation und Material mit Textur hat und an dieser Stelle mit den entsprechenden Eigenschaften eine Box platzieren. Marching cubes ist in dem Fall wohl eher unpassend. Was aman aber natürlich gut machen könnte, ist die Voxel dann alle zusammen in ein Mesh zu packen. Eine andere alternative die sicher sehr spannend wäre, ist das ganze mit Raymarching und ohne Polygone zu rendern, das lässt sich durch generieren einer Depthmap, was sich im Fall von Cubes mit bisschen Mathe lösen lassen sollte recht effektiv umsetzen, soweit ich weiß.

Ahja, aber eine wirklich hilfreiche Antwort hat eigentliche keiner von euch auf lager gehabt. wie z.b. "ja Voxel Modelle sparen oder sparen keine FPS ein"
Respekt das ist fachwissen und Hilfsbereitschaft (Wow Prinzip)

naja vielleicht war meine Frage einfach zu schwierig, also noch einen Versuch.

Ich beschäftige mich erst seit wenigen Monaten mit dem Gamestudio und ich wollte eigentlich nur wissen, wieso bei einer hohen Anzahl von ganz einfachen Körpern (etwa 3000) wie Kugeln oder Würfel ohne Skin die Framerate einbricht und was für Möglichkeiten es gibt sowas zu optimieren. Es wurden ja schon die Voxel angesprochen, aber wie sieht dort die Vorgehensweise aus, wird sowas mit Sprites oder mit eigenen Programmen realisiert?

MFG

Vergiss Voxels. Versuch einfach mehrere Modelle in ein großes zu packen, das sollte helfen. Vlt. hat ja einer von den Trollen dort oben Lust dir genauer zu erklären warum viele Modelle langsamer gerendert werden.

Ein guter Anfang wäre es meine Posts zu lesen...
Problem:

Antwort:



Problem:

Antwort:

@Microtex: Vergiss all den Voxel-Unsinn, der hier geschrieben wurde.
Die richtige Antwort hatte Dir bereits Pappenheimer am 25.09.2011 um 21:51 Uhr gegeben.

Dein Problem liegt nicht beim Rendern der 3000 Objekte (3000 Models gleichzeitig darzustellen sollte normalerweise kein Problem sein), sondern es liegt an den PHYSIK-BERECHNUNGEN für all diese Objekte. Physikberechnungen, für so viele Objekte gleichzeitig, überfordern fast jede heutige Hardware.

Du musst also einen Weg finden, die Physik-Berechnungen zu optimieren (z.B. nur für diejenigen Objekte berechnen lassen, für die es wirklich gerade notwendig ist).

Kann nicht einmal jemand meine posts lesen? -.-
Ich gehe einfach mal davon aus, dass der Verfasser dieses Threads nicht so naiv ist und glaubt dass 3000 einfache Objekte die mit einander einiger maßen physikalisch kollidieren flüssig laufen. Entsprechend gehe ich davon aus, dass diese 3000 Objekte auch ohne Physik der Performance schaden und genau das erscheint mir nicht so falsch. Denn das Problem liegt beim CPU Overhead der beim Aufruf der fürs Rendern nötigen Funktionen existiert. 3000 einzelne Objekte die mehr oder weniger alle gleichzeitig sichtbar sind, sind einfach viel zu viele. Ein besserer Ansatz sind vielleicht 50 - 200 gleichzeitig für die gesamte sichtbare Umgebung mit zusammen meinetwegen 500000 Polygonen plus noch maximal 50 dynamische Objekte, die mehr machen als bisschen im Wind zu wehen, was sich sehr gut mit einfachen Shadern zum Beispiel lösen lässt.
Ich hab das in diesem Forum allerdings schon gefühlte 100 mal gepostet und irgendwie hat es noch nie jemand mitbekommen...

Ich habe Deine Posts gelesen. Aber Du hast offensichtlich die Posts von Microtex nicht richtig gelesen?

Das hat nichts mit Naivität zu tun, sondern mit Praxiserfahrung bei der Spieleprogrammierung.
Und da Microtex erst seit ca. einer Woche hier im Forum registriert ist, und bisher nur 3 Beiträge geschrieben hatte, gehe ich mal davon aus, dass er ein Neuling ist, der sich noch nicht so gut auskennt. Außerdem schreibt er ja selbst "ich bin noch Gamestudio Neuling".

Und er wäre nicht der erste hier, der glaubt, dass man mit Gamestudio ganze Städte aus tausenden von Ziegelstein-Models bauen kann, die dann auch physikalisch korrekt zerstört werden können.


Wie ich schon oben geschrieben habe, liegst Du da aber falsch. 3000 einzelne Objekte sind überhaupt kein Problem.

In meinem Testlevel für mein Spiel (hier ein Screenshot) verwende ich sogar 4580 Objekte! Und mein Testlevel läuft absolut flüssig bei weit mehr als die 60 FPS, die mein Monitor wiedergeben kann. Und selbst wenn ich meinen Level von oben betrachte, sodass sämtliche 4580 Models gleichzeitig zu sehen sind, dann habe ich immer noch eine Framerate von ca. 40 FPS! Und das, obwohl ich einige Models verwende, die mehr als 10.000 Polygone haben.

Und Microtex schrieb, dass seine 3000 Models nur 12 Polygone haben (sind daher wahrscheinlich Quader oder Würfel). Deshalb schrieb ich, dass weder die Anzahl der Models, noch die Anzahl der Polygone ein Problem sein kann. Außer vielleicht auf extrem langsamen PCs.

Entscheidend sind natürlich auch noch andere Faktoren: zum Beispiel, ob eine Function/Action hinter jedem einzelnen Objekt hinterlegt ist, und wie rechenintensiv das Coding dahinter ist. Oder ob die Kollissionsprüfung für die Objekte aktiviert ist oder nicht, ob Schatten berechnet werden müssen oder nicht, etc. etc.!

Das Entscheidene ist, dass wenn ich 1 mio Polygone in 3000 Modellen rendere oder 100k in 3000 Modellen, wird es mit einer aktuellen Grafikkarte kaum einen Geschwindigkeitsunterschied geben. Wenn ich dagegen die 1 mio Polygone in 100 Modellen rendere wird es vermutlich schneller sein als die 100k Polygone in 3000 Modellen. Und ja, mit einer schnellen CPU sind auch 5000 Objekte noch machbar, wenn ich aber jetzt womöglich noch Schatten und reflektierendes Wasser haben möchte bin ich plötzlich schon bei ca 20k Objekten und das ist nicht mehr wirklich akzeptabel schnell.
Wenn ich also den Bottleneck, was im Fall von 3000 Modellen mit wenig Polygonen die CPU ist, selbst ohne aufwändiges drumherum, dann macht es durchaus Sinn die Anzahl der Objekte zu reduzieren, was dann auch wieder Kapazitäten für andere aufwändigere und unverzichtbare Dinge bringt.


Ich habe die Posts durchaus gelesen und hatte den Eindruck, dass Microtex eher nicht zu denen gehört .

@Slin Die Lösung kommt wohl wirklich noch am ehesten an das Problem da es sich nur um Würfel immer gleich bleibender Größe handelt die eine Textur besitzen sollen.



allerdings da ich Neuling bin ist das ganze bis jetzt eher unverständlich. Wie definiere ich also ein Voxel was jeweils eine Position eine Rotation und ein Material mit Textur hat.

MFG

Sry, das war lediglich der Versuch das Niveau des Trollens etwas zu heben. Denn das ist dann nichts mehr anderes als was du sowiso schon machst.
Was genau versuchst du denn zu erreichen, was passiert mit den Boxen? Wenn du das erklärst lässt sich dein Problem vielleicht lösen.

ich glaube um Niveau muss man sich in diesem Thread keine Gedanken mehr machen. Mein Problem lässt sich vielleicht lösen wenn du mir deinen Eintrag erklärst, oder mir zumindest sagen kannst ob es eine Anleitung dafür gibt und wenn es außer blöde Troll Kommentare hier nichts mehr gibt dann kann der Thread auch geschlossen werden bevor wieder die unendliche Zufälligkeit kommt.

Beantworte das einfach, das was ich da geschrieben hatte bringt dich nicht weiter, denn wie gesagt, ist das nichts anderes als das was du schon machst in dem du einfach 3000 Boxen erstellst.

Das mit den Phsysiks-berechnungen kann man gedrost in den Müll kloppen. die Blöcke sollen keinerlei Physikalische eigenschaften besitzen.

Stellen wir uns eine Fläche von 6000 Blöcke vor, jeder Block besitzt die maße 16x16x16 Pixel.
Texturen sind in dem Beispiel nicht vorhanden, bei dieser Anzahl von Blöcken bemerkt man schon eine sinkende Framerate.

Ich ging immer davon aus das die heutige Hardware in der lage ist so etwas ohne großen verlust an frames berechnen zu können.

Mir wurde dann gesagt das ein Voxel Modell wohl weniger Leistung braucht da man wenn ich es den dann richtig verstanden habe nur (im falle eines würfels) 6 Sprites per Koordinaten zu einem würfel verbindet.

Dieses mal bitte kein getrolle für warscheinliche Informationsfehler

MFG

Bist du an einem Spiel wie Minecraft interessiert? Wenn ja, dann muss ich dich enttäuschen und das ist der falsche Ansatz. Minecraft rendert auch nicht tausende Blöcke, sondern fast 16x16x16 (? vllt auch größer) Blöcke zu einem großen zusammen, erstellt daraus dynamisch ein einziges Mesh und rendert dieses. Das hat zur Folge, dass viel weniger Objekte auf Sichtbarkeit geprüft und viel weniger Informationen zur Graka geschickt werden müssen.

@Slin: Es ist grundsätzlich schon richig, dass das Rendern schneller ist, wenn man mehrere Models zu einem einzigen zusammenfasst. Aber der Unterschied ist eher minimal.

Wenn ich Microtex richtig verstanden habe, dann bringt ihm das doch nichts. Weil jedes einzelne seiner Objekte soll sich doch physikalisch korrekt bewegen können. Also braucht er UNABHÄNGIGE einzelne Objekte.
Zumindest habe ich das so verstanden, weil er geschrieben hatte: "und man sieht es ganz gut wenn man im Physics Sample mehr Würfel und Kugeln erzeugen lässt die ja nichtmal einen Skin haben".

Für mich klingt das so, als ob er in irgendeinem Physik-Demoprogramm einfach die Anzahl der Physik-Objekte erhöhen wollte. Und dabei ist die Engine an ihre Grenzen gestoßen. Das hat dann also mit dem Rendern nichts zu tun, sondern mit der Physik.

Aber am besten wäre es, wie Du bereits gesagt hast, wenn Microtex sein Problem genauer erklärt. Und eventuell auch das Programm hier hochlädt, damit man die Ursache analysieren kann.

Die Troll-Kommentare bezogen sich eigentlich auf den Voxel-Unsinn, den TazTheDevil am 29.09.2011, um 19:06 Uhr geschrieben hatte. Seine Aussage war ungefähr genauso sinnvoll, wie wenn er geschrieben hätte, dass sich Dein Problem mit Sauerkraut und Knödel lösen lässt. Wobei er es vermutlich ernst gemeint hatte, weil er das mit den "Voxel-Models" irgendwo aufgeschnappt hatte. Jedenfalls half Dir diese Information kein bisschen weiter, und in Folge kamen dann, um sich über seinen Kommentar lustig zu machen, weitere genauo sinnlose Kommentare.

Die Kommentare ab 1.10.2011, 18:28 Uhr, kannst Du dann wieder ernst nehmen.

Wow
Respekt also Harry potter schaft es immernoch nicht zu kappieren das es keinerlei Physik für die Models geben soll, Microtex gab nur das physiks sampel an weil dort auch viele modele generiert werden die dann bei steigender zahl die framerate fressen totz fehlender Textur(vielleicht hat er da das falsche beispiel genommen).

Desweiteren bin ich immer noch begeister davon das Harry Troller sich zwar über meinen vorschlag mit dem Voxel lustig machen kann aber es dennoch nicht schaft zu erklären (und zwar Troll frei so wie verständlich) warum es mit Voxel unsinn wäre.
(In Youtube exsistert ein Video wo der User Voxel benutzt um 8 mio Blöcke gleichzeitig darstellen zulassen und eine Framerate von über 60 FPS zu halten)

@Superku

Ja Minecraft kann man in dem fall wohl als Beispiel verweden,
kannst du uns genauer erklären was du damit meinst? das er aus den blöcken einen großes Modell macht?
Wenn ich dich jetzt richtig verstanden habe meinst du damit das er aus den Blöcken einen Chunk erstellt und diesen dann Rendern lässt?
ist das so richtig?

Falsch. Der Unterschied kann enorm sein. Vor allem, wenn es sich um viele low-poly Modelle handelt. Ob es nun eine Option für Micro darstellt oder nicht, sei erstmal dahin gestellt.
Off-Top: Wäre btw. nett wenn du deine Posts (wenn nicht ganz doll lang) nicht mehr auf 2 aufsplitten würdest...iwie stör´ mich daran-.-

@Taz: Natürlich kann man für statische Geometry Voxels zum rendern verwenden, wenn es sich anbietet. Nur muss man diese Technology erstmal implementieren. Das stellt auch für einen sehr erfahrenen Entickler viel Arbeit dar. Vieeeel. Ich kann ein Stück weit verstehen warum Anfänger immer nach neuer Technology fragen (hatte ich mir zu Beginn ja auch immer wieder gewünscht). Aber letztendlich sind diese nicht ausschlaggebend dafür ob ihr ein gutes Spiel entwickelt oder nicht. Ihr habt mit GS ein Tool, welches all eure Anforderungen erfüllen sollte. Wenn nicht, müsst ihr eure Ansprüche überdenken.

@Hummel

Danke endlich mal ne Antwort mit verständlichem Inhalt.

Wenn ich das jetzt richtig verstehe sind Voxel-Modelle nicht mit dem GS-a8 kompatibel B.z.w müssten erst wie du schon sagtest in die Enging implementiert werden?

http://www.opserver.de/ubb7/ubbthreads.php?ubb=showgallery&Number=369996#comments

http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=342592#Post342592

http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=384321#Post384321

@TazTheDevil: Und woraus schließt Du das? Microtex hatte geschrieben, dass das Problem auftaucht, wenn er "im Physics Sample mehr Würfel und Kugeln erzeugen lässt". Danach hat er sich nicht mehr zu Wort gemeldet. Also schließe ich daraus, dass Physik hier eine große Rolle spielt.

Das wissen wir erst, wenn es Microtex selbst beantwortet. Alles andere sind nur Mutmaßungen.

Erstens ist mein Name "Potter", und zweitens habe ich Dir einen Hinweis gegeben, warum es Unsinn ist. Wenn Du es nicht verstehst, kann ich ja nichts dafür. Der Hinweis war: "auf welcher Seite im Gamestudio-Handbuch sind die "Voxel models" beschrieben?".

Und falls Du es immer noch nicht verstanden hast, hier die Antwort:
Es ist aus folgenden Gründen Unsinn:
1.) Weil Gamestudio keine Voxel-Models unterstützt. Klar, wenn jemand ein sehr erfahrener Programmierer ist, kann er soetwas auch selbst implementieren. Die Frage ist halt, ob das dann auch wirklich von der Performance her optimal wäre.
2.) Voxels sind eine Technik, um Volumen zu simulieren. Das macht Sinn bei z.B. Landschaften, oder organischen Formen, die als herkömmliche Polygon-Models sehr sehr viele (hunderttausende oder millionen) Polygone hätten . Bei einzelnen würfelförmigen Objekten, macht das keinen Sinn.
3.) Es gibt kaum etwas, was schneller gerendert wird als ein Model mit nur 12 Polygonen. Hier eine andere Technik zu verwenden, wäre auf jeden Fall von der Performance her schlechter.

Damit wir hier nicht herumraten müssen, welche Auswirkung die Anzahl der Models auf die Framerate hat, habe ich mal einen Test gemacht.

Dazu hatte ich zwei Testlevels erstellt:

1.) Ein Testlevel mit sehr sehr vielen Models:
- Jedes kugelförmige Model hat 1.890 Polygone.
- Die Textur hat eine Auflösung von 2048 x 2048 Pixel.
- Die Gesamtanzahl der sichtbaren Polygone liegt bei ca. 1,5 Millionen. Die Models verwenden keine Shader, und sind auf UNLIT gesetzt. Also "reine" Polygone.
- Es gibt im Level 6.000 von diesen Models.

Die Framerate schwankt dabei zwischen 30 FPS und 32 FPS. Ist also immer noch sehr flüssig.
(Hier ein Screenshot vom ersten Test)


2.) Diesmal wurden jeweils 10 Kugeln zu einem einzigen Model zusammengefasst.
Die Anzahl der Models wurde also auf 10% reduziert:

- Jedes Model, bestehend aus 10 Kugeln, hat 18.900 Polygone (10 mal so viel wie im 1.Test).
- Die Textur hat eine Auflösung von 2048 x 2048 Pixel (genauso wie beim 1.Test).
- Die Gesamtanzahl der sichtbaren Polygone liegt bei ca. 1,5 Millionen (genauso wie beim 1.Test)
- Es gibt im Level nur noch 600 Models (um 5.400 Models weniger als im 1.Test).

Die Framerate schwankt dabei zwischen 43 FPS und 47 FPS. Ist also nur um ca. 11 bis 17 Frames schneller als im ersten Test.
(Hier ein Screenshot vom zweiten Test)

Das meinte ich damit, als ich sagte, dass die Anzahl der Models kaum eine Rolle spielt, und dass die schlechte Framerate nicht an den 3000 Models mit jeweils 12 Polygonen liegen kann.

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.

Das Problem ist, dass dann die Framerate höher als 60 FPS ist.
Und dann wird immer eine Framerate von 60 FPS angezeigt, weil das die maximale Framerate meines Monitors ist.
Oder hast Du eine Idee, wie man das umgehen kann?

Edit: Ich glaube mal gelesen zu haben, dass man die FPS-Sperre (maximal 60 FPS) bei ATI/Radeon-Grafikkarten umgehen kann, nicht jedoch bei NVIDIA-Karten?!? Oder gibt es da irgendeinen Trick?

Der Trick ist einfach, den Test nicht im Vollbild-Modus laufen zu lassen, in welchem die Frequenz deines Monitors die FPS begrenzt, sondern im Fenster - dort ist die FPS "unbegrenzt".

Ich bin mir nicht ganz sicher, aber ich glaube im Fall von Gamestudio wird für das V-Sync die Einstellung im Grafikkartentreiber übernommen. Ansonsten sollte es irgendwie auch beim start setzbar sein, was aber eventuell nicht mit Gamestudio standard Zeugs möglich ist. Für Rage wurde allerdings auch eine Möglichkeit in die Treiber implementiert das ganze zur Laufzeit zu ändern, so dass bei einem fps drop unter 60fps das V-Sync abgeschaltet werden kann, was dann zwar zu ein paar Artefakten führt, dafür aber keinen fps drop auf 30 bewirkt obwohl es eigentlich 59 sein könnten.

Edit: Okay, im Fall von Gamestudio scheint V-sync im Vollbild immer an zu sein und im Fenster kann es sowiso nicht an sein.

Der Fenstermodus ist der absolute Wahnsinn!
Anstatt 30 FPS im Vollbildmodus habe ich jetzt plötzlich nur noch zwischen 5 und 8 FPS im Fenstermodus. Und das, obwohl die Auflösung kleiner ist als im Vollbildmodus.
Ich denke, im Fenstermodus kann man keine brauchbaren Performance-Tests machen.

Hm wie kann das denn sein, hab noch nie erlebt bzw. kann mir auch keinen Grund überlegen, warum die FPS im Fenster geringer sein sollten...

Ja echt, das ist schon komisch!

Ich habe jetzt die 6000 Kugel-Models (fast 2000 Polygone je Kugel) durch Würfel-Models (12 Polygone) ersetzt.
Allerdings bleibt die Framerate im Fenstermodus auf niedrigen 41 FPS. Und im Vollbildmodus wird auf die maximal 60 FPS des Monitors begrenzt. Also ich fürchte, so kann ich kein brauchbares Testbeispiel erstellen.

Dass der Fenstermodus langsamer ist als der Vollbildmodus, hatte ich schon vor langer Zeit bei der A5 bemerkt (damals noch ein anderer PC). Seither hatte ich den Fenstermodus daher nie verwendet. Bin aber auch überrascht, dass der Unterschied soooo groß ist (8 FPS anstatt 30 FPS).

Fenstermodus hat einen gewissen Performanceverlust da dann noch mehr drumherum gehandled werden muss, der bei Vollbild wegfällt. Das sollte aber recht konstant sein und von daher ist es im Fenstermodus trotzdem ganz gut vergleichbar.

So krass sollte der Unterschied trotzdem nicht sein. Da stimmt definitiv iwas nicht. Die Erfahrung hab ich noch nie gemacht...

Hier als Beweis ein Screenshot:
Test Nr. 2 im Fenstermodus

Das ist der selbe Testlevel von oben, allerdings im Fenstermodus. Sogar mit einer wesentlich geringeren Bildschirmauflösung von 800x600 Pixel!

Erster Testlevel von oben:
Vollbildmodus: 43 bis 47 FPS
Fenstermodus: 15 FPS

Zweiter Testlevel von oben:
Vollbildmodus: 30 bis 32 FPS
Fenstermodus: 5 bis 8 FPS

Wenn ich die Kamera ins Nichts drehe, sodass kein einziges Model sichtbar ist, bekomme ich im Fenstermodus eine Framerate von 490 bis 500 FPS.

Okay, ich habe herausgefunden, wo das Problem liegt.
Die Bremse heißt WED.

Wenn ich den Level vom WED aus starte, habe ich eine Framerate von 15 FPS. Starte ich den Level jedoch vom SED aus, dann habe ich plötzlich 88 FPS!

Werde jetzt dann zwei neue Tests machen (mit wenigen Polygonen), und diesmal das Programm vom SED aus starten.

@Slin: Ich habe jetzt ein paar neue Tests gemacht.
Das Ergebnis überrascht mich, zeigt aber, dass Du recht hattest. Bei wenigen Polygonen und sehr hoher Framerate ist der Unterschied noch größer.

Hier das Ergebnis:

Bei sämtlichen Tests wurden würfelförmige Models verwendet. Und eine sehr kleine Skin von nur 256 x 256 Pixel.
Die Ausführung des Programmes erfolgte im Fenstermodus, bei einer relativ geringen Bildschirmgröße von 1024x768 Pixel.

Allerdings habe ich festgestellt, dass im Fenstermodus andere Programme, die im Hintergrund laufen (z.B. der WED), eine starke Auswirkung auf die Framerate haben (siehe weiter oben). Außerdem schwankt die Framerate in hohen Bereichen sehr stark. Bei niedriger Framerate gibt es nur Schwankungen von ca. +/- 2 Frames. Bei sehr hohen Frameraten über 200 schwankt die Framerate schon viel deutlicher. Unterschiede zwischen 50 Frames sind da keine Seltenheit. Daher sind die hier angegebenen Frameraten nur ungefähre Angaben.


Test 1: 6000 Models mit jeweils 12 Polygonen:
Framerate: 42 FPS
(Screenshot Test 1)

Test 2: 600 Models mit jeweils 120 Polygonen:
Framerate: 287 FPS
(Screenshot Test 2)

Unterschied zwischen Test 1 und 2: ca. 245 FPS.


Test 3: 3000 Models mit jeweils 12 Polygonen:
Framerate: 88 FPS
(Screenshot Test 3)

Test 4: 300 Models mit jeweils 120 Polygonen:
Framerate: 341 FPS
(Screenshot Test 4)

Unterschied zwischen Test 3 und 4: ca. 253 FPS.

Du hast es scheinbar immer noch nicht verstanden:
http://www.mvps.org/directx/articles/fps_versus_frame_time.htm

Nunja, für die starken Schwankungen bei hohen fps Zahlen ist das weiter oben von superku beschriebene Verhalten verantwortlich. Die fps berechnet die Engine schließlich in dem die Zeit für einen frame getimed wird und dann 1 durch diese Zahl (in Sekunden) geteilt wird. Dabei gibt es einerseits Schwankungen durch Hintergrundtasks und so weiter und außerdem kleine Ungenauigkeiten beim Messen. Wenn man jetzt von einer Schwankung/Ungenauigkeit von +-0.5ms ausgeht, was also insgesamt ein Unterschied von einer Millisekunde zwischen zwei Frames sein kann, dann bedeutet das bei einer fps von 30 maximum ein minimum von 29, die Schwankung fällt also nicht weiter auf, bei einer fps von 500 maximum landet man dann aber bei einem minimum von 333, die Schwankung ist also sehr auffällig.

FPS ist 1/framezeitinsec und entsprechend ist die Zeit eines frames 1/FPS.

Von daher ist es wie von Superku schon beschrieben durchaus einfacher und konstanter die im debug panel angegebenen Zeiten für die Entities anzugucken.
Aber ich wiederhole das ja grad eh nur...

Ich finde es übrigens sehr schön, dass du die Tests gemacht hast und freue mich, dass ich recht hatte . Andere Ergebnisse hätten mein Weltbild allerdings auch ziemlich zerstört .

Doch, habe ich. Ich habe das mit den Schwankungen doch nur dazugeschrieben, damit niemand hier im Forum glaubt, dass das fixe/stabile Werte sind.

Die Zeit für das Rendern der Entities pro Frame mag zwar etwas genauer sein. Aber ich bin mir nicht sicher, ob man diesem Wert hundertprozentig vertrauen kann. Weil auch dieser Wert schwankt ziemlich stark. Bei dem Test mit den 3000 Entities schwankt der Wert zwischen 8 und 12 Millisekunden.

(1000/30fps)-(1000/32fps)=2.08ms
(1000/200fps)-(1000/250fps)=1ms
->demnach sind die Schwankungen laut deinen Werten sogar größer bei niedrigeren fps.

Für Geschwindigkeitsvergleiche besser immer die spf anstatt fps verwenden.