Best Practices for UVs for SL

[Rahkis Andel]

This thread continues where my weight painting thread left off.

I changed my mind about creating clothes -- Instead, I wanted to move forward with my goal of creating avatars by making a male body base as a practical test case.

My goal for this avatar body is for it to be very easy to modify it's textures while still utilizing the most of the 2048^2 texture space.

So far, my approach is to take a cue from the default avatar and split the avatar into an upper and lower body so that I can have double the texture space off the bat. Then, rather than mirroring any of the extremities, I chose instead to hug the center of the UV space, making the UV's symmetrical across the x-axis. This will allow me to texture paint one side, and then just mirror that work to the other side in any image editor, and still preserve my ability to for instance, have a tattoo sleeve be only on one arm. Finally, rather than halve the avatar down the sides as LL did with the default avatar, I chose a different seam setup that I hoped would hide the seams a little bit better.

To make a long story short, UV's really aren't an area of expertise of mine and I'm basically just guessing here. I think I'm on the right track more or less, but I could use some guidance.

I haven't touched the lower body yet, so my next post will probably be of that.

Edit: This is what I came up with for the lower body.

If you are wondering why I didn't cut the pelvis down the sides as in the SL default avatar, I wanted to utilize the x-axis for symmetrical texture painting as I mentioned above. Having one island be smaller than the other allows it to fit in between the legs.

Plus, it sort of looks like briefs! I'm not sure if that's a good thing or not...I'll find out soon enough because I will be painting next.

[Codewarrior Congrejo]

Hey Rahkis,

found the time to scout quick over your Thread.

So far it looks good to me . Just a few things i could give as suggestion:

I would personally prolly rather make the cuts (blue) on top of the shoulder line and vertically under the armpit)
To get UV shapes like the blue example outlines i drawn onto it.
This will result in less texture stretching as compared to being stretched from a condensed topview (so to say) UV over the chest and back. And also easier to logically paint it.

I have drawn into the lower right some orange arrows. Meanwhiles i like the 'spin' of the arm, it might be tricky for texturing as well as i animation. As long as you don't have a certain need for it (armorpart ?) i would prolly relax the whole edgeflow there a bit. But that's up to you =)

And you could relax / spreaten the behind area a bit more or the texture will be a lot stretched there at the end when being applied to the model and especially in poses. (doesn't need to be as much as in my scriddle - but i guess you get the idea)

To separate it into some sort of 'briefs' is absolutely okay and nothing wrong with it

Edit - (updated the pic now*): Ah and what i forgot to paint in* : if the lower part of the last image is supposed to be the 'whole' front of the crotch. you should also give that one more UV space. and possibly think about cutting the brief's side-loops vertically in the middle, so that there is a bit of sides attached on the front UV part as well as on the back UV part of it. (the general texture spread (as in distortions / pixelated) and painting will be easier.

Cheers, Code.

[Rahkis Andel]

Thanks Codewarrior!

When I read your post last night, I was having trouble understanding what you were saying about the upper body, but I get it now. Actually, what you suggested is how I initially had my UVs laid out, but I came up with the idea to separate at the shoulders instead and put a main seam down the back.

I'm going to go back to the layout you drew because I think it's more consistent with how I laid out the lower body -- I was just experimenting, I guess. Thanks!

As for the lower body, I've already made the changes you suggested and did an AO bake overnight at 4086 and downsized it to 2048, which I hear gives an anti-aliasing effect(Citations needed):

This is a before and after, the before being a previous test with a different Layout with totally mirrored legs. I'm mostly illustrating the fact that I had a few ray errors that needed to be fixed by getting rid of some intersecting verts. Obviously, there are some major issues with the quality of the bake here that won't be fixed so easily...So I guess that means I need to learn how the Blender baking really works now.

I've been experimenting with the various settings for the last several hours and I have gotten far smoother results, but not without complications. One method is baking from multires. To do this, you add a multires modifier to your object, add enough subdivisions to get a smooth bake and then set the preview to the lowest multires you want to bake to:

 

The benefit to this method is that it uses far less memory than the standard bake. The multires bake also gave me incredibly smooth results that baked faster, which suggests that I haven't found the right balance of samples in the standard bake yet, (The standard bake should be faster according to what I've read).

