09-19-2011 05:16 AM - edited 09-19-2011 05:35 AM
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.
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.
09-19-2011 05:31 AM
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.
09-19-2011 07:35 AM - edited 09-19-2011 07:49 AM
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.
09-19-2011 08:35 AM
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.
09-19-2011 09:30 AM
This topic came up in early beta as well: http://community.secondlife.com/t5/Mesh/Alpha-sort
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.
09-19-2011 09:59 AM
Hehe everything is worth a try! Thank you for your reply.
04-29-2013 08:22 AM
I've answered the same topic on another tread but here's a copy patse to it!
That's the well-known z-buffer issue in the gaming industries.
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.
Hope that helps!