(erled.)[D3D9] Unstetige Texturkoordinaten richtig gefiltert

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Antworten
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

(erled.)[D3D9] Unstetige Texturkoordinaten richtig gefiltert

Beitrag von Krishty »

Hi,

Mal wieder eine schöne Knobeley:

Es gab scheinbar in einer steinalten OpenGL-Version mal einen außergewöhnlichen Texture Address Mode, den ich nun emulieren muss. Der lief folgendermaßen: Man definierte einen rechteckigen Ausschnitt auf der Textur und dann wurde von der Textur nichts anderes mehr gesamplet als dieser Ausschnitt. Falls die Texturkoordinaten über- oder unterliefen, wurde sie auf den Ausschnitt zurückgewrappt.

Rendern wir z.B. ein Quad mit Texturkoordinaten von 0 bis 1 und wählen einen beliebigen aktiven Teilausschnitt mit einer Größe von width÷4 × height÷4 aus, wird der Ausschnitt 4×4 Mal auf dem Quad wiederholt anstatt die komplette Textur 1×1 Mal zu rendern. Damit kriegt man einen Texturatlas ohne Bleeding getilet (vorausgesetzt, da sind nur Rechtecke drauf), kann Texturausschnitte recyclen und Vertices sparen usw. usf. It's Magic!

Das habe ich im Pixel Shader folgendermaßen implementiert:
new_uv = fmod(uv, portion.dimensions.xy) + portion.origin.xy;
(Die Alternative wäre, on-the-fly eine neue Textur mit Portionsgröße anzulegen, den Ausschnitt rüberzukopieren, Mip-Maps zu erzeugen usw. Das muss ich aber hunderte Male pro Frame machen und kann nichts cachen. No way.)

Funktioniert an sich auch granatig … bis auf ein dummes kleines Detail: Die Filterung.
Kommt man am ganz rechten Rand des Ausschnitts an, hat man die Texturkoordinate am rechten Rand des Ausschnitts. Geht man noch einen Pixel weiter, ist man wieder am linken Ausschnitt. Und dort erkennt der Texturfilter nun (zurecht!) einen riesigen Sprung und quetscht ein Viertel der Textur in 2 Pixel.

Und hier habe ich nun keinen Plan, wie ich das wegmachen soll. Und das Ganze muss mit Pixel Shader 2.0 realisiert werden; an Integern rumpfriemeln und selber filtern ist also nicht. Obwohl man theoretisch mit ddx und ddy eine Menge reißen könnte.

Muse ist willkommen, das alte Miststück!

Gruß, Ky
Zuletzt geändert von Krishty am 26.06.2011, 17:32, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Jörg
Establishment
Beiträge: 296
Registriert: 03.12.2005, 13:06
Wohnort: Trondheim
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Jörg »

Wenn es ein bisschen Resourcen kosten darf: Einfach in eine neue Textur kopieren....
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Krishty »

Nein darf es nicht, aber führt wohl nichts dran vorbei. Wie kopiere ich einen Teil einer Textur in eine andere?

UpdateSurface() geht nur vom Systemspeicher in den Grafikspeicher. Will ich das benutzen, kann ich die Originaltexturen nicht mehr benutzen, weil sie zum Rendern nicht in D3DPOOL_SYSTEMMEM liegen dürfen.

StretchRect() geht nur vom Grafikspeicher in den Grafikspeicher. Will ich das benutzen, kriege ich meine Daten nicht mehr von der Festplatte in die Texturen, weil sich D3DPOOL_DEFAULT nicht zur erstmaligen Befüllung locken lässt.

Führt denn wirklich kein Weg daran vorbei, Staging-Texturen anzulegen, die ich dann bei jedem Lost Device nochmal neu zusammenpfriemeln darf? Ich kriege hier echt gleich einen ungerichteten Wutanfall …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Jörg
Establishment
Beiträge: 296
Registriert: 03.12.2005, 13:06
Wohnort: Trondheim
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Jörg »

Noja....USAGE_RENDERTARGET | AUTOGEN_MIPMAPS koennte auch klappen. Musst halt nur bei Device-Loss nochmal antriggern und den Fall abfangen, dass der Treiber nicht mitspielt.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Krishty »

Nö, schon versucht. Eiskalt.

Und so bricht das ganze verdammte Kartenhaus dann zusammen. Die Doku labert lang und breit davon, D3DPOOL_MANAGED würde dir deine Texturen verwalten, es schiebt sie aber bloß zum Samplen auf die GPU und ist ansonsten eine scheiß Attrape. Und wenn du D3DPOOL_MANAGED nicht verwenden kannst, stehst du sofort wieder mit dem Lost Device-Müll da und musst verkrüppelte Systemspeicherressourcen und Scratch-Textures benutzen. Woran erinnert mich das nochmal?…
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von dot »

