3D Newbie Panics

Started by
9 comments, last by Jiia 19 years, 11 months ago
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.
Advertisement
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]
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).
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke
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]
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));
Shields up! Rrrrred alert!
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.
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.
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.
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]
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.

Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse

This topic is closed to new replies.

Advertisement