OpenGL UV Koordinaten Oben Links ?

[Andy16823]

Ich habe nun festgestellt, dass sich bei mir die Koordinaten der Texture wie folgt befinden

Koords.png (6.43 KiB) 5898 mal betrachtet

ich habe es aber so gelernt

http://www.foerterer.com/cpp/texturen/bilder.htm und auf http://wiki.delphigl.com/index.php/Tutorial_Lektion_4 steht es wie oben in der Grafik ? was stimmt nun ?

[dot]

Der Ursprung der Texturkoordinaten ist in OpenGL links unten, so wie du es gelernt hast. Ich vermute mal, dass du beim Laden die Daten verkehrt rum in die Textur packst (OpenGL erwartet die Bilddaten zeilenweise von unten nach oben)...

[Krishty]

Für OpenGL „stimmt“, wie dot sagte, links unten mit den Bilddaten zeilenweise von unten nach oben.

Es ist halt nur eine Konvention, und verschiedene APIs machen es unterschiedlich. Oft wird von oben links ausgegangen weil

• die ersten Terminals ihren Text von oben links nach unten rechts ausgegeben haben; und
• die Kathodenstrahlröhren der alten Monitore den Bildschirm von oben links nach unten rechts abtasten

und oben-links unter diesen Umständen einfacher zu implementieren war. Für OpenGL hat man sich aber für die mathematisch sinnvollere Konvention entschieden.

[Andy16823]

Also denn Wrapper habe ich selbst erstellt. Die Texture wird so geladen

Code: Alles auswählen

		Drawing::Rectangle Rect(0,0,width, height);
		Drawing::Imaging::BitmapData^ data = image->LockBits(Rect, Drawing::Imaging::ImageLockMode::ReadOnly, Drawing::Imaging::PixelFormat::Format24bppRgb);
		glTexImage2D(target, level, internalformat, width, height, border, format, type,(void*) data->Scan0);
		image->UnlockBits(data);

[dot]

Well, there's your problem, die Scanlines einer System.Drawing.Bitmap sind wohl top-down und nicht bottom-up... ;)

[Alexander Kornrumpf]

Potentiell dumme Frage:

Wenn wir uns mal darauf einigen, dass es relativ wenig Sinn hat, das Bild im Speicher zu visualisieren: ist es dann nicht völlig egal ob ich die Zeile die ich zuerst abtaste als "oben" oder als "unten" bezeichne?

Alternative 1: Ursprung links "oben" und "oberste" Zeile wird zuerst abgetastet.
Alternative 2: Ursprung links "unten" und "unterste" Zeile wird zuerst abgetastet.

Sind die nicht äquivalent?

[dot]

Alternative 1: Ursprung links "oben" und "oberste" Zeile wird zuerst abgetastet.
Alternative 2: Ursprung links "unten" und "unterste" Zeile wird zuerst abgetastet.

Naja, sie führen for all practical purposes zum selben Ergebnis, genau dort liegt ja, wie bereits erwähnt, der Ursprung der Verwirrung des Threaderstellers. Er hat, ohne es zu merken, die Daten verkehrt rum in die Textur gepackt, beobachtet, dass die Texturkoordinaten sich offenbar verkehrt herum verhalten, was ihn dann zu dem Trugschluss geführt hat, dass das Texturkoordinatensystem wohl doch nicht seinen Ursprung unten links hat... ;)

[Alexander Kornrumpf]

Alternative 1: Ursprung links "oben" und "oberste" Zeile wird zuerst abgetastet.
Alternative 2: Ursprung links "unten" und "unterste" Zeile wird zuerst abgetastet.

Naja, sie führen for all practical purposes zum selben Ergebnis

Das dachte ich mir ja auch.

, genau dort liegt ja, wie bereits erwähnt, der Ursprung der Verwirrung des Threaderstellers... ;)

Müsste das nicht zu weniger Verwirrung führen? So wie das row-major column-major weniger verwirrend wird wenn man sich klar macht dass es dasselbe Speicherlayout ist.

Er hat, ohne es zu merken, die Daten verkehrt rum in die Textur gepackt, beobachtet, dass die Texturkoordinaten sich offenbar verkehrt herum verhalten, was ihn dann zu dem Trugschluss geführt hat, dass das Texturkoordinatensystem wohl doch nicht seinen Ursprung unten links hat... ;)

Ich verstehe eben nicht was "verkehrt herum" sein soll. Es scheint mir reine Definitionssache zu sein.

[dot]

Müsste das nicht zu weniger Verwirrung führen? So wie das row-major column-major weniger verwirrend wird wenn man sich klar macht dass es dasselbe Speicherlayout ist.

Nope, row-major und colum-major bezeichnen gerade verschiedene Speicherlayouts. Erst zusammen mit der Multiplikationsreihenfolge (also ob man Vektoren als Zeilen oder Spalten auffasst) ergibt sich wieder so ein Fall, wo zwei eigentlich unabhängige Dinge am Ende so interagieren, dass das beobachtete Verhalten äquivalent erscheint... ;)

[Alexander Kornrumpf]

