Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skins Moves/Merges #30

Open
Outworldz opened this issue Nov 13, 2019 · 7 comments
Open

Skins Moves/Merges #30

Outworldz opened this issue Nov 13, 2019 · 7 comments

Comments

@Outworldz
Copy link
Contributor

Outworldz commented Nov 13, 2019

The Ruth/Roth repository has a lot of skins in it. Yet we created the separate Skin repo to hold them. In addition, there are many textures that can be saved out of the PSD files to make it easy for people to use them.

It might be extremely useful to save just layers in a separate folder for each skin, such as blush or eyebrows. These would be separate PNG with alpha so that they can be used in Bakes on Mesh, if I understand they way it works correctly. This would also work with heads with more than one layer, assuming the base is a JPG with no alpha.

Amy Storm has offered to de-dup and reorganize the skins, and extracting alphas, if you feel that is useful and the right direction to go. What do you think?

@aiaustin
Copy link
Member

aiaustin commented Nov 13, 2019

I am happy with the idea that all skin related textures and information are moved to the Skins repository perhaps leaving clear instructions in a text file for those actually used in Ruth and Roth RCs and Releases?

I have also been thinking we need to consider more "build up" layers for skins, hair, tattoos, makeup elements and alpha hiding elements and think that would be much more useful than the various prebuilt things.

I have not quite understood/worked out what is happening with alpha blending and alpha masking. PNG and TGA to allow for transparency seems to behave differently when uploaded. And I definitely don't understand what happens if you upload a JPG. Can we clarify that before much work is done?

As far as I can tell the "base" skin for BoM flexibility needs to be "alpha blending". Otherwise you cannot add any alpha layer (tattoo) to it to hide parts. The BoM versions of RuthToo and RothToo from Sean Heavy I think are set that way.

The problem then seem to be that if any clothing added is also alpha blending you can get transparency underneath those parts, making the body skin layer invisible for those parts. If the clothing allows modify then altering it to alpha masking seems to do the trick but of course not all clothing is modify... especially in SL.

@Outworldz
Copy link
Contributor Author

I have no idea how Bakes on Mesh works or is set up. I would love to hear more. Here is what I know about alpha, as normally used.. We use three unsigned bytes for the colors ( 24 bits) and one byte for alpha. It takes a 32 bit image to save an alpha. . In decimal, each byte is 0-255. 255 means fully opaque, 0 means fully transparent, and anything in between will use blending to make it look semi-transparent. However, this can be overridden in the viewer to be either a blend as just described, or you can change the texture to alpha Cutoff or Emission. Alpha Cutoff use a cutoff value where it is 100% alpha or not, based on the cutoff value. This is glitchless. The third property is Emission - which can make a spot on a texture glow.

If you use blend for all layers, the famous Z glitch can and will appear. The system cannot tell which alpha is in front or behind the other, and they will swap around, sometimes leaving you naked. For some other uses, such as trees, this looks awful. So I almost always edit my trees and set them to Alpha Cutoff, and fiddle with the cutoff value to make them look good again.

In the case of 'normal' multi-layer mesh heads, I would normally save the base skin a JPG and upload that for the base layer, as there is no Alpha channel to cause glitches in it. A slightly better choice is a 24 bit PNG, as it is lossless. The other mesh layers with transparency would appear glitchless on top of a JPG base skin.

@aiaustin
Copy link
Member

aiaustin commented Nov 13, 2019

Bakes on Mesh is great :-)

So if you upload a JPG it is treated as a 24 bit RGB image with no alpha?

A 24 bit saved PNG likewise will have no transparency?

A "normal" PNG will be 32 bit and have RGB and transparency between 0 and 255.

A TGA will also have 24 bit RGB and transparency between 0 and 255? What is it that people comment on with differences between PNG and TGA then? Are they comparing 24 bit PNG to TGA?

A BoM mesh body and parts I assume then needs to be set to alpha blending to make all the layers work? But any overlaid mesh attachment clothing also set to alpha blending, as a lot seems to be, will still cause issues?

@Outworldz
Copy link
Contributor Author

24 bit PNG has no transparency. JPG does not support transparency. A JPEG2000 'may' have transparency. All textures are internally converted to JPEG2000, so they may be with or without alpha, depending on the source. JPG is simply my lazy way to make them alpha-less.

If you save a Head skin as JPG, the eyelashes will be 100% black or white. The eyelashes are a tiny alpha patch in the upper right of the head texture. This is why you sometimes do not see eyelashes on mesh heads. They share the same map in standard SL avatars, which means blurry eyelashes. I have hoarded away a set of CC-0 eyelash textures at https://www.outworldz.com/cgi/free-seamless-textures.plx?c=EyeLash%20EyeBrow

@AdaRadius
Copy link
Member

AdaRadius commented Nov 14, 2019

What Fred said.
Other random thoughts:
Yay Amy! Yes! Especially as the separated layers will be usable in any graphics software. Not everyone can afford a PhotoShop subscription. [Yes, I was hoarding my old copies of PS, until the security issue earlier this year, when a copy of, I think, PS CS5 contaminated my daughter’s Mac, with all her business data, so badly she had to get it wiped and restored at the so-called genius store].

Jpg loses a little resolution every time it's saved. TGA is a pain, the alpha channel often borks and needs cleaning up, and it doesn't display in MS operating system folders. So I'm in favor of 24 bit png which imports without an alpha channel, and 32 bit png, which does. We don't want unnecessary alpha channels inworld, so this takes a little attention to make sure one has got the right one exporting out of whatever graphics software one is using in that moment. A mistake I make too often, and grateful for free texture uploads in OS so I can do it again.

The eyelash design in the legacy head texture is so awful, I'm in favor of always hiding it and using an attachment instead. Fred's collection of eyelashes and eyebrows is pretty much all anyone needs, as anything more complex does not translate well inworld, at least for the kinds’s of faces most people seem to want.

I have folders of skin layers somewhere - lips, eyebrows, nipples, makeups, etc., but I think they're mostly old, tga formats and probably the same stuff as is in the Eloh Eliot files anyway. After I get Roth in better shape in Blender 2.8 or maybe 2.81, which is a saga of its own, I'll go through my stash and see if there's anything useful in there.

@aiaustin
Copy link
Member

We also need to be selective over the dimensions of the images.. going for the resolution required but no more.

I have seen silly use of the base skin at 512x512 yet hair, beard and other overlays at 1024x1024.

Skins at 1024x1024 can look much nicer and will work with the extended server side bakes available now in Second Life. Current OpenSim 0.9.1.1 has been extended to support Bakes on Mesh but is limited to 512x512 and dine using the viewer side sharing mechanism at present.

@RuthAndRoth RuthAndRoth deleted a comment from AdaRadius Nov 14, 2019
@AdaRadius
Copy link
Member

Thank you @aiaustin for cleaning up my post

I don't think it's always silly to use 512x512 for the base skin, which should not may not need sharp detail, and use 1024x1024 for hair, which does. For machinimas, for example, shot by someone with a great graphics card and connection.

Too many 1024's in a scene and viewers with small laptops or rural connections are going to crash. So we should maybe provide both sizes? And some 256x256 as well for smaller bits.

It depends on what's going to happen at that location, in that sim. How many avatars, what scenery, how well the elements are arranged, what we can and can't control (such as what visiting avatars are wearing).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants