Archiv verlassen und diese Seite im Standarddesign anzeigen : PVR-TC
Ailuros
2003-06-14, 08:37:47
Nichts besonderes eigentlich; aber da ich Kopfschmerzen beim durchlesen bekam und nur vielleicht die Haelfte geschnappt habe, irgendwelche Meinungen?
http://l2.espacenet.com/espacenet/viewer?PN=GB2382736&CY=gb&LG=en&DB=EPD
Aqualon
2003-06-14, 12:24:54
Im Prinzip geht es darum nicht die genauen Informationen eines Datenblocks zu speichern, sondern nur nen Teil (also einen Repräsentanten) davon.
Wenn man z.B. folgenden Bildblock im RGB-Format hat (nehmen wir mal den Rot-Kanal):
1 0 1 0
0 3 0 0
0 0 1 0
2 0 0 0
Da sich die Werte kaum unterscheiden, kann man den Block auch so schreiben:
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
Und das kann man platzsparender abspeichern als den Originalblock und man dürfte keine großen Unterschiede in der Darstellung sehen.
Vll. lieg ich damit auch falsch, aber zumindest seh ich das beschriebene Verfahren so. Was aber dann IMO keine großartige neue Leistung wäre.
Aqua
Demirug
2003-06-14, 14:26:29
Irgendwie fehlt da noch der Text mit der Beschreibung.
Das ganze ist definitive ein Kompressionverfahren für Texturen. Alles was ich direkt aus den Bildern entnehmen kann ist das man dazu die Texuren zuerst einmal herunter skaliert und dann eine DeltaTexture erzeugt. Diese Daten werden dann irgendwie noch gepackt (dafür bräuchte ich aber den Text). Bei einladen wird dann aus der herunter skalierten texture und der Deltamap wieder die ursprüngliche Texture berechnet.
Der Zweg dieser Sache ist wohl folgender:
Erzeugen von Trisample aus der jeweils kleineren MipMap + eine Deltamap mit den unterschieden zur nächsten Stufe. Dürfte einiges an Bandbreite sparen.
Bei den bisampels könnte es aber auch noch was sparen.
Aber wie gesagt ich bräuchte den Text.
Original geschrieben von Demirug
Irgendwie fehlt da noch der Text mit der Beschreibung.
Das ganze ist definitive ein Kompressionverfahren für Texturen. Alles was ich direkt aus den Bildern entnehmen kann ist das man dazu die Texuren zuerst einmal herunter skaliert und dann eine DeltaTexture erzeugt. Diese Daten werden dann irgendwie noch gepackt (dafür bräuchte ich aber den Text). Bei einladen wird dann aus der herunter skalierten texture und der Deltamap wieder die ursprüngliche Texture berechnet.
Der Zweg dieser Sache ist wohl folgender:
Erzeugen von Trisample aus der jeweils kleineren MipMap + eine Deltamap mit den unterschieden zur nächsten Stufe. Dürfte einiges an Bandbreite sparen.
Bei den bisampels könnte es aber auch noch was sparen.
Aber wie gesagt ich bräuchte den Text.
wieso? Das Patent hat 83 Seiten mit jeder Menge Text.
Demirug
2003-06-14, 15:25:53
Original geschrieben von Gast
wieso? Das Patent hat 83 Seiten mit jeder Menge Text.
Bei espacenet bekomme ich aber im Moment nur die 15 Seiten mit den Zeichnungen. ???
Aqualon
2003-06-14, 15:32:16
Original geschrieben von Demirug
Bei espacenet bekomme ich aber im Moment nur die 15 Seiten mit den Zeichnungen. ???
http://l2.espacenet.com/espacenet/bnsviewer?CY=gb&LG=en&DB=EPD&PN=GB2382736&ID=GB+++2382736A++I+
Auf der Seite kann man auf alle Seiten einzeln zugreifen.
Aqua
Demirug
2003-06-14, 15:38:53
Original geschrieben von Aqualon
http://l2.espacenet.com/espacenet/bnsviewer?CY=gb&LG=en&DB=EPD&PN=GB2382736&ID=GB+++2382736A++I+
Auf der Seite kann man auf alle Seiten einzeln zugreifen.
Aqua
Danke :)
Original geschrieben von Demirug
Bei espacenet bekomme ich aber im Moment nur die 15 Seiten mit den Zeichnungen. ???
Ouch! Jetzt weiß ich wo dein Fehler liegt.
Du muss direkt auf den Link klicken ( "GB2382736"); da wo das Kästchen davor ist. Dann öffnet sich eine weitere Seite und mit dem PDF-Reader kannst du alle Seiten des Patents einzeln anschauen und sogar herunterladen. Bei 83 Seiten allerdings ein Mordsaufwand.
Ailuros
2003-06-15, 02:43:12
Ich such immer noch nach einem white paper irgendwo. Da das Patent veroeffentlicht wurde und MBX schon produziert wird, koennte man ruhig mal eine einfachere Beschreibung auf der Developer-Seite schreiben, dass die einfachen Sterblichen wie ich das ganze auch besser verstehen koennen.
Kristof Beets sagte damals in meinem Interview mit ihm, dass PVR-TC bis zu zweimal so hohe Kompressionsraten als DXTC erreichen kann. Ob das auch stimmt hab ich keine Ahnung.
Demirug
2003-06-15, 09:25:55
Original geschrieben von Ailuros
Ich such immer noch nach einem white paper irgendwo. Da das Patent veroeffentlicht wurde und MBX schon produziert wird, koennte man ruhig mal eine einfachere Beschreibung auf der Developer-Seite schreiben, dass die einfachen Sterblichen wie ich das ganze auch besser verstehen koennen.
Kristof Beets sagte damals in meinem Interview mit ihm, dass PVR-TC bis zu zweimal so hohe Kompressionsraten als DXTC erreichen kann. Ob das auch stimmt hab ich keine Ahnung.
Ja das mit der Kompressionrate stimmt. Das Patent (ich habe inzwischen den Text auch gefunden. Danke nochmal für die Hinweise :) ) beschreibt zwei Verfahren eines mit 4bpp und eines mit 2bpp. DXTC hat eine Kompression von 4:1 (bei 16 Bit Texturen) = 4bpp und 8:1 (bei 32 Bit Texturen) auch 4bpp. Der 2bpp Modus hat also die erwähnte Kompressionrate.
Was das Verfahren angeht so habe ich mich von den Bilder etwas täuschen lassen. Genaugenommen funktioniert das ganze nach folgenden Prinzip:
4bpp:
Die Ursprungstexture wird auf 25% in beide Richtungen herunterskaliert. Aus einem 4*4 Pixel Block wird also ein Datensegement. Beim Herunterskalieren werden für diesen Block nun folgende Daten gewonnen. Zwei Farben A und B. Diese werden mit jeweils 15 Bit koddiert. Das genaue Format hängt davon ab ob welches Ausgangsformat die Texture hat. Zudem wird dann noch für jeden der 16 Pixel ein Blendfactor zwischen A und B ermittelt und mit 2 Bits abgespeichert. Daraus ergibt sich das ein Block 15 Bits (farbe A) + 15 Bits (Farbe B) + 16*2 Bits (Blend faktoren) + 2Bit Steuerinformationen = 64 Bit gross ist. Unkomprimiert waren es 4*4*32 = 512 Bit. Wird später ein Sampel aus der Texture gebraucht wird lezten Endes vor den eigentlichen Texturefilter noch eine Einheit gebaut welche aus bis zu vier dieser Blöcke 4 Texel generiert. Diese Einheit besteht aus etwas Adresslogik , 4 unabhängien Blend einheiten und 8 Einheiten welche die mit 16 Bit koddierten Farben A und B in 32 Bit RGBA Werte umwandeln. Die Funktionsweise aller Einheiten ist im Patent mit C-Code erklärt. Dadurch das die Dekomprimierung "on the fly" abläuft kann die Texture im Komprimierten Zustand im Cache gehalten werden.
2bpp:
Eine Variante des oben beschriebenen Verfahrens. Hier wird nun ein 4*8 Pixel Block komprimiert. Da für 32 Pixel jetzt nur noch 32 Bit zur Verfügung stehen werden diese anders ausgwertet. Dafür gibt es zwei Varianten welche durch eines der beiden Steuerbits bestimmt werden.
1: Pro Pixel ein Bit. Das Bit gibt an ob Farbe A oder Farbe B benutzt wird.
2: Es wird nu jeder 2 Pixel gepsichert (mit 2 Bits). Die zu speichernden Pixel bilden dabei ein Schachbrettmusster bei dem nur die Schwarzen Felder gespeichert werden. Der Blendfactor für die weisen felder wird aus den Blendfaktoren der umliegenden Schwarzen Felder beim Entpacken der Texture bestimmt.
Die von mir oben erwähnte Möglichkeit ein Trisampel direkt aus einer MipMap Stufe zu erzeugen wird nicht explizit erwähnt da man sich mit der beschreibung einer Bi-TMU zufrieden gegeben hat.
Original geschrieben von Demirug
2bpp:
Eine Variante des oben beschriebenen Verfahrens. Hier wird nun ein 4*8 Pixel Block komprimiert. Da für 32 Pixel jetzt nur noch 32 Bit zur Verfügung stehen werden diese anders ausgwertet. Dafür gibt es zwei Varianten welche durch eines der beiden Steuerbits bestimmt werden.
Ich hab den Text für die 2bpp-Version etwas anders verstanden, bzw es scheint noch eine Alternativ-Version zu geben; indem PVR-TC mit CLUT's zusammen benutzt wird. Der entsprechende Text steht am Ende der Beschreibung für die 4bpp - Version (IMHO).
Demirug
2003-06-15, 13:25:00
Original geschrieben von Gast
Ich hab den Text für die 2bpp-Version etwas anders verstanden, bzw es scheint noch eine Alternativ-Version zu geben; indem PVR-TC mit CLUT's zusammen benutzt wird. Der entsprechende Text steht am Ende der Beschreibung für die 4bpp - Version (IMHO).
Durchaus möglich das ich das etwas überlesen habe.
Hast du zufällig noch die Seitennummer im Kopf?
Original geschrieben von Demirug
Durchaus möglich das ich das etwas überlesen habe.
Hast du zufällig noch die Seitennummer im Kopf?
Seite 56-59; da wird über Alternative Anwendungen und Implementierungen gesprochen.
Demirug
2003-06-15, 21:14:36
Original geschrieben von Gast
Seite 56-59; da wird über Alternative Anwendungen und Implementierungen gesprochen.
Ja stimmt da stehen noch einige Varianten die ich oben nicht ausdrücklich aufgeführt habe da sie scheinbar nicht zur Grundüberlegung gehören. Am Grundprinzip ändert sich dadurch ja eigentlich nicht wirklich etwas.
Ailuros
2003-06-16, 02:59:54
Etwas uebersichtiger:
http://simonnihal.homestead.com/files/assorted3d/fenney03texcomp.pdf
Ailuros
2003-06-16, 03:20:41
Die von mir oben erwähnte Möglichkeit ein Trisampel direkt aus einer MipMap Stufe zu erzeugen wird nicht explizit erwähnt da man sich mit der beschreibung einer Bi-TMU zufrieden gegeben hat.
Hatten sie schon in der KYRO (siehe TC + trilinear), oder nicht?
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.