Fixing texture files

I have freebie texture that I use on several items. The thing that drives me crazy about this one texture is that I can frequently see other objects throught it at certain angles, almost as it if it is set to transparent, which it is not. I noticed a Hotline post about a problem with some targa files saved as 32 bit instead of 24 which results in an alpha layer. Could this be the problem with this texture? How can I fix it? Will saving it as a jpeg and re-uploading it solve the problem?

Thanks

dont save it as jpg, working on or with jpg is a big nono becuase of the photcopy crapout effect. but yes your on the right track...

save it as bmp and then back to tga (or just upload it as bmp if its not too large)

bitmaps have no transparency

let me add, it would fix it if there is a transparent spot in your texture, altho by fixing it i mean making the transparent areas white

A Osgeld said, stay away from JPEG. However, with respect, I disagree about the BMP suggestion. There's no reason to bother with BMP. Saving as a 24-bit TGA will solve the problem, although as Osgeld pointed out, if you need the image to be transparent in whole or in part, that transparency will disappear if you make the change. Regardless, there's never a need to switch formats. Use TGA always.

In case you're wondering why that texture is behaving like it does, it's a glitch in what's known as alpha sorting, a glitch which is shared by nearly all 3D applicatioons, including video games, and even high end modeling and animation packages. Some very advanced applications like Maya actually allow you to turn the glitch on and off so that in case you're modeling for a destination that will have it, you can see what the effect will be. Certain objects like fire, trees, etc. depend on exploiting the "problem" in order to look "right".

What happens is when two 32-bit textures are placed close to eachother, the rendering engine has trouble determining which one to display. If the two objects are intersecting, usually the renderer will show the one that's most perpendicular to the camera, and the other one will disappear. If the two meet at a corner or if they overlap, the usually what happens is you see a hole in the one that's "in front" and the one that's "in back" shows through. Depending on camera angle, they'll appear to switch back and forth, and it will be tuff to tell which one is in front of the other.

It's a very commonly held assumption among those new to texturing that more bits must somehow be better than less bits, and so they end up saving everything as 32-bit at first, whether it needs to be or not. As a result, they end up with files that are 33% larger than they should be, which is candy for the lag monster, and they end up with all kinds of alpha sorting problems.

So, the bottom line is NEVER EVER save an image as 32-bit unless it actually needs transparency. As for freebies that already exist, well sometimes you get what you pay for, unfortunately. Your only recourse is to download the texture to your machine, resave it as 24-bit, and then re-upload it, which means you're gonna pay L$10 for for a "free" texture. You may want to contact the creator of the texture and refer him or her to this thread.


Oh, and by the way, if you want some understanding of what all those 24's and 32's mean, the simplest explanation is this. Images are composed of channels, each channel is an 8-bit sub-image that controls one aspect of the whole such as color or transparency. The first 3 channels control Red, Green, and Blue. Since they're 8 bits each, they add up to a total of 24. Hence, 24-bit images are color pictures with no transparency. Those first 3 channels are rquired components of every color image, but the fourth channel, commonly called "Alpha" is optional. It governs not color but transparency, and as previously mentioned, it should NOT be present unless transparency is actually needed. Numbers wise, the alpha channel adds another 8 bits to the total, bringing the image to 32 bits.

That explains why my logo sign in world sometimes looks like it's behind something that it is not! I was hoping it was just me!!!

I guess I need to make some signs with solid backgrounds. Schucks.

Is there any other work around? Would it help if I placed a 95% transparent prim behind it? Of course, I loose the full transparent effect that way, too. Hm.

Chosen, you are my new favorite person in SL. THANK YOU for explaining something that has been driving me insane for months. /me kneels and bows

there was talk about alpha fighting being reduced if you put a non-alphaed texture (i.e. 24 bit tga or jpg) on the 0-side of a prim. I don't know how much this really helps however... I still see alpha fighting when I try this technique.

(you can use llSetColor(<1,0,0>,0); to find the zero side fyi)

blaze, as far as I can tell, it doesn't matter if you use a 32-bit texture or set transparency levels in the SL editor... that puts the textures into "alpha" mode (Chosen will have the proper term for this, not me ) and you'll see the alpha fighting from certain angles (thankfully only from certain angles!) if there isn't a non-alpha prim between the two.

I've also seen alpha fighting when a prim is hollowed.

Hey! I was kneeling and bowing here first
Oh, well! Guess I can go kneel and bow at someone else. Anyone see which way Robin and Chip went?

The only work around is to put a a 24-bit surface inbetween the two 32-bit ones. It's prim-heavy, but you can "sculpt" an area behind the opaque areas of your sign, kind of like an extruision, and that will solve the problem. For example, 3 cubes to extrude the letter A or a hollow cylinder to extrude the letter O. All those prims will add up, of course, but if you want to preserve the transparent background of your sign without risking interference from other transparencies behind it, that's really the only way.

Placing a 95% transparent prim inbetween wouldn't make a difference. As Forseti mentioned, it doesn't matter whether transparency is created inside or outside of SL. It's still governed by the same principles. You'll find that two prims set by the editor to be transparent will fight with eachother the same way as if they had had 32-bit textures applied to them. The same is true if it's one of each. Transparency is transparency.


I can't think of any reason why this would work. I would agree with your findings, Forseti.

I would assume that this idea is probably a mutation from someone's partial knowledge of how local lighting works. Side zero is the governor for the color of local light rays. Whatever color you make side zero on a light prim will be the color of the light emitted from that prim. Before we had the full bright option, the common method for curtailing local light was to turn side zero black, which would cause the prim to emit black rays. Since the lighting engine is entirely additive, and black has a value of zero, this would essentially turn off local light casting from the prim while still allowing the surfaces to light up.

It sounds like somehow somebody got the idea that transparency works the same way as local light, and perpetuated this theory. The two have nothing to do with eachother. There is no technical reason whasoever that this should work, so I'm not suprised that it didn't for you.


Hehe, I can't think of a better description than "alpha mode".


Perfectly expected. It's the proximity of the the alphas in 3D space and their alignment with the camera that causes the effect. It doesn't matter whether it's one prim or a million.



Aw, thanks guys. Ben, I guess I'll have to make my own templates now or something to regain your worship.

I'm happy to be a Chosen groupie

Hehe. Congrats, Forseti, you made into the brief collection of great quotes in my sig.

hey! I guess that puts me among the chosen few!


(ba-dum-dum... kill me later )

Sacrifices are not necessary. All may worship at the feet of the Chosen.

Silly question here (and please include me in the chosen few bowing at your feet ) but wouldn't replacing the 32-bit (non-alpha) with 24 bit work without adding prims? Or did this just fly right over my head

P.S. I don't understand why jpeg is BAD, but then again, I'm old heehee

If you replace the texture with a 24-bit one it won't be transparent anymore. The idea was for the sign to have a transparent background.


JPEG is bad because it's a lossy format. Its small file size makes it practical for the web where speed is more important than quality, but since in SL all images are saved as JP2, the source file size is irrelevant. Since there's zero speed benefit, there's no justification for the loss in quality. Also JPEG does not support transparency.

Thank you. I missed the part about the sign transparency

/me bows and kisses Chosen's feet too

No, I will not bow at the feet of the Chosen


Just kidding with you Chosen. Jpeg is not really BAD, it's the lessor choice of two good options. I use jpg for some stuff because of workflow reasons. But I'll let you have the last word--LOL

its strongly advised not to use jpg as your working with the picture, every time a jpg is saved it is compressed by whatever %, so its basicly like making a photocopy of a photo copy each one getting slightly poorer picture quality, if you like jpg or need jpg use it as the final published image

this is a simulation of the effect
ps let me correct myself the edges do not adversly effect filters (ect) if they dont suck to begin with heh.

you (and my monitor) are, like, sooooooooo lucky I wasn't drinking coffee