Quarrel Kukulcan

The left half of this picture is what I get if I create a new Alpha Mask with full system blanks for Head, Eye and Hair. The right half is what I get if, for the Head, I instead supply a custom alpha mask image with all pixels 0% alpha except the lowest reaches of the neck. Most importantly, the part of the head UV where the eyelashes live (the upper right corner of the head UV) is masked out. I've tried both PNG and TGA export for the mask image, and both white and black RGB values for the transparent pixels (which shouldn't matter for this). The translucent yellow sphere is attached to the Skull point and is actually about a foot behind my actual head here. Is there any way to stop the eyelashes from alpha-ghosting with a custom mask?

1. When ramping up the environment shininess instead of the specular, SL seems to mostly reflect a static picture of the skybox, correct? In experimenting I see very little (but not zero!) influence from nearby local lights and no reflection of non-light objects. I also don't see any color influence from the specular map image, though I do see influence from the global specular tint field. Is that all to be expected? 2. Is the minimum optimal texture size 1x1 or is it something larger? Are there overhead costs and such that make, say, a 4x4 actually take up the same or a larger amount of memory than a 16x16 or 32x32? And is there a small size at which SL stops using lossy compression?

I haven't needed to give my physics mesh or lower LODs specific file names. Could those names just make them auto-fill into the appropriate upload panel fields, maybe?

It looks like you modeled your clothing around a posed armature. (Notice how the arms are swung down twice as far as normal.) You need your clothes's starting position to match the skeleton's starting position, which is the neutral T pose. Make sure you're either displaying your skeleton's rest position or clearing all your pose transformations.

Yeah, I see jewelry quickly shrinks to near-invisible. I'm down to LI 4.04 and $15 upload cost if I make the links in the Med. LOD simple, solid boxes and set the Low and Lowest to a flat strip. I already had a trivial shape for the unnecessary physics mesh. Thanks for the pointers. I hadn't realized the lower LODs affected the cost so much.

It sounds like you're talking about making a columnar tube here. I'm talking about individual links. Here's one of them.

Sculpting individual links seems to run anywhere from annoyingly to prohibitively expensive. Even a "low-poly" trial mesh I made where each link is a hexagon with triangular cross-section (so 6x3x2 = 36 triangles), untextured, generates an upload with a LI over 19 and an upload cost over $75L. I've found cylindrical cords to be lower (and the LODs are more straightforward) and great for a lot of things, but you can't do a linked look. I tried a track of flat panels as well, with an alpha-blended chain texture painted on. That was the lowest complexity-wise, and you can use a tiny texture that's identical on every quad, but looks bad from viewing angles that catch it edge-on, plus it's extra-conspicuous when it doesn't track exactly against the body.

It's not a linkset. I'm talking about designing mesh objects to not cause jellydolling.

So if I want to abuse the system and maximize the number of other users who render me, use no alpha blending (or isolate all alpha panels and eyelashes and such into their own separate texture-optimized objects).

What is a rigged mesh object with a complexity of 20k when it's all visible but 75k when the hair is off? Good? Bad? Something in between? Is the "real" complexity closer to the low end in both cases? The high end? It seems like the complexity calculation is weighting based on the vertex count of the entire object instead of just the count of alpha-blended triangles.

More verts. But never mind. PROBLEM IDENTIFIED! It was alpha blending. If any face is set to Alpha Blending mode or given a Transparency other than 0%, complexity shoots up. If they're all set to Emission, Cutoff, or None, it drops to what I'm used to seeing.

I made a mesh avatar. I used it for weeks. It had a render complexity under 20,000. Recently, I replaced just the hands with a higher-quality mesh taken from one of the many Bento reference models out there (I don't remember which). (The armature didn't change, just the hand mesh.) I uploaded it, put in all the same textures and scripts as the last version had, and wore it for a day. Then I noticed my avatar complexity was over 75,000. I switched to a slightly older version of the new one that I still had lying around (it had a minor error I hadn't noticed on the test server). Its complexity was about 20,000. I put all the textures and scripts into it and noticed it stayed around 20,000. Eventually I quit. Next time I logged in, it had also changed to over 75,000. I've confirmed I'm using the same 1024x512 diffuse texture and 512x256 normal texture. I've also tried wearing (copies!) of the original version and it's staying stable at the old complexity. They all have custom LODs and a cube physics mesh, created with the same software. I did recently start playing with Firestorm for the first time ever but all uploads were done with LL's viewer. Does anyone have an idea what might be going on? EDIT: Problem found! See replies.

To bring this back to the OP's problem: it looks like SAI is the culprit. It doesn't preserve color data for fully transparent pixels in either PNG or TGA. (That's not unheard-of. It also seems to degrade color data for very-close-to-transparent pixels but preserve everything else, which is very weird and probably a bug.) I know GIMP offers the option of preserving fully transparent colors with every export, and it sounds like Photoshop offers a plugin to do that. I'm not familiar with any other editing software.

Premultiplying is a math-saving step for storing images with partial transparency that are meant to be displayed on top of others. Here's an easy example. Say you have a pure orange pixel that's almost clear -- let's say, only 10% opaque. That pixel's original, unmultiplied RGB values are 255,128,0. But if you want to draw it on top of another pixel you'll only need 10% of those numbers since it's only 10% visible. So one thing you can do when you write that image file is to save that pixel's RGB values as 25,12,0 in the first place. Now your rendering program has less math to work out, and it'll run faster. (Plus other, more esoteric benefits.) Whether your exporter pre-multiplies depends on your image editor. Whether you WANT to pre-multiply depends on the program that'll be using the image, and how. If you're using the alpha channel as an emission mask, you do NOT want to pre-multiply. Oh, and the "over" operation is the basic "drawing an (alpha-having) image over another" task. https://en.wikipedia.org/wiki/Alpha_compositing I wouldn't be surprised. I just installed SAI and tried progressively erasing a pure color area until it was gone. (Orange, by the way... 255,128,0.) The red value stayed at 255 all the way up to the end but the green wobbled unpredictably between 128 and 127, then dropped into the 20s and 30s when I got below 10% or so and hit 0 at 1%. Then it went pure black at 0% (which is the OP's original problem).

That varies from program to program. Some programs, when you save to 32-bit w/alpha, will change all your 0% alpha pixels to black. They do this because A) large areas of solid color compress to a smaller file size, and B) the program assumes the alpha channel always means opacity and figures you don't need to save the color of completely transparent pixels since no one will see them. (Obviously, this messes things up if the alpha channel means something unusual like emission level.) Other programs might always retain transparent pixel colors. Some programs (like GIMP) let you do either. Unfortunately I'm not familiar with SAI in particular, but I can give you two general pointers: 1. Don't mask off non-glowing areas with pure 0 alpha. Use something very low but still positive, like 1 or 2 or 5. This should trick your program into retaining all image data without making those areas glow bright enough to notice. 2. If your masked-off areas are black when Emission Masking is on in SL but they show details & color when you're at Alpha: None, then your problem isn't blanked textures. If you really lost texture areas, they'd be black under all settings.

