(erled.)[D3D9] Unstetige Texturkoordinaten richtig gefiltert

[Chromanoid]

Langsam weil du erst alles in den Grafikspeicher hochladen müsstest?

[CodingCat]

Nein, im Gegenteil, StretchRect wäre ja genau der Weg, vollständig auf der GPU zu bleiben. Leider bietet DirectX 9 dort offensichtlich keine Möglichkeit der direkten Speicherkopie an, weshalb StretchRect tatsächlich mehr dem Rendern eines FS-Quads nahekommt (mit entsprechendem Overhead), und Krishty somit sogar mit dem Kopieren aus dem Systemspeicher schneller davonkommt.

[Dirk Schulz]

Hi,

dann kann er aber eigentlich auch gleich bei getrennten Texturen bleiben und auf den TexturAtlas verzichten. :!:

Hier ein (ziemlich hässlicher) Hack, um dem Ursprungsproblem zu begegnen:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=61602

Ich würde mir allgemein auch etwas mehr Kontrolle darüber wünschen, wie Filterung an (selbstdefinierten) Kanten bewerkstelligt wird. Sollte ja eigentlich keine Hardwarelimitierung sein, oder? :?:

[Chromanoid]

Nein, im Gegenteil, StretchRect wäre ja genau der Weg, vollständig auf der GPU zu bleiben. Leider bietet DirectX 9 dort offensichtlich keine Möglichkeit der direkten Speicherkopie an, weshalb StretchRect tatsächlich mehr dem Rendern eines FS-Quads nahekommt (mit entsprechendem Overhead), und Krishty somit sogar mit dem Kopieren aus dem Systemspeicher schneller davonkommt.

Mmh interessant, aber das mit dem Rendertarget müsste doch wesentlich schneller gehen?

[Krishty]

@Chromanoid: Cat hat schon recht … ich muss auch sagen, dass die Ausschnitte klein sind, 32×32 und so. Der Overhead, die StretchRect()-Shader zu setzen, die Quelltextur zum Lesen und zum Schreiben durch die Textureinheiten zu jagen, dann als Render Target zu entbinden und als Textur zu binden, usw ist scheinbar etwa 10× so hoch wie das simple memcpy() vom RAM in den VRAM, das UpdateSurface() durchführt.
Allerdings muss ich dazusagen, dass ich immernoch automatische Mip-Erzeugung auf die Ausschnitte anwende und sich das überhaupt nicht bemerkbar macht. Ich dachte immer, es sei so ziemlich das Gleiche wie ein StretchRect() pro zu erzeugendem Mip-Level – aber allein die Tatsache, dass Texturen zur Mip-Erzeugung nicht als Render Targets deklariert sein müssen zeigt, dass hier Optimierung am Werk ist. (Bei D3D >=10 ist das übrigens wieder anders; dort funktioniert automatische Mip-Erzeugung nur mit Render Targets).

@Dirk Schulz: Nein, das ist keine Lösung für das Ursprungsproblem – der Texturausschnitt darf ja beliebig oft wiederholt (getilet) werden; das Problem ist da nicht primär das Bleeding an den Rändern, sondern dass ein äußerst niedriges Mip-Level gewählt wird um den Sprung vom einen Rand der Textur zum anderen vermeintlich glattzufiltern … und dadurch wird die komplette Tile in eine zwei Pixel breite Linie geschmiert.

[Dirk Schulz]

@Dirk Schulz: Nein, das ist keine Lösung für das Ursprungsproblem – der Texturausschnitt darf ja beliebig oft wiederholt (getilet) werden; das Problem ist da nicht primär das Bleeding an den Rändern, sondern dass ein äußerst niedriges Mip-Level gewählt wird um den Sprung vom einen Rand der Textur zum anderen vermeintlich glattzufiltern … und dadurch wird die komplette Tile in eine zwei Pixel breite Linie geschmiert.

Mit AddressU / V = Clamp und/oder Miplevel = None sollte das aber eigentlich nicht passieren, oder? Tiling bekommt man da ja immernoch durch Texturkoordinaten von (0-1)*Texturwiederholung. :?:

[Krishty]

Hier ist ein 1D-Beispiel, in dem man immer wieder die drei rechten Texel einer fünf Pixel breiten Textur wiederholt (drei und fünf exemplarisch damit die Zahlen rund bleiben) und dabei je einen Texel versaut:

Reale Hardware nutzt ein Koordinatendelta auf zwei Pixeln, also sind dort auch zwei Pixel versaut statt einem. Ist aber im Beispiel schlecht darstellbar wegen den ungeraden Zahlen.

