Chosen Few

Loki Eliot wrote: Building at the lowest render cost is not going to be the best resault though. That would depend on your definition of "best result". What's the goal? If your goal is to be as lag-free as possible, then the "best result" obviously is to have nothing at all on your sim. It'll run like a champ, and everyone who comes by will have the highest FPS their machines can possibly spit out when running the SL viewer. If the goal is to have the most realistic build that could ever be built, then the "best result" would require using hundreds of millions of polygons, and ultra-high-res textures, like Hollywood CGI. But then it would take hours to render just a single frame. Obviously, neither of those scenarios is what you want. The "best result" in SL (or in any other realtime simulation), as you know, means striking the best possible balance between scene complexity and performance. Loki Eliot wrote: so i need to work out a compromise where a retain some detail and to work that out i need to know what the lowest is and an idea what the maximum might be before and can decide on a compromise. Yes, it's about compromise, but no, you don't need any hard limit to work against in order to find the ideal balance. For every build, you make the best looking model you can, at the lowest costs you can. If you've got two options that look the same, but have different costs, go with the lower cost option. If you've got two options that cost the same, but one looks better than the other, go with the one that looks better. It's not really a difficult concept. Loki Eliot wrote: For example a Building with the lowest Render cost is so many prims i cant fit it on the land, so i substitue some of the prims for a sculpty which drops the prim count below the plots allowence but adds to the overall render cost. It's not true that the lowest render cost version of a build would consist entirely of prims. A single sculpty can replace a whole bunch of prims, which can easily end up lowering the rendering cost, rather than raising it. Did you look at the numbers I posted above? When sizing is equal, a sculpty costs as much to render as just two cubes. Throw multiple textures on those two cubes, and they end up costing WAY more than the sculpty, even if the total texture load is relatively light. Render-wise, you actually get far less bang for the buck with prims than you might think, certainly a lot less than I ever would have guessed (again, assuming the numbers for display cost can be trusted). Now consider that a single mesh can replace thousands of prims, at just a tiny fraction of the render cost. Prims, with all their unremovable hidden faces, are incredibly wasteful. Build a wall out of 4x4 cubes, and at least 22% of the polygons will be hidden. (For any of my non-SL projects, if I were to waste 22% of my polygons, I'd be fired, and rightly so.) Make that same wall out of a mesh, and there would be zero waste. Unless you go to pains to make it unnecessarily expensive, the display cost for the mesh would be far, far less than the prim version. But even if you go to town on the poly count, to make it cost the same, at least you'd be using it all, which is still better than the alternative. Loki Eliot wrote: How much more detail can i put on a build before the render costs reach server or viewer performant degridation? There can be no definitive way to answer that. Technically any and every item in view causes viewer performance degradation. So, what you really want to know is how much degradation can you suffer before it's noticeable? That's going to be highly variable from computer to computer. Say my machine is good enough that I'm getting 50 FPS in my usual day-to-day experience in SL. Now let's say your build has such a high display cost that I drop 20%, down to 40 FPS, when I'm at your place. What's the chance that I'm really going to notice the difference? 40 FPS is still going to be a very smooth experience. Now say I've got a lesser machine, and I'm only getting about 20 FPS to start with. I show up at your place, and that drops to 10. Now I'm certainly going to notice. 20 FPS isn't that unresponsive, but 10 certainly is. Even a drop from 20 to 15 is jarringly apparent. If we go back to the default cube example, it's got a display cost of 389. We can put 15,000 of them in a sim. Would looking at 15,000 cubes cause noticeable degredation in YOUR viewer's performance? I don't know. Do you? Say it doesn't. Does this mean a total display cost per sim of 5,835,000 is OK? Again, I don't know. Sometimes it will be; sometimes it won't be. There are a million other chaotic factors that can affect performance. Loki Eliot wrote: i dont know because there is no scale. No, the reason you don't know is because you're asking the wrong question. It's never about "What magical number in the sky should I strive to stay below?" It's ALWAYS about "What can I do to make this build have the lowest possible cost, while still making it look as good as I want it to be?" You're looking for absolutes where there can be none. The scale is relative. Loki Eliot wrote: If building was just a simple task of hitting the lowest render costs numbers that would be easy, but it's not, Having prims, Sculpties and now mesh is about comprimising and to do that i need some idea oh what maximum costs to avoid. Again, I'd suggest you're asking the wrong question. It's not about "maximum costs to avoid". It's about minimizing waste, each and every time you create anything. We've had similar discussions hundreds of times on this forum when it comes to texturing. No doubt you've read some of them, or maybe even participated in a few. It happens all the time that someone will ask, "What size texture should I use for ______?" or "How many pixels equal a meter?" or something else equally undefinable. The answer is always the same: use the smallest texture you can get away with that still can have enough detail in it to look the way you want. Most people, even brand spankin' newbies, do seem to grasp that concept, once it's been explained. The exact same principle applies here. Use as few resources as possible, in order to create the build that looks the way you want it to look. The specific resources in question are irrelevant. The same axiom applies to all. Whatever it is, use as little of it as you can practically get away with. Follow the same rules of thumb that all other game artists follow. If a surface detail can be suggested with texturing, rather than with geometry, let the texturing do it. If you're going to expend geometry on something, make every poly count. Avoid hidden faces. If you can use a few large polygons instead of several smaller ones, do it. Don't be afraid to have disjointed faces in a model, if it saves on polys. Use a sensible UV layout, to maximize canvas usage, while minimizing the total number of UV shells. Repeat textures wherever possible. Use as few textures as you can. I could go on and on listing more 'rules'. Hopefully, the idea is coming across. Strive to do more with less, always. As you get more experience making models with these guidelines in mind, they become second nature. You start to see new possibilities as you're working, for how to achieve the same result with less polygons, or less textures, or less whatever else is relevant. You end up redoing stuff a lot as you go, because these things don't always reveal themselves right from the start. But as you do it more, you get a feel for it, and the reworks become more and more trivial. Even if there were some kind of universally applicable number cap that we all need to stay under, what would it matter. If you always work with the above principles in mind, you'd never hit it anyway.

Very nice. Looks like Deep Paint 3D has come a LONG way since the last time I used it. I enjoyed watching your technique with the liquefy filter for projections in Photshop, gave me a few ideas. Thanks for sharing!

Kris Ritter wrote: That's all most owners of content are interested in - prim count. That may be what people are interested in NOW. But that's only because up until now, prim count has been the only limit information they've ever been given. But the times, they are a-changin'. Now that we can so easily see all the real costs associated with each and every item, I strongly suspect that such narrow thinking will become a thing of the past. It may take a little time, but it's bound to happen. As time goes on, I expect that the factors that will become most important will vary from market base to market base, in accordance with specific needs. For owners of small tracts of land, prim count may remain the most important limiting factor in their build decisions and/or product-buying decisions. That's OK, though. At least they have all the information available from which to make a reasonable decision, unlike before. If someone says, "I want a shiny new gazebo on my land, and gee, I really wish I could buy that 10,000 display cost one over there, but it's 20 prims, and I've only got room for 15 on my land, so I'm gonna settle for this 20,000 display cost one over here instead," I'm fine with that. They made an appropriate decision based on balance of the relevant factors. That's exactly what we all should want people to do. To people who don't own land (which make up a HUGE portion of the buying public in SL), display cost may well become hugely important. If someone's SL experience is primarily tricking out their avatar with the latest and greatest attachments they can find, prim count is entirely irrelevant. All they care about is how good it looks, and (hopefully) how much it's going to lag them and their friends when they wear it. This is a market at which we can target very low-display-cost mesh items, without any concern whatsoever for whether or not a prim version or a sculpty version might carry a lower prim count. For a sim owner, who wants his or her server to run as smoothly as possible, physics cost will probably become the dominant factor in their decision making process. Just as sim owners have, over the years, learned to avoid certain kinds of sim-resource-hogging scripts while not rejecting ALL scripts, they'll also learn to avoid high-physics-cost meshes without rejecting all meshes. In my experience, private sim owners tend to be pretty zealous when it comes to making sure their investment looks and works its best. (Coporate owners are another animal, but we can save that topic for another discussion.) For people who like to travel a lot, download costs will be crucial. For them, the faster something can load, the better it is. While the traveler himself or herself obviously cannot control what will or won't be at each destination they arrive at, land owners can certainly learn to build with travelers in mind, if their goal is to have high traffic. If I were building a mall, for example, I'd want to make sure everything in it rezzes as quickly as possible, so that people don't poof before they've had a chance to look around. If I can make the place load 50% faster by having it look 90% as good, that's a trade I'd be willing to make. People will learn to balance all the factors, over time. It's not going to happen today or tomorrow, but it will happen. SL users are lag-conscious, and the rumor mill works fast. When it gets out that (whether true or not) that something causes lag, the whole grid seems to know about it sooner or later. That has worked out well, with regard to certain important topics. For example, I think a very good portion of builders do understand by now that smaller textures cause less lag than larger ones, as direct result of the fact that so many of us have harped over and over and over again about it. We can be equally vocal about the subject of how best to balance the various cost factors for builds, and I think the information will disseminate. Of course, we'll have to combat all manner of minsinformation, and there will no doubt be people who won't get it. But that's nothing new. Laggy builds will always be there, and under-informed people will always blame LL for it. But at least now, we've got real numbers to point at, to better explain what's really going on. It's gonna be a lot harder for the blindly dogmatic among us to defend their nonsense when we can cite actual facts and figures about any given build. That's huge. Kris Ritter wrote: IMO, if mesh is going to be useful (especially when factoring in physics), LL need to consider this. Suddenly I'm reminded of Q's advice to Jordi, when he was "considering" a difficult physics problem. "Simple. Change the gravitational constant of the universe," Q said. When Jordi asked how, Q instructed, "You just do it. That's how." Then, upon being informed that human beings do not have the capability to redefine gravity, Q tersely replied, "Oh. In that case, never mind." It's highly unlikely that LL can simply change the way the physics engine has to treat an arbitrary mesh. No matter how much they might "consider this" as you've asked, whatever way we all might prefer things work has no bearing on how they actually do work. At the end of the day, the numbers are the numbers. It's important not to underestimate what a big deal it is that SL can even do this at all. When I was at SL Views back in 2006, I discussed the subject of mesh import with some of the developers. The unanswerable question that went around the group then was, "How do you calculate physics on an arbitrary mesh?" Nobody had a viable answer at the time. Obviously, phyisics engine technology has improved tremendously since then, but the core principles are the same. As Drongle pointed out, the reason physics costs on prims are super low is because those objects are already hard-coded into the system. There's nothing you can do to or with a prim that the physics engine doesn't already know how to do. But when you hand it an arbitrary mesh that it doesn't already know about, it has to do all kinds of additional calculations. No amount of considering can change that. If you want to bring arbitrary meshes and prims into perfect balance in this regard, you've only got three options. One, you can artificially increase the cost of prims, which obviously would just make everything suck, so we don't want that. Two, you can invent a whole new physics engine technology that somehow magically can handle any and every object you can throw at it with equal efficiency (good luck). Or three, you can lie, and pretend the numbers are something other than what they actually are (not cool). I don't know about you, but I'd rather not have options one or three be in consideration at all. As for option two, hey, if you want to wait another decade or two for someone to pull that off, go right ahead. Me, I'm gonna go ahead and use what we've got now.

Don't try to think of it in terms of absolute measurements, but rather as comparisons. The only way to answer to your question, "Is a display impact of '8000' low, medium or high?" is with another question, "Compared to what?" If you can build the same item in a different way, to give it a lower rendering cost, then 8000 is high. If every other way you can think of to make the item comes out higher, then 8000 is low. If all methods come out more or less the same, then 8000 is medium. Consider this. A default cube has a display impact of 389. A sculpty of the same size has a display imact of around 750-800, depending on the particular sculpt shape. So, all other things being equal, it takes two default cubes to equal the rendering cost of one sculpty. (Double the size of the sculpty to equal the size of two default cubes, and its display cost remains pretty much the same.) But as we all know, things are rarely so equal. Take that default cube, put a (high contrast) 512x512 texture on one side of it, leaving the other sides as default plywood, and the display cost jumps above that of the sculpty, to well over 900. Even if we put an equally high contrast 1024x1024 texture on the sculpty, its display cost only goes up to just a hair over 800. So, this time, all other things being equal, it would seem that a cube with two or more textures is inherently more expensive to render than the sculpty with its single texture, even if the sculpty's texture is larger than the cube's two textures combined. This information (assuming it's to be trusted) is incredibly valuable. I had always assumed that a sculpty carried the rendering weight of around 11 prims, since it has as many polygons as that many prims, by average usage. But now we can easily see that those kinds of simple assumptions need to be reevaluated. When the addition or subtraction of a single texture can throw things this far out of whack on just this simple little example, imagine the difference in an entire build, or an entire sim. So, what's the magic number you should shoot for? The lowest one you can hit. That's really the only answer there can be.