A downside is that you can't set the preview multires level to less than 1, which means the resulting bake is meant to be applied to your mesh with a subdiv level of 1...meaning those incredibly smooth results are actually fake and won't line up accurately with the low poly mesh that I'll actually be uploading to Second life.

Another potential downside to this method is that you can't take into account the effect proximity to the ground would have on your mesh. This is why there is no detail towards the center of geometry (no detail in the knees for example) -- it's only receiving a darkening effect from nearby body parts even though I have a ground plane in my scene.

So here is the standard bake using selected to active -- To do this, I duplicated my mesh, named it "high poly" and gave it a subdiv modifier at 5 levels, which is the lowest number that got me perfectly smooth results. I left my low poly mesh without a subdiv modifier at all (and named it "low poly"). I selected the high poly first, then low poly (the order is important)  and made sure "selected to active" was checked. I also have "normalized" checked so as to avoid bringing in material settings into the AO:

So here we are. There are a few immediately obvious things different about this bake. For one, we have a bake that is much more accurate to the actual geometry of our low poly mesh, which doesn't look as smooth, but when applied will still look better and more accurate overall. The second thing I notice is that the margin is terribly messed up. Luckily, I figured out how to fix this. This is a ray error caused by the intersecting points from the upper body, which I forgot to hide from render. I'll make sure that is fixed for my final test.

My final test will illustrate what this type of bake will look like with a mesh floor to add in the additional data from bounced rays. All my settings are exactly the same as above except I have a "ground plane" in my scene with rendering enabled. It isn't actually a plane, though -- I created it by adding a UV sphere that was just big enough to enclose the lower body and cut off the top half of the sphere.

With a floor, we get much more detail than before, which is really nice. Plus, turning off the render visibility of the upper body removed all of the ray errors at the top of the pelvis -- we just  have the faintest of artifacts from the margin, which I have set to 4 to prevent some seam gaps (I notice if you zoom out a lot you start to see more seams the lower the margin is, though I'm not sure if that will be visible in game or not). I think this is the best result yet, and I believe I could fine-tune the darkness a little by moving the body further from the ground plane. Note that the strength of the AO effect is based on proximity. Since a hemisphere will have some points further away to the mesh than others, we would get a different effect with a flat plane (or other objects). From my experience, the difference is extremely subtle, but the shading seems a bit softer to me with the hemisphere, which I like.

If someone wants to see a comparison of the effect different ground planes have, I could do it, but I think this post is long enough as it is.

Hopefully my trial and error work winds up being useful to someone!

Edit: I forgot to mention, I'm using 32 samples for all of the above examples. Anything more gave me unnoticable returns and 16 wasn't high enough to keep away the graininess. You set this in the world settings under Gather. The raytrace samples will be grayed out while it isn't baking but you can still set the samples whenever you like.

Kind of a stupid Blender UI thing, I admit.

[Codewarrior Congrejo]

i see and yeah i think that's the better layout. Also the edits now on the 'briefs' are giving better UV and texture space.

Funny wise the multires bake allways gives me troubles. especially since they just removed now the possibility to bake from level Zero to the highest -.-  with the expression: no one would need that anyways. well i do? lol

But yeah allways getting artifacts with multires bakes. But then again i mostly bake from a heavily sculpted (as in changes on the whole height-depth etc, structures, and so on - and not just plain subdivided by multires allone) very highdetail to a low detail mesh and that is, evidentally , not blender's strong suit. So i mostly take it out into other 3D Suits which have far better renderers, or additional available renderers.

But in your case i agree and think the multires bakes gave the best outcome.

Blender is trying to become better regarding the whole baking methods and results. Which is visible with all the things they added in the baking procedures. I hope one day they keep up with the others in that matter. =)

Keep on going!
Already looking forward to the final model =)

PS: for general shape bakes i usually just do a AO bake. its the fastest way to get bright/dark areas, and with being light / shadow casting independed (which is better for games - since the lightinfluence happens insides the engine).. and later on add specularity maps, so the material itself defines how and where light is broken when it encounters it insides an engine. (specular maps etc is not available yet for SL, but ive seen they work on normals and spec already)

[Rahkis Andel]

I would be excited to hear about improvements to the multires system in Blender. There is so much potential there -- it should be a higher priority, since so much sculpting relies on that working well.

Anyway, I'll be going with the final result and using that as the basis for my diffuse texture. My goal is to do as much of the texture paintng in blender as possible. Gimp will be used only to do minor image editing tasks like creating tilable textures and alpha brushes. I will be using a similar technique to

here to paint the skin color on the model in the 3d viewport. Then I'm going to attempt to create some alpha textures of skin to try and do the same thing.

Based on previous experience, I predict a 95% chance of headaches! But this is all a test to find the best workflow for me, so much fun will be had.

[Nalates Urriah]

If you upload 2048x2048 textures that means you would upload 3 – 12.6mb images for the avatar. Of course the SL system will immediately resize those to 1024x1024 JPEG2000 images. So, there is going to be image quality loss. The SL system will squeeze the size to something under 6mb. Still that is a lot of texture download for something that generally puts so few pixels on screen.

The coming SSA (Server Side Appearance) baking will likely reduce that load even more. I am not sure how good a quality the SSA system is going to produce. I expect it, from personal experience to date, to do a good job. I have not seen where anyone has tested whether initial image size has a significant visible affect on avatar appearance. But, I wouldn’t be surprised to find it does.

Many feel the optimum size for avatar stuff in-world is 128x128 to 512x512 pixels. The smaller the image the better.

Ambient Occlusion is part of the viewer. If you add AO to skins and clothes, a significant number of users will see doubled AO, yours and what the viewer adds.

AFAIK, there is no way to test to see if the viewer has AO enabled. So we can’t have a script select the texture to use.

Plus other features are being added to third party viewers (TPV). Designing for the best render is not a simple decision. See Exodus Viewer and NiranV’s Viewer.

With the arrival of the Materials System we will move more toward high-poly models in Blender that bake normal maps for use with low-poly models we upload into SL.

[Rahkis Andel]

---

Nalates Urriah wrote:

If you upload 2048x2048 textures that means you would upload 3 – 12.6mb images for the avatar. Of course the SL system will immediately resize those to 1024x1024 JPEG2000 images. So, there is going to be image quality loss. The SL system will squeeze the size to something under 6mb. Still that is a lot of texture download for something that generally puts so few pixels on screen.

I am aware of this. Looking back, I am not sure why I said 2048. It could have been a typo or maybe I didn't know at the time that the max for SL was 1024. I think I actually have another UV thread with a slightly more updated representation of what I know.

The coming SSA (Server Side Appearance) baking will likely reduce that load even more. I am not sure how good a quality the SSA system is going to produce. I expect it, from personal experience to date, to do a good job. I have not seen where anyone has tested whether initial image size has a significant visible affect on avatar appearance. But, I wouldn’t be surprised to find it does.

Many feel the optimum size for avatar stuff in-world is 128x128 to 512x512 pixels. The smaller the image the better.

I really don't understand what the new server side baking addresses since I have yet to actually use Second Life for anything but testing my models. From what you say, I'm excited!

Ambient Occlusion is part of the viewer. If you add AO to skins and clothes, a significant number of users will see doubled AO, yours and what the viewer adds.

AFAIK, there is no way to test to see if the viewer has AO enabled. So we can’t have a script select the texture to use.

Plus other features are being added to third party viewers (TPV). Designing for the best render is not a simple decision. See

Exodus Viewer

and

NiranV’s Viewer

.

I am aware that having AO directly in your diffuse texture is bad practice. AO is meant to be applied to ambient lighting, not diffuse lighting and will therefore clash in an obvious way if it is too strong. It is still a nice template for texture painting so long as you tone it down.

My personal stance is that it would make the most sense to leave out pure AO bakes. It doesn't make sense to me to alter the appearance of objects to people with AO enabled for the sake of those who don't. I haven't quite decided on exactly how I will use AO in my SL projects, if at all.

With the arrival of the Materials System we will move more toward high-poly models in Blender that bake normal maps for use with low-poly models we upload into SL.

I'm designing for that as we speak. Very exciting.

---