Strawberry Lionheart

As far as i know not all viewers support multiple avatar alpha layer. and unless the creator has time and patient to download all the available viewers and make a list of which is compatible, it's not an effective way to do imo... And the only other way around is asking the customers to stick to the official viewer which support up to 4 layers of alpha.

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:

I've answered the 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:

You don't need media on to load a url as texture on a surface of a prim since v2. Not many know of its existance but it can be done by script alone. What they might be doing is having an api gateway which creates name jpg on their server and direct display it on the prim. So you WILL need to have your own server for that :catwink:

The Old Micro Avatars (before mesh) are using a fixed pelvis position animation file that re-run itself on a 0.1 second timer (it's considered a very resource taking script (cause lag) but also the only way to prevent any other animation to rewrite it during play). Depending on how you want to "Adjust" your avatar it will end up with hundreds of animation files needed. But making an adjuster is possible. (Check Marketplace for BB Micro Adjuster for example) For Up Down only it's easy.. But if you want a match of Up Down + Left Right or Front Back. You will need a script that do math with a series of animations to match the calculated math and playback the animation file with a 0.1 timer. eg.. Front 1 Up 1 = 1 file, Front 2 Up 1 = 1 file, Front 1 Up 2 = 1 file, Front 2 Up 2 = 1 file. The more "adjustable positions" there are, the more animation files you need. The above method is the only method that works with script command so far. (as of date of this post there's no way we can control the offset with script) We are currently voting to get SL to add a new script command so we can adjust offset without any use of animation just like the llSitTarget with both Position and Rotation in Jira. If you guys are interested in a new function like that do go and add a vote. And hopefully we will get enough votes to get Linden Lab to add the new script command. Vote site: https://jira.secondlife.com/browse/SCR-349

The Old Micro Avatars (before mesh) are using a fixed pelvis position animation file that re-run itself on a 0.1 second timer (it's considered a very resource taking script (cause lag) but also the only way to prevent any other animation to rewrite it during play). Depending on how you want to "Adjust" your avatar it will end up with hundreds of animation files needed. But making an adjuster is possible. (Check Marketplace for BB Micro Adjuster for example) For Up Down only it's easy.. But if you want a match of Up Down + Left Right or Front Back. You will need a script that do math with a series of animations to match the calculated math and playback the animation file with a 0.1 timer. eg.. Front 1 Up 1 = 1 file, Front 2 Up 1 = 1 file, Front 1 Up 2 = 1 file, Front 2 Up 2 = 1 file. The more "adjustable positions" there are, the more animation files you need. The above method is the only method that works with script command so far. (as of date of this post there's no way we can control the offset with script) We are currently voting to get SL to add a new script command so we can adjust offset without any use of animation just like the llSitTarget with both Position and Rotation in Jira. If you guys are interested in a new function like that do go and add a vote. And hopefully we will get enough votes to get Linden Lab to add the new script command. Vote site: https://jira.secondlife.com/browse/SCR-349

I haven't seen any successful case of a flexible path weighted mesh in Second Life so far. What others do is they simply "animate" the mesh with a series of keyframed exported meshes and script them to "move" in SL with script (Just like the old animated sculpts but with a different script). And yes that means you need to export and import EVERY frame needed to be used in the mesh/sculpt animation and for rigged clothing, re-rig every frame before exporting. There is one way to reduce the export numbers by multi-subbing but it will also means a more complex script needed to animate the meshes. And if you are good with script you can control "When" the mesh starts to animate and do "Which" animation pattern according to what the avatar is currently doing.. eg. walking stance, sitting stance, flying stance, idle stance... Please remember that this method, tho working, is not the best way because it costs a lot of loading time as well as rendering resources... So it's quite the irresponsible way of creating a mesh since they will be the ones that lag SL up a lot. Especially when you are not good with mesh polygon control when you build and ended up with an overly faced mesh.. Animating that kind of mesh will be lag hell for everyone.

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:

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.:catvery-happy: Hope that helps! :catembarrassed: