1 registered members (AndrewAMD),
1,306
guests, and 3
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Framerate
[Re: Microtex]
#383794
09/25/11 13:50
09/25/11 13:50
|
Joined: Dec 2002
Posts: 3,363 Vindobona (Ostarichi)
Harry Potter
Expert
|
Expert
Joined: Dec 2002
Posts: 3,363
Vindobona (Ostarichi)
|
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).
Last edited by Harry Potter; 09/25/11 14:02.
|
|
|
Re: Framerate
[Re: Harry Potter]
#383811
09/25/11 18:56
09/25/11 18:56
|
Joined: Sep 2003
Posts: 5,900 Bielefeld, Germany
Pappenheimer
Senior Expert
|
Senior Expert
Joined: Sep 2003
Posts: 5,900
Bielefeld, Germany
|
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.
|
|
|
Re: Framerate
[Re: Harry Potter]
#383900
09/26/11 23:56
09/26/11 23:56
|
Joined: May 2005
Posts: 2,713 Lübeck
Slin
Expert
|
Expert
Joined: May 2005
Posts: 2,713
Lübeck
|
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.
Ö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 .
|
|
|
Re: Framerate
[Re: Slin]
#383916
09/27/11 08:51
09/27/11 08:51
|
Joined: Jul 2001
Posts: 6,904
HeelX
Senior Expert
|
Senior Expert
Joined: Jul 2001
Posts: 6,904
|
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.
Last edited by HeelX; 09/27/11 09:00.
|
|
|
|