Today we begin to look at the first of those topics. This "Part I" installment will take more of a theoretical overview approach to (hopefully) give you a conceptual understanding of what we're trying to achieve. The "Part II" installment will cover a few of the nuts-and-bolts basics in how to do it.
If you've been following along with this series you may remember that in the "bonus tutorial" part of the Virgins and Mice tutorial I urged you to make the Cycles Render engine your default and asked you to "trust me" that there's a good reason for doing so. There is...and while it's just beyond the scope of a novice level tutorial to try to explain all of the reasons why, we'll at least see part of the reason in this two-part tutorial. If you choose to use the Blender Render engine instead, Part I and the UV-mapping portion of Part II will still apply but the materials methods shown in Part II will not (a Google search will give you plenty of links for that).
OverviewWhat we'll be talking about in this two-part tutorial is what you'd typically call "texturing stuff" in-world. Our mesh is a wireframe object that is covered by a surface and our goal is to put one or more textures onto this surface and have it end up looking nice. Sounds simple; but it isn't.
There are two parts to the process: UV-mapping and assigning materials. In most respects they are handled separately and independently, yet they combine to determine the appearance of your mesh. The materials portion is something you'll find fairly intuitive since it's quite a lot like putting textures on prims in-world. The UV-mapping side of things is the area most of trouble with: somehow making the surface of a three-dimensional object look good when we're putting a two-dimensional image texture on it.
Conceptually this immediately presents something of a challenge. It's like wanting to give someone a birthday present. There are lots of different ways we can put wrapping paper on our present but it's a lot easier to do with something that's boxed instead of something that has an odd shape.
In the world of 3D modeling it gets even more problematic than gift-giving because we have to exactly wrap our object without letting any of the paper overlap or wrinkle and it has to follow the shape of the object. If you're working with mesh avatars or mesh clothing it also has to move and stretch nicely as the mesh is animated. Try gift-wrapping a live cat and you'll see just how challenging it can be (please only actually try doing that with parental supervision).
UV Unwrapping and Mapping
The process of doing this gift-wrapping with a 3D model is called "UV unwrapping" because (roughly) what we're actually starting with is our already-wrapped model and then taking some (imaginary) scissors to it to cut and pull it apart, flatten everything, and hopefully make it such that when you wrap it all back onto the surface you don't see any nasty seams and your paper doesn't get stretched too much.
To use another convenient analogy, think of the various maps you've seen of the Earth in books or on the internet. These face the identical challenge of "unwrapping" our planet and presenting its surface as a two-dimensional image. There are a number of fairly common methods used to create these maps, typically called selecting the "map projection" in cartography, and the method you choose determines where your distortions occur and how significant they are.
|Source: Geospatial Training and Analysis Cooperative|
As you will have seen if you followed the map-projection link, there are dozens of different ways to "unwrap" the world, each with its own method of showing the planet and each with its own choice about what gets distorted in your final two-dimensional map. There's no "right" or "wrong" way to do it -- just different ways -- and in each case we end up with a map. When we do this with a 3D model in Blender we call this final result the "UV map."
Just like parcel-wrapping, UV-unwrapping is pretty easy to do with a cube -- you've probably even played with paper cubes as a child which will have looked a lot like the checkerboard shape in the first picture shown in this tutorial -- but for anything else it starts to get tricky and is rarely possible to do without at least some problem areas. The trick is to try to minimize those areas or make them be somewhere that's a little hidden or less noticeable if possible. The shape of the object will determine just how easy or hard this task can be.
In SL/Opensim, each of our basic building blocks -- prims -- has a special preset way that textures are applied to the surface which means that the folks at Linden Lab already did the UV-unwrapping of them and have given us their UV maps. Technically, they've actually given us two which you can choose between when editing a prim's texture: the "default" mapping and the "planar" mapping.
As we saw above, with a more complex object -- even something "basic" like a sphere -- there are a lot of different (imaginary) ways to cut it apart. In Blender we have complete control over how this is done and, when we upload our file, our UV map is part of that upload and tells your viewer how to put textures back onto the object.
Here's an example of UV-mapping for a considerably more complex object that you've almost certainly seen if you've made any clothing or skins: your avatar. It's made up of three mesh objects, each of which has been unwrapped into a UV map. When you make textures for it, you use those map as guidelines for "what goes where" and then when you upload and apply them your viewer maps the texture onto the three-dimensional shapes of your head, upper body and lower body. SL clothing items work exactly the same way.
|The SL body unwrapped into its three UV maps|
When building with prims we're extremely limited (even if you don't initially think you are) in what we can do with the textures we put onto those prims' surfaces. We can change their tiling and offset or rotate them and we can make a few other changes (tint, transparency, etc); but it's often necessary to use multiple prims and turn them into a linkset to make even a relatively simple object look the way we want it to. This subsequently makes the linkset object a bit difficult or cumbersome to work with.
In 3D modeling sofware like Blender, all of those limitations completely disappear when we're inside the program itself. You'd be astounded by things that are possible to achieve! Unfortunately we have to discard a large portion of that power when we're exporting something that we want to upload in-world because SL/Opensim imposes a lot of annoying limits on what's allowed. Fortunately there are some work-arounds to let us retain many of the more basic added benefits.
TerminologyBefore proceeding any further we need to agree on some terminology to use because any discussion about "Blender, Opensim/SL, and texturing" instantly becomes confusing: there's a mismatch in the terms commonly used in-world and the terms used in the real world of 3D modeling. Why the folks at Linden Labs chose to use the words they did is a complete mystery to me, but we're all used to using them so we're going to need to agree to use a certain terminology when we're talking about texturing in Blender. As we look at each I'll try to give you some context about what it means in-world.
Blender and SL/Opensim agree on the meaning of this word. This is an image file that is applied to the surface of an object based on its UV map. They're used somewhat similarly as well. In Opensim we upload textures which are then stored in our inventory in the "Textures" folder to be used when building. In Blender we can either have a pre-made texture somewhere in our computer which we load into Blender for subsequent use, or we can use Blender itself to create what are called "procedural" textures.
Pre-made textures usually come from web downloads, photos you take using a digital camera, or are something you might create in a raster-based image manipulation program like GIMP or Adobe PhotoShop.
Procedural textures are created by "rendering" it from a set of instructions using one of Blender's rendering engines. The Cycles Render engine is considerably more powerful and flexible to use than the much older Blender Render engine, which is a large part of why I suggest making Cycles your default. You won't likely begin to create procedural textures until you're a somewhat advanced user but getting used to the way Cycles Render textures are handled (which is fundamentally different than the way Blender Render does it ) will save you the trouble of learning a completely different method later on. With recent improvements to Cycles, I can't think of any reason to use the older method any longer (as I stated in a previous tutorial, Cycles Render is the one receiving active development now and the old one will likely be deprecated and possibly even removed at some point in the future).
SL/Opensim has a fairly restrictive list of allowed image formats for textures (tga, bmp, jpg, and png) whereas Blender will let you use almost any raster format you like. I'd suggest that you make a habit of using only two of those for all of your in-world and Blender work: png and jpg. The jpg format is a compressed image file that is be the smallest to store but results in a loss of image quality and doesn't support the use of an alpha channel (transparency). The png format uses lossless compression which preserves image quality and can be either 24-bit (no alpha channel) or 32-bit (includes alpha channel).
I do 99.9% of my Blender work using png to retain quality and keep my options open with regards to transparency. It's a little more demanding on my graphics card and uses a bit more space in my hard drive to store the textures, but I dislike limiting my options or reducing quality until I'm absolutely sure I want to. I leave those quality-discarding decisions until the very end, just before export.
When you upload any of the texture image formats in-world they're converted to a hybrid format (jpeg-2000) which has lossy compression but does support use of the alpha channel. They're also (annoyingly!) auto-scaled for you to the downwards-nearest power of 2 on each dimension with a maximum size of 1024x1024 (yes, you can upload larger ones but they're scaled when you do so). Needless to say, a dedicated image manipulation program like PhotoShop or Gimp does a far better job of scaling than your viewer does, so I suggest always working with images where each side is already scaled to one of 1024, 512, 256, 128, 64, 32, 16 or 8 using software designed to do a good job with that scaling. For most things, 512x512 or 256x256 would be your go-to texture size unless you need the added resolution of 1024 (but don't use too many of these in your region or it will make it extremely slow to rez).
This is where things start to get confusing (if the whole discussion of UV unwrapping and maps didn't already do so). In Blender a "face" refers to the smallest unit of a mesh's surface. It's the tiny little area enclosed by three or more edges. We usually try to do most of our work using four-sided faces (called "quads") whereas all objects in SL/Opensim must use only three-sided faces which -- on the rare occasion they're referred to at all -- are called "tris" (short for the "triangle" shape of the face). Before exporting anything from Blender for upload in-world, we need to convert all of our faces to tris but Blender has a variety of easy ways to do this.
As far as I'm aware, every single 3D modeling program uses this same meaning for "face" and any time I ever use the term when talking about Blender or meshes, this is what I'm referring to. Occasionally I'll hyphenate it into the longer term "Blender-face" if I want to be absolutely clear that I'm talking about a face in the context of texturing it.
I can at least somewhat understand Linden Lab's quirky choice of "tri" for a face since it does reinforce the notion that all faces must be triangles. What's unfathomable, however, is their decision to use the word "face" as their misleading and confusing term in texturing for the next thing we'll look at. When talking about mesh I will never use the word "face" in the SL sense of a face. I'll always call it a SL-face (and suppress the urge to vomit each time I do so).
MaterialsTo understand what "material" means in Blender, think of it as being similar to putting a texture onto the SL-face of a prim and then setting all of its texture properties like tiling, texture offset, texture rotation, shinyness, bumpiness, etc. In Blender we set up a material to have all of these properties (and potentially many, many more!) and then use it on parts of mesh objects in roughly the way you put a texture on an SL-face in-world. In SL the extra settings are per-prim ones. In Blender they're per-material instead.
With SL/Opensim prims, there are usually a number of SL-faces. A Cube has 6, which grows to 7 when you make it hollow or path-cut it, or 8 if you do both. A sphere has one SL-face, which also increases to higher numbers when you path cut or hollow it. The same is true of the torus prim. A cylinder has 3 faces which, again, can increase if you hollow or path-cut it. You can't subdivide these in any way, nor can you change them. They're hard-coded into the definitions Linden Labs made for them (which, admittedly, has its advantages for their specific applications). You can, however, apply different textures, each with different texture properties, to each of a prim's SL-faces.
With an individual mesh object in Blender, we select one or more Blender-faces and assign them to use a material. We can use that same material (with all of its settings!) on a different mesh object that has a completely different set of selected Blender-faces. We can even use the material on a different selection of Blender-faces in the same object that is already using that material but "UV-map" it completely differently.
We have complete and absolute control over every aspect of this in Blender and, combined with our control over the UV mapping, this gives us immense control over the appearance of an object. Blender places no limits on how many UV maps or materials are associated with a single mesh object. It's not uncommon in commercial models to have a dozen or more different materials assigned to a single mesh. Sometimes they'll use the same UV map and could even use the same texture, but have other differences in the way the material appears. At other times there could be multiple different textures involved, each with its own special settings and individual UV mapping. It all depends on what is most convenient -- and looks best -- for any given model. Blender gives us complete autonomy over these decisions.
Unfortunately this flexibility is compromised when we upload the mesh to SL/Opensim because there are limits imposed on mesh that force it to conform to Linden Labs' arbitrary (and in my opinion short-sighted) decisions made some 10-15 years ago in early development:
- A mesh object may have a maximum of eight (8) materials (SL-faces)
- If any one material uses more than 21,844 triangles it will be arbitrarily split into two SL-faces, using up an extra SL-face per multiple of 21,844. The way this split-up is done is utterly mystifying and can make things extremely difficult to apply textures to in-world so I recommend keeping your in-Blender per-material-per-object face counts within this limit. Because we usually work with quads which are then cut in half to triangulate for export, a good rule of thumb is to limit each material in a mesh object in Blender to 10,000 quads or less.
- Blender allows double-sided faces. SL/Opensim does not. The "back side" of a face will be invisible/transparent in-world. To make something double-sided you have to "solidify" it in Blender which at least doubles the face count.
The rationale behind the limits is perfectly reasonable in a general sense: they address issues relating to a sim's ability to deliver textures and shapes as rapidly as possible to the viewer, and then the viewer's ability to display them real-time on your screen. These aren't considerations that Blender's normal target audience is all that worried about since the typical user isn't surprised or upset when it takes many minutes to "render" a single frame for you to look at. Opensim needs the graphics card to be able to render 30 or more frames per second which is a much, much harder thing to achieve and more or less mandates a lot of highly restrictive rules.
Putting It Back TogetherWe've now talked briefly (and only conceptually) about two different subjects: the UV mapping of a 3D object and materials assigned to the Blender-faces of that object. The former is a template or plan for how to put a texture onto a 3D object while the latter is more a definition of which texture(s) to use, what additional properties should be associated with the texture, and which Blender-faces to put them on.
In Part II of the tutorial we'll look at a few basics of how to do this. For the UV mapping side of things it doesn't matter which rendering engine we use; but for materials it does (my tutorial will cover the Cycles Render method).
It's also worth noting that the order you choose to do these two aspect of texturing doesn't matter, and you don't have to do either. If you don't, a mesh will be given a single default material and mapping which might even look semi-decent in-world for something that's extremely basic. Most often, however, you'll want to at least do the UV unwrapping and for more elaborate objects you'll want to assign materials as well. As a more advanced user, you may start to create some of your textures using one of Blender's render engines as well.