Wow, somebody goofed on this one, for sure. The behavior is quite interesting. On a cube, sides 0, 1, and 3 behave as if the projector stays put while the object moves. Slide the object side to side along the local X axis, and you'll watch the texture scroll across the surface. Sides 2 and 4 are just all kinds of screwed up. It's hard to make heads or tails of it. Textures do anything from exhibiting totally bizarre repeat values, to actually getting radially twisted up, almost like polar coordinates are being applied. It's got kind of a neat psychedelic vibe to it, actually. Side 5 behaves normally, which I guess maybe is to be expected, since that side is the base, and so can never be affected by the flexing. Prisms and cylinders each exhibit their own variants of these same behaviors per side. I'd say this deserves a JIRA. I would go ahead and call it a showstopper, if you've got products that depend on it working properly.

Domitan Redenblack wrote: Yes, I thought mouse-down on arrow, then arrow keys to step. That could certainly work if SL had an option to allow you to preserve selection of a manipulator handle, like Maya and some other 3D modeling programs do. But it doesn't. All you can do is temporarily select handles for dragging. As soon as you let go of the mouse button, the focus is released back to the object selection. I would imagine changing that behavior would not be trivial, but it is an interesting idea. By the way, you inspired me to do a little digging, and it turns out Maya does indeed offer an option to move objects with arrow keys. All these years I've been using it, I never knew. If any other Maya users out there might be interested, here's how it works. Alt plus an arrow key will move the selected object one screen pixel at a time. It seems a largely useless feature to me, since the in-scene value of a pixel is totally arbitrary. But some developer somwehere did see fit to include it. You learn something new every day, right?

How about working the other way around, from the bottom up, instead of the top down? In your modeling program, create the model first with the fewst amount of triangles you can possibly get away with while still representing the basic shape and allowing for the basic UV layout you're going to need. There's your low LOD model. From there, step it up, to manually create the higher LOD versions. Add more detailing (while remaning mindful of the UV framework). As a very simple example, say you're making something cylindrical. Cylinder prims in SL have 24 quads around the circumference. But obviously, you don't need 24 to suggest that something is a round shaft, especially if it's not going to be very large on screen. At the very lowest LOD, it could have as few as four sides, and assuming the endge normals are soft, it will look round enough to get by. For the next setting up, give it six sides (most small to medium sized cylinders in game art have only six sides anyway). The next higher one gets eight sides. Only the very highest level should get anything approaching 24. Really, 12 is plenty for most cases. Of course, it takes a bit longer to work this way, creating multiple versions of each model. But it's the only way to ensure your models look the way you want them, at all LOD levels.

Domitan Redenblack wrote: I use Photoshop a lot and like to be able to nudge one pixel with arrow keys etc. I suspected that was why you were asking. That works in Photoshop because it's a 2D program. In 2D, up is always up, down is always down, left and right are always left and right. But in a 3D environment, that simply can't be the case. What is "up" in 3D space? Is it the top of the screen, like in 2D? Or is it the positive direction on the global/local/referenced Z axis? Or is it forward along the camera vector? There are any number of possibilities. Let's say we come up with a definition, and we say up always means positive Z. OK, down then becomes negative Z, easy so far. But what about left and right? Do those correspond with X or Y? Without six arrow keys (or at least six combinations of keys), it's pretty hard to make it work logically. Alright, so let's give it six keys. A logical way to assign them could be we could take our cues from SL's cardinal directions, and from the avatar controls that people are already familiar with. In that case, the up and down arrows would be north and south (Y axis), the left and right arrows would be east and west (X axis), and PgUp and PgDn would be the Z axis (up and down). That all works if we're thinking only about the map. But there are some major consistency problems that could make things awfully confusing. For example, what if we're building a vehicle? SL considers "forward and backward" for vehicles to be the local X axis. Therefore, it's usually best practice to have a vehicle be facing east while it's under construction. Say I'm doing that, and I want to nudge the whole vehicle forward. If I do the intuitive thing, and press the up arrow, the vehicle would move its left instead of forward. To move it forward, I'd need to press the right arrow key. That could get really confusing, really fast. OK, one might say vehicles are a special case, and vehicle builders can just deal with that one level of inconsistency. It works for every other kind of project, right? Wrong! Things actually get way more confusing than that. How often is anyone's point of view actually oriented with cardinal directions? Almost never. People move their cameras around all the time. Heck, most of the time, cameras aren't even level, let alone looking eastward ("forward"). What if I'm building something small, I've zoomed way in on it, and I'm looking up and diangonally at it from some oblique angle I've arbitrarily arrived at? How the heck am I gonna instinctively know which way is north? Sure, I could look at the mini map or put my manipulator on world mode and select an object, but the fact that I'd have to do either of those things represents a severe degree of disconect between me and my work. Every time I'd have to stop to figure things out, not only would it make the entire build take longer, it would also disrupt my creative flow. And chances are I'd have to make such stops A LOT. This is why SL has the on-screen rulers, which are fantastic. If you haven't been using them, you absolutely should be. They enable you to very easily snap the movement of objects (as well as rotation and scale) to any increments you want. If you need to be able to move things a centimeter at a time, no problem. Just set your grid units to that size, drag the object along the ruler, and snap it to the next ledger line. As you get used to working this way, you'll find yourself quickly forgetting all about the arrow keys (and key commands in general). You'll never have to lift your hand off the mouse, so there's never any mental break between what you're looking at and what your hand is doing, which is the way it aught to be. You want something to move, just pick it up and move it, simple, intuitive, done. You get to rely on your body's muscle memory to make all the physical decisions, leaving your brain totally free to concentrate on the quality of the work, rather than on the how-to's. This is how pretty much every 3D modeling program expects you to work. To my knowledge, I've never encountered one that uses arrow keys to move objects around in 3D space.

Chelsea Malibu wrote: My external HD, whch is where I had a lot of my old image files that I created is now died and the only place I have these textures is in world. What exactly happened to the drive? Are you sure the HDD itself died, or is it possibly just the housing that's having a problem? I'd suggest you open up the housing, pull the drive out, and plug it directly into your desktop computer before you decide it's toast. Also, I'd suggest you talk to a data recovery specialist. I had my life saved by one a few years ago, when my main data drive took a dump, and I didn't have a backup. $200 and three days later, all my data was restored, just like nothing had ever happened. Those recovery guys are worth their weight in gold. They guy who did the work told me he's usually able to recover data even from drives that have been in house fires. The computer may have melted, but the platter inside the drive still has the ones and zeroes on it. Unless the drive has been physically shredded, or you've overwritten the whole thing with zeroes, I'd be willing to bet your PSD's (and everything else) can be recovered.

You should definitely upgrade. PS7 is not only ancient, it was riddled with problems, even when it was current. Adobe royally screwed up with that version, and they admittted as much just a few short months after its release. Among other problems, it's the one and only version of Photoshop that cannot process alpha channels correctly in TGA files, which is more or less a showstopper for texturing. The free 7.0.1 patch fixes most of the major flaws in 7.0. At the very least, you should download and install that patch before you do anything else. http://www.adobe.com/support/downloads/detail.jsp?ftpID=1851

Thanks for that, Drongle. Good to know. What an annoyance, though. This is yet another example of where FPS considerations and streaming considerations are at odds. Smart users will learn to strike a balance, but as we all know, most users aren't so well informerd on these things. I suspect low rendering costs will take a backseat to low streaming costs in most cases, which is unfortunate, at least from my perspective. I really don't care if something takes a few seconds longer to load, as long as my ongoing usability after it loads is good. I know not everyone feels the same on that.

I'll give you the same answer for this that I give for any and every "How to I draw/paint ______________" question: Take an art class. If I handed you pencil and paper, and asked you to draw a woman with nice cleavage, would you be able to do it? If the answer is no, then chances are you won't be able to do it in the computer either. It's the exact same skill after all, just a slightly different tool set. Being a digital artist is 99.999% about being an artist, and 0.0001% about having technical expertise. As much as I love discussion forums, and the SL content forums in particular, the fact of the matter is it's pretty hard to give art lessons in writing. If you had a technical question like "How do I make an alpha channel?" or "What's a good method in Photoshop for applying weathering effects to this wooden table I just made?" we could give you any number of highly informative step-by-step written tutorials to follow, and you'd have all the information you need to become as technically proficient as anyone else here. But obviously, those kinds of questions aren't about aesthetic sensibility or artistry. They're strictly about button-pushing. A question like "How do I paint cleavage?" is all about developing your skill as an artist. There's no magical "make it look good" button in Photoshop. You're going to have to become a painter, if you're not one already. Hopefully this will help get you started. I'll share with you the advice my favorite art teacher in college used to give. Almost every class, he would repeat these words, "Approach every subject as a problem of light and shadow, and you'll never go wrong." In other words, don't think of it as "How do I draw cleavage?" Instead, think about how do light and shadow fall across cleavage. What do the shadows look like? What do the highlights look like? The real answer to "How do I draw cleavage?" is you can't. Even for the greatest artist in the world, no amount of applying pencil to paper or applying coloration to on-screen pixels is going to magically cause a pair of breasts to spring into existence out of thin air. What you CAN do is draw the shading that cleavage produces. That's easy. So what are the relevant properties of cleavage we need to consider, and how do those properties affect the behavior of light and shadow? Well, first of all, breasts are round, which means light and shadow will grade around them. Obviously, flat shading won't do. Second, breasts come in pairs. Put any two objects in close proximity, and less will light escape from in between them than from around them. Hilltops are sunnier than hillsides, if you know what I mean. Unless the breasts are totally squeezed together, the sternum area in between them will be visible. Unlike the breast surfaces immediately to either side of it, which face each other, the sternum itself faces forward, so it reflects light straight out. Hence it appears more brightly lit than the inner cleavage area of each breast. It's often just as bright as the most forward-facing parts of the breasts themselves. The whole thing is covered in skin, which is partially translucent, very slightly shiny, and somewhat diffuse. Light and shadow behave differently on skin than on fabric or metal or wood, etc. The particular skin of the chest area on females tends to be wrinkle-free, even on the elderly. Thus thin spindly highlights and shadows will look unnatural. You want wide, sweeping highlights and carefully graded shadows. Remember, it's not just about the breasts. The flesh of the upper chest and along the sternum is among the thinnest in the entire body (only the forehead and shins are thinner), which means underlying bone structure tends to be visible, even on the obese. Also, breasts sit on top of pectoral muscles, and although most people don't tend to realize it, the pecs play a huge role in defining the cleavage. Many trained artists, when drawing a woman, will actually draw the pecs first, and then draw the breasts right on top of them afterward. With all that in mind, take a really good look at the light and shadow on some real cleavage, and draw what you see. A live model would be best, if you have someone around who's willing to let you stare at her chest for a while. If not, a photograph will do. Pay close attention to the nuances of the lighting and the shading, as they fall across the subject, and reproduce the same on your canvas. It'll take practice to get good at it, of course. Just keep at it. Drawing is a skill every human being can learn to do well. Some people stumble across it on their own at a young age, and we label them "artists" early on, but they're certainly not the only ones who can do it. Everybody can, literally everyone. If we couldn't, we also wouldn't be able to watch movies or see identify objects in photographs and paintings. It's all the same brain function. As for what tools to use in Photoshop for this, whenever it comes to highlighting and shading, the burn & dodge tools are your friends. After you lay down your base skin texture, use the burn & dodge tools (on an overlay layer) to shade the roundness of the breasts. Bam, you've got cleavage. Finish fleshing it out by also shading underlying shapes of the rib cage, the collar bones, the pectoral muscles, etc. But let me reiterate, the tools alone aren't going to make it look right. For that, YOU need to know what to paint with them. And for that, YOU need to have done your homework as an artist. I hope this has been helpful. As I said, it's pretty hard to try to teach any of this with just words. Good luck, and have fun.

The funky shading in Maya is the result of normals pointing in odd directions. We collapsed 3/4 of the faces in the model when we snapped all those vertices on top of each other. As a result, some of the light is reflecting parallel to the surface instead of away from it. Less light from the affected faces makes it to the camera, so those faces appear darker. To solve the problem, simply select the model, and harden the normals. That will reset them all to be pointing in the right directions. As for what's going on with the SL version, there are a few issues to consider. Take a look at the wireframe, and you'll probably want to puke. It's gonna be all kinds of sloppy. There are only 256 possible stops in each direction, and you're trying to make a 32-sided cylinder. It can't be perfect. Sculpties just weren't meant for this kind of work. Regarding your question about how to texture a mesh, the answer is any way you want. Right now, you're probably so used to SL's iron fisted restrictions, it might not even occur to you how much freedom is at your fingertips with mesh modeling. With sculpties and prims, you're stuck with just one UV layout, so there's almost zero control over how the texture wraps around the canvas. Every texture wraps in basically the exact same way. But with an arbrary mesh, the UV layout is just that, arbitary. If you want it to be just a grid like with a sculpty, fine, you have that option (assuming the model has that kind of topology, of course). But you can also set it up any other way you might want. There are no rules constricting how you might choose to place each face of the 3D model onto the 2D texture canvas. However you think it best fits, do it. Before I can elaborate on that, let's first take a look at the gear as an arbitrary mesh model, instead of a sculpty. Just to show you how easy mesh is to work with, here's how to make that same gear in just a dozen clicks or less. (Technically, it's 10 clicks, and two drags, but who's counting, right?) Note, there are a gazillion and one ways you might go about mesh modeling gear. This is just the one I happened to choose right now, since it's super easy to explain, and even easier to actually do. Plus, I just thought "dozen clicks or less" had a nice ring to it. Here goes: Click 1. Start with a polygonal tube, with16 divisions around the axis, and one division along the height. (Okay, you might have to click two extra times, to plug in those numbers, if your Create Tube settings don't happen to be that way already, but we're not counting those.) Clicks 2-9. Around the outer surface, select every other face. Clicks 10 and 11. Extrude. When you click the Extrude button, the manipulator will change to extrusion mode, and it will move to align with the surface normal of one of the selcted faces. In this state, whatever you do with the manipulator will affect all the selected faces, each relative to its own surface normal. So, to create the gear teeth, simply drag the manipulator along its local Z axis. All eight of the selected faces will extrude outward, forming new faces in their wakes. Click 12. Scale. Right now, the teeth are square. If you're OK with that, you're all done modeling. But that's not really how gears are usually shaped. In most cases, the teeth will be tapered a little, so let's do that. With the manipulator still in extrusion mode, grab the local X axis scaling handle (the red box on the end of the red arrow), and drag it toward the center. There you go. A perfectly good gear, in just 12 clicks. If you were making your own gear for the first time as you were reading this, it probably took you a few minutes, since you were reading as you were working. The second time you do it'll probably take you about 30 seconds. Try making a sculpty gear from scratch in 30 seconds; I double dog dare ya! Now let's talk about how you might UV this model. Before we dive into it, let me first say I'm not going to give an A-Z walkthrough of how I created each of the following examples. I'll give a basic overview for each one, but I'm not sure it would be a good use of my time today to write a beginner level textbook on the ins and outs of UV'ing 101 right here in this thread. I'm much more interested right now in discussing the concepts of what makes a sensible UV layout than the specific button pushing. If you've never done any UV'ing at all before, the best way to learn is just to do it. Read the relevant chapeter in the User Guide section of your Maya help file, and take a look at any of the thousands of beginner tutorials you'll find all over the Web. UV your first model, and you'll understand how it all works. With that out of the way, let's take a look at some possible UV layouts for this particular model. As I said before, there are any number of ways you could choose to set it up. Let's start with one of the most obvious possible layouts: I created this layout by applying planar UV mapping to the top and bottom, and then applying a cylindrical mapping to the inner faces and outer faces. Then I simply scaled the results, and moved them to where they fit most easily on the cavas. With this layout, the top and bottom of the gear are very easy to see, so if you're 2D painting a texture by hand, you can't miss. The surfaces inside the hole are evenly spaced across the top of the canvas, and those of the outer side are across the bottom, each laid out wrap-around style, to be textured in much the same way as you'd texture the side of a cylinder in SL. That's all nice and logical, and very easily visualized, but it's not very efficient. A tremendous amount of canvas space is left unused. That's not good when your goal is to be as low-lag as possible. Now here's the opposite extreme layout. This one totally maximizes the canvas space, and scales all the faces to their best relative sizes, to ensure uniform pixel density across all: With UV layouts like this, you'll be the king or queen of low-lag texturing. But needless to say, painting this sucker in any 2D paint program would be a nightmare. You can do it, but it's gonna take time and effort to constantly keep track of which face is which. Maps like this work best if you're going to be 3D painting and/or baking, scenarios in which you really don't have to care about where any particular face is on the canvas. Now, obviously creating a layout like this one can be tedious. All that moving, rotating, and scaling of each little face can drive you batty, if you're dong it all by hand. On a simple model like this gear, it's not terribly time consuming, only takes a minute or two, but still, it's annoying. On a complex model, it can take hours. I don't have the patience for that, which is why I've got this awesome little plugin for Maya called Unwrella (also available for Max). It's designed specifically to do what I just said above, maxmize canvas usage while ensuring even pixel density across all faces. With Unwrella, I was able to create that second layout instantly, in precisely two clicks. It's a fantastic tool. At around $200, it more than pays for itself in a single project. If you don't want to buy Unwrella, you can acheive pretty decent results quickly with Maya's various automated mapping methods. Just be aware that you'll often have to refine the map by hand afterwards, as the built-in systems aren't as sophisticated as the plugin. The above two layouts assume you want one texture to cover the entire model, and you want each face to receive a unique area of that texture. But that's hardly the only way to go about texturing a model. For starters, there's no rule that says each face needs its own space. Put two faces in the same space, and they'll both get the same texturing. This is why the SL avatar gets the same texturing on both arms, for example. Both arms have their UV's occupying the exact same part of the map. Hence whatever you do to one happens to the other. And of course, there's also no rule that says the model has to have only one texture on it. What if you want to texture this gear the same way you'd texture a typical SL prim, which each "side" getting its own texture, and with each texture being very squarely laid out across the surface? In that case, you'd probably want a UV map that looks like this: Here, we've repeated the same basic logic as in the first example, except this time, each "side" of the model fills the whole canvas. This is the same way a hollow cylinder works in SL. The bottom, top, inside, and outside each fill the canvas fully, as separate UV shells. The top and bottom are planar mapped, while the inside and outside are cylindrically mapped. Notice I've put each side in its own UV tile. Technically, each tile is just another repeat of the texture canvas, so in terms of actual texture placement, it really doesn't matter whether we pile all the UV's into just one tile, or spread them out like this. The mapped results will be the same either way. However, using multiple tiles does afford a couple of usability advantages. First, most obviously, it makes things much easier to see. Second, 3D paint programs like Mudbox tend to interpret each tile as a unique material, so it's usually good practice to do it this way if your intent really is for each side to have its own texture. Needless to say, we've got the same inefficiency problems we had in the first example. The top and bottom leave a lot of canvas space unused. And pixel density is about as bass ackwards as it gets. Including the teeth, the outer side has twice as many faces as the inner side, which means each outer face only gets half as much canvas space as each inner face, even though the faces inside the hole are physically smaller on the model than most of the outer faces. Efficiency wise, this particular layout is pretty silly. But it's the layout that SL users are familiar with. You could slap any of the thousands of pre-existing textures in SL on this thing, and they'll all work. If maximum compatibility is the goal, this would be one way to acheive it. Those are just the tip of the iceberg. There are as many ways to UV a model as there are stars in the sky. There's no absolute right or absolute wrong way to UV anything. As with anything else, make intelligent decisions on a case by case basis, in accordance with the specific goals of each build. So, once again, to answer your question, the way to texture a mesh model is any darned way you please!

