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?

What is "SL community"??? How could a large gathering of people who mostly never meet each other may have an unanimous anc concerted opinion on a given point? There is nothing such as a collective intent for SL users. What we have is a variety of users with different needs. Linden Labs just has to service them at best, with as only limits technical and cost constrains. Oh, and yes, the community has a place to speak however, and it is the JIRA site. And precisely it is expressing a demand, on this page.

On the topic, to have partly or completelly invisible avatars would be great for small shapes or non-human shapes. I myself tried (in another world) to appear just as a light glow, like a ghost or strange phenomenon. This was great, and people were very intrigued or interested. In SL this would require to make everything invisible. It would also need to make the name tag invisible, in order not to spoil the game. However to be completely invisible could be used by griefers, so if we implement this, it would need some safety, such as a "show hidden names" quick button, or the system indicated two posts above by Adeon Writer..

So I support this feature request, with probably enough other residents to make it implementable.

I like Brent Linden's proposal allot. Being able to mask parts or even the entire Base avatar effectively allows much more diverse avatars to be made. and will eliminate the need for the current invisiprim hack. aside from being able to completely change an avatar's mesh, skeletal structure, or the already implemented sculpted prims, this would be the most significant change that could be done for all of the users that prefer to use non human or modified human avatars.

As for the concerns of making a while avatar invisible... It seems like that's more of moot point since the switch to showing small particle clouds for unloaded avatars. I've seen griefers exploiting that already implemented change to make themselves almost unnoticeable. Those that this feature would benefit greatly outweigh the potential for abuse in my opinion. As long as avatar names couldn't be easily hidden and if the masked parts could be shown using show transparent griefers could still be identified and caught.

Hopefully we'll see this improvement eventually...

1. Whether or not we view nametags is up to our client settings. We have an option to always display a person's nametag floating over his head regardless of what settings he might have on his client.
2. Most people have avatar scanners that tell them who is how close (and quite often) where.
3. Avatars generate all kinds of racket that can be heard (provided you don't have your volume turned down).
4. Avatars are displayed on the map and minimap
5. They create particle streams when editing things
6. You can run into them and they can run into you.
7. They have a nametag floating over their heads.

Unless you have a private island, true privacy is a joke anyway when it comes to SL. A person who is not "cloaked" can zoom in with his or her camera and listen to your "private" voice conversation from across the sim. People can cam around walls and peek in on people doing private things in their SL homes. They can get around banlines with the camera, fly over banlines, get around flight disabled sims by using a neighboring sim, or sitting on an object of their creation. There are all kinds of ways that currently exist that are far, far superior to using an "invisible avatar" that provide perfect anonymity.

Transparent avatars would allow a great deal of opportunity for aesthetically improving SL in the things we can build and the avatar varieties we can produce. No one in their right mind would use an "invisible" avatar to try and spy on someone. Anyone who did could be just as easily dealt with as someone who wasn't "invisible". I'll also second the simple and good suggestion to let avatars show up as a "Ruth" or something if they are made invisible (hopefully in a manner that does not bring up alpha sorting issues).

For me this issue has always been about just adding the option for alpha on the skin of the AV. Not hiding the name tag as well. If there was a fully invisible av, I would still expect to see their name tag. No doubt there will be fully alpha avs who will want to remove their name tag for effect. But let's not confuse name tags with skin alpha! It's a seperate issue surely!

I also like the idea of being able to expose invisible avs through some sort of highlight transparency option. I think that should work exactly the same way as highlight transparency does now. Perhaps with a slightly different colour than the red to distinguish avs from objects.

Can't you just update the avatar base skin to allow alpha?

With all of the votes on this, you would think we could just utilize 32bit alpha mapped TGAs.

The reason I care is like most. For people that want to make avatars, but dislike how invisiprims distort water, other avatars, etc....that is the reason alpha should be allowed.

I think a past concern was that people could spy or whatever. I think nowadays that threat is kind of a ridiculous concern.

People can cam throughout sims already as well as wear invisiprims etc....so I think the lack of alpha at the skin base level is only hurting those that want to not use invisiprims.

Thanks and please implement this.... look at the amount of votes!

However the currently proposed system by Brent Linden to me would serve much more useful to those not wishing to use invisiprims, than simply allowing them to put alpha directly on the skin. (Would also be nice, of course)

For information on this technique, check here: http://tinypaste.com/a48ab it's a copy of the notecard that was passed to me.

This technique really works and actually improves framerate, hopefully it can help you too!

*edit to add* Those wanting a copy of the attachment in Second Life just let me know.

This feature has been a large part of the end-goal of an avatar pipeline improvements project that several lindens (myself included) have been working on for a while. We have some internal demos of the functionality that are currently going through testing as we speak. I will post images of what kinds of things you can expect to see with this feature shortly. We will be rolling out our first round of changes in the 1.23 client, but due to backwards compatibility issues, will be unable to expose the functionality for a couple more versions of the client. This will give us sufficient time to get the interface and other aspects of the design solidified and working 100%.

Once released, there will be two options:
1) hide your entire base avatar

2) Use alpha-masking to mask out pieces of your base avatar

Alpha masking will work much like Brent Linden's design above, however, we will not be changing the UV mapping of the meshes. These "alpha masks" will be assets that you can wear & detatch and will cause parts of your avatar mesh to not be drawn on a per-pixel basis. There will be no alpha blending with these masks which means you will not be able to have your avatar appear semi-transparent, but there will be no blending issues that there are with invisiprims.

I will be happy to discuss the scope and some details of these features in this JIRA, or at my office hours at noon PST on Wednesdays in Borrowdale http://slurl.com/secondlife/Borrowdale/74/217/32.

Feel free to watch this jira issue to keep up to date or stop by office hours with any questions, comments, or feedback.

One concern we have though is the rendering pipeline and how avs are rendered within it... already, there is some disparity between the avatar mesh and attachments in the rendering process... i.e. if you wear a white texture on your avatar, and attach a white prim to yourself, they come out very different shades/colors depdending on lighting situation.

Would changing the avatar rendering to allow alpha make this worse? make it better? have no effect? It makes things like more intricate/elaborate clothing which requires a combo of skin textures and prims somewhat hard to do, at least for lighter colors... darker colors seem to line up better.

https://jira.secondlife.com/browse/VWR-8012

@damien: Supporting it only for a while isn't really an option. If we do so, we'll be stuck supporting it for much longer as residents will now rely on it for their purchased avatars. I'd recommend that nobody use the megaprim bug that you mentioned, as it is a bug and it will be fixed at some point. Any inventory that comes to rely on it will then break when we fix the bug. The downside to using it now (or us looking the other way) is that a lot of residents will be very angry with us later down the line when their purchases stop working.

"Today, those wishing to change their basic skin appearance must apply a second, overlaying skin using the "tattoo" feature.

This makes it difficult to use "real" tattoos, make-up, freckles, or other skin additions (including appearance sliders) without manually incorporating them into the "tattoo" texture. It also means each avatar with a custom skin still has an unnecessary texture underneath.

Further, those wishing to alter their basic avatar shape must apply "invisiprims" to hide body parts. These prims also hide other objects with 32-bit textures (nearby avatars, water, floors, etc), which causes frustration for those who use them, introduces alpha sorting problems, and inhibits design freedom.

Both of these issues could be addressed by allowing users to specify the underlying skin textures on their head, eyes, upper body, and lower body. Or to allow skin-creators to specify an overall alpha level for their "base" skin layer of their avatars, for example as a slider in the skin settings for an avatar.

(Images illustrate how "tattoos" are commonly used to override the base skin, and how poorly invisiprims work for avatar builds)."

and regarding Linden support, how about you guys promise to keep it working as it currently does only untill the official solution comes, and have one of those dialogs with a "don't show this again" check box for when someone wears an attachment that triggers the trick, informing people the trick is only supported temporarily and will cease to work soon, and that there will be a true official way of doing that in the future ? (perhaps with additional info in the dialog, like a link to this jira entry and a suggestion they talk with the creator to make sure they will be providing a fixed version free of cost when the current trick ceases to work)

The demo screenshot looks awesome, Nyx. Thanks!

@TigroSpottystripes: Additionally, having a dialog to announce that info to residents when they use the bug, would require development resources and also wouldn't be released into the wild for a while, since it would still have to go through the QA, merge, and release candidate pipeline. This would mean, that the changes to support the hack temporarily couldn't actually be released until not much before support for alpha masks and invisible avatars would officially be rolled out anyways.

For now, enjoy the awesome screenshots that nyx posted and please continue relying on features that are officially supported.

Changing UV mapping of the avatar, the underlying skeleton, or the mesh itself is not a part of this avatar project. That isn't to say that we never will change any of these things, just that they are not within the scope of this project.

Nyx, thanks for implementing some solutions to this problem. Both:
1) hide your entire base avatar
2) Use alpha-masking to mask out pieces of your base avatar
are interesting possibilities.

I remember an experience (before SL, in the blaxun worlds) where I appeared just as a ball of light. People had very interesting reactions, it was a positive experience. It is also great for any non-human av.

Also the cautions about not supporting problematic fixes and hacks may be frustrating, but in the long run it is much better, to avoid frustration. Many people may not undesrtand why a "feature" (buggy) will no more be supported, and some creators may abuse of this, not knowing the issue or from being scruppleless.
This happens because most people are not knowledgeable into computer programming, and thus they cannot make the difference between a robust solution and a problematic hack, since both seems to work as well. So congrats to the Lindens who decided things this way.

Those avatars can only be done thanks to a bug, which turns the mesh into an animation skeleton and prims into the mesh that is being rigged to it. If this "bug", for example, was removed, the freedom which it gives to avatar creation of those outstanding giant avatars would be removed too, and we wouldn't be able to create such huge avatars anymore...

I know that the standard avatar UV map treats both arms with a single set of uv coords, which already has clothing creators annoyed as they can't make assymetric tattoos, gloves and such for them.

There are many different avatars in-world, even the plain human ones are vastly different from each other. Having to wear a 'real' primmed/sculpted arm additional to, say, a robotic one would look horrible in most cases, as you simply can't match nearly all the skin tones, and especially the musculature done by the body sliders in a prim/sculpted attachment for most people in any way.

So ultimately:

Make it a n option when creating a skin as to wether you want the base skin to be 100% transparent, or 100% opaque. Perhaps add in an additional slider for said option...rather then making the skin 100% transparent by default instead of opaque.

On the other hand, that alpha mask could be an attribute of the pegleg I wear, just like Brent Linden was proposing, that when worn automatically hides that portion of your leg. Makes pretty good sense to me.

Personally, I'm a fan of the flexibility that's given in the latter option.

If it's just a black & white texture you use to mask parts of an avatar then I didn't see why it shouldn't be a skin setting right under the 3 tatoo textures, as I thought there wouldn't be any point to making a new item just to apply an alpha texture to an avatar (basically a wearable for a single setting). However if this new item would have its own sliders for hiding body parts individually or other settings as well, then sure it's best as an entirely new item.

When I said it's best as a skin attribute I imagined this would still be just an alpha texture you'd apply to the avatar, so what use is there to make a new wearable for only one avatar setting then.

1.) A new 'clothing' item, that you can wear one of. Creating them would seem to be similar to creating a new skin: (this is a guess as to how it will work, but it's fairly safe assumptions)

-Create three textures: head, upper body, lower body, consisting of alpha-layer UV maps (Color channels in the texture will be ignored.)
-Go to edit appearance, pick Avatar Mask tab, choose Create New Avatar Mask.
-Drop in your three textures, hit save
-You now have an inventory item based avatar mask, which 'holds' those three textures as one clothing item, similar to how skins hold three textures as one item.

2.) A property of a Linkset.

Brent Linden's proposal. I'm not sure if Nyx Linden is still implementing this one, but it would behave as a property of a link set and automatically apply to your avie when you wear the linkset
It is detailed in full here.
https://wiki.secondlife.com/wiki/User:Brent_Linden/VWR-812_Design_Proposal
The benefits to this second method is you can wear many avatar masks, based on each item. The downside is if the linkset is no mod you may not be able to wear it without activating the avatar mask.
I would assume you would actually attach the clothing based mask to the linkset, rather than a texture (since it would actually require three.)

These don't seem mutually exclusive. Both would be great.

A random thought:
You could put all three textures (head, upper body, lower body) on one texture just by having them as the red, green, and blue channels. This would make one Avatar Mask asset 66% smaller as it would only use one texture rather than three, at the cost of not being as intuitive to create.

About the random thought, those don't seem to be possible, since the texture should map the EXACT UV coordinates, and if you set it as a single texture for everything, we're doomed, because the UV coordinates would go crazy... I doubt it to be possible. (Maybe it is, but I can't see it possible right now)

I'm curious about the avatar in Nyx's picture. It's textured inside, I see it being useful. I'm thinking we'll see a few M.C. Escher's 'Rinds'. Will this be toggleable for those who want their avatar invisible from inside the mesh?

1) The alpha masks will use "alpha rejection" which doesn't draw pixels that are rejected. This is different than "alpha blending" which is used for partially-transparent pixels. Alpha blending has the ordering and fighting issues you see in semitransparent objects today, alpha rejection does not as you can see with the linden trees.

So you are correct, there will not be the blending/ordering issues with the alpha masks. See the screenshot alpha mask example (taken by the water).

2) Currently we have avatars rendering both sides of their geometry, resulting in the ability to see the "inside" of the avatar through the holes made by the alpha masks. At this time we don't have plans to change this, unless some issues come up that require us to. Content creators not wanting the inside geometry to be visible should "cap" any holes generated by the alpha masking.

For example, if you were a pirate and wanted a pegleg, you would want to make sure that the pegleg lined up with the alpha mask at the same point in the leg so someone wouldn't see "up" your upper leg to the inside of your avatar. I can't guarantee this will be the case at the time we release this functionality as details are always being tweaked, but if this remains, I hope to see a lot of creative uses for it!

3) Alpha masks will cover every default part of the avatar - head, hair, eyes, upper body, and lower body. There will not be an alpha mask for the skirt, as it can already have an alpha texture applied to it or be taken off if it should not be visible.

So you are correct, there will not be the blending/ordering issues with the alpha masks. See the screenshot alpha mask example (taken by the water).
===

for things like walls with windows, curtains, hair, floors, and pattern overlays on dresses, which use alpha not for transparency but for creating spaces between solid parts of the texture, could this not be added to kill alot of the alpha bug?

For example the glass of a window would still be transparent but my solid drapes that follow the sides will not produce the alpha bug?

However, as you say, adding the option to upload any texture with a 1-bit alpha-mask would be useful for solving certain kinds of alpha-sorting issues, or, since not many programs support explicit 1-bit channels, the option to have SL filter a regular alpha-channel into a 1-bit one would be neat.

Then have an option on image upload that says "Use 1-bit alpha mask?"

I think that's the most practical, yet, compatible scene, in my opinion, so we could still use the file formats we are used to...

If the entire avatar is hidden using option #2, the geometry will not be drawn. However, we needed a more robust solution for cases where only part of the avatar needed to be hidden - high heeled shoes, peg legs, robotic arms, etc.

Right now the AV UV map doesn't allow for assymetrical arm textures, and thus as you pointed out before, you can't make only one arm invisible. You also said that redoing the avatar UV map was not a part of this task. So, I just have a question relating to that:

Let's say, for sake of discussion, that another task did in fact change the avatar UV map so that it was nicely laid out and allowed for the arms to be assymetrical in textures. Would the new changes for avatar alpha hinder that development, or would they have little to no effect on it? Would these changes going to avatar alpha make it harder to redo the avatar UV map?

Doesn't sound fun at all... so many sales out there will become a total loss of money, and all the work of those developers will be completely trashed... there should be an option which allows us to choose between the new or legacy UV layer, and apply that to the alpha masks as well, otherwise leaving the UV maps like they are right now...

Trust me, as a user of a full-prim avatar, and several partial-prim avatars, I'm all for avatar transparency. I'm excited it's coming and it has my full support. At the same time, I'm not sure I'd be willing to trade it for a better UV map, that would enable better products for assets such as clothing and skin. Again, like Shakeno, I'm not trying to change the subject. I'm just concerned about how avatar transparency might affect the future of the avatar itself.

