Wie funktioniert 3dc

[seahawk]

Ich dachte für führen hier mal eine Diskussion über die praktische Nutzbarkeit von 3dc und wie die Texturenkonvertierung funktioniert.

[micki]

mein tip:
wie bei dxt1
4*4 kacheln

pro kachel
-32bit an indices (2bit/pixel)
-2 normalen codiert durch 2 winkelangaben in je 8bit (zusammen 32bit)

beim entpacken:
-zu den 2 normalen die durch zwei winkel angegeben werden wieder 2 normalen interpolieren auch mit je zwei winkeln
-dann aus umwandlung der winkelangaben in 'richtige' normalen und mittels der indices eine 4*4 kacheln aufbauen.

MfG
micki

[Demirug]

micki, ich habe das genaue Verfahren im Büro liegen und poste es morgen. Ich habe seahawk vorhin in einem anderen Thread gesagt das wir besser einen Thread im technologie Forum dafür aufmachen weil es sonst untergeht.

[aths]

Komprimierung:

Nur .X und .Y wird berücksichtigt, und mit je 8 Bit der kleinste und größte Wert gespeichert (= 4 * 8 = 32 Bit.)

Pro Normale und Komponente dann 3 Bit als Lookup. Die Lookup-Tabelle ist eine lineare Interpolation zwischen dem jeweils kleinsten und größten Wert. Macht 16 (Werte in der Kachel) * 2 (Anzahl Komponenten) * 3 (Index für Lookup) = 96 Bit.

Insgesamt 128 Bit = 16 Byte. Spart ggü. unkomprimierter 2-Kanal-8-Bit-Textur 50% Speicherplatz, natürlich geht das etwas zulasten der Qualität.

[micki]

Original geschrieben von aths
Komprimierung:

Nur .X und .Y wird berücksichtigt, und mit je 8 Bit der kleinste und größte Wert gespeichert (= 4 * 8 = 32 Bit.)

Pro Normale und Komponente dann 3 Bit als Lookup. Die Lookup-Tabelle ist eine lineare Interpolation zwischen dem jeweils kleinsten und größten Wert. Macht 16 (Werte in der Kachel) * 2 (Anzahl Komponenten) * 3 (Index für Lookup) = 96 Bit.

Insgesamt 128 Bit = 16 Byte. Spart ggü. unkomprimierter 2-Kanal-8-Bit-Textur 50% Speicherplatz, natürlich geht das etwas zulasten der Qualität.

nur x und y? und was ist mit z? geht man davon aus dass z immer positiv ist oder wie?

MfG
micki

[Demirug]

Original geschrieben von micki
nur x und y? und was ist mit z? geht man davon aus dass z immer positiv ist oder wie?

MfG
micki

Ja Z muss im Pixelshader wieder errechnet werden: z = sqrt (1-x*x-y*y). Da Z bei einer Normalmap ja in der Regel positiv ist stellt das eigentlich kein Problem da. Eine Normalmap mit negativen Z-Werten kann mit 3dc nicht komprimiert werden.

[micki]

Original geschrieben von Demirug
Ja Z muss im Pixelshader wieder errechnet werden: z = sqrt (1-x*x-y*y). Da Z bei einer Normalmap ja in der Regel positiv ist stellt das eigentlich kein Problem da. Eine Normalmap mit negativen Z-Werten kann mit 3dc nicht komprimiert werden.
Was in der regel ist bezweifle ich, object space bumpmapping dürfte genau so oft wie tangentspace benutzt werden. also wenn das wirklich die art ist wie das komprimiert wird, fänd ich das schwach von ATI.
dass eine kompression die qualität angreifft ist ja zu akzeptieren, aber dass sie oft nicht klappt und mann dann auch per hand nachkorrigieren darf wenn's funzt, das find ich 'grausam'

MfG
micki

[Demirug]

