• Announcements

    • Xiola Linden

      The New Community Platform   03/21/2017

      We are still working on making adjustments and changes to the new platform. Thanks  to everyone who has been sending in feedback and filing any bugs you've encountered! 
Sign in to follow this  
Followers 0
warehousefifteendesigns

Alpha sorting glitch within a mesh

18 posts in this topic

Righto I've tried many things and now it's getting annoying. :P Will this alpha sorting glitch ever be sorted out? Because now it's happening on my meshes, too. I have a single mesh, a hedge. It's all one piece, not in components. I have the inner core which is solid, and an outer layer with an alpha to bring some leaves forward for a bit of depth.

The outer alpha layer is appearing behind the inner core, so is hardly seen apart from arund the edge where there's a gap in between the two bits. I'm used to and have (somewhat) come to accept this happening when two objects with alphas are placed near each other, but it's happening within my one object now.

Is there a way to fix this? I don't want to have to compromise features of some of my objects because of this. I am also thinking of what'll happen when I come to bring some mesh trees in... it would look awful.

Share this post


Link to post
Share on other sites

Alpha shuffling is practically a decade old, has existed in SL from the beginning, and has no public plans to be fixed.  More recent shadow capable clients have included an automatic toggle to 1-bit alpha if too few grays are found in the mask, but that breaks just as much content as it fixes. (._.)

My advice at this point is; work around it.  Games that use OpenGL have been doing it for years.  (._.)

 

 

1 person likes this

Share this post


Link to post
Share on other sites

Ah there's a very slim chance it will be fixed then heh if it's been around since the beginning. I'll have to try more stuff, or just stay away from plant objects lol. Thanks for your reply! :)

Share this post


Link to post
Share on other sites

This probably won't work, but I'll mention it anyway JUST in case....

Have you tried sectioning out your alpha planes into separate materials? A long shot, but worth trying....

1 person likes this

Share this post


Link to post
Share on other sites

Alpha sorting glitch is opengl thing. Thus there is nothing a viewer can do about it. It should be corrected in the opengl itself, if at all possible. As this thing has been in opengl for ages I wouldn't keep my hopes high. The best thing to do is avoid any alphas in meshes. Why do you need alphas there anyway? Can't you just model the thing what you're doing?

1 person likes this

Share this post


Link to post
Share on other sites

I think Maeve is correct. If you make the core and the outer different materials, so they are different faces inworld, then make sure the core face is textured with a completely non-alpha texture (24 bits), you should be ok. f you try that, please let us know the result here.

1 person likes this

Share this post


Link to post
Share on other sites

Hmm making the outer shell a seperate component and making the inner core non-alpha seems to have worked out beautfully, and it now looks as I modelled it. :)workinghedges1.png

This is exactly what i was tryin to achieve. Before, the outer shell would appear behind the core and it couldn't be seen. I wanted to achieve something with depth, so the inner core has a block hedge texture, as well as shadows from the outer core, and the outer core just sits on top.

 

Thanks for the advice, glad it got fixed in the end :)

Share this post


Link to post
Share on other sites