duLuna Bosatsu wrote: When I selected Reverse Normals nothing happened, at least nothing that was notable in SL- still uploaded reverse. Not sure why it wouldn't have worked. You did have the object selected when you clicked the command, right? Were you in object mode or component mode? Did you enable backface culling and/or normals display, to verify that the normals were indeed pointing in the right direction? Did you delete history before exporting the sculpt map? duLuna Bosatsu wrote: when I went to export the sculpt map, it had a strange black stripe on it what happened~? Somehow, the exporter thinks you've got a row of vertices all at <0,0,0>. Here are the usual suspects that might cause that: You didn't merge any of the overlapping vertices before exporting, did you? Have you checked the UV map to make sure it's correct? Did you remember to delete history, and freeze & reset transformations before you exported? If none of those are the culprit, I'm stumped for now.

My guess is when you folded the plane, you folded inward instead of outward. In other words, the back face of the plane became the outside of the tube. An easy way to avoid that is to work with backface culling turned on in Maya. That way, you'll always know beforehand which side to expose. Alternatively, you can turn enable normals display, so you can see which way the normals are pointing as you work. To fix any existing polygonal models that are inside out, simply reverse the normals. For NURBS models, reverse the surface direction on one axis.

Very nice looking model, Jack, but I have to question the poly count. It looks like it's got to be awfully high. Remember, you're modeling for a realtime environment here. Game modeling is ALWAYS about doing more with less. Aesthetics must be balanced with performance considerations. The model itself must have as few polygons as you can possibly get away with. Fine details should be implied by texturing, not modeled with geometry. People can't wait hours for a frame to render. It's got to be done in a fraction of a second. Even at a mere 20 FPS (which is abysmally slow for most games, but not atypical for SL), you've only got a twentieth of a second for everything in the scene to be drawn. The more geometry you've got in each model, the less the chance that there's going to be enough time to render it all at any semblance of good speed. I see lots and lots of details in your model that don't need to be there. The ridges on the snout, for example, can easily be textured instead of modeled. I notice all kinds of lovely imperfections around the mouth area, which, lifelike as they are, really shouldn't be on any game model. Again, the texturing can suggest the same effect, at far less rendering cost. The same is true for the musculature of the torso. Those well defined pectorals you've sculpted are very nice, but they're obvious polygon hogs. You could achieve almost the same effect with just a handful of large polygons, accompanied by good texturing. The abdominal muscles and ribbing really don't need to be there at all, as the texturing can more than adequately suggest their presence. Let me answer some of your questions: JackRipper666 wrote: What do you mean by weighted? Like adding more polygons or some how using something in maya to keep those area's more weighed down from moving so that it stretches correctly? Sounds like you're new to rigging. In this context "weight" refers to the amount of influence a given bone has on a piece of geometry. When you first bind a skin to a skeleton, Maya will (optionally) calculate weights for you, based on the proximity of each bone to the surface structure. Assuming you've constructed the model and the skeleton to fit each other well*, this will generally yield a good starting point. But you'll almost always need to refine it further by hand, to make it work properly. Maya offers several options for adjusting how bone weights apply to a model. The one you'll use most is the Paint Weights tool. Just as its name suggest, this tool allows you to physically paint the influence of each bone onto the model's surface. As with nearly everything else in the graphics world, alpha mapping logic applies to this. Any area you paint white on the model will be 100% influenced by the selected bone. Any area you paint black will receive zero influence from the selected bone. Shades of gray represent all degrees of influence in between. The Paint Weights tool provides a fantastic way for you to use your artistic sensibilities to get your rig working, at pretty good speed. But it does have its shortcomings. For example, because it's a painting tool, it relies on UV mapping. So, any areas of the model that have overlapping UV's will receive identical weightings to any given bone. This is a problem for a model like the default avatar mesh, which puts both arms on the same UV canvas space, as well as both feet. Here's where the Component Editor comes in handy. With this tool, you can directly edit the mathematical values of the bone weights, on a per-vertex basis. Want to separate the two feet? No problem. Simply select all the vertices in the right foot, and zero out the values for the influence of the left foot bones. Rinse and repeat for the other foot. If you want to be able to rig successfully, you'll need to become intimately familiar with these tools. *Note, you can't use a custom skeleton for SL (yet). You have to use the pre-existing avatar skeleton. So when you construct your model, you should make it fit that skeleton. JackRipper666 wrote: I built the inside of the mouth but it has no teeth or gums yet. So I need to build that and put it in. Careful. Mouth parts can be a HUGE source of polygon waste. First, you should consider whether the inside of the mouth even belongs at all, since the avatar skeleton has no jaw bone. You won't be able to use animations to make the mouth open and close. There's nothing there to animate. You could fake it by having a couple different versions of the head, scripted to appear and disappear on command. But needless to say, that would be tremendously wasteful, since you'd be doubling the poly count. Even when invisible (full alpha) the polygons are all still there. Second, if you do decide the mouth interior should be there, be mindful of how much geometry you put in there. For example, do you need to model the indivdual teeth, when just a few planes with an alpha texture could do the job? The vast majority of game characters employ the latter strategy, including the SL avatar. JackRipper666 wrote: Some facial expressions to. This is really hard though LOL! It's even harder than you're probably thinking. The avatar skeleton has no face bones (except for the eyes). So, you cannot animate expressions. Again, you could fake it with multiple versions of the head, but each one you put in would multiply the poly count, not to mention complicate the scripting. JackRipper666 wrote: What do you prefer to use for rigging and animations? I was thinking I could try it in maya or zbrush. Use Maya. Zbrush's approach to rigging is a little weird. Maya's going to give you a lot more power and control. Also, I'm not sure if there's an existing avatar skeleton available for Zbrush. You could make one if there's not, but you'd need to really know what you're doing, and it sounds like you're pretty new to this. I'm also not sure if the available COLLADA exporter for Zbrush includes bone weights. Maybe someone can chime in on this. In any case, Maya has all the tools you need, built right in. JackRipper666 wrote: Then make animations in something like MotionBuilder. Motion Builder really would be overkill for this. If you've got it, and you know how to use it, you can certainly do it. But if you're planning on learning it just for this, there's really no need to go so elaborate. Are you really planning to use a mocap system, or to retarget existing animations from other skeletons? You can do the animations you need, right inside Maya. You'll just need a script to export to BVH, so SL can import it. Like most animation programs, Maya is set up out of the box to import BVH, but not export it. (They expect BVH data to be coming into the program from a mocap system, not going out from the program to somewhere else.) A few years back, Alexia Mechanique created a BVH exporter for Maya, and then Orion Neville added on by creating some easy-to-use buttons, and an accompanying rig. Both people generously made their work available to community for free. You can find the files available for download at http://abbloch.com/orion/ JackRipper666 wrote: As for textures I am not sure probably paint the model first with like polypainting or ptex painting and bake them into a UVmap later I think is how it's done. Here's where you'll want to use Z-brush, if that's your 3D paint program of choice. I prefer Mudbox, myself, but Zbrush is certainly more than capable. You might also want to create a very high-poly version of the model, from which you can bake textures for the low-poly version. That way, you can simulate your high-poly details within the texturing, while keeping the in-game model very light weight. This is common practice in the industry. I wouldn't bother with Ptex. It's cool technology, but there's really no need for it for this. It would just add an unnecessary layer of complication to what you're doing, since you'd then need to bake the results back to a UV mapped texture anyway. I'd suggest you just UV the model well, paint, bake, and be done.