Original geschrieben von micki
Was in der regel ist bezweifle ich, object space bumpmapping dürfte genau so oft wie tangentspace benutzt werden. also wenn das wirklich die art ist wie das komprimiert wird, fänd ich das schwach von ATI.
dass eine kompression die qualität angreifft ist ja zu akzeptieren, aber dass sie oft nicht klappt und mann dann auch per hand nachkorrigieren darf wenn's funzt, das find ich 'grausam'

MfG
micki

Beim Object Space Bumpmapping ist man natürlich aufgeschmissen. Aber wird das wirklich noch so oft genutzt? Auf einer Karte mit VS würde ich eigentlich immer den Tangentspace bevorzugen.

Ich finde "grausam" das man für 3dc jeden Pixelshader der eine normalmap benutzt anfassen muss und eine Version für 3dc und eine ohne braucht. Ausser man legt fest das man eben nur Normalmaps mit X und Y benutzt.

[ScottManDeath]

Ist ein Argument, aber wenn man aber mit HLSL arbeitet dürfte das doch mehr oder weniger nur eine "Fleissfrage" sein. Sind die Devs nicht schon recht frühzeitig gebrieft und wissen was auf sie zukommt?


float3 expand(in float3 val)
{
return 2.0f* val - 1.0f;
}

float3 fetch_normal_3dc(in uniform sampler2D map, float2 texcoord)
{
float3 tex = float3(tex2D(map, texcoord),0.0f);
tex = expand(tex);
tex.z = sqrt( 1.0f- tex.x*tex.x - tex.y*tex.y);
return tex;
}

float3 fetch_normal_rgb (in uniform sampler2D map, float2 texcoord)
{
float3 tex = float3(tex2D(map, texcoord),0.0f);
tex = expand(tex);
return tex;
}


float3 fetch_normal (in uniform sampler2D map, float2 tex)
{
#if USE_3DC
return fetch_normal_3dc(map,tex);
#else
return fetch_normal_rgb(map,tex);
#endif
}


void main(....
in float2 tc : TEXCOORD0,
uniform sampler2D normalmap
)
{

...
float3 normal = fetch_normal(normalmap, tc);
...
}



Wenn man das ganze aber für die ASM Shader machen muss, sieht das gruslig aus..... Könnte man aber eventuell automatisieren wenn sich das lohnt... ansonsten, es gibt ja willige Praktikanten die den Shadercode anpassen können... =)

[Demirug]

ScottManDeath, einige "Opfer" hat sich ATI wohl schon frühzeitig ausgesucht. Die Allgemeinheit wurde aber erst auf der GDC informiert.

Das es mit HLSL jetzt relative einfach geht habe ich ja nicht abgestritten es aber Definitive eine Fleisarbeit wenn man viele Shader hat.

[micki]

Original geschrieben von Demirug
Beim Object Space Bumpmapping ist man natürlich aufgeschmissen. Aber wird das wirklich noch so oft genutzt? Auf einer Karte mit VS würde ich eigentlich immer den Tangentspace bevorzugen.


ja, wird es, gerade für nicht animierte dinge ist es einfach und billig, weil graphiker ohne ahnung vom realtime modeling wirklich hochqualitative graphiken generieren können und das dann auf lowpoly runtergerechnet wird (mit sammt der colormap usw wenn man das richtige tool hat ;D)

es wird immer öfter benutzung finden, dessen bin ich mir sicher, auch wenn ich tangentspace bevorzuge :-/

MfG
micki

[seahawk]

Denke ich aber auch. Die Tangentspacelösung kostet doch immer iweder Qualität im Vergleich zur handgezeichneten Textur.

Wie sieht es eigentlich mit den Eingagnsdaten aus. Gibt es da eine Tool das DXT automatisch in 3dc konvertiert ??

Mit der Hand würde ich das nicht machen wollen, Das ist dann nämlich nochmal eine ziemliche Fleissarbeit.

[Xmas]

Ob ATI eine spezielle Instruktion im PS hat, um sqrt(1 - x² - y²) zu beschleunigen? Mir ist aufgefallen, dass diese Formel mit PS3.0 einfacher zu realisieren ist.
Was sind die Default-Werte für Z und W bei TEXLD aus einer 3Dc-Textur?

[aths]

Original geschrieben von Xmas
Ob ATI eine spezielle Instruktion im PS hat, um sqrt(1 - x² - y²) zu beschleunigen?Gibt es diese Konvertierung nicht sogar in einer Textursampler-Instruction?

[Xmas]

Wie meinst du das? Dass die TMU den Z-Wert automatisch generiert, wenn eine 3Dc-Textur gelesen wird? Sicher nicht. Der Z-Wert muss im Shader errechnet werden.

[micki]

Original geschrieben von aths
Gibt es diese Konvertierung nicht sogar in einer Textursampler-Instruction?
finde auch dass das automatisch gehen sollte, was soll denn das, dass man selbst immer die convertierung machen muss, dann müßte man ja abhängig vom texturformat alternativshader bzw codesnippels einfügen. das sollte unbedingt bei tld automatisch passieren!

MFG
micki

[CrazyIvan]

Frage an de Experdden:

Wenn bei der ganzen Geschichte eh die Hälfte über nen geänderten Shader gemacht werden muss, wäre es nicht auch möglich, die komplette Dekompression über nen Shader abzuwickeln? Speedmäßig vielleicht grausam, aber immerhin bringts Kompatibilität zu R3xx und NV3x.

[seahawk]

Kann 3dc eigentlich Farbdaten speichern ??

[aths]

Original geschrieben von seahawk
Kann 3dc eigentlich Farbdaten speichern ?? Bitte!! (www.aktiv-gegen-plenken.de)

3Dc kann alles speichern, was mit 2 Kanälen und 8 Bit Auflösung auskommt.

[seahawk]

Kannst Du das für mich etwas einfacher ausdrücken?

Ich verstehe die pdf-Datein von ATI so, dass es sich hauptsächlich um eine Komprimierung von Normalmaps handelt.
Für den eigentlichen Farblayer (um es mal so auszudrücken) scheint es mir nicht geeignet.

(jetzt sollten die Satzzeichen stimmen)

[aths]

Original geschrieben von seahawk
Kannst Du das für mich etwas einfacher ausdrücken?

Ich verstehe die pdf-Datein von ATI so, dass es sich hauptsächlich um eine Komprimierung von Normalmaps handelt. 3Dc komprimiert einfach Daten, was möglich ist, da meist ein gewisser lokaler Zusammenhang herrscht.

Bei großen Amplituden gibt es mehr Rauschen durch die Komprimierung, was meist nicht so schlimm ist, da große Amplituden das Rauschen "maskieren".

Original geschrieben von seahawk
Für den eigentlichen Farblayer (um es mal so auszudrücken) scheint es mir nicht geeignet.Farben brauchen (mindestens) drei Informationen. Sofern man nicht implizit immer die gleiche Helligkeit oder den gleichen Farbton voraussetzt, kann man mit 3Dc keine Farben speichern, weil dieses nur 2 Kanäle berücksichtigt.

[mboeller2]

Original geschrieben von aths
Bitte!! (www.aktiv-gegen-plenken.de)

3Dc kann alles speichern, was mit 2 Kanälen und 8 Bit Auflösung auskommt.


8bit? ich dachte 2x 16bit. Wurde zumindest so von Dio auf Beyond3D gesagt.

[Demirug]

Original geschrieben von mboeller2
8bit? ich dachte 2x 16bit. Wurde zumindest so von Dio auf Beyond3D gesagt.

In den Unterlagen ist nur die Kompression von 8Bit Werte aufgeführt.

[mboeller2]

Ich hoffe ich blamiere mich jetzt nicht :

http://www.beyond3d.com/forum/viewtopic.php?t=12117&highlight=

Dio:
No arguments there. Hence 3Dc - pretty much comparable to the 16:16 textures that our demo-porting group used to insist on at 1/4 the size.


Basic :
So it is 16:16 -> 3Dc that gives the 4:1 compression ratio. From most places I read it seemed like XYZ* 8:8:8:8 -> 3Dc was the reason.

