T2D 1.1 scaling artifact
by Spider · in Torque Game Builder · 12/22/2005 (10:44 pm) · 12 replies
I made a png resource of an arrow whose dimensions were 64 x 31. The edges were all transparent pixels... Rotating and scaling this created white artifacts around the edges reminiscent of the old problem that filterpad fixed. Redrawing my resource at 64 x 32 fixed the problem. I know that I was paying the price for being anal about that perfectly one-pixel-tipped arrow ;)
#2
You can use the art-package to change this colour or the core texture-manager could chnage to alter it. Either way, it'll be a single colour. I provided a small mod to T2D recently to a gaming studio but this will mod increased the texture processing time as it stepped through each image and changed the totally transparent regions to a specified color. This is a nice quick fix but this should really be a core TGE thing.
I've been through this one a number of times; here's a post from the TGE Public Art forums discussing the same problems. This problem shows up in any texturing that supports an alpha layer.
- Melv.
12/24/2005 (5:03 am)
Just to add; if your art-package is saving white in the totally transparent region of your image, this is what you are seeing. Photoshop does this! Obviously the graphics card will blend from one colour to another even if the blend is going towards transparent.You can use the art-package to change this colour or the core texture-manager could chnage to alter it. Either way, it'll be a single colour. I provided a small mod to T2D recently to a gaming studio but this will mod increased the texture processing time as it stepped through each image and changed the totally transparent regions to a specified color. This is a nice quick fix but this should really be a core TGE thing.
I've been through this one a number of times; here's a post from the TGE Public Art forums discussing the same problems. This problem shows up in any texturing that supports an alpha layer.
- Melv.
#3
Here's a picture of the arrow, with little white pixels around the bottom left edge. These are not in the photoshop image. Here's the png:
It looks white because it's a white arrow on a transparent background...
12/24/2005 (5:03 pm)
Here's a picture of the arrow, with little white pixels around the bottom left edge. These are not in the photoshop image. Here's the png:
It looks white because it's a white arrow on a transparent background...
#4
I'm not so sure I agree.
Remember, without knowing the blend mode, the alpha value itself is meaningless. An alpha of 0 may mean transparent, or it may mean something completely different. To have the system assume that it means transparent unnecessarily restricts the developer.
Obviously one could have a flag saying whether or not to do the conversion. But, more than that, I think it's important for the developer to take better care of their data and not just let the code do everything. It's one thing to cut a bitmap up into multiple textures or add padding for blending and so forth; that's dealing with a hardware-specific issue (ie, not knowing how big textures should be). It's quite another thing to start actually modifying the pixel data itself to correct a mistake by the artist.
12/24/2005 (7:28 pm)
Quote:This is a nice quick fix but this should really be a core TGE thing.
I'm not so sure I agree.
Remember, without knowing the blend mode, the alpha value itself is meaningless. An alpha of 0 may mean transparent, or it may mean something completely different. To have the system assume that it means transparent unnecessarily restricts the developer.
Obviously one could have a flag saying whether or not to do the conversion. But, more than that, I think it's important for the developer to take better care of their data and not just let the code do everything. It's one thing to cut a bitmap up into multiple textures or add padding for blending and so forth; that's dealing with a hardware-specific issue (ie, not knowing how big textures should be). It's quite another thing to start actually modifying the pixel data itself to correct a mistake by the artist.
#5
You guys are talking about a totally different issue than what you see in the pic above, right? Those pixels showing up are NOT in my image. They change position when I change rotation of the arrow. Should I post another picture of that?
Btw, I use photoshop and it doesn't ever save a color to my transparent areas... I'm not really sure exactly what you're talking about there.
12/24/2005 (9:17 pm)
Re: the alpha value/color and photoshop saving thing...You guys are talking about a totally different issue than what you see in the pic above, right? Those pixels showing up are NOT in my image. They change position when I change rotation of the arrow. Should I post another picture of that?
Btw, I use photoshop and it doesn't ever save a color to my transparent areas... I'm not really sure exactly what you're talking about there.
#6
I had this problem 1 time, and i think that fixed it.
12/24/2005 (9:57 pm)
In photoshop go to Image->Trim, and put a check mark in the Transparent pixels box. I had this problem 1 time, and i think that fixed it.
#7
The reason I state that it should be a core TGE thing is not to say that I'm really happy about putting in the processing routine but to say that if it were to go in, the core is where it should be to stop each and every image-map doing the processing and to be able to make this adjustment for non T2D stuff like the GUI which also has this problem.
@Spider: To explain; when photoshop saves your 32-bit image (24-bits of color plus 8 bits of alpha) it does have to actually put a color to the transparent regions. In other words, each pixel has 4-channels, 8-bits each, 3 for the color and 1 for the alpha. Even if the alpha-channel indicates that a specific pixel is totally transparent, there are still 3-channels that specify a color even if it's not used. Photoshop saves this as white by default.
Could you email me the PNG? Everything saved from this page is as a JPG. Either that or put the image as a URL in your post. When I get the image, I will be able to tell you what is causing the problem. It would help if you could post me a tiny bit of script you're using as well.
*sneaks back to wife at xmas*
- Melv.
12/26/2005 (3:56 am)
@Smaug: I agree in the sense that we shouldn't really be putting in fix after fix for "artifacts" resulting from the way image-data is configured by the artist but in the end, you have to bow to the pressure of community reporting the same thing again and again (as well as a few game-studios). Perhaps this is better suited to some info in TDN. The obvious downside to this processing is that it slows down the image load/process time and would probably result in people reporting that T2D is slow, yada yada and we're back to a support issue again.The reason I state that it should be a core TGE thing is not to say that I'm really happy about putting in the processing routine but to say that if it were to go in, the core is where it should be to stop each and every image-map doing the processing and to be able to make this adjustment for non T2D stuff like the GUI which also has this problem.
@Spider: To explain; when photoshop saves your 32-bit image (24-bits of color plus 8 bits of alpha) it does have to actually put a color to the transparent regions. In other words, each pixel has 4-channels, 8-bits each, 3 for the color and 1 for the alpha. Even if the alpha-channel indicates that a specific pixel is totally transparent, there are still 3-channels that specify a color even if it's not used. Photoshop saves this as white by default.
Could you email me the PNG? Everything saved from this page is as a JPG. Either that or put the image as a URL in your post. When I get the image, I will be able to tell you what is causing the problem. It would help if you could post me a tiny bit of script you're using as well.
*sneaks back to wife at xmas*
- Melv.
#8
12/26/2005 (9:25 am)
Interestingly, I tried photoshop trim and also I've ported to alpha2, and I can no longer see the artifact. So I think it was probably my image, but who knows. I'll save off a version if I ever see the problem again.
#9
- Melv.
12/26/2005 (12:50 pm)
The only difference I can see then is that the alpha#2 has "filterPad" on by default if bilinear filtering (smooth) is on. Having the image would still be handy though.- Melv.
#10
Got your email with the code and it seems that the "filterPad" isn't being specified (and it defaults to "off" in the alpha#1 but "on" in the alpha#2) therefore you're open to the standard filtering artifacts. Adding the "filterPad" field removes the problem.
If you could confirm that on your machine it'd be cool.
- Melv.
12/27/2005 (2:21 am)
Spider,Got your email with the code and it seems that the "filterPad" isn't being specified (and it defaults to "off" in the alpha#1 but "on" in the alpha#2) therefore you're open to the standard filtering artifacts. Adding the "filterPad" field removes the problem.
If you could confirm that on your machine it'd be cool.
- Melv.
Associate Melv May
- Melv.