Have you tried moving the deformer? I take it you're new to using deformers. Try moving it along each axis, and see what happens. Keep in mind that the deformation effect is centered around the deformer itself, and you'll be able to make sense of what you're seeing. As you'll discover, you can solve your current problem simply by moving the deformer up. Another option is to proportion the model so that the deformer will automatically bend it in the way that you want. Before you apply the deformer, think about the proportions the object's base topology would need to have if you were bending it in RL. Say in RL you were bending a piece of hose into a torus shape. How would that work? Quite obviously, the length of the hose is going to become the major circumference of the torus. And of course, the hose's depth and height are going to be the minor diameters of the torus. With that in mind, what proportions does the hose need to have? If the hose's length is equal to its width and height, it's not gonna work. You'd never be able to bend it in the way that you need. The only way it can work is if the hose is far longer than it is tall or wide. The same is true here. It looks to me like you started with a more or less equlateral square tube. Squish the tube vertically*, and you'll see the problem go away as you effectively change the minor diameter of the torus. You can also prevent the problem in the first place, by giving the object proper proportions before you apply the deformer. Stretch the model lengthwise a good deal, then apply the deformer, and the problem won't crop up. (For what it's worth, I'm not sure how you would have arrived at equal length, width, and height, in the first place. By starting with a square plane, and then folding it three times, the resulting piece of "square tubing" should have ended up four times as long as it was tall.) *A few things to note: When I said "vertically", I meant in relation to the deformer's up axis, which from your screenshot, happens to be global Z axis. After you've applied the deformer, the object looks round, but it's not really. That's just the visual effect produced by the deformer acting upon the object's shape. It's an illusion of mathematics, nothing more. The model's actual shape is multiuplied by the deformer's shape, to produce the visual effect. The real geometric shape of the model itself is still that same square tube it was before the deformer was applied. Keep in mind, the power of custruction history in Maya. The object's base shape comes first in the history, and the deformation comes second. Because of this, you can change the base shape all you want, and it won't change the major roundness of the torus. That roundness comes only from the deformer, not from the base model. To "bake in" the effects of a deformer, delete construction history. Only at that point will the perceived shape become real. With the hostiry gone, you've remove Maya's memory of how the visual shape came into being. At that point, Maya simply concludes that the shape the object appears to be is the shape it actually is, and that's that. This is one of the many reasons that, to ensure a clean outcome, you MUST delete history before exporting your sculpt map.

