Transparent textures on rigged mesh 'bug-out'?

[Iain Pinelli]

Hello Folks!

I've encountered an issue with rigged mesh avatars, where transparent textures commonly used with hair in 3D models the transparent texture for parts such as the hair ends causes what appear to be some sort of texture-layering issues. However i have noticed some SL mesh creators making clothing and hair using this same method without issue.

EXAMPLES:

http://i.imgur.com/hmqEg.jpg

http://i.imgur.com/3tGny.jpg

The alternative is I could just make a complete mesh hair and a non-transparent texture and reform the hair so the hair creates the 'ends' and 'curls' but this would waste ALOT of polygons which for SL avatars as most people know is already a big issue.

[Maeve Balfour]

Meshes are subject to this kind of alpha glitching in SL, so you will have to work around that.
(I know the type of hair you are referring to (DAZ and Poser hair for example), where the hair is built up with many layers of polygon mesh, with textures using alpha channels applied to each layer, This style of hair (NON-SL) generally uses thousands of polygons and many layers of hair for this kind of effect. However, this is just not feasible (and irresponsible) to do in SL due to the associated render cost).

This kind of glitching can be reduced via the usage of material mapping to ISOLATE sections of the mesh which utilise textures with alpha channels. Also, keep in mind that this glitching effect might also be due to the mesh normals pointing outward in one direction, so with transparency in usage, you are also probably seeing parts of this same mesh from behind, hence the sudden invisible aspects.
Flexi prim hair has the advantage of standard prims having faces in all directions, which mesh does not (unless you create backfaces to each hair texture face, which will instantly double your triangle count - not good if you are trying to keep your render cost responsible).

I would suggest dividing up your mesh into sections, using a combination of linked meshes and material mapping. You will probably require a base mesh hair shape with NO alpha channel textures used for its associated material zones, to give the hair a solid look, and have a couple/few other mesh layers above this with alpha channel textures. The glitching will still be there though, so it is just something you have to allow for and work around.

:matte-motes-smile:

 

[Ashasekayi Ra]

You can control the glitching within the hair by controlling the priority given to each layer. The process probably depends on which 3D modeling software you use. If you use Blender, I could explain how to setup your model.

[Drongle McMahon]

Ash, I remember testing your method successfully during the beta. I think it would be very valuable if you felt like explaining it to people here.

[Ashasekayi Ra]

---

Drongle McMahon wrote:

Ash, I remember testing your method successfully during the beta. I think it would be very valuable if you felt like explaining it to people here.

---

I actually don't remember what I wrote back then for Blender 2.49.

But, I have been working with hair more in Blender 2.62. My process has been to give each individual layer its own material id. But most importantly, I make sure to build the hair up until the piece that needs the highest alpha priority is on top. For example, I build the skullcap first, then the bottom strands and finish with the very top layer of hair. After some experiementing. I found that if I created or imported in a skullcap after making the hair, it would always appear to sit on top of the hair because of alpha sorting issues.

[Drongle McMahon]

I think that's what I remember .. that the last added mesh faces come out as if they were on top whatever their actual position. It might have to do with the order the triangles are presented to opengl. Of course that could change with different exporters putting them in different orders in the collada file. I guess anyone wanting to copntrol this has to do their own experiments.

[Drongle McMahon]

Thought I'd better check. This is with Blender 2.49 and the current release viewer. I made a mesh with just two planes, all the same material, but one plane UV mapped so that the texture was smaller and repeated more. The plane with the repeated texture was made first, and then the second was added in edit mode.

Here are three versions, all textured with the same texture that has transparent areas. On the left, the second added plane is in front. No alpha glitch. In the middle, that plane was moved behind. Now the glitch happens because opengl is putting the texture of the second added plane in front of the first added one despite the fact that they are geometrically in the other order. Note that the shadows are cast onto the texture that should be behind although it is rendered in front. Ugh!.

S then I edited the Collada file that gave the glitch, by hand. I simply took the first 18 indices in the <triangles> tag, specifying the first plane, and moved them to after the 18 indices specifying the second plane. The third example is the result of this edit. Now the planes are rendered in the right order.

So it does appear that, within one material, the faces are rendered in the order they are specified in the Collada file. For Blender 2.49, this is the order they were added to the mesh, the later added ones being rendered as if in front of the later added ones, at least in this simple case. 

This is presumably a consequence of the order in which the triangles are passed to opengl for rendering. The usefulness of this effect will depend on how far that order reflects the order in the Collada file. It may not be that simple for more complex meshes. It might be useful if people report further observations here that may bear upon that question.

 

ETA - Important note: This behaviour does NOT apply to faces with different materials. These behave just like different objects, with the rendering order depending on the distance of centers, and thus on the angle of view.

[Ashasekayi Ra]

Thanks for the interesting experiment, Drongle.

One thing that I noticed when experimenting with the skullcap was that it didn't seem like I could change the order by importing the objects in. To use hair as an example again, I had this one hair that I designed without a skullcap. Later, I changed my mind and wanted to add a skullcap underneath. However, nothing worked to get the alpha order of that skullcap to appear below the other hair. I even tried exporting out each hair piece and re-importing them in the correct order. That still didn't work. I ended up having to rebuild it from the bottom up.

Note: Each hair piece did have separate material ids.

[Strawberry Lionheart]

I've answered your same topic on another site but here goes! :cattongue:

 

That's the well-known z-buffer issue in the gaming industries.:catembarrassed:

 

If you are in 3dsmax all you need is to setup the z-sort in the layers.

For blender it's best you resort the vertex(vertices) numbers from low to high (lower layers should have fewer numbers). That's how most game read the layers by vertex number. So say.. you have 3 semi-transparent layers close to each other and the camera doesn't know which one should be on top when it comes to render and it simply render from the smallest numbers to the largest. so if your top layer is 1-4 and 2nd layer is 5-8 and bottom layer is 9-12. you will definitely get an alpha blending bug with the z-buffer rendering in SL. so what you should do is, have your top layer's vertices sort to 9-12, 2nd layer 5-8 and bottom layer 1-4. This way when z-buffer render the mesh it will load the bottom mesh 1st then cover it with the 2nd layer and then the top layer thus eliminates the bug shown in the picture you post. :catwink:

 

Hope that helps! :catembarrassed: