Motherboard Forums


Reply
Thread Tools Display Modes

Strange vertical line.(texture mapping test).

 
 





















Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 05:14 AM


Hello,

There is a strange vertical line visible during a texture mapping test, a
screenshot can be seen here:

http://members.home.nl/hbthoupperman...rticalLine.PNG

What do you make of this ?

Driver bug or programming bug ?

Some details about the code:

500 by 400 verteces are draw to OpenGL. (0 to 499 and 0 to 399)

The texture coordinates are set to X/(500-1) and Y/(500-1)

Red = (X/(500-1)) * 255
Green = (Y/(400-1)) * 255
Blue = 255

Image uploaded to gfx card with:

glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, mTextureWidth[vTextureIndex],
mTextureHeight[vTextureIndex]-1, 0, GL_RGBA, GL_UNSIGNED_BYTE,
mTexture[vTextureIndex]);

(Was testing height-1 during screenshot but doesn't matter. problem
remains.)

Other settings are:

// after a texture is bound it's settings can be set.
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST );

// use only original texture no mipmap levels
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_LOD, 0 );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAX_LOD, 0 );

// sets the mipmap levels to just one/original zero
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 0 );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0 );

// don't use border texels.
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );

// turn mipmapping off just in case.
glTexParameteri( GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_FALSE);


glViewport(0,0,OpenGLv2.Width,OpenGLv2.Height); //
Resetuje aktuální nastavení
glMatrixMode(GL_PROJECTION);
glLoadIdentity;

gluOrtho2D(0.0-0.5, OpenGLv2.Width-0.5, OpenGLv2.Height-0.5, 0.0 - 0.5);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity;

glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
// Smaze obrazovku

glBegin(GL_POINTS);
for for etc
glVertex3f( vX, vY, 0 ); // could be 2f as well for 2d version
tried glVertex2f too... still strange vertical line...
end end
glEnd;

Vertex.cg:

float4x4 WorldViewProj : WorldViewProjection;

struct TVertexShaderIn
{
float3 mPosition : POSITION;
float2 mTextureCoordinate0 : TEXCOORD0;
};

struct TVertexShaderOut
{
float4 mPosition : POSITION;
float2 mTextureCoordinate0 : TEXCOORD0;
};

// void routines not supported by nvidia shader debugger
/*
void TVertexShader_Main( in TVertexShaderIn ParaIn , out TVertexShaderOut
ParaOut )
{
ParaOut.mPosition = mul(WorldViewProj, float4(ParaIn.mPosition.xyz, 1.0));
ParaOut.mTextureCoordinate0 = ParaIn.mTextureCoordinate0;
}
*/

// return routines/functions do work in nvidia shader debugger:
TVertexShaderOut TVertexShader_Main( in TVertexShaderIn ParaIn )
{
TVertexShaderOut ParaOut;

ParaOut.mPosition = mul(WorldViewProj, float4(ParaIn.mPosition.xyz, 1.0));
ParaOut.mTextureCoordinate0 = ParaIn.mTextureCoordinate0;
// ParaOut.mTextureCoordinate0.x = ParaIn.mPosition.x;
// ParaOut.mTextureCoordinate0.y = ParaIn.mPosition.y;

return ParaOut;
}


Pixel.cg:

/*
texture SpaceShipTexture
<
string ResourceName = ""; // must be set in fx composer gui/properties.
string UIName = "SpaceShipTexture";
string ResourceType = "2D";
>;

*/
sampler2D mTexture = sampler_state
{
// Texture = <SpaceShipTexture>;
// MinFilter = Linear;
// MipFilter = Linear;
// MagFilter = Linear;
// AddressU = Clamp;
// AddressV = Clamp;
};

struct TPixelShaderIn
{
float2 mPosition : TEXCOORD0;
const uniform sampler2D mTexture;

};

struct TPixelShaderOut
{
float4 mColor : COLOR;
};