When you rig the mesh, you'll bind it to the avatar's skeleton. Thus it will capable of moving in every way the avatar itself can move. The default avatar body is just a rigged mesh, technically no different from the one you're building. It's capable of turning its head, and so will yours. As long as all the polygons on your mesh's head are weighted fully to the head bone on the skeleton, the skin and bone will move as one. For best realism, the polygons on the neck should mostly be weighted to the neck bone, but also partially weighted to the head and partially weighted to the chest. That way, when the head moves, the "flesh" of the neck will be pulled by it, just as a real neck's flesh is pulled when a real head moves. If for some reason you really want the head be a separate piece, you certainly can do it that way. It'll just be a more complicated rigging job, since you'll need to take steps to ensure the skin doesn't appear to tear when the two pieces move independently.

Thanks for clarifying. Much appreciated.

I don't mean to rain on anyone's parade, but I have to say I don't quite understand the point of this thread. When I saw the title, with its exclamation points, I was briefly excited, as it looked like you were announcing that a new feature had been confirmed. But all you were really doing was making a suggestion. The suggestion itself has of course been made hundreds of times since the dawn of SL. Many of us have asked for the abilty to individually animate fingers, the jaw, parts of the face, etc., in the default avatar. We've also had many a conversation about the ability to create custom skeletons for rigged meshes. The former is unlikely ever to happen, but the latter is in the works. Needless to say, the allowance of arbitrary skeletons would negate any need to add anything at all to the default one. If you don't like how the default skeleton works, you can just replace it with your own.

http://www2.actden.com/writ_den/tips/sentence/puctuate.htm

Medhue is of course correct that if you're creating a mesh model to replace or augment the default avatar model, it's generally best to make the whole body a single mesh, just as you would for any other character model. However, from the wording of your question, Jack, I'm not sure completely sure that that was really what you were trying to ask. You used the word "prim" a lot. Are you in fact constructing an arbitrary mesh model, or are you piecing something together out of primitives? What exactly are you trying to do?

I've got a three guesses as to what might be going on. You mentioned you haven't scaled the mesh properly. If it's very small, my guess is it's buried inside your avatar's body. If so, try turning off avatar rendering, and perhaps you'll be able to see it. If it's the reverse, and the mesh is way too big, then the reason you're not seeing it could be that your camera is inside it. If that's the case, disable camera constraints, and zoom way out. The third option is maybe it's located at some offset distance from the attachment point. If it's tiny and offset a good distance it may be quite difficult to locate.

Thanks, Kaluura, for doing the right thing. Your answer was very informative. No doubt it will be extremely helpful to anyone looking to do this. Sounds like it doesn't pertain to those of us who don't use third party viewers, as I'd guessed. Still, it's quite interesting.

Kaluura Boa wrote: You don't want me to ruin the fun of the discovery for everybody, do you? Yes, actually. That's precisely what the forum is for. Frankly, it was pretty rude of you to come here asking for help, only to deliberately decide not return the favor afterward, when others asked for a full explanation. Really, it's an abuse of the forums, and a slap in the face to everyone here. Kaluura Boa wrote: Export, look and you'll find. Export how, exactly? Look for what, precisely? Not everyone knows the same things you know. How about showing the rest of the community the same spirit of generosity you asked all of us for when you first posted the question in the first place? I've been in SL for almost as long as SL itself has existed, and this is the first I've heard of importiing/exporting sculpties via XML files. Is this a third party viewer thing? If so, are you certain the results will be viewable by everyone? Kaluura Boa wrote: It's really damn easy. The modification of the file to import requires no more than 2 keyboard shortcuts. Seriously! Great, then it shouldn't take much effort on your part to write out the steps. If the technique is really as easy as you say, then it would have taken you no longer to explain it than it did for you to say you weren't going to explain, so you would have lost nothing by being a little nicer. It's not too late now. How about stepping up? Kaluura Boa wrote: But be prepared to be a bit desappointed... It just adds new constraints in the straightjacket of the sculpties. How so? Again, would a sentence or two to clarify really kill you?