Das lässt sich wohl nur verhindern, indem man auf alles außer bilineare Filterung ohne Mip-Levels verzichtet. Und die anisotrope Filterung ist mir die Kopie dann doch wert.

[Dirk Schulz]

genau das Problem wird mit der im Link beschriebenen Technik verhindert. Wenn du bei 1.0 angekommen bist, wird das Filtering an Stelle "1.01" (bildlich) weitermachen, da die Textur dort nicht zuende ist. Wie du auf dem Texturatlas sehen kannst, fängt dort die Textur wieder von vorne an. Dasselbe im negativen Sinne bei kleiner 0.0 .

Das Hauptproblem ist eben, dass die Hälfte des Texturplatzes verschenkt wird. Aus einem 64x64 Atlas wird ein 32x32 Atlas mit "Filterpuffern" an allen Seiten.

[Krishty]

genau das Problem wird mit der im Link beschriebenen Technik verhindert. Wenn du bei 1.0 angekommen bist, wird das Filtering an Stelle "1.01" (bildlich) weitermachen, da die Textur dort nicht zuende ist.

Nein, wird es nicht. Der Nachbar von 1,0 ist kein bildliches 1,01 sondern 0,5.

Bedenk, dass ich hier keine seperaten Dreiecke habe, wo das Linke mit 1,0 aufhört und das Rechte mit 0,5 anfängt – ich habe hier pure Texturkoordinaten, die meist um bildliche 0,01 größer werden, aber am Ende jeder Kachelung einen Sprung von -0,5 machen.

[Dirk Schulz]

hm ... wird denn bei der Filterung der Shader durchlaufen (und damit in den passenden Wertebereich für den Atlasindex geclamped)?

Habe manchmal das Gefühl, dass eben nicht der Shader durchlaufen wird, sondern einfach die letzten Texturkoordinaten leicht verschoben erneut gesampled werden. :?:


Die Texturkoordinaten vom Mesh können ja sein wie sie wollen, der zu benutzende Atlas kann ja über den Shader definiert werden.

Zur Not übergibt man ihm noch eine Variable, wie oft die Textur wiederholt werden soll.

[Krishty]

Nein, aber das Delta zwischen zwei Pixeln wird genutzt um zu bestimmen, welches Mip-Level gesamplet wird (bei bilinearem Filter) und wie viele Samples wo auf der Textur benötigt werden (beim Anisotropen). Und da, wo die Textur springt, ist das Delta nunmal -0,5 – und deshalb wird das zweitkleinste Mip-Level genommen (beim bilinearen Filter, weil dann 0,5 Teile der Textur in einen Pixel passen) oder der Durchschnitt aus allen Texeln zwischen 0,5 und 1 (beim Anisotropen).

Und diese Koordinaten kommen ja bereits aus einem Shader, der normale Koordinaten auf Atlaskoordinaten übertragen hat.

[Zudomon]

Um mal etwas vom Thema abzulenken... ich fände es generell sehr interessant, wenn man es wirklich schaffen könnte, direkt über den Shader so einen Texturatlas zu adressieren, also mit wrap und alles. Weil wenn man das vernünftig hinbekäme, dann könnte man ja mal probieren, mal von den rechteckigen Charts Abstand zu nehmen. Wenn man dann noch angeben könnte, wo die Texturkoordinaten weitergehen, wenn man den Bereich eines Charts verlässt, dann könnte man doch letztendlich auch Seams komplett vermeiden, was sehr geil wäre. Okay, ich gebe zu, das wäre dann doch noch ein langer Weg.

Nun aber wieder zurück zum Thema... *g*

[Krishty]

Dich hält doch, zumindest ab D3D >=10, nichts davon ab, die Abschnittsdaten eines Texturatlas per Puffer an den Pixel Shader zu binden, pro Dreieck zu adressieren und die Filterung entsprechend dieser Daten manuell vorzunehmen?

[Krishty]

Sooo … ich bin vorerst dabei geblieben, eine Kopie der Textur im Systemspeicher (D3DPOOL_SYSTEMMEM) zu halten und den benötigten Ausschnitt per UpdateSurface() just-in-time auf die GPU hochzuladen. Damit bin ich zwar persönlich nicht zufrieden, aber die Ausschnitte werden perfekt gefiltert und derzeit ist noch alles im flüssigen Bereich … und letztendlich muss das Projekt auch weitergehen. Ich danke euch für eure Hilfe.