Quarrel Kukulcan

A jump start of years of experience dabbling half-butted in Blender before returning to SL after a decade-long haitus and discovering it had mesh uploads now. Lots of forum scanning. Experimentation. (Make an beta grid account! Learn to use local textures!)

LL's own avatar source is in various formats at https://wiki.secondlife.com/wiki/Project_Bento_Resources_and_Information The mesh looks like it has UVs. The armature there only contains Bento bones, not Fitted Mesh bones. If you need those, they're available for Blender at https://www.avalab.org/avatar-workbench/ on the Fitted Mesh Kit page (but that armature doesn't have Bento bones). There's also UV map images at https://www.robinwood.com/Catalog/Technical/SL-Tuts/SLPages/AVUVTemplates.html.

Since you're using Firestorm, try the "Cube" preset for the physics shape instead of "Lowest". Every object in SL requires a physics shape. It's mandatory. But for rigged mesh, it's ignored, so the safest, fastest and easiest thing to use is a simple shape, even if it doesn't match the mesh. "Lowest" (which the video shows) uses the lowest version Level of Detail of your mesh object as the physics shape. Between the shapes that Bento Buddy autogenerated for you and the way SL simplified them when it autogenerated the Medium, Low, and Lowest-detail versions, something about the final result was unsuitable for SL's physics engine.

Cube or Lowest. It greatly depends on what you're making. For a dresser or a small shrub, cube is fine. If it's large enough to have hollow spots you want people to be able to move through -- like, say, a tree with branches you want people to be able to walk under but a solid trunk -- try Lowest first. Things like chairs or vehicles, where you want residents sitting on specific spots, might not work right unless you use Low or Medium, but that's also the point where you should be making your own collision shape. Rooms or houses with doorways and windows definitely require learning how SL uses physics in detail.

It might solve the problem, but the Medium LOD is basically guaranteed to be far more complex than a physics shape needs to be, so you're making the server work extra-hard. Most small, solid objects don't need anything fancier than a cube.

Are you trying to make just the inside? Solidifying will give you both together for one export. At least, it should, with the correct normals. You may need to apply the modifier manually, and keep in mind a lot of modifiers work funny if you have unapplied scaling on the object. If it still doesn't work, you can make an inner shell manually: Go into Edit Mode. Select all. Duplicate (Shift-D). Scale along normals (Alt-S). Move the mouse a little to put the inner shell where you want it, then left-click. Flip the normals. (You should still have just the inner shell selected, which is what you want to flip.)

It's because the SL rendering engine only renders the front sides of triangles. (Some renderers only do the fronts, some always render both front and back, and some can do it either way. It depends on the programming.)

It's called the Beta Grid, Preview Grid, or "Aditi". It is invaluable for uploading mesh for testing physics & materials without spending real Lindens. You will probably have to file a support ticket to enable access and wait a few days, but trust me, it's worth it. https://wiki.secondlife.com/wiki/Preview_Grid

There's no modifier to eliminate them, but there is a built-in plugin that can help find them. Go into Preferences->Add-ons, search for "3D-Print Toolbox" and enable it. You'll get a new tab that you can use to analyze a mesh for geometry errors that'll mess with 3D printing -- most of which will also mess with SL physics. Go into Edit Mode on your mesh and click "Check All" in the 3D-Print tab. Pretty much every error except Sharp Edge and Overhang Face could impact SL physics. If you have any, you can click on the error name to select all the parts of your mesh causing it.

Judging from how SL didn't triangulate two faces that look like quads, you have some geometry that looks connected but really isn't. Like here. The thing that looks like a quad on the right really isn't. The lime-colored edge does NOT stop at the vertex in the middle. It's a separate edge that goes directly from end to end. That messes up your surface -- the triangle on the right doesn't share any edges with the two triangles on the left, and there's a zero-width gap between them.

Then I'm out of ideas. I tried making a cel outline with the solidify modifier like in the tutorial and it kept all the weights intact. I don't know why you can export the original head but not your modified one.