// void not supported by nvidia shader debugger
/*
void TPixelShader_Main( in TPixelShaderIn ParaIn, out TPixelShaderOut
ParaOut )
{
ParaOut.mColor = tex2D( SpaceShipSampler2D, ParaIn.mPosition );
}
*/

float gPI = 3.1415926535897932384626433832795;

float gSeconds : TIME;

// return routines/functions do work in nvidia shader debugger:
TPixelShaderOut TPixelShader_Main( in TPixelShaderIn ParaIn )
{
TPixelShaderOut ParaOut;

float4 vTexel;
float4 vOutput;

// vOutput.x = ParaIn.mPosition.x/500.0; // ParaIn.mPosition.x;
// vOutput.y = ParaIn.mPosition.y/500.0;

vTexel = tex2D( mTexture, ParaIn.mPosition );

vOutput.x = vTexel.x;
vOutput.y = vTexel.y;
vOutput.z = 1.0;

ParaOut.mColor = vOutput;

return ParaOut;
}

Any idea what's wrong ???????????????????????

(Please no driver bug ?? Me praying...)

Doesn't seem like I am doing anything wrong... code is messy... but I don't
see an obvious mistake or anything ?!

I pretty much tried changing everything like +0.5 or -0.5... line doesn't go
away ?!?

Try zooming in on the line and you ll see it are actually pixels and not
just monitor artifact !

I WANT THIS VERTICAL LINE TERMINATED !

HEEEELLPPPP

Bye,
Skybuck.


 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 05:23 AM
When I change these two lines

glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );

to this:

glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_BORDER );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_BORDER );

Then two blue lines become visible... one vertical line on the left
and one horizontal line on the bottom...

I set border to zero in glTexImage2D... so kinda strange ?!?

I think opengl might think that there is a border... and ignore/overwrite
the border in glTexImage2D ?

Anyway... both situations don't solve my problem... I want all strange lines
gone !

Maybe I need to use another format for glTexImage2D ?

Bye,
Skybuck.


 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 05:25 AM


"Skybuck Flying" <> wrote in message
news:59c97$4ac18bb3$d53372a9$ b.home.nl...
> When I change these two lines
>
> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
>
> to this:
>
> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_BORDER );
> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_BORDER );
>
> Then two blue lines become visible... one vertical line on the left
> and one horizontal line on the bottom...


The following two lines also produce the strange vertical line as seen in
the picture:

glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP );

Bye,
Skybuck.



 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 05:29 AM

"Skybuck Flying" <> wrote in message
news:8efdc$4ac18c29$d53372a9$ b.home.nl...
>
>
> "Skybuck Flying" <> wrote in message
> news:59c97$4ac18bb3$d53372a9$ b.home.nl...
>> When I change these two lines
>>
>> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
>> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
>>
>> to this:
>>
>> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_BORDER );
>> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_BORDER );
>>
>> Then two blue lines become visible... one vertical line on the left
>> and one horizontal line on the bottom...

>
> The following two lines also produce the strange vertical line as seen in
> the picture:
>
> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP );
> glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP );


The following two lines produce a strange horizontal line at the bottom...
colored line in the picture:

glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT );

For now I am guessing somehow the texture coordinates are fishy ?

Or it's some kind of driver bug...

I don't really want texture coordinates ranging from 0 to 1

I would like to use simple integer coordinates like 0 to 499 and 0 to 399

Maybe that will make things look better... ? hmm.

But then first I need to figure out how to do that... maybe simply stuff
vertex coordinates into output or so instead of tex coordinates... or maybe
there is a special pixel format for it or special opengl extension... I
think I did see something but not sure.

Bye,
Skybuck.


 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 06:02 AM
I am doing some further testing to figure out what's wrong.

Vertex shader has been changed to output vertex coordinates as texture
coordinates for pixel shader.

Pixel shader does the following:
vTexel = tex2D( mTexture, float2( ParaIn.mPosition.x/500,
ParaIn.mPosition.y/400) );

Comparing the output on the screen to the texture in memory the following
can be seen for the first pixel:
Screen color.mRed = 0;
Texel color.mRed = 1;

This is strange...

Could be a weird rounding error somewhere...

Maybe rounding error in shader or rounding error in my texture filler.

Maybe trunc should be used or so ?

Hmm... gotta figure out what's going on... bit boring but ok.

Shitty floating points !

Maybe I can keep it simple and just change shader to integers or so ?!?!?

Bye,
Skybuck.



 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 06:08 AM
Let's all do the calculations shall we ?

Texture.mRed is set by the following delphi formula:

Round( (vTexelX / (mTextureWidth[vTextureIndex]-1)) * 255 );

Round( ( 0 / (500-1)) * 255 );

0/499 = 0 * 255 = 0;

According to my manual calculations the texel should be 0.

Yet Delphi shows it to be 1 ?!?!?!?!?!?!?!?!?!?!?!?!?

WTF ?!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

WEIRD.

Something really weird is going on here...

Doesn't mean that this was the original problem... this could just be an
extra weird bug ?!

****y ?!

WOW

I can't do math.. or something is really ****ed up ! =D

Gotta investigate further !

Bye,
Skybuck.


 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 06:12 AM
Ok,

I made a wrong assumption... I was assuming the first pixel coordinate was
already showing a difference (0,0)...

That is not the case... this time I displayed x,y coordinates and the
following pixel is the first one with a difference:

So new information is:

X:1 Y: 0
screen.red = 0
texel.red = 1

In my next posting I will investigate this !

Bye,
Skybuck.


 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 06:19 AM

"Skybuck Flying" <> wrote in message
news:4e7f6$4ac19748$d53372a9$ .home.nl...
> Ok,
>
> I made a wrong assumption... I was assuming the first pixel coordinate was
> already showing a difference (0,0)...
>
> That is not the case... this time I displayed x,y coordinates and the
> following pixel is the first one with a difference:
>
> So new information is:
>
> X:1 Y: 0
> screen.red = 0
> texel.red = 1


Let's first verify the texel.red also to understand it better:

Round( (vTexelX / (mTextureWidth[vTextureIndex]-1)) * 255 )

