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
.
