# S3TC Dekompression



## Alemarius Nexus (8. Aug 2009)

Hallo mal wieder,

Ich habe vor, Texturen für mein Java3D-Programm zu laden, die teilweise mit S3TC (DXT1, 3 und 5) komprimiert sind. Gibt es in Java oder Java3D, womöglich auch mit einer externen Bibliothek, eine Möglichkeit, auf diese Weise komprimierte Bilder zu laden? Muss man so komprimierte Bilder überhaupt dekomprimieren um sie einfach nur anzeigen zu können? Es sieht nämlich aus, als würden trotz Kompression alle Bilder korrekt geladen werden.


----------



## Noctarius (8. Aug 2009)

Alemarius Nexus hat gesagt.:


> Hallo mal wieder,
> 
> Ich habe vor, Texturen für mein Java3D-Programm zu laden, die teilweise mit S3TC (DXT1, 3 und 5) komprimiert sind. Gibt es in Java oder Java3D, womöglich auch mit einer externen Bibliothek, eine Möglichkeit, auf diese Weise komprimierte Bilder zu laden? Muss man so komprimierte Bilder überhaupt dekomprimieren um sie einfach nur anzeigen zu können? Es sieht nämlich aus, als würden trotz Kompression alle Bilder korrekt geladen werden.



Ist S3TC nicht aus dem DDS Dateiformat von DirectX? Das DDS Dateiformat ist doch klasse dokumentiert um hohe Verbreitung zu erreichen. Im schlimmsten Fall sollte man sich so einen DDS-Reader bauen können.

Ob die richtig geladen werden wäre doch durch Ausprobieren recht einfach zu testen, oder nicht?


----------



## Alemarius Nexus (8. Aug 2009)

> Ist S3TC nicht aus dem DDS Dateiformat von DirectX? Das DDS Dateiformat ist doch klasse dokumentiert um hohe Verbreitung zu erreichen. Im schlimmsten Fall sollte man sich so einen DDS-Reader bauen können.



Laut Wikipedia müsste man für eine eigene Implementierung Lizenzgebühren zahlen, weil der Algorithmus patentiert ist, wenn ich das richtig verstehe (bin auf dem Gebiet aber nicht sehr bewandert. Also korrigiert mich bitte, wenn ich Schwachsinn rede). Zahlen möchte ich dafür auf jeden Fall nicht!




> Ob die richtig geladen werden wäre doch durch Ausprobieren recht einfach zu testen, oder nicht?



Ich bin dabei, habe das bisher aber nur bei (zumindest angeblich) DXT1 komprimierten Bildern testen können. Die anderen kann ich erst testen wenn ich ein weiteres Bildformat laden kann, woran ich gerade arbeite.


----------



## Noctarius (8. Aug 2009)

Prinzipiell sollten Grafikkarten S3TC auch lesen bzw verarbeiten können, zumal die Komprimierung ja nun doch ein paar Jahre auf dem Buckel hat.


----------



## Alemarius Nexus (8. Aug 2009)

> Prinzipiell sollten Grafikkarten S3TC auch lesen bzw verarbeiten können, zumal die Komprimierung ja nun doch ein paar Jahre auf dem Buckel hat.



Gut, aber das Problem wird wohl sein, an die internen Funktionen der Grafikkarte ranzukommen. Java ist dazu ja nun nicht wirklich geeignet. Der einzige Weg zur Dekompression würde dann ja über JNI führen. Ich würde mich aber nur ungerne richtig in C einarbeiten wollen. Wenn das wirklich die einzige Methode ist, dann muss ich wohl auf die Unterstützung für DXT-komprimierte Dateien verzichten. Schade!

//EDIT: Es wäre ja möglich, mit JNI nur eine Schnittstelle zu einer bereits vorhandenen, legalen Implementierung bereitzustellen. Wäre das rechtlich bedenklich?


----------



## Evil-Devil (8. Aug 2009)

Für Java3D kenne ich keine Möglichkeit. Du könntest höchstens auf JOGL/LWJGL umsteigen und dann über die verfügbaren OpenGL Funktionen die S3TCs laden und anzeigen was recht einfach ist.

Das schöne an S3TC/DDS ist ja, dass man sie komprimiert an die Grafikkarte schicken kann ohne sie vorher dekomprieren zu müssen.


----------



## Alemarius Nexus (8. Aug 2009)

> Das schöne an S3TC/DDS ist ja, dass man sie komprimiert an die Grafikkarte schicken kann ohne sie vorher dekomprieren zu müssen.



Na mal sehen wie das dann so aussieht. Das Format, das ich laden will, ist nämlich nicht DDS. Mal hoffen, dass das kein zu großer Aufwand wird!