Round( (1 / (500-1) * 255 )

1/499 = 0.0020040080160320641282565130260521 * 255 =
0.51102204408817635270541082164329

Holyshit ?!

The difference between 0 and 1 is only 0.011 or so...

That's indeed very little. But delphi does it correctly... it rounds up.

Now let's see what happens in shader:
Vertex shader probably doesn't do much expect pass the coordinate (1,0) on
to pixel shader.

Pixel shader does following:

float2( ParaIn.mPosition.x/500, ParaIn.mPosition.y/400)

(1/500, 0 / 400)

I think I see problem here... the positions range from 0 to 499 so to get
coordinates from 0 to 1... it would have to be divide by 499...

Also I am not using floating point divisions... /500 = integer division
****ing **** !

So I should correct code to

x/499.0

But just for kicks let's see what

1/500 would do:

If it was floating point then: 0.002

However it's probably integer so it's: 0

That explains wrong texel coordinate...

Hmmm...

Well since all positions are from 0 to 499 it probably doesn't matter much
except maybe for these case...

It's kinda weird... I am surprised it works at all... if it truely was
division by integer.. then shouldn't it have returned 0 only ?!?!?!?

Really weird...

Anyway gonna try and fix it first to see what happens ?!

Bye,
Skybuck.


 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 06:24 AM
Ok,

Now that the shader has been corrected... the output matches the texture
input.

I am still kinda surprised about the division...

Anyway /499 as well as /499.0 both work flawlessly...

Maybe if it's a float it already does a floating point division that could
explain it.

Anyway I would still like to pass the texture coordinates instead of the
vertex coordinates...

However it seems to texture coordinates in the vertex shader or "normalized"
?!?!?

I wonder if there is any way to get rid of it...

Also I would have to "normalize" the texture coordinates my self in tex2D as
well...

Costing expensive divisions ? or maybe the free ? But I don't think so !

A tex2d integer version would be nice...
as well as pixel shaders which can return rgba in byte format or so...

Is this possible or too much to ask for me wonders ? hmm...

Bye,
Skybuck.


 
Reply With Quote
 
Skybuck Flying
Guest
Posts: n/a

 
      09-29-2009, 07:19 AM
Hello,

The GPGPU tutorial which I have been studieing/examining as well has an
interesting section:

if (textureParameters.texTarget = GL_TEXTURE_2D) then
begin
// render with normalized texcoords
glBegin(GL_QUADS);
glTexCoord2f(0.0, 0.0);
glVertex2f(0.0, 0.0);
glTexCoord2f(1.0, 0.0);
glVertex2f(texSize, 0.0);
glTexCoord2f(1.0, 1.0);
glVertex2f(texSize, texSize);
glTexCoord2f(0.0, 1.0);
glVertex2f(0.0, texSize);
glEnd();
end else
begin
// render with unnormalized texcoords
glBegin(GL_QUADS);
glTexCoord2f(0.0, 0.0);
glVertex2f(0.0, 0.0);
glTexCoord2f(texSize, 0.0);
glVertex2f(texSize, 0.0);
glTexCoord2f(texSize, texSize);
glVertex2f(texSize, texSize);
glTexCoord2f(0.0, texSize);
glVertex2f(0.0, texSize);
glEnd();
end;

According to this code GL_TEXTURE_2D is always normalized...

Which would mean using any other texture format would not be normalized ?!


I know this format works:
rect_arb_rgba_32.texTarget := GL_TEXTURE_RECTANGLE_ARB;
rect_arb_rgba_32.texInternalFormat := GL_RGBA32F_ARB;
rect_arb_rgba_32.texFormat := GL_RGBA;

and this one too (twice as fast but less precision)

rect_arb_rgba_16.name := 'TEXRECT - float_ARB - RGBA - 16';
rect_arb_rgba_16.texTarget := GL_TEXTURE_RECTANGLE_ARB;
rect_arb_rgba_16.texInternalFormat := GL_RGBA16F_ARB;
rect_arb_rgba_16.texFormat := GL_RGBA;

According to the documentation these would be slower but my benchmark today
shows that these one's are slighty faster... that difference doesn't have to
mean much... but it's nice anyway.

One last remark about the naming:

GL_TEXTURE_RECTANGLE_ARB

ARB looks very confusing to me ! I am like: "WTF IS THAT **** ?"

Is it alpha red blue ?

I don't think that's the case.. ARB is some abbrevation for some
organization that makes this extension...

Let's hope that there will never be a company which calls itself: RGBA

I shall give ARB a try and hope that it works on as many cards as possible !


Bye,
Skybuck


 
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best Prometric Test center in Bangalore (like Microsoft, SunMicrosystems, CISCO, Exin - ITIL, Dell, HP) Prometric Test center Apple 0 06-28-2008 11:54 AM
Bangalore's Best Prometric Test center (like Microsoft, SunMicrosystems, Exin - ITIL, Dell, HP) Prometric Test center Apple 0 03-17-2008 07:43 AM
Bangalore's Best Prometric Test center (like Microsoft, SunMicrosystems, Dell, HP) Prometric Test center Apple 2 03-04-2008 09:13 PM
My Dell won't start. Popess Pantiara Evokovitch, BAYBEE! Dell 2 12-28-2007 07:34 AM
Update on "Question on ASUS A7N8X Deluxe motherboard and compatible processor " amandaf37@gmail.com Asus 26 09-10-2007 03:50 AM


All times are GMT. The time now is 01:26 PM.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43