I mean the "emission mask of 0 makes colors darker" problem that we're trying to solve.

...or the OP's problem may be a bug related to the Environment Enhancement Project that was supposed to be fixed in early February but wasn't. https://jira.secondlife.com/browse/BUG-228172 That said, I can't reproduce it with the texture in the bug report ("a8c3bdcc-6a98-0947-457f-4cee2520020f"), so...

1. If your diffuse texture has an alpha channel at all, it will affect glow intensity, yes. This is true regardless of whether you set the face's alpha mode to None, Alpha Blending, Alpha Masking, or Emissive Mask. 2. I just tried Full Bright with glow and SL still only put the Glow effect on the high-alpha parts (plus made the underlying texture bright everywhere). I don't know if this is a Firestorm vs. LL viewer thing, or a Test Server vs. Live thing, or what, but I don't get your result. 3. Emissive masks require Advanced Lighting to be on. Full Bright and Glow always work.

Ahhh. I think what you're seeing is interference from your bump & shiny settings. Those can interact poorly. (In general, the shinier an object is, the darker it will be overall, and I've just discovered that if I use a system-standard bump pattern but a custom shininess texture, my whole object turns solid black. Just, black. All of it. The textures doesn't matter.) Where is that fur pattern coming from? It's not in your texture. Are you using any kind of shininess? (Mathematically it's impossible for the emission mask to darken anything, since 0% means "display it normally" and anything higher makes it brighter. That fact plus the quirkiness of SL's advanced lighting combinations makes me suspect it's not the emission mask itself causing your issues.)

PNGs can absolutely have an alpha channel. My copy of Photoshop CS4 from 2008 can make alpha PNGs just fine. Glow and emission masks enhance each other, yes, and if there is an alpha channel in your texture it will affect the glow brightness (regardless of how you use that channel, too, at least in Linden Lab's viewer). That's nice because it lets you limit the glow to certain areas instead of putting a nimbus around the whole object. You don't need to turn glow on to make emissive areas look brighter than normal in dark areas, though. Plus SL's glow feature adds "fuzz" as well as brightness, and you don't always want that. And, technically, neither of these features actually "emit" light in the sense of illuminating nearby objects. You have to flag the prim as a light source, which is yet another setting. Here's a quick experiment I ran. The texture is a solid color with a simple 0%-100% alpha gradient.

My point is only that Blender can do a combined bake. Pick "Combined" as the bake type and check the Diffuse (w/direct & indirect) and the Ambient Occlusion boxes (plus maybe also Glossy if you want highlights too). This produces a single texture with the base diffuse plus shadows (and possibly highlights) combined into it. (AFAICT this is pretty much what anyone who talks about "baking textures" is referring to.) It's faster than making a separate AO image plus exporting plus hand-merging. Of course, if you want an AO image (like so people can make better custom textures for your shirt), obviously make one. Or if you can't figure out how to do full texture bakes (because they're fussier to set up than isolated AO generation is), just do what works.

Exactly. That's my point. "and then bake a diffuse map" means "have Blender combine everything instead of exporting things separately and merging them with Photoshop". It's another option -- one that shouldn't be too tricky because figuring out how to make Blender create shadow and/or bright spot maps in the first place is the hard part (and is required by both methods!) Once you've got that down, you're 90% done.

How do you get Blender to produce that AO map in the first place? I know you need to set up nodes to create a normal map.

Probably and yes. It was well over a month ago and I don't really remember. I do know it was across multiple versions of Blender in the 2.7 and 2.8 version lines, including experimenting with the BVH export Python file to see how its code changes over the years might affect things.

I was under the impression that Blender can bake in crevice shadows itself, and that you don't need to go through the extra steps of A) produce an image of just the shadows, B) save that image separately, and C) use an entire separate program to merge the shadow texture onto the base diffuse texture for every object you create -- just the ones you intend to be easily retextured by other creators (or even by yourself).