Müsste das nicht zu weniger Verwirrung führen? So wie das row-major column-major weniger verwirrend wird wenn man sich klar macht dass es dasselbe Speicherlayout ist.

Nope, row-major und colum-major bezeichnen gerade verschiedene Speicherlayouts. Erst zusammen mit der Multiplikationsreihenfolge (also ob man Vektoren als Zeilen oder Spalten auffasst) ergibt sich wieder so ein Fall, wo zwei eigentlich unabhängige Dinge am Ende so interagieren, dass das beobachtete Verhalten äquivalent erscheint... ;)

Das meinte ich. Es ist hier ja genauso. Koordinatenursprung und Abtastreihenfolge sind unabhängig und interagieren.

[dot]

Die beiden Dinge sind völlig unabhängige Konzepte, lediglich die Art und Weise, wie sie interagieren führt in zwei verschiedenen möglichen Kombinationen zur gleichen Beobachtung! Am Ende landet der selbe Farbwert an der selben Stelle am Bildschirm. Die Texel, von denen die Farbwerte kommen, liegen aber z.B. immer noch an anderen Speicheradressen, gleich wie die Elemente der Matrix...

Man kann beide Varianten von mir aus als äquivalent im Sinne von "es werden am Ende die selben arithmetischen Operationen mit den selben Werten angestellt" bezeichnen, identisch sind sie aber nicht...

[Andy16823]

Ich weiß nicht in wie fern das hier rein passt, ich habe nun eine Funktion erstellt, die so ausseht

Code: Alles auswählen

	void NetGL::OpenGL::Build2DMipmaps(int target, int Level, int Width, int Height, int Format, int Type, array<int>^ data)
	{
		GLint *n_data = new GLint[data->Length];
		for(int i = 0; i < data->Length; i++)
		{
			n_data[i] = data[i];
		}
		gluBuild2DMipmaps(target, Level, Width, Height, Format, Type, n_data);
	}

Ich übergebe also ein .Net Array, das Array wird so erstellt

Code: Alles auswählen

        public int Width { get; set; }
        public int Height { get; set; }
        public int[] Pixel { get; set; }

        public Texture2D(System.Drawing.Bitmap Image)
        {
            this.Width = Image.Width;
            this.Height = Image.Height;
            this.ReadPixel(Image);
        }

        private void ReadPixel(System.Drawing.Bitmap Image)
        {
            this.Pixel = new int[this.Width * this.Height * 4];
            for (int y = 0; y < this.Height; y++)
            {
                for (int x = 0; x < this.Width; x++)
                {
                    this.Pixel[y * this.Width + x] = Image.GetPixel(x, y).R;
                    this.Pixel[y * this.Width + x + 1] = Image.GetPixel(x, y).G;
                    this.Pixel[y * this.Width + x + 2] = Image.GetPixel(x, y).B;
                    this.Pixel[y * this.Width + x + 3] = Image.GetPixel(x, y).A;
                }
            }
        }

aber als ergebniss erhalte ich nicht das bild. Zu der Frage, wie muss ich das Texturen Array Füllen ?

[Andy16823]

Habe es, so Funktioniert es

Code: Alles auswählen

        private void ReadPixel(System.Drawing.Bitmap Image)
        {
            this.Pixel = new int[this.Width * this.Height];
            for (int y = 0; y < this.Height; y++)
            {
                for (int x = 0; x < this.Width; x++)
                {
                    this.Pixel[y * this.Width + x] = Image.GetPixel(x, y).ToArgb();
                    
                }
            }
        }

[xq]

Da ihr hier .NET-Bilder verwendet, flipped die Bilder doch einfach direkt nach dem Laden:
Hier ist der Ladecode aus meinem aktuellen Spiel:

Code: Alles auswählen

private int LoadTexture(string fileName)
{
	int tex = GL.GenTexture();
	GL.BindTexture(TextureTarget.Texture2D, tex);
	using (var bmp = new Bitmap(fileName))
	{
		bmp.RotateFlip(RotateFlipType.RotateNoneFlipY);
		var data = bmp.LockBits(
			new Rectangle(0, 0, bmp.Width, bmp.Height),
			System.Drawing.Imaging.ImageLockMode.ReadOnly,
			System.Drawing.Imaging.PixelFormat.Format32bppArgb);
		GL.TexImage2D(TextureTarget.Texture2D, 0, PixelInternalFormat.Rgba, bmp.Width, bmp.Height, 0, PixelFormat.Bgra, PixelType.UnsignedByte, data.Scan0);
		bmp.UnlockBits(data);
	}
	GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureMinFilter, (int)TextureMinFilter.Nearest);
	GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureMagFilter, (int)TextureMagFilter.Nearest);
	GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureWrapR, (int)TextureWrapMode.ClampToEdge);
	GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureWrapS, (int)TextureWrapMode.ClampToEdge);
	GL.TexParameter(TextureTarget.Texture2D, TextureParameterName.TextureWrapT, (int)TextureWrapMode.ClampToEdge);
	GL.BindTexture(TextureTarget.Texture2D, 0);
	return tex;
}