Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
ich nutze fast nur noch komprimierte Texturen. Containerformat entweder DDS oder KTX, zum Komprimieren nutze ich die PowerVR Tex Tools.
Tutorial brauchts eigentlich keins. Sinn und Zweck ist es ja die Daten dann komprimiert ohne umwandeln direkt auf die GPU zu schieben. Also einfach Laden und direkt zur GPU hochladen sofern die das Format kann.
Welches Format man verwendet muss man selbst entscheiden, Kompressionsstufen gibt es bei jedem Format, in unterschiedlicher Granularität. Format gibt es ganz viele.
Welches man nutzt hängt dann halt auch davon ab was die GPU kann. Also z.B. BC (DXT, S3TC), ASTC, ETC, etc. ASTC z.B. bietet recht viele Kompressionsstufen und ist damit flexibler als DXT/S3TC.
Gibt auch spezielle Format für z.B. Normalmaps, bei denen die normalen komprimierten Format nicht so toll sind.
Was für ein Format würdest du für Android wählen, da sollte man nach meines wissens auf den Speicherverbrauch gucken. Gibt es auch ein Format welches so effizient komprimiert wir JPG ?
Gibt es auch ein Format welches so effizient komprimiert wir JPG ?
JPG ist afaik eine ganz normale verlustbehaftete Blockkompression. Also genauso wie z.B. ETC oder DXT. Aber effizient ist JPG ja nur auf der Platte, da keine GPU ein solches Format kennt. ETC sollte hier eigentlich ganz ordentlich was in Sachen Bandbreite bringen, und auch beim Laden sehr viel schneller sein da man es direkt in den VRAM schieben kann.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
mathias hat geschrieben:
Zitat:
Unter Android ist die ETC-Variante am weitesten verbreitet (Liste mit komprimierten Formaten unter Android)
So wie ich sehe, ist das ETC1_RGB8_OES am meisten verbreitet. Aber am Namen an, wird dies wohl keinen Alpha-Kanal unterstützen.
Ja, das stimmt leider. Komprimierte Formate mit Alpha-Kanal gibt es unter Android leider nicht weit verbreitet. Man muss also basteln, z.B. wie hier beschrieben.
Schön wäre ein Format gewesen, das unter Android, WebGL und Desktop gleich gut funktionieren würde, so das ich immer die gleichen Rohdaten verwenden könnte.
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Naja, betrachte es mal aus diesem Blickwinkel: Im Allgemeinen musst du für jede Platform schon irgendwo Weichen einbauen, oft schon zur Compiletime (linke ich jetzt die AndroidEngine oder die DesktopEngine klasse?). In diesen Fällen sind unterscheidungen Abhängig von der Plattform ganz normal – also warum nicht auch für Daten?
Am Anfang will man die Bilddaten sowieso verlustfrei vorliegen haben, z.B. für den Fall, dass mal eine Änderung notwendig ist. Da man für die unterschiedlichen Targets meist unterschiedliche Binaries erzeugt, ist das dann Sache des Buildsystems, die Bilder beim Bauen in das richtige Format für das Target zu konvertieren. So wäre zumindest mein Ansatz. Mit CMake oder dergleichen und einem passenden Umwandlungstool sollte das trivial sein.
Das kann man dann auch auf Modelle weiterspinnen und für Android z.B. niedrigere Polygonzahlen deployen, indem man sich ein kleines Tool baut, was halt entweder Full-Blown ein Blenderskript auf die Daten draufwirft oder halt die Daten z.B. in surface_mesh lädt, einmal simplify darauf aufruft und wieder rausdumpt.
viele Grüße, Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.