Glad it works! Also, try it out as a single mesh... (I probably didn't word my idea very clearly, due to the early hours of the morning LOL)... In theory, if you have it as one mesh component, and for each of the alpha areas use a different material (up to 8 in a single mesh), I would assume the result would still be the same (each material area can have entirely different and independent textures/alphas/UVs etc). Looking at your screenshot, I would think it would render exactly as it does here, and probably save a little percentage of PE in the process (being one mesh instead of two, although the difference would be very slight).

I often use materials to separate out components in my meshes... say, if I want to hide a bit of overlap in a prefab room interior, I can apply a full alpha texture. Materials are definitely worth using for their added versatility.

:matte-motes-smile:

1 person likes this

Share this post


Link to post
Share on other sites

Hmm... I'll explain myself a little better (my usage of the word component is probably confusing the issue).

To explain materials.... As an example, think of the faces on a standard prim cube in SL - it has six faces. Now, say you created a basic MESH cube. You could define each of those sides as a separate material (most modeler programs should have a method to define material zones). SL treats materials in the same manner as it does with faces on a prim... so in this example of a mesh cube, with six material zones defined (one for each of its sides), you can apply totally independent textures, just as you do with a prim cube in SL.

Now, since with material zones you can display totally independent textures, this means you can overlap the UVs, as long as the UV islands for each specific material area don't clash - so in the example of the mesh cube, each face could share the exact same UV space (I hope I worded that clearly LOL).

In my mention of hiding components in my meshes in my last post, I was referring to how i define sections of my meshes into separate material components (doorways, walls, trims, overlapping sections where my prefab meshes meet etc) - by being defined as individual materials, they can be hidden if needed via alphas applied to them specifically (via the edit face option in the SL build menu).

.......

Now... here is a potential big advantage with materials (I havent properly tested this yet, but since it works in general 3D modeling, I would think it reasonable to assume it works for SL also (anyone please correct me if I am wrong). Say you have a large, complex mesh, which will be difficult to fit everything into a single UV map without it all being reduced to tiny islands with not much resolution for detail.... If you build your mesh with materials in mind, you can break it up into partial components (SL mesh supports up to eight materials in a single mesh object - so you could divide up a complex mesh into eight components if necessary). Now, what I would do is export each of these components to a separate file, where I'd UV map them on their own. When done, I'd import them back into a single mesh file - each of these pre-UVmapped imported meshes should hold their UVs. I wouldn't recommend doing any changes to the new imported component meshes other than a little resizing if needed (welding / deleting vertices and faces will probably kill their UVs). At this stage, define each of the imported components as individual MATERIALS. When done, export the project as a single DAE file for SL... this should automatically include the UVs as a single merged map (or mayhaps the file would treat them as independent?). Regardless... each of the material components can have their own independent textures painted onto their defined UVs, and then applied as textures using the SELECT FACE option in the SL build menu.

Now, If this concept works... I imagine it would also be feasible to use repeats of material components within a single mesh file to further add to their versatility (say, a single column inside a building, defined once with a single UV and material, used repeatedly inside the mesh (it would have the same texture for each repeat)).

Fingers-crossed this actually works - as I said, I haven't properly tried this as yet. :matte-motes-big-grin-wink:

And ALSO, keep in mind that single material zones DON'T HAVE TO BE CONNECTED... the polys can be totally separated if need be, spread throughout a mesh - say, a series of windows in a house, or posters on walls all over the place - they could all share the same material and UV within the same mesh file. Try doing that with a prim!

Phew... I've probably missed something there somewhere. But yah, materials combined with overlapping UVs can be seriously powerful. The biggest challenge (and FUN) is thinking of all the different ways you can harness their usage.

:matte-motes-smile:

1 person likes this

Share this post


Link to post
Share on other sites

Oh wow! Thanks for all of that :) This sounds very promising. As I work wth big textures for best quality, I found it hard to even fit everything into a 2048 map with the detail I wanted.

I am definitely going to try this now. I'm going to quickly model a tree and see if the different component thing works :))

Thanks again! Will report back soon.

Share this post


Link to post
Share on other sites

Some notes.

The maximum size of a texture in SL is 1024 x 1024. If you upload a larger texture, it will be resized by the jpeg2000 library before it is uploaded.  This will result in loss of detail.

Despite ther name and how they are displayed, UV maps are nothing more than a list of the locations in the texture plane (u,v coordinates) that will be applied to each mesh vertex. The rendering software uses these to work out how to stretch the texture over the mesh triangles. For two different materials (which become different faces in SL), the UV coordinates refer to different textures, and so there are no restrictions on overlapping them.

For one texture, the default process is to make each part of the texture correspond to a different part of the mesh surface. This appears in the UV map editor as non-overlapping 'islands' of polygons on the UV map. However, this is not a requirement. With reasonable care, different parts of the mesh can share the same parts of a texture image. For example, both sides of a hedge could be identically textured by exactly overlaying the polygons representing them on the UV map; several window frames in a wall could similarly be overlayed and receive the same texture. This 'stacking' of similarly textured surfaces means that each can (re)use a larger part of the available texture area, and thus have more detail. This is one of the most effective ways of increasing the surface detail vailable from a texture of a fixed size.

 

1 person likes this

Share this post


Link to post
Share on other sites

Thank you all for your ongoing help. :) I think seperatig the alpha bits into their own components seems to have solved my problems. I can start building up my meshes in SL now :)

Thank you all again! +Kudos to all the posts here. :)

birchtreeworking.png

Share this post


Link to post
Share on other sites

This topic came up in early beta as well: http://community.secondlife.com/t5/Mesh/Alpha-sorting/m-p/418761#M1741

After some experimenting in Blender, I found that the last item joined to the model had the highest priority when it came to alpha. I tested this with hair. So, I built the hair from the bottom of the scalp up to the forehead. That prevented alpha sorting. I haven't played with this since those early days though. Hopefully, it still works.

1 person likes this

Share this post


Link to post
Share on other sites

I've answered the same topic on another tread but here's a copy patse to it! :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:

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
Followers 0