Aramis hat geschrieben:Womit ich allerdings zurückrudern muss ist bezüglich meiner obigen Aussage 'Default==16'. Das hatte ich irgendwie falsch im Kopf, der Defaultwert ist 12, sorry. Das ändert nichts daran dass es mit 4 Bits am effektivsten sein dürfte, lässt aber die Hoffnung dass es mit 15/16 Cache-Slots sogar noch besser werden könnte :-)
Werde ich gleich mal testen :)
Ansonsten frage ich mich, wieso ihr die Cache-Optimierung unbedingt *vor* der Kompression ausführen wollt. Wieso nicht einfach die Indexliste auf bessere Komprimierbarkeit hin umsortieren (z.B. einfach Brute Force), dann nach dem Dekomprimieren den Cache-Optimizer laufen lassen? Viel Zeit braucht das nicht, die meisten brauchbaren Algorithmen sind O(n) oder O(nlogn). Und es war ja sowieso Just for Fun.
Weil es ein space-time-tradeoff ist, bei dem ich schnelle Ausführung bevorzuge – ich muss hier ja dauernd erwähnen, dass ich nur einen einzigen Pass je zum Packen und Entpacken haben will, weil das Ganze am Ende für Echtzeit-Manipulationen gebraucht wird … wenn es nach maximaler Kompression ginge, würde ich alles in einen Triangle-Strip packen, den in Segmente mit eigener Delta-Kompression unterteilen, PAQ8 drüberjagen und die Daten nicht mehr anfassen :) Vertauschen möchte ich eigentlich auch nichts, denn, wie TGGC schon sagte – man weiß nie, ob man nicht hinterher doch Spezialfälle für Alpha-Blending o.ä. einführt …
… was aber nicht heißen soll, dass ich was dagegen hätte, dass Dirk und Julien da anders vorgehen – je mehr Alternativen ausprobiert werden, desto besser.
Im Extremfall macht die Rotation der Indizes die Arbeit des Cache-Optimizers kaputt. Zumindest wenn der Optimizer *exakt* auf eine bestimmte Cache-Größe hin optimiert, wie unserer. Meinem Verständnis des Post-Transform Caches zufolge ist es jedenfalls so, ich lasse mich aber gerne korrigieren :-)
Ich denke, schon … ich sehe es aber so: durch Rotation kann das aktuelle Dreieck höchstens zwei aus dem Cache geflogene Vertices mehr wiedereinführen als das unrotierte Dreieck … bei zwölf Vertices im Cache wird die Performance schlimmstenfalls um ein Sechstel reduziert. Arbeitet der Optimizer mit 16 Vertices, ist es nurnoch ein Achtel usw.