If they are going to plan to remove invisiprims, they need serious lead time with this to allow people to begin to work with it, and update existing customer bases.

There are quite literally millions of users/products out there with invisiprims on them... Thats not all going to update in an hour, or a day, or likely even a week.

One would assume/hope that they successfully deploy this new feature, get the kinks worked out, make sure everyone is happy with it, then if they did want to 'fix' the invisiprim 'bug' they would announce a time, several weeks in advance, and let people bring this out to existing customers. That is generally how you accomplish this kind of feature 'transition' successfully.

Of course, even that won't fix content from creators who are no longer active, etc, which bring into question whether 'fixing' invisiprims will ever really be an activity which can 'succeed' vs just piss of a whole giant pile of people.

Its great that going forwards people will soon be able to use a validated, supported option for their designs, but that has very little to do with 'removing invisiprims'... that is honestly a wholly different, and hopefully much much later (if ever) activity.

Shakeno Tomsen added a comment - 27/Apr/09 04:52 PM
I need to ask... will invisiprim still exist after the "bug" has been "fixed"?
In the way of the shiny in a transparent primitive. It is really handy sometimes.

do you mean like how they screwed up with VWR-4167 ?

Personally, I can work around the megaprim thing getting broken quickly. There also aren't quite as many products out there using that compared to standard invisiprims, so the number of people put out by breaking it at the same time as releasing alpha masking wouldn't be that bad. Standard inivisprims, on the other hand, require a lot of lead time, as eltee said.

Consider the content creators like me who are disabled and can't possibly scramble to update their entire line in a short period of time. Also, most creators don't do this full time anyway, so they'll take even longer. You can't possibly expect everyone to be ok with having invisiprims suddenly broken without time to update to the "new and approved" method.

In short, you break it, you buy it.

ps:if anyone wanna know the exact trick involved, it is basicly just the same thing as the so called "cell shading" (which is actually about outlines, and in some cases solid colors, and not technicly true cell shading, but people often don't differentiate cell shading from stuff with outlines), but you make the "color" part be invisiprim, and the outline you make black (or whatever color you want) and make it have just 1 of transparency, under most circunstances that little transparency isn't noticeable, but invisiprims will prevent the rendering of anything with any level of transparency other than zero that is behind it

There's still a need for invisiprims anyway, for hiding one arm only, and for occlusion effects in builds (eg, the wall of invisiprims I use to hide the adfarm south of Coonspiracy Central.

Argent is also correct about the megaprim invisibility bug. We plan on breaking that as soon as possible. We've been warning the community since the bug was first discovered that we plan on doing so and it will simply cease to work soon with no particular warning.

Take a look at the screenshot I just uploaded. It's an animated micro, and its whole body is hidden by the avatar mesh. That means it's impossible to build without the megaprim hack (invisiprims would prevent selecting the visible prims). This isn't the only example of such a thing, just one I had a screenshot of already, and one of my more popular products. I reiterate, SIMULTANEOUS hack broken + mask enabled. It'll be easier on everyone that way. It's a lot easier than trying to update things to use invisiprims, and then having to update again when masks come out. Only needing to update around the megaprim bug means the update is easy too: "Delete this one object, and use this thing instead" is a lot easier than "Ok, y'all wait for a couple of weeks while I update the prim work to not have invisiprims on it."

The invisibility bug is VERY useful, VERY different to allowing alpha skins, because it hides the avatar entirely, allowing selection of prims inside it, and the invisibility bug can be turned on and off via script, but skins cannot.

I am completely against removing the megaprim invisibility bug, and even more adversely against the idea of removing it before there is an ability to add alpha to the base skin.

Edited to add, in response to Alyx: I would imagine that alpha masking would also allow the selection of prims inside the mesh, because of how ray trace picking or whatever it is. That tends to ignore anything that isn't visible, including fully alpha prims. All in all, I do agree with Papi that it's a bug and may as well be patched. Just not before we can hide the mesh some other way.

Granted . . . well, I'll let someone else state my thoughts about megaprims and security exploits

@ Drake: LL has said they're not doing anything about megaprims, because of their beneficial uses and lack of bugs, thanks to H4. Though I never had trouble with them in H1 either.

EDIT: Also, this JIRA is the only place I've seen anything from LL about the megaprim hider. Too little too late when it comes to content creation. I only heard very recently that LL had a problem with it, from only one of my many content creator friends.

Also, megaprims were causing alot of crashes in the H1 running Furnation sims. Things have stablized in H4, thankfully, but still it does lag down.

Megaprims were banned in Furnation as a result.

I see nothing suspect about BigPapi's explanations or his stance on the issue. To me, it's very cut and dry. Does Linden Labs want to deal with as little grief as possible now, or more later on after this bug has become more widespread and in use? Less grief is better. The longer you let something like this sit around, the more people are going to assume that it's safe for use. But it's not safe. It's a B U G, it's an UNsupported NONfeature, and it's risky and foolish to try to CAPITALIZE off of this BUG knowing full well that you can give your customers no guarantee that the product will still be working tomorrow. (Yeah, I know, like you can guarantee anything. But you can even less so in this case. =P)

Who's selling a product that relies on a bug, Maya? This is your fault, and any frustration and angst should be directed towards yourself, not BigPapi or Linden Labs. Own up to your own mistake.

—

On the other hand, I think it's a fun and useful bug, and I wouldn't mind it if they just left it alone.. Sort of like they did with Invisiprims.. and WarpPos().. and.. Megaprims, and who knows what else. I just wouldn't sell anything that uses it.

Why should they fix it? I don't know. Maybe there is some critical reason for doing so. But maybe because it's just totally unintuitive and WEIRD that it should be fixed, too. I like the tools that we have in SL to make sense. This one doesn't make any sense. The other bugs I mentioned at least don't leave you scratching your head over them.

P.S. The penny snatchers are adorable.

BigPapi hasn't given any reason at all for fixing it and leaving no other method of hiding the avatar in the meantime bewteen 1.23 (bug fix) and 1.24 (alpha masking).

On the upset people front, which is worse: Five or six people that don't know about alpha masking having to use the new system tool when it's available and the bug stops working at the same time, or a hundred people that have no means of hiding their avatar for several months? Sure LL will get annoyed IMs from people one way or the other, but it'll be a heck of a lot more if they fix the bug without allowing some other means of hiding the avatar mesh.

Who's selling stuff that relies on a bug? Most animal avatar makers.

And like I said, no real communication from LL was made regarding this bug. I still wouldn't know it was going to be removed if I wasn't friends with a bunch of other creators. And like I said, only ONE of them knew and told me.

edit:though if you or who told you about the bug discovered it by themselves, the blame is on you relying on a fresh bug instead of waiting till it existed for time enough and was used enough to have LL be forced to support it, like megas and the invisiprim trick, it is a gamble, you might profit with products that got a feature not avaiable thru normal means, but there is the risk the bug will be fixed and you wil have upset customers and unsold broken products

Besides, SL is pretty much one big bug anyway.

Also, in response to Uchi's PS: Thanks, that means a lot coming from you. :3 Obviously my creations that use this bug aren't going anywhere, and the customers have been informed of 1.2fail. I also never started updating my older avatars that need a hidden avatar mesh, because I did know that alpha masking was coming soon. What I didn't know was that LL knew about the megaprim bug and were planning to kill it before alpha masking became an option.

If they commit the surprisingly foolish mistake of nixing the bug before the alpha mask feature, all that will really mean is more people not using 1.23 and sticking with 1.22. I'm just trying to save myself and other creators some time and effort, and the Lindens some angry IMs from customers. If they want people yelling at them, that's their problem. /me shrugs.

QFT. By not providing a non-hack solution in 1.23, they'll be breaking content and as a result, forced to support the bug by public outcry. If they just put the fix in 1.24, or alpha masks in 1.23, that won't be a problem.

The fact that despite this, people are relying on this bug and having an issue with our disabling it shows that the bug has been kept around for too long. We are disabling it before additional content is created using it. The harm in leaving it around is even more content will be created that relies on it. We are being very careful not to leave it around to the point where we have to support it eventually.

Use invisiprims for now, and then alpha masks once they are released.

All that aside, since invisiprims can't be used on some of the smaller avatars, people that want to use them will need to be able to keep using 1.22 until 1.24. I assume 1.23 will not be a forced upgrade?

@Nyx That still doesn't explain why it has to be nuked before alpha masking is available. Is there a technical reason? I also reiterate that there really wasn't much warning about the removal.

He explained why, removing it sooner rather then later has a social reason not a technical one. The longer it is kept, the more content will be made with it. Which will result in more breaking of content.

Alpha masking will not magically fix that content, it will just mean that it might be fixed.

So content will break, I rather have them break some now, then more later.

Still no answer to my question. Will 1.23 be a mandatory update?

It is better for SL to not have to keep bugs alive indefinitely, and by waiting longer LL might be persuade/forced once more, like before.

-Nyx

@Nyx: Still waiting for an answer to my question!

If so, I'd much rather see it available both on the base skin, AND as a component of existing clothing layers, or its own layer. Applications of this would include the ability to sell avatar attachments or parts that have a suitable alpha mask, without interfering with existing alpha work on that avatar. What if someone wants to have a hole in their chest, a peg leg, and a robotic arm, all purchased from different creators?

How exactly will this work, or will such an avatar simply not be possible without individual custom work?

like lets say, if the alpha makes the avatar look torso-less, would a shirt only have sleeves or it would cover the invisible torso?

I think it would be interesting to have the two alternative be two non-exclusive options, if someone wants they can have a body hole, and another hole that applies to the clothes as well even if they partially overlap (if they overlap completly and exactly, there is no point in having the body alpha as just the alpha over the body and clothes would already do the job, but it would be possible anyway)

If you wanted to look like an invisible person wearing visible clothes, you'd need to make your avatar mask accordingly. If you need to put a hole in only the clothing, not the layers below - clothing already supports transparency.

I'm only asking these questions because I'm hoping things will be done right the first time, rather than having irreversable bad ideas like the way the current skin/texture system is done (only one arm).. now would be the perfect time to add multiple masks, possibly only affecting certain body parts (so someone could have alpha on their left or right arm, for example) the same way clothes can be set to only affect a certain part of the skin, even though the texture may be enough to cover the whole avatar.

That was just the skin, nothing else. Also, I hadn't resized the hands/legs yet so those weren't attached. It was only happening to one copy of the skin. I have four copies in my Avatars folder, adult female, adult male, cub female, and cub male. Only the cub female was showing this behavior.

All images, even skins, are converted to JPEG2000 format and stored on the server. That format does support alpha, but since you uploaded them as JPG there should be no alpha layer in them. That's why I found it so interesting.

I just checked again and now the skin looks normal. Anyway, I thought it was an interesting effect

Avatar masks seem like a great way to add effects to the avatar mesh on a per-pixel bases. It's already been stated that we can use more than one avatar mask at a time, so how possible would it be to allow more effects than just transparency when making an avatar mask? For example, an avatar mask that adds glow to the mesh in the locations detailed by the mask, rather than making it transparent? Or another choice for shiny? These things have been requested on the mesh for some time (glow or shiny meshes), and an avatar mask seems like a logical way that they could be added.

Let's go guys, chop chop.

Please do try to keep the two-sided rendering of avatar polygons with this feature. There are many creative uses in which someone would want to people to be able to see "up your leg" as you put it and it would be much easier to use the existing avatar geometry than try to match an inverted sculpt or cylinder to the hole.

I eagerly await the release of this feature. I have so many ideas that could only be done with this capability. Please do take the time to do it right. Just know that I am very grateful that this new feature is moving forward.

A good example of this would be in-world anatomy classes, where the "inside" of the avatar mesh would serve as a container for veins, muscles, skeletal structure, etc.

Edit:

However, there should be a way to prevent it from rendering as well, since there are also many instances where it would not be desireable to have it showing.If this could be made optional, I would be all for keeping it. If it can't be made optional, unfortunately I think the uses without it would outnumber the uses of having it.

And yes, a ctrl+r rebake kills it, appearance changes kill it, and changing clothes kills it.

Tho I wonder why. If that option would be 'officially' supported with those cases respected, it would be an easy, new and awesome feature til alpha layers for skins are implemented.

And yes, a ctrl+r rebake kills it, appearance changes kill it, and changing clothes kills it.

Tho I wonder why.

Just guessing here, but I could imagine that this menu entry just uploads a set of baked textures which is marked as fully transparent on the new alpha mask layer, but doesn't remember that fact client-side. So everything that will trigger new baked textures to be uploaded will reverse the effect.

It isn't a very good way to do anyway. When I was able to test it, after a bit you go back to opaque again.

Bon, there's no need to upgrade this to showstopper. Nyx has been VERY transparent on the progress of this project. Perhaps you should consider visiting Nyx's office hours and asking him yourself. He's even given demos of this new functionality, and has told us about the progress on bug working.

This is being included with several other improvements to how textures on the avatar are handled, and it all requires a new interface be put in for handling clothing layers, so Nyx has a lot of work on his plate, and he can't just "shove this out there." It already has his full attention in development, and he wants it as much as we do.

Furthermore, they never gave us any promise of telling us when it would be out. Nyx has given us as close a guesstimate as he can. Whether or not they should have patched out the invisi-megs or not is a different matter, but I wouldn't say that not giving us a date is "uncalled for."

Again, I suggest visiting Nyx's office hours and asking him about it. It's been discussed there plenty of times in the recent past and Nyx has been more than happy to provide details of the progress.

@Ezian: Good for you, but most people need to be able to hide parts of their mesh.

@Sebastean: Nyx may have talked about it in meetings, but not all of us can get to those meetings. There's only one a week, and I, for one, am usually sleeping when it happens. If Nyx is so forthcoming with info, why hasn't he posted here in so long? Not that the JIRA is a good way to communicate with the content creators, but it's a heck of a lot more far reaching than a short little office hour that only a handful of people can attend.

Like I said somewhere else in this thread, to me it is a showstopper to not have a good way to hide the avatar mesh. In other words, I don't use any viewer based on 1.23, unless it's been patched. I've heard from a number of people that they're doing the same thing. So technically, it's not a showstopper, no. It is, however, extremely important to get it done, and fast.

Maya, you can login into SL, run successfully SL even without hiding parts of your mesh. So it's by definition no showstopper. It's just a new feature that would be higly appreciated. ( A showstopper is more if you crash all the time, or see only triangles, or permission system is bugged, these kind of things that seriously disturb the experience of thousands. The missing implementation of a new feature is no showstopper)

Besides that I would be the first who would hide parts of my flesh by this new implementation. But SL is working even without that

however we need o wait until all other viewers out there have caught up and for people using older viewers to upgrade before it becomes somthing you can use.

I have seen people testing the feture and it works fine, if and ONLY IF you are using the new viewer. If you using 1.22 viewer or one based on the 1.22 (or earlier) code then it will not show them as invisible. Which is why they need a long lead time before people start using this as it will look wrong on some older viewers.

But I can't find it in the newest version either.

How do LL decide when enough people have updated, when there is so many people registered but not active in SL.

1.23 has the ability to properly render alpha-masked avatars
it does not have the ability to create nor use alpha-mask wearables required to make full use of this feature.

We're working on getting the UI finished for our next major release - the feature itself is working on internal builds - I have demonstrated the effect at office hours a couple of times.

The feature is not in 1.23 but disabled, there is just an incomplete implementation in 1.23 for backwards compatibility once we release the full version.

This is what we're working on, if curious: http://nathanielstern.com/giventime/ (and the avatars, obviously, will be translucent in addition to hand-drawn with pastels and charcoal)

[...] and the avatars, obviously, will be translucent in [...]

I don't know what exactly you mean by "translucent" but note that, if I'm not completely mistaken, this feature will only allow full transparency and full opacity for every given texel (i.e. no semi-transparency, except when emulated by dithering, which often looks ugly).