Does that mean that the interpolation in R420 is done at high enough precision to get the 10-11 bits per component that is theoretically possible to get from 3Dc on a favourable texture?

Dio:
Remember that we have filtering for 16:16 and 10:10:10:2 textures

3Dc will be significantly higher quality than an 8:8:8 bump map in most cases.

[DrumDub]

also ati selber sagt:

Works with any two-channel data format
http://www.ati.com/products/radeonx800/specs.html

damit geht dann imho die kompression normaler texturen nicht. wie aths schon sagte.

[Demirug]

Original geschrieben von mboeller2
Ich hoffe ich blamiere mich jetzt nicht :

http://www.beyond3d.com/forum/viewtopic.php?t=12117&highlight=


Dio:
Remember that we have filtering for 16:16 and 10:10:10:2 textures

3Dc will be significantly higher quality than an 8:8:8 bump map in most cases.


Typpisch Dio. Natürlich kann man mit 3dc auch 16 Bit Daten komprimieren nur ist dann eben der Verlust entsprechend höher.

Die beiden Stützpunkte für das lineare Interpolieren bei 3dc sind und bleiben nun mal 8 Bit Werte. Dazwischen liegen nun noch 6 Zwischenwerte was mit den beiden Endpunkten genau 8 Werte ergibt. Da immer 16 Werte pro Kachel komprimiert werden muss zwangsläufig mindestens einer dieser 8 Werte mehrfach benutzt werden.

Liegen nun die beiden Endwerte nur ein Bit auseinander kommt man mit den 6 Werte dazwischen auf fast 11 Bit Genauigkeit. Das funktioniert aber nur wenn alle 16 Werte sich innerhalb von 3 Bit bewegen. Gerade an einer Stelle mit einer Furche wird man das schwer finden. Diese Stellen sind aber die Interesantesten.

[mboeller2]

Original geschrieben von Demirug
Typpisch Dio. Natürlich kann man mit 3dc auch 16 Bit Daten komprimieren nur ist dann eben der Verlust entsprechend höher.

Die beiden Stützpunkte für das lineare Interpolieren bei 3dc sind und bleiben nun mal 8 Bit Werte. Dazwischen liegen nun noch 6 Zwischenwerte was mit den beiden Endpunkten genau 8 Werte ergibt. Da immer 16 Werte pro Kachel komprimiert werden muss zwangsläufig mindestens einer dieser 8 Werte mehrfach benutzt werden.

Liegen nun die beiden Endwerte nur ein Bit auseinander kommt man mit den 6 Werte dazwischen auf fast 11 Bit Genauigkeit. Das funktioniert aber nur wenn alle 16 Werte sich innerhalb von 3 Bit bewegen. Gerade an einer Stelle mit einer Furche wird man das schwer finden. Diese Stellen sind aber die Interesantesten.


Ähh ja...:kratz2:

gibt es dazu auch Unterlagen?

