Hallo,

in meinem Programm wird ein Rechteck (bestehend aus zwei Dreiecken) gezeichnet. Dem Rechteck wurde dabei folgende Textur zugewiesen:
- https://drive.google.com/file/d/1vvfLY1 ... wPi0u/view

Der untere Teil der Textur ist dabei transparent. Wenn ich das Rechteck mit der Textur drauf nun zeichne, so sieht man am unteren Rand eine dunkle (hellgraue) Linie.

Hier ein Bild davon:
- https://drive.google.com/file/d/12iFim9 ... HbqsL/view

Es scheint so zu sein, dass die Texturpixel von der Oberseite des Rechtecks auf die Unterseite des Rechtecks übertragen werden. Warum auch immer, ich kann es mir nicht erklären und möchte diese Linie nun unbedingt wegbringen.

Das Problem tritt dabei immer auf, wenn ich GL_LINEAR verwende:
GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MIN_FILTER, GLES20.GL_LINEAR );
GLES20.glTexParameteri(GLES20.GL_TEXTURE_2D, GLES20.GL_TEXTURE_MAG_FILTER, GLES20.GL_LINEAR );

Wenn ich GL_NEAREST verwende, so ist die Linie weg. Dafür sind dann die einzelnen Pixel der Textur sehr stark zu sehen. Es ist somit auch keine wirkliche Alternative.

Könnt ihr mir da weiterhelfen? Vielen Dank schon mal für eure Hilfe.


LG arenas

In onDrawFrame() wird das Rechteck, bzw. die beiden Dreiecke mit folgendem Code gezeichnet:




Habe die Vermutung, dass das Problem auch mit dem Blending zusammenhängen könnte. Was meint ihr?

Überprüfe mal deine Texturkoordinaten. Sind die irgendwo (ein ganz kleines bisschen) größer als 1.0 oder kleiner als 0.0? Wenn ja und wenn du Kachelung mit glTexParameter aktiviert hast, dann könnte das zu dem beschriebenen Problem führen. In dem Fall würde auch GL_CLAMP_TO_EDGE statt GL_REPEAT für GL_TEXTURE_WRAP_S und GL_TEXTURE_WRAP_T Abhilfe bringen.

PS: Üblicherweise arbeitet man übrigens mit Texturen, die quadratisch sind und deren Seitenlänge 2^x ist (also 128, 256, 512 usw.). Das vermeidet Probleme u.a. beim Mipmapping.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Das war vermutlich das Problem, habe jetzt folgende Zeilen eingefügt und das Problem scheint weg zu sein:


GL_REPEAT scheint die Voreinstellung zu sein, die standardmäßig aktiv ist. Nun wurde diese Einstellung durch GL_CLAMP_TO_EDGE ersetzt und es scheint zu funktionieren.




Habe irgendwo im Netz gelesen, dass quadratische Texturen seit OpenGL 2.0 (oder so ähnlich) nicht mehr nötig sind. Sollte man trotzdem immer noch quadratische Texturen verwenden?


Vielen Dank glAwesome, du hast mir sehr geholfen. War schon total verzweifelt. Vielen Dank.

Versuche mal GL_CLAMP_TO_EDGE durch GL_CLAMP_TO_BORDER zu ersetzen.
Sieh auch folgendes: https://open.gl/textures
Da sieht man den Unterschied sehr gut.

Nötig sind sie bei neueren OpenGL-Versionen nicht mehr, funktionieren tun auch unregelmässige Texturen. Aber wie der Vorredner schon schreibt nicht optimal. Evtl. kann es eine Geschwindigkeitseinbusse geben, dies müsste man ausprobieren. Ob es zB. mit 512x128 auch nicht Optimal ist, kann ich nicht sagen.
Bei Cubemap versagt es bei mir auch mit modernem OpenGL.

_________________
OpenGL

Puh, ehrlich gesagt kann ich dir außer den CubeMaps kein konkretes Beispiel nennen, wo nicht-quadratische Texturen definitiv Probleme machen. Ich weiß nur, dass ich mal welche hatte und seitdem meide ich sie. Ist vielleicht nur mein altmodisches Bauchgefühl. Also ja, modernes OpenGL unterstützt das.

Das mit dem Mipmapping bezog sich auf NPOT-Texturen.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Man müsste mal einen Speed-Test machen. Generell liebt ein Computer Ausrichtungen. Ich könnte mir vorstellen, das er bei einer 2er Potenz schneller rechnen kann. Eine Division/Multiplikation mit 2/4/8/16/... geht um einiges schneller als eine ungerade Zahl, da nur geschiftet werde muss.

_________________
OpenGL

@mathias: Jetzt vermischst du aber zwei Dinge. Das eine sind NPOT-Texturen. Das andere sind nicht-quadratische Texturen, also welche, bei denen die Breite nicht gleich der Höhe ist (wiederum was anderes sind Rectangle Textures). Mein Text, den du zitiert hast, bezieht sich auf nicht-quadratische Texturen. Dein Kommentar hingegen auf NPOT-Texturen.

Den Vorteil von POT-Texturen sehe ich (neben dem sauberen Mipmapping natürlich) eher darin, dass die Zeilen einer Textur im Grafikspeicher genau an geraden Addressen ausgerichtet werden können und keine Löcher dazwischen entstehen. Aber ich bezweifle, dass sich dies auch praktisch in der Performance niederschlägt.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Verstehe ich es richtig, POT sind Texturen, welche solche Formate haben: 128x512, 1024x64, 32x128, ... ?
Und eine NPOT ist 234x567, 734x838, ... ?

Rectangle Texture, dies müsste ich mal genauer angucken, davon habe ich nie gehört.
Erstelle tut man die angeblich so:

_________________
OpenGL

Ja. Und 200x200 ist auch NPOT (nur als Beispiel, dass quadratisch und NPOT auch gleichzeitig geht).

Nein, lohnt sich nicht. Um den verlinkten Artikel zu zitiern:

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Dies hätte ich vermutet, die hätte ich erwähnen sollen.

Das habe ich fast vermutet, Google liefert nichts gescheites.
Der einzige Nutzen den ich vorstellen kann ist, eine kleine Textur erscheint klein und eine Grosse gross.

_________________
OpenGL