> Für Java3D kenne ich keine Möglichkeit. Du könntest höchstens auf JOGL/LWJGL umsteigen und dann über die verfügbaren OpenGL Funktionen die S3TCs laden und anzeigen was recht einfach ist.



Langsam glaube ich, dass das wohl tatsächlich besser ist. Ich habe JOGL bisher immer für weniger gut als Java3D gehalten, weil ich davon weniger gehört habe. Aber wies aussieht ist das sogar die bessere Wahl. Ich werds mir mal genauer ansehen.

Danke für eure Hilfe!


----------



## Noctarius (9. Aug 2009)

Im schlimmsten Fall musst du dir einen Reader für das Dateiformat schreiben und die komprimierten Grafikdaten mit passendem Flag über OpenGL Funktionen an den Grafikkartenspeicher durchreichen.


----------



## Evil-Devil (10. Aug 2009)

Naja, bevor er das macht sollte er auf eines der beiden OpenGL Bindings wechseln. Was sonst noch möglich wäre ist das DDS zu lesen und dann an ein BufferedImage zu schicken. Aber ob sich der Aufwand dafür lohnt mag ich nicht beurteilen. Einen DDS Loader zu schreiben ist jedenfalls relativ einfach.

Hab mal einen alten DDS Loader Part von mir angehängt. Der läuft via LWJGL. Hoffe das hilft dir weiter.


----------



## Alemarius Nexus (11. Aug 2009)

> Im schlimmsten Fall musst du dir einen Reader für das Dateiformat schreiben und die komprimierten Grafikdaten mit passendem Flag über OpenGL Funktionen an den Grafikkartenspeicher durchreichen.



Einen Reader dafür muss ich sowieso schreiben: Das Dateiformat ist kaum bekannt. Ich muss mich aber erstmal richtig in OpenGL (JOGL) einarbeiten um einschätzen zu können, was das dann noch für ein Aufwand ist.




> Naja, bevor er das macht sollte er auf eines der beiden OpenGL Bindings wechseln.



Habe ich getan, bzw. tue ich noch.




> Was sonst noch möglich wäre ist das DDS zu lesen und dann an ein BufferedImage zu schicken.



Wie gesagt: Es ist nicht DDS, sondern ein ziemlich unbekanntes Format, das teilweise mit DXT komprimiert ist. Die Daten der unkomprimierten Bilder dieses Typs kann ich schon auslesen und damit ein BufferedImage erzeugen. Das Problem ist wirklich nur die Kompression.




> Hab mal einen alten DDS Loader Part von mir angehängt. Der läuft via LWJGL. Hoffe das hilft dir weiter.



Ich werde ihn mir aufheben und ihn später mal studieren, wenn ich mich etwas in OpenGL eingearbeitet habe, kann mir bestimmt noch nützlich werden. Danke!


----------



## Evil-Devil (11. Aug 2009)

Wie soll denn teilweise mit DXT komprimiert sein? Wenn kann nur die ganze Textur im DXT vorliegen, da DXT unter anderem auch die MipMaps/CubeMaps und derlei verwaltet.
Das DXT Format ist sehr gut dokumentiert. Entweder im DirectX SDK schauen oder aber auf den Dev Seiten von NVidia und ATI.

Schreibst du einen Client-Reader oder um welches Spiel handelt es sich bei den Texturen? ^^


----------



## Alemarius Nexus (11. Aug 2009)

> Wie soll denn teilweise mit DXT komprimiert sein?



Sie sind natürlich ganz komprimiert, aber nicht alle, sondern nur einige davon.




> Das DXT Format ist sehr gut dokumentiert. Entweder im DirectX SDK schauen oder aber auf den Dev Seiten von NVidia und ATI.



Mal sehen, wenn die Dekompression in JOGL schon eingebaut ist, muss ich darüber ja nicht viel mehr wissen als ich sowieso schon weiß.




> Schreibst du einen Client-Reader oder um welches Spiel handelt es sich bei den Texturen? ^^



Es geht um die Texturen in GTA


----------



## Evil-Devil (11. Aug 2009)

Ok, also JOGL ist ja "nur" ein OpenGL Binding und in OpenGL gibt es die S3TC Extension bzw. in GL 1.2 ist S3TC direkt enthalten.
Du würdest deine GTA Texture entsprechend lesen und den DXT Krams entsprechend im Falle von LWJGL in einen nativen Buffer schreiben und dann via opengl an die Grafikkarte schicken.

Schau dir einfach den Loader an. Den reinen Loader Code dürfte man ohne große Probleme nach JOGL portieren dürfen und evtl. gibt es auch entsprechende JOGL Tutorials. Als LWJGL User bin ich leider nicht so sehr auf dem JOGL Pfad bewandert, außer das es halt beides OpenGL Bindings sind und sie recht nah beieinander sind.


----------

