Opaque Textures Allow Hidden Polygons To Be Seen

[perfectslam]

I've created my third mesh and I've two problems.  The first is that polygons that should be hidden by a textured face are visible at any angle.  The textures themselves are PNGs which do not have any transparencies at all.  The textures themselves are applied properly, but they are not hiding polygons behind them as it should.

The second issue is also annoying.  The object is an open top box, and the avatars should fall down to the floor beneath but they constantly walk along the top as if there is invisible force field holding them up.  It seems the Physics option in the uploader isn't working right.

The source modeller is Cheetah3D and the files were exported into DAE with no trouble and DAZ Studio renders the objects properly by SL does not.

I'm spending a bit of a small fortune reimporting these things.  Any help would be appreciated.

[perfectslam]

Update: I figured out the texture problem.  I was exporting as PNG files.  As soon as I uploaded JPEG versions the problems stopped.

Now just have the floating avatar problem.

[Chosen Few]

---

perfectslam wrote:

The textures themselves are PNGs which do not have any transparencies at all.  The textures themselves are applied properly, but they are not hiding polygons behind them as it should.

---

To be clear (no pun intended), it's not that your textures don't have transparency.  If they didn't have it, the effect you're describing could not happen.  Images that contain transparency can still look opaque, if the value of the transparency happens to be zero (or very close to zero).  A value of zero is not the same thing is not having a value at all.

With that in mind, you've discovered one of the major drawbacks of using PNG as your source format for texturing.  Because that format supports multiple forms of transparency, the margin for user error is greater than it is with the other formats that SL can import.  If so much as a single pixel is less than 100% opaque, the image becomes a 32-bit texture when uploaded.

For better control, use TGA.  It's nearly impossible to accidentally create a 32-bit TGA (unless you're using funky software).  Either you include an alpha channel or you don't.  If you don't put that extra channel in there, the image is 24-bit, by definition, and that's that.

Alternatively, if you want to be absolutely, positively, without any conceivable doubt, certain of opacity, use BMP.  SL cannot import 32-bit BMP's, only 24-bit.  So, there's zero margin for error.

JPEG is the same deal, as far as bit depth goes, but it's one of the absolute worst formats in existence for texturing.  It's lossy.  And since SL's internal format (JPEG2000) is also lossy, you get the 'copy of a copy' effect, losing quality not just once, but twice.  You'll never see a professional texture artist touch JPEG with a 10-foot pole.

All that said, if you really, really, really just can't live without PNG, and if you're using Photoshop, there is a way to ensure complete opacity.  Use the Save For Web feature.  In the Save For Web dialog, there's a checkbox for transparency.  If you uncheck it, no transparency data will be written into the file.  It's not as fool-proof as just using a format that doesn't support transparency in the first place, but it's better than just hitting Save, and hoping for the best.

 

 

In case anyone doesn't know what I mean by "32-bit", and "24-bit", here's a very quick explanation.  In an environment like SL, 32-bit images have transparency, by definition, even if the actual value of the transparency is zero.  24-bit images do not have transparency, again by definition. The extra 8 bits in a 32-bit image contain the transparency information.  In order for there to truly be no transparency, the image MUST be 24-bit.

It's not uncommon for those new to texturing to assume "more bits" must somehow be better than "less bits", so they save everything as 32-bit at first, before they learn the hard way that that's not how it works.

The phenomenon the OP described is called the alpha sorting glitch.  It happens two or more surfaces with 32-bit textures on them overlap in 3D space.  Computers do not define concepts like "in back" and "in front" the same way humans do.  When the renderer is confronted with multiple 32-bit textures, it has to belend them together, and surfaces that a human might define as "in back" will often end up getting drawn "in front" and vice versa. 

If you understand what you're looking at, it's all very predictable.  It happens in accordance with a fixed set of mathematical rules, which I won't delve into here.  Sufficeth to say, the reason you don't see it happen in professionally designed simulations like video games is because game artists are careful to work around the problem.  We just don't overlap our 32-bit texrured surfaces.  In SL, you see it all the time, because SL is mostly created by amateurs who don't know what not to do.

 

---

perfectslam wrote:

The object is an open top box, and the avatars should fall down to the floor beneath but they constantly walk along the top as if there is invisible force field holding them up.  It seems the Physics option in the uploader isn't working right.

---

The uploader works fine (occasional bugs notwithstanding, of course).  If you're not getting the results you want from it, chances are quite high that it's YOU who aren't working right.  Most claims of "It doesn't work" tend to boil down to user error.

Did you create a physics mesh?  Did you upload it along with the model itself?  Were you careful to refrain from pressing the Analyze button in the physics section of the uploader?  And did you set the object's physics type to prim, after you rezzed it?

If you failed to do any or all of those things, that's your problem.  If you did do all of those things, and it still didn't work, please describe your process, in as much detail as possible, so we can best pinpoint where you went wrong.

If you truly did everything right, then it's possible you've discovered a bug, which should be reported.  It's very unlikely that that's the case, though.  99 times out of 100, these things turn out to be simple user mistakes.

[Gavin Hird]

You wil have to create a physical model in Cheetah also, and export that as DAE separately, and then import the physical model as part of importing of the real model (Physics from file in the physics drop down.)

Cheetah does not support the concept of exporting just selected parts of your model (the physics model), so a workaround is to save your file with both the physics and real model in jas format (Cheetah native), then delete the real model in the Object browser, and then export to DAE. Then without saving, undo to restore the full content, delete the physics model from the object browser, again export as DAE, and finally undo to get the content restored.  If you somehow good up on this, revert to the saved file.  You can of course save the physics model in a file separate from the model to be on the safer side. 

 

[perfectslam]

I should start exporting to TGA.  I just prefer smaller file size.

As for the floating problem, I went back to an earlier version of the mesh (I make milestone copies for the ability of having super-undo capability).  I also did make DAE physics file(s) as well which didn't seem to work.  Every time I did, the upload cost shot up from ~$40 to about $700 and over when it didn't give me an "Invalid Asset" error, that is.  I also tried using one of the three generated LOD objects and got various errors

I'm going to have to sacrifice prim count because if I import the objects and assemble it, the physics problem goes away.  I'm not sure what Cheetah is doing when I collapse the mesh using the boolean operation; I don't believe grouped objects inside Cheetah are created as single items in COLLADA format.  Things seem to be working fine now but I wanted to have as few prims as possible buf if a slighly larger prim count is needed to make it work right, then so be it.

Were you careful to refrain from pressing the Analyze button in the physics section of the uploader?

That causes problems?