Texturproblem
-
hi,
Hab grad ne schöne Lifebar gebastelt und stelle nun fest, dass die Textur am Rand (nur eim Rendern so) einen roten Streifen hat. Weiß einer woran das liegen kann?
DANKE!
-
Wie wärs mal mit mehr Informationen ?
-
ok,
ich hab mit der orthogalen Projektion ein Rechteck mit Textur gerendert (mit Transparenz: Farbe die Transparent wird = weiß;andere enthaltene Farben = grau). Da das Rechteck mal bei einem Game anzeigen soll, wieviel Leben der Spieler noch hat, bewegt Rechteck sich nicht.=>Mir fällt nun auf, dass am oberen und rechten Rand schöne bunte Streifen sind, die da nich sein sollten (bzw. in der Textur nicht enthalten sind) und das gefällt mir gar nich!
-
mit Direct3D 9
-
Das liegt meistens daran, wie die Grafikkarte die Texturkoordinaten interpretiert. Die Streifen stammen wohl vom anderen Ende der Textur. Nimm nicht Texturkoordinaten wie (0, 0) oder (1, 1), sondern (0.01, 0.01) und (0.99, 0.99). Wenn die Karten versuchen, die Pixelkoordinaten zu berechnen und dabei dann Filtering benutzen, können ungewollte Pixel mit ins Spiel kommen.
-
hi,
danke für die antwort!
Jetzt sind die Streifen weg!!!
Wie interpretiert die Grafikkarte den die Texturkoordinaten 0.0 u. 1.0?
Danke!
-
Original erstellt von blue:
**hi,danke für die antwort!
Jetzt sind die Streifen weg!!!
Wie interpretiert die Grafikkarte den die Texturkoordinaten 0.0 u. 1.0?
Danke!**Also 0.0f, und die Farbe bei bilinearen Filtern wird dann aus den 4 umgebenen Pixeln zusammengemischt.
-
Und da es ja links von 0 keinen Pixel mehr gibt, kommt das Wrapping zum Einsatz und er nimmt den vom rechten Rand.
-
Hi,
so lange die Wiederholung der Textur <= 1.0f ist und man kein Offset hat gibt es dafür das Texture Clamping, mit dem die Koordinaten in den Bereich 0.0f bis 1.0f gezwungen werden. Das sollte auch das Filtering nicht zerstören können
Ciao,
Stefan
-
@Stefan Zerbst
Wie benutzt man Texture Clamping
beispiele plz
-
Mit Texture Clamping kannst Du aber auch keine gekachelten Texturen mehr verwenden. Es geht so:
pD3DDevice->SetSamplerState(0, D3DSAMP_ADDRESSU, D3DTADDRESS_CLAMP); pD3DDevice->SetSamplerState(0, D3DSAMP_ADDRESSV, D3DTADDRESS_CLAMP);
-
Original erstellt von Stefan Zerbst:
**Hi,so lange die Wiederholung der Textur <= 1.0f ist und man kein Offset hat gibt es dafür das Texture Clamping, mit dem die Koordinaten in den Bereich 0.0f bis 1.0f gezwungen werden. Das sollte auch das Filtering nicht zerstören können
Ciao,
Stefan**Der Bereich ist geringer als 0 - 1, da wie oben schon erwähnt, bei 0 (und auch 1), Pixel "von der anderen Seiten" gefiltert werden. Die Koordinaten werden stets auf 0.5 / Texturewidth-height bis 1 - 0.5 / Texturewidth-height geclamped.
-
Hi,
D3DTADDRESS_CLAMP
Texture coordinates outside the range [0.0, 1.0] are set to the texture color at 0.0 or 1.0, respectively.Aber vielleicht irrt sich die DirectX SDK Doku ja auch in diesem Punkt (wie in einigen anderen...)
Es stimmt also nicht, dass die Koordinaten beschränkt werden, sondern die Farbe wird entsprechend gesetzt damit kein Farbumbruch entsteht. Ich hab mich oben also etwas schlampig ausgedrückt.
Ciao,
Stefan[ Dieser Beitrag wurde am 13.02.2003 um 18:32 Uhr von Stefan Zerbst editiert. ]
-
Original erstellt von Stefan Zerbst:
**Hi,Aber vielleicht irrt sich die DirectX SDK Doku ja auch in diesem Punkt (wie in einigen anderen...)
Es stimmt also nicht, dass die Koordinaten beschränkt werden, sondern die Farbe wird entsprechend gesetzt damit kein Farbumbruch entsteht. Ich hab mich oben also etwas schlampig ausgedrückt.
Ciao,
Stefan**Aber die Farbe bei 0.0 / 1.0 ist doch auch wieder die Mischfarbe. Hört sich für mich also falsch an, da die benutzte Farbe eindeutig die Farbe des letzten Pixels ist, und nicht etwa wie bei GL_CLAMP ein 50% Blend mit der Randfarbe.
-
Hi,
bei (bi-)linearem Filtering hatte ich nie Probleme diese Farbfehler durch Aktivierung von Clamping in den Griff zu bekommen, da beim Filtern eben nicht der Farbwert des Pixels von der anderen Seite verwendet wird, jedenfalls nicht bei Direct3D.
Der einzige Nachteil ist eben, dass man das nicht bei Texture Repeat oder Offset einsetzen kann.
Ciao,
Stefan
-
Original erstellt von Stefan Zerbst:
**da beim Filtern eben nicht der Farbwert des Pixels von der anderen Seite verwendet wird, jedenfalls nicht bei Direct3D.
**Also wird nicht die Farbe bei 0.0 genommen, sondern die bei den oben genannten Koordinaten. Da diese in der Mitte des Texels liegen, ist dies keine Mischfarbe. Ausserdem wird bei Clamping nicht der Farbwert von der anderen Seite genommen, sondern höchstens der aus dem Randfarbe bzw. dem (speziell gesetzten) Texturrand.
Übrigens macht es keinen Unterschied, ob man die Farbe an einer bestimmten Koordinate nimmt, oder "nur" die Koordinaten auf diesen Wert gesetzt werden, damit wird dann nämlich ebenfalls diese Farbe gewählt. Man kann also sagen, die Aussage in der DXDoku ist genauso richtig oder falsch wie deine.
Bye, TGGC
-
hi,
Schon wieder n problem mit der Textur!
An den übergängen von transparenter zur nicht-transparenten farbe werden transparente und nicht-transparente farbe gemischt (glaub ich, da farben entstegen, die in meiner textur nicht enthalten sind). Wie kann man dieses mischen unterbinden?
Danke für eure Antworten!
-
Hi,
auch das ist ein Filterproblem, weil beim Interpolieren der Farbwerte für einen Pixel auch Texel verwendet werden, die Transparenz beinhalten, dann aber auch einen untransparenten Pixel mitinterpoliert werden. An den transparenten Stellen der Textur sollte man daher keine wilde Farbe verwenden, sondern ein einfaches weiss.
Ciao,
Stefan
