Why wont things hide inside or behind each other when I'm building?

[Aeric Kingsley]

Why won't things hide inside or behind each other when I'm building?

[Zslash Cyberstar]

what do you mean? like u can see stuff behind a wall ?

[Aeric Kingsley]

If things are overlaping (which is usualy the best way to build with basic prims) it looks like it puts one whole prim in front of the other ones when they are in the same place

[Aeric Kingsley]

[Min Barzane]

this is classic alpha texture issue,use non transparent textures and you will fix the problem!

[Honey Puddles]

to clarify what Min said...

The texture you are using, was uploaded as a "32 bit" texture. Maybe there's a small amount of transparency to it, maybe there isn't.. but Second Life uses OpenGL for rendering, and OpenGL is notoriously bad at understanding what to do when two 32-bit textures overlap.

The easilest solution is to either use another texture that isn't 32 bit, or (assuming the texture is full perms), save the texture off to your HD, and use an image editing program like Gimp or Photoshop, to save the file in a 24-bit mode. Then re-upload the image and it should be fine.

I've found that the SL image uploader doesn't reliably process 24bit (solid) PNG files properly, and very often, a PNG on my HD that's perfectly flat, will upload as a 32bit image to SL. My solution for this is to always save textures I intend to upload to SL, as TGA files. You have to manually create an alpha mask for TGA files, and while it's a bit more time consuming to make textures as TGAs, the SL program has no trouble understanding that a 24bit TGA is meant to upload as a 24bit texture.

[Aeric Kingsley]

Fascinating. At the moment I'm using free textures to see how things look whilst I put the prims together.

I couldn't find enough information in 'properties' so I tried another texture and now I can see what i'm doing

Thank you.

 

[Chosen Few]

Hi Winter.  Some of your information isn't quite accurate.  Allow me to clarify, if I may.

 

---

Winter Ventura wrote:

OpenGL is notoriously bad at understanding what to do when two 32-bit textures overlap.

---

 

Just so you know, it's not an OpenGL issue.  DirectX behaves exactly the same way.  It's an inherent property of how realtime rasterization works in graphics cards.

There's no such thing as being "bad at understanding" it, as far as OpenGL or any oher graphics language is concerned.  Alpha sorting works exactly as it was designed to work, without exception, every single time, whether in an OpenGL environment or not.  With that in mind, I would word the issue quite the opposite of how you put it:  it is SL users who are notoriously bad at understanding how alpha sorting works, and who consequently, are notoriously prone to misusing it.

There are only two reasons you see alpha sorting 'problems' happen in SL.  First, SL's content is user-created, and most users (quite understandably) have no idea what the frell they're doing.  Second, the camera has entirely free range of motion, so there's no way to predict the angles at which people might be viewing things.

Further, there is only one reason you never see these kinds of problems with 32-bit textures in professionally built games.  Professional game artists know how to work within and around the the issue.  We either design in such a way as to make sure that 32-bit textures never overlap, or we actively take advantage of the sorting behavior, so that certain objects become much easier to construct (trees, plants, fire, chandeliers, etc.).  We also make sure to use camera constraints, to ensure that users can never view a scene from such an angle that any two 32-bit textures could come into any unfortunate alignment.

 

---

Winter Ventura wrote:

I've found that the SL image uploader doesn't reliably process 24bit (solid) PNG files properly

---

I've never ever seen the uploader malfunction.  It works exactly as designed.  Yet 'accidental' 32-bit textures sourced from PNG are indeed rampant in SL.  Why is this?

Well, as much as nobody ever wants to hear this, the problem ALWAYS comes down to simple user error.   It's due to the fact that the PNG format supports multiple forms of transparency, including so-called "simple transparency", or "WSIWYG transparency".  Thus, if so much as a single pixel in the image is anything less than 100% opaque, the entire image will read as 32-bit when converted to JPEG2000 by the SL uploader.  After all, the uploader has no way of knowing that you didn't actually want that pixel to be translucent.

This is one of the primary reasons I don't recommend using PNG for texturing.  It's just too easy to make a mistake with it.

 

 

---

Winter Ventura wrote:

a PNG on my HD that's perfectly flat, will upload as a 32bit image to SL.

---

 

I'm not sure what you mean by this.  An image that is "flat" is one that does not contain layers.  Thus all PNG's are flat, by definition, as the PNG format does not support layers in any way, shape, or form. 

Was your use of the word "flat" a typo, where you actually meant to use the word "opaque"?  If so, then I'd question whether the images you're talking about were indeed PERFECTLY opaque.  If you were to examine them pixel by pixel, I'll bet you any amount of money you'd care to name that you've got at least one pixel in there somewhere that is not totally opaque. 

Even if one pixel has an opacity value of 254 out of 255, that's enough to make the uploaded texture become 32-bit.  To have no transparency, each and every pixel MUST be a perfect 255 on the opacity scale, no exceptions.  It can be hard to ensure that with PNG.

 

 

---

Winter Ventura wrote:

it's a bit more time consuming to make textures as TGAs

---

 

I'm always a little baffled when people say this.  In truth, alpha mapping is not any more time consuming than any WYSIWG procedure.  In fact, it's often MUCH faster.

It does require a little bit of extra learning in the beginning, since the kind of metaphorical thinking it requires doesn't tend to occur to the layman, right off the bat.  People all too often confuse extra mental effort with extra time.  But in actual practice, alpha channel work flow is incredibly fast, and very, very simple to execute.  This is why it has remained in existence for the better part of 40 years now.  

Alpha channels were invented in the 1970's.  It stands as testament that while so many other aspects of computing have changed exponentially, and continue to change around us as we speak, the alpha channel has remain a foundational staple of modern graphics, and will likely continue as such for decades to come.

The alpha map is one of the rare examples in computing of something that was gotten right the first time.  It just works, period.  It's fast, reliable, and super easy, once one understands how it works, and has had a little practice with it.

By the way, it may be worth noting that the alpha metaphor far predates the advent of the alpha channel itself.  It goes all the way back to analog matting and compositing techniques that were in use long before computers had ever even been dreamed of.  Old black and white photographers in primitive darkrooms were using the same metaphor to composite photographs, practically since the invention of the camera.  The alpha channel simply integrated the principle into digital imagery, in a manner that could be self-contained.

 

Don't fear the alpha!