draw2DImage() Problems!!!

[nutpor]

Why in draw2DImage() have to add 0.5f?
I found in both COpenGLDriver.cpp and CD3D9Driver.cpp
at function draw2DImage().


core::rect<f32> tcoords;
tcoords.UpperLeftCorner.X = (((f32)srcRect.UpperLeftCorner.X)+0.5f) * ssw ;
tcoords.UpperLeftCorner.Y = (((f32)srcRect.UpperLeftCorner.Y)+0.5f) * ssh;
tcoords.LowerRightCorner.X = (((f32)srcRect.UpperLeftCorner.X +0.5f + (f32)srcRect.getWidth())) * ssw;
tcoords.LowerRightCorner.Y = (((f32)srcRect.UpperLeftCorner.Y +0.5f + (f32)srcRect.getHeight())) * ssh;


and


core::rect<float> npos;
npos.UpperLeftCorner.X = (f32)(trgRect.UpperLeftCorner.X+xPlus+0.5f) * xFact;
npos.UpperLeftCorner.Y = (f32)(yPlus-trgRect.UpperLeftCorner.Y+0.5f) * yFact;
npos.LowerRightCorner.X = (f32)(trgRect.LowerRightCorner.X+xPlus+0.5f) * xFact;
npos.LowerRightCorner.Y = (f32)(yPlus-trgRect.LowerRightCorner.Y+0.5f) * yFact;


This addition also in draw2DImage of directx versions.
It cause problem in my 3d card (Radeon 9500 pro) the 2d image is render incorrect it have some artifact at the bottom line, but my friend SiS card don't have this problem, I tried to update my display driver but nothing has changed. Then I remove those +0.5f stuff from above and it works!!! all artiface are gone (test both Radeon and SiS).
So I curious why add +0.5f in vertex and texture coord?,
and I don't sure that fix this spot is the right for my problem?,
and it will lead to some unseen bugs?.
Please correct me if what I done is wrong.
Any suggestion would be greatly appreaited.

[nutpor]

I'm very disappointed. I just looking forward for help.
But all the threads that I asked NEVER get an answer.
Am I posting in wrong forum? or I don't describe the problem clear enough?
So sad...

[Fred]

It's a hack to get around some kind of bug?

[nutpor]

Yes, when I use method above all texture seem to rendering correctly on my graphic card and no effect on my friend's card

Problem with opengl driver is

http://cc.cpe.ku.ac.th/~b4405241/gl_prob.bmp

and on directx 9 driver is

http://cc.cpe.ku.ac.th/~b4405241/dx9-no-prob.bmp

but I want to use opengl for my project and I don't sure that my hack will cause problem later or not.

[Guest]

So... anyone, any ideas?
I'm looking for it!

[Guest]

I also had a similar problem with my nvidia card, and removing the "+0.5" fixed that as well.

However, I believed that this was only a workaround that would produce bad results at other cards, because when going through the code you mentioned the +0.5f made perfect sense to me, and I'm still not convinced because I'm not into OpenGL at all.

This is how I understand it: Your texture consists of, say, 10 * 10 pixels. From the view of GL, however, all textures have their upper left corner at 0.0f, 0.0f and their lower right corner at 1.0f, 1.0f. The problem is that 0.0f, 0.0f isn't the middle of the top left pixel, it is the top left "corner" of the top left pixel. The same goes for 1.0f, 1.0f, here it's the lower right corner of the lower right pixel. So if you simply map pixel position 0,0 to 0.0f, 0.0f, then you get the corner of the pixel, but you will want the middle. So, in a nutshell, you alter your equation so that the mapped coordinates lie in the middle of the texture pixels, which can be done by adding 0.5 to the original pixel x/y position and dividing this by the texture width/height.

If what I write above is true, then the code should map the pixel positions correctly. However, since it doesn't, I strongly suspect that there is at least one mistake in the assumptions made above. If someone with knowledge about OpenGL finds the mistake please let us know. It's the key to the fix.

MedO

[nutpor]

Thanks for reply.

I have learn openGL from web and some books, but all I find in texture mapping is usually mapping from
(0.0f, 0.0f) to (1.0f, 1.0f) for map entire texture to entire quad. I think this way make sense too.
So, anyone please correct me if my understanding is wrong.

[nutpor]

Mapping from 0.0 to 1.0 when +0.5 I understand that it means add half of entire texture spaces!
And add 0.5 both top-left and bottom-right.
At bottom-right does it mean the texture is wrap up? any ideas???

ps. I think someone would boring if I bring this topic up too much, but I REALLY NEED HELP, please anyone help me...

[xterminhate]

+1 (up)

Well, I've got the same problem.

[Guest]

Mapping from 0.0 to 1.0 when +0.5 I understand that it means add half of entire texture spaces!

There is no place in the code where 0.5 is added to the GL texture coordinate. It is always added to the SOURCE RECT COORDINATES, which is a measure in PIXELS, so HALF A PIXEL is added and NOT HALF A TEXTURE SPACE.

Look at the code again. After 0.5 is added there is a multiplication left to do, guess what it does. Right, it turns pixel coordinates into GL texture coordinates.

I'm not saying the code is ok, just that this is not the problem.

MedO

[Guest]

While working through this again, I might have found the problem. However, an OpenGL guru should confirm this.

A bit of history, the relevant functions here haven't been written my Nico, but by Zola. I believe there was a misunderstanding about the core::rect class with textures.

...I just tried a quick fix and it didn't work well (all blurry)... however, it might be that two mistakes went together here.

Could you all try removing all those +0.5f occurences (remember to do it in BOTH draw2DImage functions)? I know I originally said they make sense, but this way the texture should be mapped from (0.0f,0.0f) to (1.0f,1.0f), and the screen coordinates should be mapped from (-1.0f,-1.0f) to (1.0f,1.0f)... and MAYBE this is the correct way after all . At least it works here, but it worked here before as well... oh, whatever.

Sorry for sounding so uncertain about it, but I'm not an expert in OpenGL and am just applying whatever theories I have about it.

MedO

[Guest]

th 0.5 thing is generally accepted as the correct way to map textures. Read the DX sdk docs or any decent 3D book and they point out why this is needed for correct 1:1 mapping. 0-1 just isn't correct.

Howver that is not to say there is something else not right with it in irrlicht if it is causing problems.. though different drivers etc can all mess things up.

[bearSoft]

Code: Select all

Your texture consists of, say, 10 * 10 pixels.

Am i wrong but shouldent textures be 2^n?
8*8 would be ok then 16*16 (or 8*16 or or..)
this somehwat limits the use of textures but i think it is needed... ?
The so far weirdest texture thing i saw was regarding heighfield textures the poster (darn cant remember name) claimed 2^n + ONE px -eg like 9*17
that is to ..special for me
havent seen any problem with pure 2^n [/quote]

[Guest]

Am i wrong but shouldent textures be 2^n?

Valid point, but it doesn't make any difference here. The 10x10 example is never used later in the post anyway, I just forgot to remove it while rewriting the explanation. Sorry if that caused confusion. I really should register so I can edit my posts

MedO

[nutpor]

I copied this from DXSDK 9.0c doc

Your application can assign texture coordinates directly to vertices. This capability gives you control over which portion of a texture is mapped into a primitive. For instance, suppose you create a rectangular primitive that is exactly the same size as the texture in the following illustration. In this example, you want your application to map the whole texture onto the whole wall. The texture coordinates your application assigns to the vertices of the primitive are (0.0,0.0), (1.0,0.0), (1.0,1.0), and (0.0,1.0).

th 0.5 thing is generally accepted as the correct way to map textures. Read the DX sdk docs or any decent 3D book and they point out why this is needed for correct 1:1 mapping. 0-1 just isn't correct.

I see about 0.5f approx. in this topic in DXSDK doc
Directly Mapping Texels to Pixels

However, my Directx9 driver don't cause any problem with +0.5f things BUT it has trouble in OpenGL driver with +0.5f! and my team want to use OpenGL for portability.

If this is a bug in my display driver, it may be disappear when I upgrade driver to the new one, and I see some ppl with NVidia (mine is ATI) cause this problem too! So I don't exactly know where the problem is.