Archived

This topic is now archived and is closed to further replies.

Jiia

3D Newbie Panics

Recommended Posts

I have a serious problem - Eck!? My textured quads have cracks in them! You can see thin lines between each two quads. Changing the color in the texture around the quad-texture coordinates changes the color of the cracks. This means the texture coordinates are flowing outside of ...their coordinates. Is this a normal thing? It takes my plans and progress, and crumbles them up into wads of useless debree. I''ve tried painting "padding" in the quad textures around the texture coordinates to match the colors of the lines inside the coordinates, and it makes it look a little better. However, my situation requires that the quads "link" together and look like a single object, but you can plainly see where they are glued together. See effects here. Thanks for any explanations of this terrible tragedy.

Share this post


Link to post
Share on other sites
If those quads have tiled texture like those on that screenshot, simply set


lpD3DDev->SetSamplerState(0,D3DSAMP_ADDRESSV,D3DTADDRESS_WRAP);
lpD3DDev->SetSamplerState(0,D3DSAMP_ADDRESSU,D3DTADDRESS_WRAP);


now textures will be tiled. Maybe you know that already, but it helps anyway :]

Edit: yes, i know thats just solution not explanation - i had that problem and i solved it this way back then.

[edited by - Uriel on May 17, 2004 4:57:29 PM]

Share this post


Link to post
Share on other sites
What are the dimensions of the images used for your textures? If they''re not powers of two, then it is likely that DX is making larger textures (so that the width/height are powers of two), and then only filling in relevant parts with your images. Everything else will be transparent black. If this is the case, then texture filtering (use SetSamplerState() to change filter types) might cause your image to be blended with the transparent black on the edges. Set your MIN_FILTER and MAX_FILTER to POINT (or whatever the exact constants are; just look up SetSamplerState() in the docs). Hopefully this would fix it. There are other ways around this, if you want to keep the texture filtering, but for the time being, this will work (if this is indeed the problem).

Share this post


Link to post
Share on other sites
All of the quads share the same texture. This texture is
a power of 2 (256x256). But each seperated quad (which
shouldn't look seperated!) has specific texture coordinates
inside that texture that are not powers of 2. I didn't think
they needed to be..?

The top left corner quad texture's pixel coordinates are
0,0 -> 5,5. So that's 5 / 256 = 0.01953125.
So 0.0,0.0 -> 0.01953125,0.01953125.

Even if I use texture coordinates that are even (and easily
divisible by 256), such as 32,32 -> 64,64,
(which is 0.125,0.125 -> 0.25,0.25), they still bleed.

I don't think I'm tiling in the manner you're suggesting.
Or am I? Each quad is a totally seperate mesh. They don't
share the same vertices. So no images are being tiled. I
just need to find a way to make them look as though they
are the same object.

Thanks for the help!

EDIT:
The reason there are transparent cracks is because
the color surrounding each texture coordinate is the
transparent color (black). I can fill it with blue,
and the cracks turn blue.

[edited by - Jiia on May 17, 2004 5:54:26 PM]

Share this post


Link to post
Share on other sites
The problem is that the color is decided from the "middle" of a pixel or something like that, so some of the color from surronding pixels get added in. Im not to sure about it. What you do to solve it, is to start reading the image with a 1 or 2 pixel offset. I had the exact same problem when doing tiles with textured quads in d3d.

This is the code, the +2 -2 are to correct this problem:

// set texture transformation

D3DXMATRIX texturematrix;
D3DXMatrixIdentity(&texturematrix);
texturematrix._11 = (srcWidth-2.0f)/texturevec[id]->width; // spritewidth/texturewidth

texturematrix._22 = (srcHeight-2.0f)/texturevec[id]->height; // spriteheight/textureheight

texturematrix._31 = (2.0f+srcRect->x1)/texturevec[id]->width; // spriteoffsetx/texturewidth

texturematrix._32 = (2.0f+srcRect->y1)/texturevec[id]->height; // spriteoffsety/textureheight


if(FAILED( hr = d3ddevice->SetTransform( D3DTS_TEXTURE0, &texturematrix )))
TTrace::Error("Could not do d3ddevice->SetTransform. Error = %s.", DXGetErrorString9(hr));

Share this post


Link to post
Share on other sites
But it looks like you''re ignoring the first and last two
pixels on your image data. What if the image is sensitive,
and those missing pixels would not be acceptable?

My only other alternative that I know of is to just create
a mesh for every size window I need. Which would be a pain, really.

Share this post


Link to post
Share on other sites
I figured out a way to trick it into working. I had to put
the right padding in the right places on the texture. I made
sure each piece was padded by the color of the texture it
would lie next to. See results.

I only hope this trick works with other video cards.

Share this post


Link to post
Share on other sites
I don''t think 256 is the correct number to divide by I think it should be 255. Think about it. You count from 0 all the way across your texture and the last pixel is 255. Dividing that by 256 doesn''t give 1.

Share this post


Link to post
Share on other sites
Erk!! Sorry about that. You're correct, it's 255.

I'm not actually doing the divide myself, though. I'm using
the ID3DXSprite interface. So it's not the cause of the glitch.
Not unless Microsoft goofed.

My bad, anyways.

EDIT:

Ya know, even though I'm not doing the divide, it does mean
that my power of 2 coordinates were not so easily divided by
the size of the image as I thought. As a matter of fact,
32 / 255 = 0.12549019607843137254901960784314!!

This could actually be the problem! I'll try to come up with
some better rounded numbers as soon as I get a chance to test
it out. Thanks for bringing it to my attention

[edited by - Jiia on May 17, 2004 9:58:25 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Jiia
I''m using the ID3DXSprite interface. So it''s not the cause of the glitch. Not unless Microsoft goofed.


Are you using the DirectX9 Summer Update pack? There were some problems with ID3DXSprite in the initial release, which got fixed in the Summer Update.

Share this post


Link to post
Share on other sites
Yes I am. So this is not something that usually happens?
It could even be a glitch in my video card, for all I know.
So if you assign texture coordinates to a single quad (a 4
vertice mesh, not attached to anything else) the pixel
coordinates 1,1 -> width-1,height-1, and paint a specific
color border around that area, you don''t normally see that
border bleeding through?

Share this post


Link to post
Share on other sites