Was hältst du dann davon anstelle von 3Dc DXT5 mit einem tweak zu benutzen. Es soll nahezu genauogut funktionieren und auf fast allen Chips laufen (wird auf Beyond3D (http://www.beyond3d.com/forum/viewtopic.php?t=12160) so diskutiert)

[aths]

Original geschrieben von mboeller2
Was hältst du dann davon anstelle von 3Dc DXT5 mit einem tweak zu benutzen. Es soll nahezu genauogut funktionieren und auf fast allen Chips laufen (wird auf Beyond3D (http://www.beyond3d.com/forum/viewtopic.php?t=12160) so diskutiert) Lustigerweise hat das ursprünglich ATI selbst vorgeschlagen :)

[zeckensack]

3DC ist massiv überbewertet, dafür aber sehr einfach nutzbar. Den Trick mit der Rekonstruktion des dritten Werts kann man btw auch ohne "3DC" benutzen.

[Demirug]

Original geschrieben von zeckensack
3DC ist massiv überbewertet, dafür aber sehr einfach nutzbar. Den Trick mit der Rekonstruktion des dritten Werts kann man btw auch ohne "3DC" benutzen.

Und bei FP16 Normalmaps ist das wahrscheinlich sogar eine gute Idee.

Was man ebenfalls tun könnte ist folgendes. Wenn man bei der Decalmap den Alphateil nicht braucht kann man dort den X Wert des normalmap Vektors reinpacken und in eine zweite textur ebenfalls in den Alphawert den Y-Wert. Da die Alphawerte bei DXTC ja genau wie bei 3dc komprimiert werden können hat man so die 3dc Vorteile (Speicherverbrauch und Bandbreite) auch auf nicht 3dc fähigen Karten. Der Farbwert der zweiten Textur steht natürlich noch für andere Daten zur Verfügung.

[Monger]

Sorry, irgendwie bin ich da schwer von Begriff:


Angenommen es wird zukünftig ein Spiel entwickelt, was 3DC (oder S3TC) Texturkompression unterstützt.

Sind dann die Texturen gewissermaßen abwärtskompatibel zu den Normalmaps?

Wenn nicht, bedeutet dass das ich zwingend eine Grafikkarte brauche die eben diese Kompression unterstützt?


Das würde ja heißen, dass man für das selbe Spiel zwei verschiedene Texturpakete mitliefern muss, oder?

Wenn das so ist, kann man vermutlich auf S3TC/3DC ewig warten, denn dann kann man dieses Feature erst bringen, wenn jeder potentielle Käufer eine Grafikkarte hat, die genau dieses Feature unterstützt.

[zeckensack]

Original geschrieben von Monger
Sorry, irgendwie bin ich da schwer von Begriff:


Angenommen es wird zukünftig ein Spiel entwickelt, was 3DC (oder S3TC) Texturkompression unterstützt.

Sind dann die Texturen gewissermaßen abwärtskompatibel zu den Normalmaps?

Wenn nicht, bedeutet dass das ich zwingend eine Grafikkarte brauche die eben diese Kompression unterstützt?


Das würde ja heißen, dass man für das selbe Spiel zwei verschiedene Texturpakete mitliefern muss, oder?

Wenn das so ist, kann man vermutlich auf S3TC/3DC ewig warten, denn dann kann man dieses Feature erst bringen, wenn jeder potentielle Käufer eine Grafikkarte hat, die genau dieses Feature unterstützt. Wenn man eine Texturkompressionstechnik unterstützt, tut man das IMO am sinnvollsten indem man den gesamten Content nur noch komprimiert ausliefert. Wenn man dann zur Laufzeit feststellt, dass die Karte das komprimierte Format nicht nativ unterstützt, kann man es einfach beim Laden (in Software) dekomprimieren. Diese Texturkompressionsalgorithmen sind so einfach, dass man auf jedem halbwegs modernen Prozessor mit >1GB/s Texturen dekomprimieren kann. Ist also echt kein Verlust.

Im Austausch kann man das Spiel dann auf weniger CDs ausliefern, und spart Plattenplatz.

[Demirug]

Original geschrieben von zeckensack
Wenn man eine Texturkompressionstechnik unterstützt, tut man das IMO am sinnvollsten indem man den gesamten Content nur noch komprimiert ausliefert. Wenn man dann zur Laufzeit feststellt, dass die Karte das komprimierte Format nicht nativ unterstützt, kann man es einfach beim Laden (in Software) dekomprimieren. Diese Texturkompressionsalgorithmen sind so einfach, dass man auf jedem halbwegs modernen Prozessor mit >1GB/s Texturen dekomprimieren kann. Ist also echt kein Verlust.

Im Austausch kann man das Spiel dann auf weniger CDs ausliefern, und spart Plattenplatz.

Da bin ich aber etwas anderer Meinung. Texturen auf der CD verlustfrei mit PNG oder was auch immer komprimieren. Beim installieren in unkomprimierte wandeln und falls die Karte die entsprechenden Kompressionverfahren unterstützt entsprechend komprimieren. Warum sollte man jemand zusätzlich bestrafen wenn seine Karte ein Kompressionverfahren nicht beherscht?

[Monger]

Original geschrieben von zeckensack
Wenn man eine Texturkompressionstechnik unterstützt, tut man das IMO am sinnvollsten indem man den gesamten Content nur noch komprimiert ausliefert. Wenn man dann zur Laufzeit feststellt, dass die Karte das komprimierte Format nicht nativ unterstützt, kann man es einfach beim Laden (in Software) dekomprimieren. Diese Texturkompressionsalgorithmen sind so einfach, dass man auf jedem halbwegs modernen Prozessor mit >1GB/s Texturen dekomprimieren kann...

Gut, das macht Sinn. Wenn man das per Prozessor entpackt, bleibt dann die Bildqualität erhalten, so dass halt die Grafikkarte ohne 3DC Unterstützung kräfter arbeiten muss, oder verliert man einen Teil der Bildqualität? Oder ist beides denkbar?

[zeckensack]

Original geschrieben von Demirug
Da bin ich aber etwas anderer Meinung. Texturen auf der CD verlustfrei mit PNG oder was auch immer komprimieren. Beim installieren in unkomprimierte wandeln und falls die Karte die entsprechenden Kompressionverfahren unterstützt entsprechend komprimieren. Warum sollte man jemand zusätzlich bestrafen wenn seine Karte ein Kompressionverfahren nicht beherscht? Kompression dauert wesentlich länger als Dekompression, vor allem wenn man vernünftige Kompressoren benutzt.

Wenn eine Textur selbst mit einem "optimalen" Kompressor komprimiert wirklich übel aussieht, dann kann man das ja vorher feststellen, und diese eben immer ohne Kompression benutzen (und auch verlustfrei - oder garnicht - komprimiert ausliefern).

Und es ist IMO auch keine Strafe. Die Performance-Kosten für die Dekompression sind absolut zu vernachlässigen. Von der Qualität her habe ich auch keine Bedenken. Die komprimierten Texturen sollten IMO "die besten" sein, und nicht etwa RGBA8888 ...

Original geschrieben von Monger
Gut, das macht Sinn. Wenn man das per Prozessor entpackt, bleibt dann die Bildqualität erhalten, so dass halt die Grafikkarte ohne 3DC Unterstützung kräfter arbeiten muss, oder verliert man einen Teil der Bildqualität? Oder ist beides denkbar? Wenn man es richtig macht, ist das Ergebnis der Software-Dekompression exakt gleich zu dem das die Hardware-Dekompression liefern würde.

Der Nachteil ist natürlich der höhere Speicherplatz- und Bandbreitenverbrauch auf der Grafikkarte. Aber wenn die Karte keine komprimierten Texturen beherrscht, dann muss man das sowieso in Kauf nehmen. Die Texturauflösung runterzuregeln ist dann die naheliegendste Massnahme, um dem entgegenzuwirken. Wenn die Karte genug Speicher und Bandbreite hat, kann man sich das natürlich sparen. Die zukünftigen NV40-User werden dafür auch dankbar sein ;)

Nochmal: 3DC macht Texturen nicht schöner, eher im Gegenteil. Es sorgt lediglich dafür, dass sie weniger Speicherplatz belegen. Das Presse-Material von ATI ist in diesem Punkt leider sehr irreführend.

Die Rekonstruktion der fehlenden dritten Komponente hat auch inhärent nichts mit 3DC zu tun. Das kann man auf jeder Pixel-Shader-Hardware tun, und es macht ab einem gewissen Verhältnis von Shaderleistung zu Bandbreite auch Sinn.
3DC (de)komprimiert nur die verbliebenen zwei Kanäle.

[Xmas]

Das schöne an 3Dc ist, dass man es verdammt schnell in DXT5 "umpacken" kann. Mit Verlust natürlich, aber man kann so 3Dc-Texturen ausliefern und diese bei Bedarf in DXT5 umwandeln. Damit hat man 99% der Hardware abgedeckt, und der Rest bekommt eh nur low-Res schnell zum laufen, so dass dort die entpackten high-Res Texturen auch brauchbar sind.