I think therefore this would be too widely used to be a viable option. Even if you buy a full-skin set, you still have a 'base' skin layer underneath, which is annoying. This proposal to let us change that base-skin to an alpha value, this way when you apply skin textures with alpha values, the invisible parts will be completely invisible.

My request is that they reimplement this so those of us who design non-human avatars don't have to rely on hideously ugly invisiprims to get the job done in hiding pieces. I have to use complex animations in order to get all my robotic avatars small enough to fit.

Well yes, but previously you could become completely invisible. And people freaked out and went nuts complaining about privacy violations, when the minimap still showed little green dots and you could turn avatar names on and still see the user.

So instead of just dealing with that, they removed pretty vital functionality from the system and forced us into using gross invisiprims that could be broken on a moment's notice.

And yes, even a fully invisible AV will still be visible via the name plate - removing that feature was silly.

As the title suggests, the best idea might be to simply permit modification of the underlying avatar skin, where an alpha channel would be used to define visibility.

This would eliminate the need to use avatar invisiprims, or the need to use tattoos as full-body skins. It would effectively restore the original intended use of the tattoo feature.

This has no effect on the "invisible avatar" argument, as anyone can become less visible today using invisiprims, animations, or unlocked cameras. The same work-arounds apply (parcel restriction, highlight transparent, HUD monitors, security bots, etc).

Anyone with a custom body skin, robotic, furry, or other unique avatar would benefit greatly from this long-desired addition.

Having the ability to make portions of the avatar invisible would be a gigantic help.

Basically, attachments would be able to specify a transparency map, this is a simple 8-bit image describing alpha which will be applied to the avatar. These maps simple specify white as 100% visible, and anything else as partially visible.
Since multiple attachments could specify these images, they are combined, essentially the lowest (most transparent value) for a pixel is used. The end result being that if you have two attachments, one removing the left hand, and one removing the right hand, then the combination of the two would remove both hands, but leave the rest of the avatar untouched.

This would be done in the same way as regular avatar baking, the result being that a fully-baked avatar would have a 24-bit body texture if no attachments provide transparency maps, or a 32-bit texture if transparency is to be applied to the final baked image.

Obviously this is much more complicated than this basic proposal, which seeks to allow the base skin to be removed, at which point tattoos/clothes are used to build the avatar back up again. But is more flexible/useful.

I didn't come up with this till after the issue was posted though, but it's worth considering if any Linden does take this onboard at some point =)

Another thought on this alpha channel layer idea, a problem actually. The SL avatar only has one arm as far as texturing is concerned. I'd really hate to be limited to being required to make either both arms transparent, or visible, and in exactly the same way. We'd be stuck back with the invisiprim workaround for people who wanted one mechanical arm or something like that.

Really, this ties in with the idea that SL needs a brand new av mesh (or rather, a set of av meshes to allow for a variety of bodytypes that cannot, as we've seen for years now, be achieved by distorting a single mesh), with a different texturing setup that allows all body parts to be individually textured, and we need different mapping layers. We need a skin layer, a tattoo layer, the multiple clothing layers, and in addition to those we need the alpha channel, and a layer for specular maps and other effects maps.

I would love to see a new mesh, and new clothing layers too. Jackets and shirts should both be able to be loose, so you can wear a loose jacket over a T-shirt. For females, the shirt layer should be able to separate from the cleavage. There shouldn't be a gap in the skirt layer around the waist. There needs to be a floating layer for the upper body, for capes, and the jacket layer should be contiguous with the skirt layer rather than the pants layer.

Is there any reason why we can't :-

1) Change the texture on the base skin layer?

2) Apply a 32bit alpha texture to the base skin layer?

3) Apply a special invisible texture to any clothing layer? (see below)

The tattoo layer is currently being used as a replacment for the skin layer in at least 95% of SL residents. So why not let us apply a custom texture to the skin layer too? It will remove one texture from most avatars, and let the tattoo layer be used for tattos!

If we could apply a 100% alpha texture to the default skin layer we we not need invisible prims to hide body parts in cool avatars. As a 100% alpha texture will only hide the surface it is applied to there will be no more distortion of other objects behind it. ( as shown in the photos above)

Wouldnt it be simple to provide a texture that will make anything it is applied to invisible. Not like the invisi-prim-texture currently in use, but like setting 100% alpha on a prim. So a shoe maker can give us a pair of socks that make our feet invisible for high heal shoes, but it will only effect the avatar/object the texture is on. Avatars have layers of textures, so if the top one has this new invisible texture, all the layers under it are also invisible. It could be as simple as using 255,255,255 colour with 0 Alpha or some other combiantion to tell the viewer not to dender that spot on the texture.

Darling.

@Torley

This and the extra layers for tattoos and such is probably the the highest priority in terms of avatar development in my opinion and I think all of us are getting frustrated by LL's ignoring our reasonable and repeated requests for this feature.

This Jira issue is over a year old, and has over 200 votes. It's one of the most requested options I've ever seen in SL, and yet, as far as I know, the only explanation ever given for the option to hide the avatar mesh was removed in the first place was the ignorant fear that people would make invisible avatars and sneak around undetected.

The ability to make correct, human-looking shoes and high heels without needing invisiprims: is that something the SL community wants?

The extensive non-human avatars that comprise the majority of the SL userbase. Furries, nekos, animals, robots, non-anthropomorphic avatars that look CORRECT, and don't rely on an exploit to utilize; is this something that the SL community wants?

You are seriously kidding me, right?

Completely invisible avatars isn't the aim of this, and 100% alpha avatars aren't truly invisible anyway as the name tag will still be there, and the avatar should still be clickable.
The aim is to allow us to remove the avatar and use tattoo layers to define which parts are visible so that we can remove parts of the avatar we don't want. In my case I have a full-prim avatar so yes, a 100% invisible avatar would be great, as I can them slim down my design rather than having it enlarged to cover up the avatar underneath.

They won't be invisible to sensors, their nametag will still be there. Hell, you can even make them show with view transparent.

This is the kind of feature that a Linden Lab developer familiar with the area of code could probably do in a couple hours, including considering how best to do it. Yet the long-term benefits are HUGE as it will open the door for the creative community to finally cast off the need for invisi-prims! I mean with Windlight added to the viewer invisi-prims look even WORSE than before as they clash horrible with the sea and sky and cause all kinds of other weirdness that means you can "see" them, we really need a better solution!

An issue with 277 votes on it deserves some REAL communication too. If there's an issue with this proposal then let's have it! Is there a technical reason why it can't be done? Hell, at this rate the most voted on issue of all time is going to one proposing that LL actually talks to us so that posting new features that the community wants isn't such a god-damned waste of time.

We, the community (LL's customers) WANT features like this, and multiple attachments per point, and a myriad of other popular issues. What is it actually going to take for us to be listened to? Do we have to start leaving in droves for other platforms that DO listen to what the community wants and DO provide the features we require?

Whoever makes decisions like this needs to also realize that there are a LOT of things that are pretty critical to SL that have failed to appear, and you know what? The general community will never make a fuss about it because they are things people never realize they need. All people know is that they have to have low expectations for SL. Not exactly something to boast about.

Like I said in at least one previous comment, the inability to create non-standard avatars without using awful kludges and exploits is every bit as bad as if LL forced everyone to use the awful default avatar skin. Any pro character designer worth their salt would tell you the same. Nothing resembling the problems with invisiprims would ever make it into a pro CG production or video game, and that's not something you can blame on user created content, because even a pro is stuck using the horrible invisiprim kludge if they want to make an avatar outside the shape the av mesh is limited to.

Not only should this remain open until resolved, but if LL were taking SL, and content creation within SL, seriously the priority would be bumped to critical where it belongs.

Some, like MISC-208 could cause problems for the system, to track that extra data.
Some like SVC-676 are jsut full of hundreds of ideas thrown in there, and aren't really actionable, or have a clear victory condition
Some like SVC-212 still don't have a clear implementation plan, and the community has been divided for a long time on how it should be implemented.

But here, we have an issue with a clear objective. Which can be implemented entirely clientside, and is in fact simply a request for the restoration of an old feature, so it's certainly possible too.

This feature could make a lot of regular users, and content creators happy with a minimum of effort on LL's part, and you guys should jump on the chance to do so.

Remember we are not striving to turn the base avatar layer simply on or off (e.g. making the avatar invisible). Plenty of residents have ordinary avatars which hide only specific areas (e.g. a void in the chest, an arm, heel, etc).

What this issue describes is the ability to specify the base texture for avatar skins, including an alpha layer to replace "invisiprim" functionality.

Let's please not get out of scope by discussing other issues and policies. That just kills issues.

My main concern will be avatars that dont alpha sort correctly and the resulting complaints from that. How will that be addressed?

Just, I think alpha blending on the avatar skin is a bad idea We want alpha masking, not alpha blending

I guess that's the only way we could get them correctly... because if we use the standard preview method (1% transparency = 100% opacity) it would give really bad results.

[EDIT]
@Coadey: What about using a grayscale texture telling which parts should be hidden and which ones should be visible? It is like we would have...
"Head Tattoos"
"Head opacity"
"Upper Tattoos"
"Upper opacity"
"Lower Tattoos"
"Lower opacity"

Or maybe a new wearable... like the "Skin" one, but called "Body opacity"... to avoid having 999 textures on the "Skin" part which would be really uncomfortable, since the appearance window is small... which would also let us more customisation, and the ability to use different skins with X opacity wearable.

The alpha could be another clothing layer, or additional skin layer textures. I would prefer another clothing layer so you could use it without having to modify the skin. you may not be ABLE to modify the skin, for that matter.

nothing has alpha masking aside from Linden plants.

Clothing on avatars uses alpha blending, and will need to for when you need alpha blending. Transparency on tails for furries and nekos use alpha blending. Alpha masking vs. alpha blending needs to be a toggle.

I agree also that it needs to be a toggle in the clothing layers as well. The skin is not a good place to apply transparency for attachments. (though it could use it for other kinds of avatar creation, where you need to hide the avatar for furries and other prim based avatars. But the skin will better utilise alpha masking for most purposes. Alpha blending is only good if you want semi-transparency. (and you'll surely run into the alpha sorting problem - I think its important to stress this can happen so people aren't surprised by it when it does)

I do know all the rest of that, and was largely agreeing with you.

I do not think this should be a tweak in the skin layer, nor some kind of hack in the clothing layers that makes the clothing alpha act like a mask on the skin layer... it really needs to be a new layer.

Remember this one? When the asset server failed to produce a texture in a timely manner and the avatar was wearing "MISSING TEXTURE"? When a few Lindens posted publicly on how the layer composing worked, and what was the final result?

Yes, you have to remember that only in one spot is the graphic card actually using layers: The body shape and clothing editor in-client. To save the GPU some effort, the client effectively flattens the RGBA-formatted layers into one RGB texture and sends it up to LL's asset server for others (and strangely enough you, to pull back down again) to see.

For those confused, open up a copy of The Gimp, make an image, and then several layers. The background would be the skin. The client auto-flattens that against white. The layers would be your tatoos and clothing.

Now, all other times the client sends up the "all flattened" or cooked texture to the GPU. This saves bandwidth, GPU memory space, and GPU speed; it's only sending one texture, not five or twelve. It's why the old "MISSING TEXTURE" bug's work-around was to use Advanced >> Character >> Rebake Textures.

So why all this, you're probably asking? I'm bringing this all back to make a point: It's not that we need a new layer, but we need to put it in the right place in the rendering line.

That right place is AFTER the flattening/cooking is done. A thresholded greyscale mask will be applied to the avatar's cooked/flattened texture indicating transparency. For the editor, it may mean that the composing is done before sending textures to the GPU, or all layers have the mask applied first (I'm not sure how LL coded the editor, but I'm very sure this is why they hesitate to put this feature in).

Implimenting this will have some cost. We'll be sending two textures down to clients – the cooked avatar skin and the mask. The GPU will have to consider RGBA casting on it's models, so we'll take a small framerate hit. And then there's the griefers...

...which will require coding the client to enforce a policy: Any mask/attachment combination that makes the avatar completely invisible will force the client to show the avatar's name/title tag box irreguardless of the user's settings. Cloud/spirit mode optional in 1.20.x.

Down to the root of this issue, it means we need more options for alpha than we have currently, so users can better deal with them, hence the link for VWR-6713.

And remember our old friend Ctrl Alt T... they'll show up.

People can be totally invisible with invisiprims (and not even Ctrl alt T works on that) so it just doesn't matter.

Lets keep this to the technical discussion of how to implement alpha on the avatar skin, and the technical problems associated with that - which are large enough. If its not implemented correctly we could end up with a lot of broken content, that has to be avoided. And that is far more important than some griefer which is easily dealt with without even seeing the av.

no, you can use alpha to coverage.

http://msdn.microsoft.com/en-us/library/bb205072(VS.85).aspx#Alpha_To_Coverage

http://www.humus.ca/index.php?page=3D&ID=61

You can probably even get away with using the same alpha texture with an automatic algorithm for masking and blending. Yes there will be more of a GPU hit though.

another link

http://developer.nvidia.com/object/transparency_aa.html

http://http.download.nvidia.com/developer/SDK/Individual_Samples/MEDIA/Video/Samples/TransparencyAA.wmv

Note the toggle modes how NVIDIA is changing how the alpha masking/test/blending occurs on the alpha test edges. This is pretty much what we need in SL, toggles to decide how to apply the transparency.

Remember, the clothing and tattoos are already RGBA textures, so we don't need to add another alpha texture to those (they have it built in). The skin itself is stock RGB, and they all flatten to RGB. We need to add the mask after it's flattened (and as someone pointed out, we can merge the mask into alpha at this point making it RGBA before it's sent to the GPU).

UI itself would follow that, requiring another texture box in the body shape editor for the last end-all-be-all mask with a "Default" button making the default fully opaque (white).

I'll put policy aside (it can go in a different JIRA bug) as we're in technical details here – I did want to remind folks of the possible abuse this tool could allow.

Not that this layer would be necessary, as LL has an automatic algorithm for 1 bit alpha - this was a highly unpopular feature in Windlight that was pulled back. The reason I mention the toggles is that one could use toggles and sliders to decide how much transparency, and whether to apply the alpha test.

I'll have to do a mockup I guess... but what I imagine is, have a check mark for alpha test, and you can use the alpha percentage to decide the level of antialiasing applied to the edges. The rollback behavior for old graphics cards which dont support the feature will be to default to a simple alpha test in instances where alpha test is checked to be used, ignoring the antialiasing.

For the majority of avatar developers this should be an adequate solution as they typically deliver a package (the full avatar). It doesn't suit one off attachments so well unfortunately, but it's a very simple solution to implement and covers things like furry avatars with digigrade legs, and full-prim avatars such robots, tinies, macros etc.

In the case of attachments such as shoes it would be great to be able to bundle them with "mask" layers to wear instead of needing invisi-prims, especially as these could be given priority over other layers so that trousers will fit shoes/digigrade legs etc. but it starts to get a lot more complicated as the discussion shows =)

"My original thought process on this proposal was just to add the option to make the base skin layer transparent, either as a togglable "on/off" setting, or a slider to make it anywhere between opaque and 100% transparent. It's not the most flexible solution, but using it you can remove the base avatar layer, and add skin back in using the tattoo layers that cover the areas you want. "

the problem is alpha sorting. I've posted links about how to deal with the alpha sorting.

Now, the avatar already has alpha. It's just limited to the eyelashes. What you are asking for is to extend it to the rest of the avatar. But this is going to be a 1 bit transparency mask, like it is with the eyelashes. Take a look at your eyelashes in sl, and see how jaggy those edges are. Nasty work... I know.

Most modern cards will support alpha to coverage. It is easy to rollback to simple alpha test for cards that don't support it. LL has the automatic 1 bit alpha test algorithm, this is hiding in your debug menus under fast alpha. But what you are asking is mostly impossible, to have translucency and masking on the avatar at one time. Masking is possible, and doable. Translucency is only possible on clothing, but this disappears in the baking process as Drake earlier mentioned. The skin becomes opaque after all the layers are baked together.

We are going to have to choose between translucency and masking, you wont get one or the other. What I would like to see is a way to choose if something is masking or translucent, or a way to apply both translucency and masking.

I've been giving it some thought... and I can see that for clothing items, we're going to need an extra tattoo slot for the mask layer, as most clothes are going to need the translucency to bake onto the avatar skin. But I think having a whole separate layer for the mask isn't a good idea, because it means only one person can use it, and many clothing items may need to use it, each separately.

In that case I support masking; I don't really see why it would be a huge asset problem, it shouldn't be hard to add support for images with lower bit-ranges. IIRC JPEG 2000 supports greyscale images which cuts down on size right away, if it supports 1-bit (black/white only) images then we could do that for hard opaque/transparent only masking. At which point the mask images would become tiny. Then surely once all mask images are downloaded then we can (if there are any) just combine them and throw them into the alpha-layer of the baked image? This way there is only a small extra overhead in fetching the mask layers, baking wouldn't be much more complex and for people around you the process is unchanged, they just download the finished result and apply it.

I doubt JPEG 2000 will support 1-bit images, so downloading PNG's (which do support it and progressive loading) will need to be done. Meanwhile, we can use 8-bit greyscale images of which the client runs a threshold algorithm down to 1-bit.

@Hypatia The clothing already has translucency, so it doesn't need extra slots for masking. If you need proof, you need to go shopping in-world over at Black Rose (B*R) for a bikini or a pair of shorts (depending on your gender).

This is going to increase the overhead of the avatar texture download though - to six textures from 3 that we have now. The good thing is the mask layer is very easily compressed, and could be a simple black and white image without an alpha channel. Extra textures can't really be avoided however.

The clothes will need extra slots for masking, especially the shoes where you need to make the upper part translucent and often have a texture, or you'll end up making parts invisible that you don't want invisible. You will have a mask layer that has to be baked onto seperately anyway.

And I'm in agreement with your post underneath mine made at 10:20am. The client pulls three baked textures at this time: the head, the upper body, and lower body. We'll have to take a hit for three greyscale masks that'll form that post-bake alpha.

What I don't get is why you want the clothing layer to have the masks too, when we know they'll be flattened into the set before being sent up with the seperate end-all mask set (and be brought back down to earth again).

http://wiki.secondlife.com/wiki/Texture_Pipeline_Improvements#Avatar_Pipeline_Improvements

Roadmap for avatar improvements.

That's precisely what I'm referring to. This slot would be filled by wearing a "transparency" asset. The clothing layer isn't an asset, the clothing layer is created by combining multiple assets (skin, each article of clothing, and so on). This would be another asset.

This is necessary for end users to customize their avatars (for example, to add robot limbs). making it an attribute of the existing assets won't work. If nothing else, look at "bad_invisiprims4.jpg". You can't make just one arm invisible with any of the existing layers.

As most skins are no mod and use up the tattoo slots, they need to do this with socks, gloves, underwear, etc. They need to make their own masks.

We need more tattoo slots anyway, especially for the skins, where people want to add makeup and tattoos to nomod assets. (but that's VWR-1449)

The second method, where you would simply use partially alpha skinning, would be more ideal for furry type avatars, etc since you could still use most of the human mesh for your avatar, but just blank out the parts where it would interfere with your design. There is a problem with this though.

OpenGL (and directx for that matter, pretty much any polygon rendering system) has serious issues with alpha polygons vs standard ones... specifically when it comes to draw ordering (i.e. which things are shown 'infront of' i.e. drawn on top of, which other things). SL certainly has not 'triumphed' over these innate difficulties, and in fact suffers from them more than most commercial games since the usual way this problem is handled in those games is simply by not allowing the level/character designers to layer alpha things ontop of/near eachother...

Since no one tells you what you can or can't do on your land in SL, theres lots of builds which over-use alpha and end up with things like a window behind a door its obviously infront of, or weird 'flckering' in flexible tails as different alpha prims end up being drawn infront of or behind others...

I worry that if you add alpha to the base avatar skin the avatars would also be drawn with these alpha problems and for instance may appear 'under' a glass platform that they were actually standing on top of..

(anyone who wants really funky tangible evidence of this alpha bug/problem i have some objects in world i can give you which are designed to show it off (sometimes artistically!)

-eltee Statosky

eltee, there is no problem with alpha as long as its a 1 bit alpha mask, or using alpha to coverage.

Hypatia: this would have to be applied after the texture is baked, not applied to each texture in turn during the baking process, because as you say they already have an alpha mask to them. Given that, it doesn't make any sense to apply it as part of the wearable... it would add much more complexity to the baking process. What's the "use case" you're trying to address by having a separate 1-bit alpha layer for each wearable?

Of course, being involved at this level, I have disclosed my involvement in both articles.

Anyone who knows SL, knows that privacy without an island sim is a fallacy. Cameras can go whever people have the ability to put them: through walls, past doors, over sim borders, and up skirts. On top of that, the camera does not have a nametag floating over it. If given the ability to have an invisible skin was renabled, anyone trying to spy by doing that doesn't really know what he's doing. What's more, a person can spy on voice using the camera because someone can "listen" from the perspective of their camera, instead of their avatar, meaning that if their camera can be close to a conversation, they can eavesdrop as if right in the middle of the conversation with no one the wiser.

Thus, I would say that the privacy reasons for disallowing invisible avatars are rendered meaningless. Enabling invisible avatars, however, opens up a wide gate of creativity and opportunity for improving SL and the things in it, and, it's as easy as re-enabling an old feature. In any case, the pros far outweight the cons, and I will challenge any who try to present a case for privacy on the basis of (not truly) "invisible" avatars. Radars, See Transparent (Ctrl-Shft-T), the minimap, nametags, collision scripts, and all kinds of other things can and are used to control intrusion from visible avatars, and would be no less effective against someone using a transparent skin.

Layers over the top of it shouldn't be affected, so you could use transparent socks to hide your feet for shoes, but they wouldn't affect any pants you wear over the top.

An explicit layer would avoid issues with wearing unmodifiable clothes that prevent you from using the invisibility layer... kind of a clothing equivalent to attachment collisions: anyone with a non-human avatar that's had skirts blow off tails, objects blow off paws, hats blow off your head, knows how much fun that is.

An explicit layer could also use a lower resolution texture, and could use a layer-specific texture that allowed for asymmetrical invisibility (so you could have one robot arm).

I want invisishoes, with a little box for the alpha texture separate from the shoe textures in my shoe shape, yes. So instead of one texture in the shoe shape, there would be two.

Because an explicit invisilayer can only be used by one person, whereas having a baked alpha texture allows you to compose textures from several makers to one explicit alpha layer that is uploaded to the sim after baking them together. (actually, it would be four textures, as the avatar is comprised of eyes, head, upperbody and lower body, all of which could use alpha for various attachments.)

There is still an explicit alpha layer, however this process allows many makers to use that layer instead of one person hogging it.

Both can coexist.

should override all other alpha layers defined in skin and clothing textures

should be only accessible in appearance

should not be tradable

should force avatar makers who wish to use this layer to supply a full perms texture so that users can modify this layer as needed

(as a side note, this layer would be good if you extended tattoo slots to the textures as well - because people would like to apply tattoos and makeup and can't because such a layer does not exist)

Alphaed skin is only useful for people who make full avatars. But it's not fair to bill that as a solution for those who need alpha for attachments, as most times they'll have no access to alpha on the skin to use them for their products. In fact, the customer won't either, often enough, so just having it in the skin layer will be useless for most people.

And it should probably be a single texture, and definitely with a new map, to allow asymmetrical hiding of limbs. It may not even be a texture, but rather a simple set of checkboxes indicating the parts of the avatar to hide (left foot, right foot, left lower leg, right lower leg, ...) as in VWR-8394.

Brandon: another point is that with any of the existing layers you can't have asymmetrical avatars (eg, left peg leg). See above.

Brent: People keep bringing up privacy issues here. I think they're mistaken but if they're worried about privacy it's better that they discuss it in another JIRA.

Which may need to be modified by the user if it collides with another attachment.

An override layer is for the user not for content makers. This is why it should not be tradable, because then its subjected to the permissions system, and what use is a layer that can override other layers if you make it no mod, too.

If you want something tradeable, use the alpha in the part that covers it. This is why I've pushed for a two part system. Alpha needs to be in the clothing and skin layers for tradeable assets. A distinct override layer needs to be for the user alone.

I'm all for layers, but layers need to be for the users to override and modify no mod assets. If a content maker wishes to sell content for this layer they are welcome to sell the user a texture.

This is why textures are more useful ... they're more flexible. It's going to boil down to an alpha test texture anyway. Even hiding parts of clothing uses a texture, these invisibility layers are easily seen in the character directory on your drive.

Clothing baking utilises a hierarchy, the baking of alpha will utilise the same hierarchy. The override layer for alpha should be applied on top of the rest, in the case of attachments that do things that are unwanted.

Once upon a time people sold textures for the body, such as tattoos. When skins took up the tattoo slots and were then sold as no mod, and were traded as no mod assets, people were stuck to using the underwear layer for their tattoos, and it made it harder for them to wear clothes.

If we make this alpha layer tradable, the same thing that happened to the skins will happen to this alpha layer. One maker will hog the asset, and others who needed it will not have use of alpha, and will still be using invisiprims. Nothing will be gained.

As I said, the fur will fly, literally. Users will capture the no mod asset so they can mod it. The usual screams will be heard when people do this. Let's just avoid it and make people supply a texture instead.

Appearance is currently composed of assets, but it doesn't have to be so. We can have material layers interspersed that intersect those assets at various points. This alpha layer would affect all layers, at the top of the hierarchy. It would bake at the end an alpha test texture that will be comprised of many alpha textures, from various attachments and the skin. Say you want an invisible man, but wearing the clothing, ala the movies. Well you could do that as the clothing would appear normally that didnt have an alpha test texture, as that alpha test for your invisible man would be on the skin layer, which is at the bottom of the hierarchy. It could let you do some pretty interesting things, as you exploit that hierarchy.

I believe a baked alpha system is far more flexible than having just one single alpha layer that many makers have to vye over, and won't really solve the problem entirely. Not against having an explicit alpha layer, as long as its for the user and can be used to override no mod assets without compromising permissions.

Since I'm starting to build Cel-Shaded AV's, this would cut out a large amount of (horrible looking, I might add) invisiprims...

If it can be done on a prim that doesn't distort every alpha texture or translucent prim around it, then I guess I'm okay with that.

But again, from the perspective of someone that rolls out avatars in several different colors, it would be a pain to move the 'hider' prim to recolor or modify the prims under the thing. Seriously this is one of my big hangups of invisiprims. You have to make the invisiprim large enough to cover the whole area, no matter what animation, no matter if the hand is in a fist or outstretched, no matter how far from the attachment point.

I think hiding the avatar under the prim is not the way to go. Putting it on the skin would help av builders more than anything.

Anyway, that sounds like a great idea. I really look forward to this feature's addition, even if it means a swath of avatar updates to finally rid myself of those invisiprims!

Really while a full alpha texture is an either/or situation, it's better than what we have now. As to selective body parts becoming invisible I really don't think a texture on a prim is the way to implement this.

Why can't an additional clothing/texture layer come into play?

*I am not a programmer

As a scripter, though the idea to have it accessible through scripts is a fun idea, I personally wouldn't find it useful for the majority of things i would use it for. I grant that there are reasons out there, but they would generally be the minority.

Most of the reasons I laid out were in reference to it being a prim hiding the avatar body part, but there are still some issues that remain (and some that are now brought up:
1. Not all avatars need invisibility in just one place, or on the whole thing. Some need it in distinct parts, like biomechanical arms. To pull that off, one would need one bloating prim covering the entire arm, and that would only accomplish hiding the whole arm, it wouldn't let you have certain parts of the AV arm showing. That, and it causes a major problem with selecting things. I hate having to constantly reposition my camera to click things because I'm mistakenly clicking an invisible prim that's attached to me.
2. How would the attachment determine how much of the avatar to hide, or what part? Is it based on attachment point, or bounding box of the attachment (and if it's the bounding box, that brings back several problems with invisiprims). Where does the hand end and the arm begin, and how does the attachment know where that point is? My point essentially is that prims will need invisible sections on the avatar as unique as the attachment itself. If you need the hand and part of the upper arm hidden, but the attachment can only hide the hand, or the invisibility changes with the hands rotation, you'll have to have another attachment on the arm to try and hide the lower part of it. But what if that hides the whole arm? Conundrums like that come up.

I'm sorry, but I still think a "skin-tight" solution is the best one, having the skin layer be alphaed, and the explicit alpha layer that's been mentioned. I will say, I don't think it has to be non-tradeable or no-mod. I know there are fears of people hogging the feature, but quite frankly, if people can't use a person's products easily for mixing and matching, they won't buy them. Compatibility is something that I've already seen advertised among vendors, "Works well also with such-and-such avatars!" We can't hope that everyone will be that smart, but I think the majority who are economically savvy will. Modding in SL is as common as putting on makeup. That aside, for specific avatars it's generally easier to make part of the skin developed for that avatar to be alpha, rather than creating special, separate parts for the attachments.

But in the MEAN time, is there any reason why we can't have a new type of invisiprim that knocks out ONLY the avatar mesh??? If I had any idea how invisiprims worked in the first place, I might be able to answer the question myself. But I Don't! So.. If it is possible, it would be really cool and way less complicated to pursue that for the short run... It would solve a lot of problems for people and leave just mildly irritating things (ie. them getting in the way of selections), and, then we could do other neat flashy effects.

If not for those problems shown in the example images, invisiprims would be pretty darn slick. So... INVISIPRIMS 2.0! You know, just for now... until bodymapped transparency gets here.

thumbs up

Yeah, it's far from perfect. But if it's even feasible, it's something worth considering for the short run. I'll open up a separate JIRA entry if so. My gut feeling is that it's not.

The main problem I see with masking is that the current UV mapping for avatars doesn't support left/right arms which is extremely annoying. Is it possible that in future we may be able to support two UV maps on the same avatar mesh, one that applies the same part to both arms (as it is now) and one which can texture each arm individually? As this is going to be a requirement for masking, especially with the robot-arm example.

There is still a need for an additional transparency asset.

First of all, however any additional layer is implemented, it has to be an asset somehow, otherwise there's no place to store it when you're not wearing it: there has to be something in the inventory to make this work. However it's implemented, whatever rights and restrictions you have, it MUST be an asset. There's no way around it.

Second, it can't just be in "the alpha in the part that covers it" because there is no such layer for heads (there is only one texture layer for the head, and it's used by the skin).

It is needed for asymmetrical attachment products. The example of a steampunk robot arm can not be handled by any combinations of the existing textures, and expecting the user to download and edit invisibility layers and upload new ones is not reasonable ... most of them don't even have a painting program that can handle transparency!

If the invisibility layer (whether a part of the skin is not a wearable then it can not be included as part of the product and worn just by selecting the folder containing the product and selecting "wear". Anything more complex than that is not usable... by any product. I'm not just talking about avatars here.

Brent's suggesting of having it riding on a prim is workable, but inelegant.

Most of the work involved in creating this would be in the handling of multiple texture layers overlaid on the avatar. That is, the avatar has to have support for multiple identical slots each containing a texture. Why not use the existing inventory user interface to create and apply these textures?

That is, let the texture itself be the asset!

You would have the invisibility texture using a new low resolution (because it doesn't need to be any higher resolution than the mesh itself) full body UV map that allows asymmetrical limb invisibility. You could select the texture and "wear" it, and that texture would be added to your avatar and the alpha layer (only) of that texture would be applied. So your robot arm would have (say) four components: the hand object, lower arm object, upper arm object, and arm invisibility texture. Right click the folder and select "add to avatar" and the whole thing goes on, including the wearable texture.

The texture asset could also be marked wearable in its properties. Putting an attachment with a "wearable" texture in its root prim contents would also have the same effect.

This is much simpler, more intuitive, and more consistent with the existing user interface.

That being said...

"First of all, however any additional layer is implemented, it has to be an asset somehow, otherwise there's no place to store it when you're not wearing it: there has to be something in the inventory to make this work. However it's implemented, whatever rights and restrictions you have, it MUST be an asset. There's no way around it.
"

@Argent

The only way its going to be truly "user usable" as an asset is if we can dynamically create such layers as we need them. That is, we can create them as an asset and it will just appear in the appearance menu, as many of them as you want, then utilising the baked texture pipeline to flatten it down to fewer alpha textures which then get distributed like all the rest of the body textures.

This brings up another idea for the UI in appearance. The user could move the layers around to intersect where they want the baking to take place. Say you need a layer between the skin and clothes, this is where you would make your layer as a full body av designer. Someone who just needs to block out a part of an arm can put that layer between the shirt and the jacket, say.

But the user could move another layer behind it or in front of it, to modify the layer as they need to. Sort of like moving tabs in Firefox. That would be so nice in the Appearance to modify the baked texture order that way.

Please read my last message, all the way through. Particularly starting at "let the texture be the asset".

Brent: I think that bit is equivalent to your proposal too... except that you don't need what you're calling the knockout texture and what I'm calling a texture with an "invisible wearable" bit to be in a prim.

maybe my experience with 3d programs and the ability to make many layers in this way in the materials influences how I see this issue. Say in Modo, example > http://tinyurl.com/5ngwxe - I can make as many texture "layers" as I want with that handy "add layer" button, and then define them as being alpha, normal, diffuse color, etc. I don't see why we shouldnt have this in SL, in fact at some point we're probably going to need a material asset that allows us to do these things, as fragment shaders are extended to the avatar itself, and the ability to define things like shinyness and normal mapping can be done on clothing and the avatar skin. The UI really needs some rework in appearance to scale to new features.

The appearance menu is simply a tabbed layout anyway. There is no reason why it cant work like tabbed windows in a browser, with the ability to make more tabs as you need. Importantly, you need to be able to shuffle these layers so they work where they need to work. Layers can be useful for more than just alpha, it can be used to make decals to no mod assets on the texture level, effectively allowing modification without compromising perms. This would be truly powerful for end users.

The simple fact is, you're often going to need several textures to make an alpha, not just one. That's how the avatar is designed. That alpha is going to cover parts of the skin that you may not be attaching to. So users need to be able to change things when they need to.

The baked texture pipeline is the way to deal with it ultimately so sims arent sending out too many textures.

You could select the texture and "wear" it, and that texture would be ADDED TO your avatar and the alpha layer (only) of that texture would be applied.

Additional capabilities, like ordering layers and support for arbitrary texture layers, are good ideas but really outside the scope of this JIRA.

https://wiki.secondlife.com/wiki/User:Brent_Linden/VWR-812_Design_Proposal

One should be able to use a texture, define the threshold for the 1-bitification (technical term, not shown in storyboard) of the knockout, see it on the avatar and commit it to the attachment.

The map image is for demonstration only. It would have to be asymmetrical (which is why I chose a leg instead of an arm. The map for arms is symmetrical, the map for legs is not). In other words, we'd need to design a new, full-body map for this knockout layer.

The only difference is that you don't have an "Avatar mask" on the object editor, the avatar mask is applied by having a texture with the "Avatar mask" bit set in its properties in the root prim. The advantage of this is:

• You can have multiple mask textures in the same prim, which can be important for end users making mashups.

• You don't have to have a prim, you can just wear the mask texture from inventory, so that you can bundle (say) a shoe wearable and a knockout texture together to make a stiletto heel without prims.

llApplyAvatarMask(list masks);

That would become a property of the object/root prim like in Brent's example. But since you want mashups, that texture select window that pops up when you click the "Avatar Mask" button could just include a list of selected textures. Up to 4? 8? 16?

How many textures? Should be a pretty big number, since they can be precomposed, and a UUID is pretty small.

Yes, yes, you can add some scripting if you like, but mostly I want to retain the concept that the texture is the asset, so you don't have to have it in a prim to get it to work.

I don't see how this is possible. The storyboard showed only one image, so it seems like it would only be possibleto hide the lowerbody, upperbody, or head with a single attachment, not all three.

Am I missing something here

PRIM_AVATAR_MASK (string texture)

would take a uuid, or texture name in inventory.

I completely agree that the scripting engine should have access to these masks eventually, however I do not agree that scripting should be the only way to use them. I believe in designing interfaces that are accessible to all, regardless of scripting know-how.

disclaimer Please keep in mind that this is just an idea. We're not actively designing this right this second. I wanted to include you guys in the brainstorming of different, less-technical ways of handling this problem So if you have ideas you'd like to storyboard please do!

https://wiki.secondlife.com/wiki/User:Brent_Linden/VWR-812_Design_Proposal

That's a really great idea to implement this Brent! And a perfect example of what content creators need. It sounds like an ideal solution for mix-and-matchers, albeit it more complicated to implement.

And yes, 1-bit alpha is about the only way to do avatars without encountering sorting performance I'm told.

Whoever implements avatar alpha will have the undying gratitude of hundreds of residents.

Consider that it could be as low resolution as the "mask" in VWR-8394 and still serve the main purpose of this feature.

Using an invisibe texture is a way to do so. There could be others, such as importing custom meshes for avatars (see VWR-8145 about importing meshes in SL, in place of using prims).

Brent: what's the current status of this? I know that you said you all aren't actively developing this right now, but I'm still anxious to hear what's going on, even for the early process.

(and, by the way, I did not realized first, but this is not the right thread to discuss custom meshes. Please go to VWR-8145 )

hopefilly they will have things worked out before shadows get mainstream...

it is already disappointing when you catch glimpses of the wires, imagine when it becomes obvious everything is made of cardboard and tinfoil.....

How about invisible sections of avatars show up as transparent red when highlight transparent is turned on, just like prims?