[SOLVED] Unwanted artifacts (lines) when using billboards

[DavidR]

Hi,

I'm using billboards in combination with an OrthoLH camera. However, on some of my billboarded objects, I randomly get corrupted 'lines' visible above the object, which seem to repeat the last pixel line of the texture.

For example, here is the billboard of an object (a sort of 'pot') showing a corrupt line at the top:



These lines are definitely not part of the texture, and are only visible at certain times (Somehow associated with angle or something?). The billboards are using no lighting, and TRANSPARENT_ALPHA_CHANNEL (they're PNGs with alpha). I would post code, but there is nothing really of interest other than the creation of an ortho camera, and the creation of billboards with no particularly special attributes.

I assume this is probably a code/irrlicht issue rather than drivers, but for reference I'm using an 8800GS with 512mb.

Can anyone help me with this problem? Has anyone experienced it before?

[devsh]

the uv coords are bad

[Lonesome Ducky]

It's probably bad when you get farther away right? This could be a mipmapping problem, try turning off mipmapping before the texture is created.

[B@z]

no uvmaps for billboard xD

or maybe your image is not power of 2?

or are you using antiasling?

[DavidR]

This could be a mipmapping problem, try turning off mipmapping before the texture is created.

Yeah, that sort of helps, although I think it's just hiding the problem a bit, since it is still visible in some situations

or maybe your image is not power of 2?

Nah, all of the textures are 128x128

or are you using antiasling?

I'm not, although thanks for that link - it's very interesting since the effect on other objects is extremely similar to what is shown there.

(To clarify, I'm not using AA in game, although the edges of the objects are AAed when drawn/made. I assume that link is talking about scene AA and not images though)

[Lonesome Ducky]

Try moving the non-transparent part of the image up in the texture. It looks like it's mapping the texture with a little bit of inaccuracy, which causes it to wrap, so the top is taking the pixel from the bottom of the image. So just try having some blank space in the bottom of the texture. Even 1 pixel ought to do.

[sio2]

DX9 rasterisation rules:
http://msdn.microsoft.com/en-us/library/bb147314.aspx

[devsh]

didn't I say DX sucks and so does microsoft

[Lonesome Ducky]

didn't I say DX sucks and so does microsoft

Ohhhh, so that's why most games use DirectX.

[devsh]

well id software rule and they use OGL only

[Lonesome Ducky]

Well, to each their own I suppose.

[Mel]

http://irrlicht.sourceforge.net/docu/na ... f84b39811f

Take a peek there, it wouldn't surprise me that OGL made the same . The textures repeat when they are aplied by default, so, when the bilinear filtering is made, in the moment of sampling the edge of a texture, it also samples the other side to complete the interpolation. This can be corrected telling the texture to clamp to the edges, so, the texture will never sample the other edge to get the correct pixel, and instead, it will keep within the image.

Also, a good practice is to keep everything as far as posible from the edges , so this kind of problem is reduced to a minimum.

[DavidR]

Ahh yes, clamping completely fixes the issue

Thank you very much for finding that. For anyone else who also wishes to fix this problem, the clamping is accessed via:

Code: Select all

Node->getMaterial(0).TextureLayer[0].TextureWrap = ETC_CLAMP;

ETC_CLAMP did the job to stop this problem for me.

(I also changed the subject so this thread is easier to find for anyone else experiencing the same issue)

[henkten]

Thank you Mel for the solution and to DavidR for creating this thread and for putting in the solution code so plainly in the end- that really helps newbies like me , I wish guys would do that more often.

[DavidR]

Sorry for the huge bump, but just a quick fix to this for the latest ver. of Irrlicht (for reference to anyone looking for the solution)

The CLAMP setting is now accessed like this:

Code: Select all

node->getMaterial(0).TextureLayer[0].TextureWrapU = ETC_CLAMP; 
node->getMaterial(0).TextureLayer[0].TextureWrapV = ETC_CLAMP;

Even though TextureWrapU/TextureWrapV state their values are nabbed from ETC_CLAMP, this is just a slight clarification for anyone who missed it (including myself)