Krishty hat geschrieben:Führt denn wirklich kein Weg daran vorbei, Staging-Texturen anzulegen [...]
Ich fürchte nicht. SYSTEMMEM <-> D3DPOOL_DEFAULT ist der einzige mir bekannte Weg um in D3D9 Daten in eine Texture zu bekommen.
Jörg
Establishment
Beiträge: 296
Registriert: 03.12.2005, 13:06
Wohnort: Trondheim
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Jörg »

oder eben per Shader...
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von dot »

Dann muss er das ganze Texture-Filtering aber selber im Shader machen...
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Krishty »

Das ist aber nur die Kopie, also Point Filtering. Da ist schon was dran. Das sollte auch mit D3D9 realisierbar sein … ob Render-Target und dynamisch oder nicht sollte für die Textur auch wumpe sein; wenn man kopieren muss ist die Leistung so oder so ruiniert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von dot »

Achso die Kopie über Shader...stimmt, das sollte gehen.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Krishty »

Ich habe der Vollständigkeit halber die Staging-Textur probiert. Und die ist etwa um den Faktor zehn langsamer als jedes Mal den Ausschnitt aus dem Systemspeicher hochzuladen. Absolut krass.

Also, um der Klarheit Willen: Ich kopiere nun am Anfang vom RAM in den VRAM, und kopiere dann jedes Mal, wenn ich einen Ausschnitt brauche, per StretchRect() von VRAM zu VRAM. Das ist langsam. Den Ausschnitt jedes Mal aus der RAM-Textur zu holen ist deutlich schneller. Wahrscheinlich, weil UpdateSurface() als Speicherkopie realisiert ist und nicht als bescheuertes Rendering wie StretchRect().
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Schrompf »

Und wenn Du das Filtern im Shader implementierst? Bilinear ist schnell gemacht, trilinear auch, alles darüber wird potentiell anstrengend. Wenn Du aber Fillrate übrig hast, wäre das doch ne schnelle Lösung. Und ich hab damals bei unserem Bloom für bestimmte Grakas manuelles Filtern einbauen müssen und war überrascht, wie wenig es sich bemerkbar gemacht hat.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Krishty »

Ja, Cat hat das auch schon vorgeschlagen. Ich müsste ddx und ddy quasi selber berechnen und könnte anhand derer entscheiden, ob der Pixel springt oder nicht. Problematisch klingt für mich dabei der Blickwinkel der Filterung: Das Delta, durch das ich die Koordinatenableitung bestimme, muss einerseits klein genug sein um auf dem Bildschirm nur einen einzigen Pixel zu verdecken, aber andererseits noch bei relativ flachen Blickwinkeln zuverlässig Sprünge erkennen können. Und Bleeding werde ich damit auch nicht los.

Ich probiere gerade, Daten der aktuellen Texturausschnitte über Draw-Calls hinwegzutransportieren, um die Ausschnitte wiederzuverwenden. Falls mir das gelingt, kriege ich die Ausschnitte von hunderten pro Frame auf ein Dutzend runter.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Zudomon »

Huhu Krishty!

Sind die Texturausschnitte immer gleich groß oder verschieden?

Was mir spontan einfallen würde, den Texturauschnitt zu kopieren. Davon habt ihr ja schon geredet, ich habe aber jetzt nicht ganz verstanden, ob es genauso wäre, wie ich es machen würde.

Du nimmst eine Rendertargettextur, die den Texturausschnit darstellt. Darein Renderst du jetzt einfach ein Fullscreenquad mit dem entsprechenden Texturausschnitt und fertig.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Krishty »

Japp, so in etwa mache ich es. Nur, dass ich direkt vom Systemspeicher kopiere statt ein Quad zu rendern oder StretchRect() zu benutzen, weil letzteres zu langsam ist.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Chromanoid »

Langsam weil du erst alles in den Grafikspeicher hochladen müsstest?
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Dirk Schulz
Establishment
Beiträge: 130
Registriert: 01.03.2009, 14:21
Alter Benutzername: frittentuete

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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? :?:
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Chromanoid »

CodingCat hat geschrieben: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?
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Dirk Schulz
Establishment
Beiträge: 130
Registriert: 01.03.2009, 14:21
Alter Benutzername: frittentuete

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Dirk Schulz »

Krishty hat geschrieben: @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. :?:
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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:
texcoords.png
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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Dirk Schulz
Establishment
Beiträge: 130
Registriert: 01.03.2009, 14:21
Alter Benutzername: frittentuete

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von Krishty »

Dirk Schulz hat geschrieben: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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Dirk Schulz
Establishment
Beiträge: 130
Registriert: 01.03.2009, 14:21
Alter Benutzername: frittentuete

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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*
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [D3D9] Unstetige Texturkoordinaten richtig gefiltert kri

Beitrag von 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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Antworten