If you made the cel with the Solidify modifier, then I don't think you rescaled anything and applying scale won't be the issue. The issue is that the dev kit you used was probably created for Avastar (I know some of Utilizator's meshes are), and that means it won't work right with plain Blender. Can you tell whether any of the original mesh vertices are weighted to the bone named "HEAD", or do they use the bone "mHead"?

Being its own separate object is fine. What is the "original head" and where did it come from? Have you applied location/rotation/scale to it? Are you weighting to the "HEAD" or "NECK" bones? Those are Fitted Mesh bones, which deform your mesh unless you use a SL-friendly add-on or add custom properties to your bones. (Just two bones are easy enough to do by hand if you need to, and I can walk you through it if that's the case.)

Looping it is necessary but that isn't enough. You need to assign it a higher priority than the system idle animations (which isn't hard, they're all in the 0-2 range except for a couple manual gestures). You'll need a keyframe for every basic bone even if your animation doesn't change them, so SL knows you specifically want them at that angle. Also, with BVH files, the first frame is used as a reference frame and isn't played. Instead, SL cross-checks the first frame with the second and ignores every bone for the whole import that's at the same position and angle in both. If you're using a SL-friendly addon, it might have an option for adding a reference frame, but if not, you'll have to make it yourself. Figure out every bone you want your pose to affect, then add an extra frame to the beginning where it's bent differently. It doesn't even have to look good, just be different.

Is it a single dance that locks you to a preset position and that you have to stand up to stop? (There are some dance and poseballs that work that way.) If that's the case, then you are sitting. You'll need to control your tail manually or find a different way of dancing. AOs typically can't tell the difference between sitting on an invisible ball that plays a dance animation on you and sitting on a prim that lets the default sit animation play.

There are two possible issues, both UV-related. First, SL's renderer is always blending texture pixels. (It looks better in general -- it avoids pixelization close up and interference patterns at a distance.) You never get "one texture pixel = one pixel on the screen". Every rendering pixel put on the monitor of the resident looking at your mesh is created from a blend texture pixels around that mathematical pinpoint. But it can't blend between two different textures. It can't blend the top pixel of one image with the bottom pixel of another, for example, so that break will be visually distinct. You might need to do a little bit of manual blending yourself. Second, SL treats all textures as wraparound. If you run your UV mappings all the way to the edge of the texture, you'll pick up a little bit of bleed from the pixels at the other side at the edges of each panel. This is an issue with any material, not just merging panels like you're doing, but it's another factor that makes edges more visible. The solution here is to never go all the way to 0.0 or 1.0 for your U or V coordinates. Even a fraction of a percent makes a difference.

Second Life does not support scale changes in animations AFAIK. It does support translations, but you have to leave the export option "Root Translation Only" unset. Also, if you're doing a straight BVH export from plain Blender and not using an add-on, you need to enter a scale of 39.4 -- at least, if you're using the default scale of "1 Blender length unit = 1 meter". Second Life's BVH importer treats all distances as inches.

...I completely misread that that was their actual question. My bad. I thought they were asking how the PBR AO channel results in any different rendering look than burning it into the diffuse texture yourself.

Not to be overly pendantic, but just to allay some confusion... SSAO is yet another, third type of AO and has nothing to do with textures, PBR or Yseult's question. It's real, and neat, but it's its own thing.

Deciding what collision physics it'll need, which will determine how you make your physics mesh and what settings to use during import.

I might have pasted the wrong link. It wasn't a sign. I'll go back and fix it.

There's also this LOD example from Wulfie Reanimator. https://community.secondlife.com/forums/topic/454514-tutorials-that-have-links-that-still-work/#comment-2114943

LI for custom mesh (rigged or not) is based on a weighted average of your LODs, with the one that SL thinks it'll use most often having the most impact. For an avatar-sized object, that's High and Medium. Also, for rigged mesh worn on an avatar, the swap distances are much farther than normal. The rule of thumb I use for rigged mesh is to make the Medium LOD about Low-quality, make Low Lowest and make Lowest either the same as Low or actually decimate to triangles because it'll never be displayed except to residents that have set their viewer to unrealistic options. Also, the point of an LOD is to omit details that aren't necessary at a distance. You shouldn't still have shoelaces, antennae or individual fingers at Low. Even Medium doesn't need shoe tongues, and probably not antennae (although removing them completely will alter your bounding box and cause your LOD to shift, so you might want to keep a degenerate triangle there purely to preserve avatar height). The perfection you're going for isn't necessary, and it's what's costing you so much LI. (Your physics is too high too. Just use a cube. All mesh objects need a physics frame, but an object's frame is ignored while attached to an avatar, so go as simple as you can to keep overall bandwidth use down.) Mainly rigging-related issues. Fitted Mesh bones (the ALL_CAPS ones), previewing the effects of SL's shape sliders, and animation exporting are the biggest ones. LODs and UV mapping are still done with Blender basics.

Does this new PBR support come with any changes to the rendering engine or is this simply an alternate arrangement of data channels? i.e. Will you be able to use both emission and translucency on a single face? Will the metallic channel produce the same appearance as it does in PBR renderers or will it just be an alias to SL's environment channel?

It's very strange. I don't see any bones displayed inside the head & arms to explain why the mesh has moved. (FYI, when you display bones in SL, red means a bone you've moved to a custom position, aqua means a bone your mesh uses in its default position and green means a bone you've neither moved nor weighted to. https://community.secondlife.com/knowledgebase/english/enhanced-skeleton-project-bento-r773/ ) Does everything look fine when you rotate bones in Blender's pose mode? Go through every bone you think you're rigging to. Have you applied all scaling/location/rotation to your mesh and your armature? Do you have any modifiers on the mesh other than Armature?