Chosen Few

Hi Ars. I'm having a little trouble understanding some of your points. I realize English is not your first language, so perhaps I'm just misreading you, but it seems you're operating based on some incorrect assumptions, particularly with regard to how textuirng of sculpties can or should be done. Allow me to try to explain. I'll take it one point at a time. ArsHarmonia wrote: I noticed that every day more builders include "shaded" o "shadowed" textures in their building, houses and stores but what called more of my attention, is that I can see that effect in almost every new item. I think that trend started with the sculpties mostly, it's not too difficult to include ambient occlusion in a texture, or even shadows. In the "old" times, we didn't had reflection and shadows, I don't remember if we had them by the time the sculpties came to life into sl, but certainly we do now! Problem: you need a decent video card, a decent computer, etc, to be able to appreciate those client-side capabilities. With textures seems easier... But... a few things I noticed too: Just so you know, the main reason why we see so many more textures with baked shadows nowadays than we did years ago is because texture artists in SL have had the ensuing years to hone their techniques, to get better at making thing look more realistic, and more aesthetically accomplished. Back in the day, SL looked quite awful, for the most part. Just about everything, textures included, was very underdeveloped, very flat, very amateurish. People hadn't yet figured out what worked and what didn't, artistically. But now, a great many content creators know how to make things look very, very good. Shading is a HUGE part of that. But of course, as with all things, there is a downside. Not everyone knows how to optimize. The SL population is still made up primarily of amateurs who have no idea what they're doing. They see a nice looking build, made by a professional, and it inspires them. So they set out to make something that looks just as good. But because they lack the proper knowledge of how to do it efficiently, they end up creating what amounts to a very good looking lag monster. Eventually everyone does learn to make things that are both good looking and well performing. But it doesn't happen over night. The majority of people will always be somewhere in the middle of the learning process. As a result, most content will be inefficient, and SL will never run as smoothly as it otherwise could. That's just something you have to accept in SL. It's the nature of the beast (and it's not a bad thing). Bottom line, if you want a virtual world for which you don't need high end hardware to experience high performance, go to one that is not made up of user generated content. The requirements for World of Warcraft, for example, are extremely light. In a world where amateurs make almost everything, system requirements are always going to be relatively high. ArsHarmonia wrote: 1) some sculpties could be easily textured with a single texture I'm not sure what you're trying to say here. The words "some" and "could" do not apply in this context. EVERY sculpty IS textured with a single texture. By definition, a sculpty is a singular contiguous surface. One sculpty can't have more than one texture on it, ever. Am I perhaps misunderstanding what you were trying to say? If so, could you please clarify? ArsHarmonia wrote: 1) but if I use ambient occlusion, I most likely need to generate a uv map for that certain sculpt, This assumption is not accurate, for two reasons: First, by definition, all sculpties have the exact same UV map, just a perfectly uniform grid, nothing more, nothing less. If you change a sculpty's UV map, it won't be a sculpty anymore. The uniform grid layout is absolutely essential in order for a sculpty to be a sculpty. Second, there's absolutely no reason you'd need to alter the existing UV layout just to add ambient occlusion to a texture. All you need to do is apply the proper render settings (or possibly apply an occlusion shader to the surface, depending on what modeling program and renderer you're using), and bake the texture image. That's it. ArsHarmonia wrote: I most likely need to generate a uv map for that certain sculpt, that when deformed a bit won't look that nice, I don't quite understand what you mean. Why would the UV map be deformed? Terminology issue, perhaps? Are you maybe talking about something other than a UV map? ArsHarmonia wrote: this causes some buildings that require more than one prim with the same texture if to require a different texture for it, and in the client side, a lot of rezzing time. Yes, if two prims that would otherwise have the same texture on them require different shading, and you want to bake the shading into the texturing, then the result would be two different textures. This will, of course, increase rezzing time, just as you've noted. There are a few things you can do to cut down on this, though. One is to combine your textures into multi-panel "texture sheets". For example, instead of having two unique 256x256's, you could put them both on a single 256x512 canvas, and then just display half the image on each prim. This won't lower the total amount of texture memory being used, but it will cut down on network overhead, since only one asset needs to be delivered instead of two. Another option is to put the same texture on both prims, and then create the shading with additional prims that have "shadow textures" on them. Since the shadow images themselves typically don't require much detail, they can be really, really small, like 64x64 or less. Small shadow textures, laid over the top of larger diffuse color textures, will often cut down significantly on total texture overhead. But of course, prim usage goes up, as does the amount of render passes, as well as the likelihood of alpha sorting issues, so it's not always a win. Sometimes you come out ahead this way; sometimes you don't. Beyond that, the remaining options are either don't have shadows, or bake the shadows in. Until and unless we get better technologies built into SL, such as lightmaps, there's no really elegant solution. It's always going to be a balancing act between aesthetics and performance considerations. ArsHarmonia wrote: 2) some builders tend to use (I think it is quite popular) one texture with darkened borders, and you can see it in different stretching sizes in same building, so the borders match, but the deformation of the patterns is visible. Yeah, I hate seeing that. While it's possible that it's sometimes done for efficiency reasons, the impression it tends to convey is of a lazy, sloppy builder who either didn't know how to make it look better, or just didn't care. ArsHarmonia wrote: 3)abuse of shadows: this is, in places like a building outdoors that isn't occluded by any building at all, and wouldn't be occluded because it is too tall, and it is surrounded by a significantly void area, still it haa textures with shadows, in some cases I'd think the person who rezzed the building didn't payed attention to that detail, or the builder had some other landscape in mind, but the more I look around, I see this as a tendency, and I see quality buildings with this kind of details that make me wonder: why? why?! Well, in RL, even items that are entirely unoccluded still have shading. There's only one object you see in everyday life that has no shadows on it at all, and that is the sun. Everything else, including buildings, trees, people, clouds, even sheets of plain white paper, all have highlights and shadows on them, always. Heck, even the sky has shading (it's darkest at the horizon, and lightest where the sun is). Now, if someone shades something over-dramatically, or otherwise unrealistically, whether it's an indoor or outdoor item, well, that's just poor artistic judgment. I'd have a hard time calling it "abuse", just because it doesn't look good. That said, do keep in mind, not to shade something at all, simply because it's meant to be an outdoor item, is to be just as unrealistic. Surfaces don't become immune to the natural laws of physics, just because they're outside. Everything has shading, everything. Unshaded surfaces look flat, under-developed, and amateurish. If you want your builds to pop, you must give them some shading. Otherwise, they'll always be dull and cartoonish. ArsHarmonia wrote: I assume most of this details and buildings are made considering a vast majority of users use the client in lower quality settings, and in those cases most buildings might look better, but is this an improvement? Most people don't run on Ultra, if that's what you mean. And the vast majority certainly don't have dynamic shadows enabled. That's not even an option in many of the viewers that are out there right now, and it's not yet an officially supported feature even in the viewers that do have it. It's still under development, and highly experimental. As for what does or doesn't make a building look "better", and what is and isn't an "improvement", that's obviously subjective. Ask a hundred people, and you'll get a hundred answers. For my part, I usually shade outdoor scenes with the "overcast day" look. That means lots of non-directional lighting and shading. That way, it looks plausible, no matter what direction the sun is currently in. Also, it tends to compliment, rather than contradict, dynamic shadows. It's really only when baked shadows are too directional that they start to conflict overtly with the actual in-world lighting. Non-directional global illumination effects, such as ambient occlusion, final gather, or even just good old fashioned gradients or inner shadows, don't tend to cause issues, no matter what the state of the real lighting conditions, as long as they're used tastefully and intelligently. ArsHarmonia wrote: what should be the client settings and performance settings took in consideration when making a "quality building" for everybody to enjoy? You're barking up the wrong tree with that question. There's no single collection of viewer settings that is going to match what everybody else is using. Everyone's got different settings. And even if it were possible to figure out some kind of "average user" settings (which it's not), there would still be the problem that eveyrone's got different hardware configurations. Take two viewers with identical settings, and look at them on different monitors, and with different video cards, and they're going to look quite different from each other. There's no way to have things look exactly the same unless the settings and the hardware are identical. What you should instead be thinking about is how you can make your builds look good at all different viewer settings. When you make something, don't just examine it at your usual settings. Lower the settings, raise the settings, look at it under as many conditions as you can. If it doesn't look reasonably good at all settings, redo it until it does. With enough practice, you'll get a feel for what kinds of things always work. By the way, I use four monitors on my main computer. I've got two ultra high end artist-quality Eizo flat panels, and two eight-year-old Samsung panels. Whenever I texture something, I make sure to look at it on both sets of monitors. If it looks good on the Eizos (which are way better than what most people have) and the old Samsungs (which are quite a bit worse than what most people have), then I know it's going to also look good on everything in between. If you don't have access to that kind of setup, don't worry. Chances are you've got something in the middle anyway. What looks OK on your screen will likely look OK on most other people's screens as well. You just don't have the luxury of being absolutely certain unless you can test on the full range. But you can still make reasonable assumptions.

Even though you can simply turn the overlays off via the forum settings, the question is still a good one, from an image editing perspective. The answer is that a a second overlay with exactly the opposite grayscale value will cancel out the first (assuming the overlay method and opacity are the same for both). In the following image, the two circles are overlays, each set to linear light mode. The dark one has a grayscale value of 60%, and the light one 40%. Since 50% is neutral for an overlay, 60 and 40 are exact opposites. As you can see, the area where they overlap yields exactly the same color as the non-overlayed background.

I didn't mean to make it a bitter pill, Eloise. Sorry if it sounded at all harsh. That wasn't my intent. The "art teacher voice" doesn't always translate too well to plain text (which is why I so rarely give artistic criticism on the forums, and instead almost always focus just on the technicals). My purpose was just to try to suggest that you might better approach the problem from a different direction, rather than get too caught up in just the proportions. In any case, I'm glad you took the advice to heart. The problems with the iris weren't really your fault, from a technical perspective. You followed the instructions you had, flawlessly It just happens that they weren't particularly useful instructions, at least not if realism was the goal. If it's any consolation, eyes are always the hardest thing to make, in any medium, from pencil to paint to sculpture to pixels. Human beings are absurdly good at recognizing facial features. We are hard-wired for that, from birth. And eyes happen to be the one feature we focus on the most. It's not a simple task to make eyes look convincing, from scratch. Keep at it. Try multiple techniques. Look at lots of different tutorials. You'll make it work.

Two things: First, do you have a ton of subunits showing on your grid, or is your sculpty really like a hundred units wide? For best results, you should never have more than 10 units between any two vertices. Maya's default units are centimeters, and SL's are meters, which makes it easy to assume that 100 Maya units equal 1 SL unit. But tht's not actually the case. A unit is a unit. "Centimeter" and "meter" in this context are just arbitrary labels. If those grid lines are indeed each a unit, then your model is 100 times too big. The exporter will often work anyway. It's generally pretty good at figuring out the maximum size of a model, and calling that "one", and then going from there for the rest of the vertices. But it doesn't always work out that way. For the most predictable outcome, keep all vertices within a ten-unit sphere (five-unit radius) at all times. Second, in addition to the lossless upload, did you remember to freeze & reset transformations, and delete history before you exported your sculpt map? Failure to do one or all of those things is the most common reason for "lumpy" sculpties.

Here's a really simple overview of one method of creating that kind of hammer-patterned look. This is assuming you've already created your base metal texture. 1. Duplicate the base metal layer. Make sure the duplicate is above the original in the layer stack. 2. Give the duplicate layer a mask, and make the mask black with white polka dots. There are any number of filters you could apply to generate the polka dots, or you could just use a white paint brush, and click-click-click away. 3. Apply bevel effect to the duplicate layer. Set the structure direction to down instead of up, and it will look like the polka dot areas are recessed into the metal.

When you say the eyes are huge, I assume you're referring to the fact that the irises you've got there are almost twice the size of RL human irises, in proportion to the rest of the eye. In a real eye, the diameter of the iris is roughly 1/3 the width of the eye slit. In your screenshot, the irises are about 60% of the width of the eye slits. The easy solution, logical solution is simply to reduce the size of the iris area on your template by about 40-45% of its present size. That would bring it into normal human proportions. Unfortunately however, if you do that, ypu'll find that the irises look like little more than beady little dots in the middle of a sea of white. This is because the avatar eye isn't (usually) shaped like a real human eye. On most avatars, the eye slit is grossly out of proportion, in terms of its opening vs. its width, and the degree to which it wraps around the eyeball. Furthermore, most avatars' eyes are way too big in proportion to the whole face. For whatever reason, people tend to overemphasize the eyes when designing face shapes, resulting in eyes that are too large, and too close together. Your screenshot is a perfect example of this. On a real face, the eyes are almost exactly 20% of the width of the head. There's enough room to fit a third eye in between, as well as a fourth and fifth on either side. The eyes in your picture, however, are closer to 29% of width of the head, which means they're almost 50% wider than they should be. The result is eyes that appear to be too close together, and temporal bones that appear to be way too narrow. The whole face looks like it's been squished in a vice, when compared to the eyes' widths. Granted, part of this is due to camera distortion from zooming in. The image looks a bit fisheyed. But still, even if you were to straighten that out, I'd be willing to be the eyes would still be too big. 99.99% of avatar eyes are. That's not necessarily a bad thing, by the way. So don't get too bent out of shape over it. These kinds of proportional "mistakes" are so common, they've become the norm, the accepted aesthetic of SL. Avatars don't look like real people; they look like avatars. It's a cartoon-like styling. If you want to, you could easily shirnk those irises. But you'll have to experiment to find what you consider to be the happy medium between realistic intr-eye proportion, and acceptable looking proportion with respect to the face as a whole. My biggest problems with the eyes you've created have nothing to do with the proportions. If you want my critique, here's what I'd say. First, the irises look like circles with stripes converging toward the center (because that's what they are), which is not how real irises look. Take a good look at a real iris, and you'll see that it's not really made of up of converging stripes. It's actually built more like a carpet, with what appear to be millions of little twisty hair-like structures. They do all converge toward the pupil, but they don't do it so linearly as what you've got there. There's a lot more noise in the pattern, if you know what I mean The lines you've got are way too straight. Second, the lines are far wider than they should be in most places. In some areas, there's they are so overly wide (primarily in the upper right quadrant) that it looks like the person has some sort of bruising of the iris, or other ocular malady going on. No real person has wedges of black or wide stripes of blue in their irises like that. Third, you don't have any veins in the whites. Nobody's eyes are pure white. There are always red veins. I'd suggest you ditch the tutorial you used, and give this one a whirl: http://www.3dtotal.com/team/Tutorials/antro_eye2/antro_eyetex_01.php (or any of the literally hundreds of thousands of good Photoshop eye tutorials that are all over the web). You'll have to adjust the proportions to make it all fit the SL eyeball, of course, but that's hardly a big deal. Also, the author suggests starting with a 1000x1000px canvas. Change that to 1024x1024. Downsize to 256x256 before upload, of course, since that's the size the texture will end up at when applied to the avatar.

I'm really not familar with Animation Master, but I just took a look at their demo video, and it seems to have an impressive feature set, for its price tag. My best guesss as to what might be going wrong are either you didn't create your model with sculpty-compatible topology and UV'ing, or else Blender simply isn't interpreting things the same way that Animation Master is. If it's the latter, it MIGHT be the result of using the 3DS format as a go-between, or it might just be a more fundamental incompatibility between the two programs. If it's the former, then you'll need to read up on how sculpties actually work. Source models for sculpties have to be made in very specific, very limited, way. Just any old arbitrary model won't work. One thing I did notice in the video is that Animation Master's modeling pipeline appears to be entirely spline-based. If that's the case, then it's possible the models are coming into Blender as NURBS surfaces, rather than as polygons. If that's what's going on, then you might need to convert to polygons in Blender before you can generate a sculpt map. As I said, I really don't know much about Animation Master, so I'm just guessing here. I hope it helps. I'd recommend you take another stab at learning Blender. If you haven't done so already, watch the Machinimatrix video tutorials. They're fantastic. They present Blender in a manner that makes it easy and fun to learn. It's really ground-breaking stuff, since Blender's documentation has traditionally been so dry and hard to follow. I used to think Blender was a good program, suffering from a really bad interface, and that it was that bad interface that made the program hard to use. But now, thanks to Gaia Clary and the Machinimatrix team, I see that Blender is a good program with actually a pretty decent interface that just happens to have been really poorly explained for a good 99% of its time on Earth. Maya's still my program of choice, so I can hardly say I'm in love with Blender now, but at least I know it's not such a bitch to use as I'd always thought. Watch those videos, and I'm sure you'll reach the same conclusion.

Oromis Dragovar wrote: Hello all. I started using Maya recently and actually I'm having a problems... Let me stop you right there. If I'm misinterpreting you, forgive me, but it sounds like this is your first foray into using Maya. If that's indeed the case, then please take this first response to heart. I'll answer the specific question you asked, since we're here, but before I do, let me help you a whole lot more by offering you some good, solid advice, gained from many years of experience in both doing and teaching this material. If you're brand new to Maya, forget all about sculpties for now. Don't even attempt them until after you've spent some time learning the basics of Maya itself first. I know that's not what you want to hear, but let me explain. It is nearly always a recipe for disaster whenever anyone approaches Maya with "I want to make _______" in mind, No matter what the blank happens to be, the end result is always the same, frustration. It's not that learning Maya is hard. Quite the opposite, in fact. It's actually one of the easiest programs to learn in existence on this planet. But the information has to be absorbed in the right order, or it just doesn't work. The basic fundamentals have to be there first, or nothing else makes much sense. I tell people this all the time. If you try to put the cart before the horse, you will inevitably experience nothing but frustration after frustration, after frustration, and you won't know why. Today, you happen to be experiencing a simple misunderstanding about what a NURBS cube really is (one of those basic fundamentals I just mentioned). Tomorrow it'll be something else. And then something else, and something else, and something else... Keep that going, and six months from now, you'll be barely any further along than you are now, because you will have spent five and half months worth of that time trying to problem-solve at every turn, rather than actually getting anything done. Again, without the fundamentals in place, the whole thing doesn't work. Trust me; I've seen it a thousand times. Some people are tempted to respond with, "I'm smart. I'll figure it out as I go. Now let me just make my _______, and be on my way." But the reality is the question of how smart or capable you may be is beside the point. This simply isn't the way to learn Maya, period. The way that absolutely works every single time, for every single new user, at all capability levels, is to learn Maya itself first, and then apply that knowledge to making whatever you want, be it sculpties or anything else. So, as I said, forget all about sculpties for the next few weeks, and instead spend that time diving into Maya's basics. The way every single proficiient user of Maya has ever done it, from hobbyists to high end professionals, starts is by going through all the Getting Started tutorials in the help file. And I do mean ALL of them. Don't skip over any, don't go out of order. Even if you don't (yet) see how a particular tutorial relates to what you (think you) want to know, do it anyway. Trust me; it's all relevant, and it's all critical need-to-know information. You see, unlike with most other programs, Maya's help file is actually helpful. A sizable portion of the $3500 price tag of Maya goes to pay for that help file. It is quite simply THE best included help of any program I've ever seen. There is absolutely no better way to get started with Maya than to use those tutorials. Even 3D graphics majors at universities and high end trade schools, who pay thousands of dollars for professional instruction in Maya, are expected to do those Getting Started tutorials before they do anything else at all. You paid several hundred dollars for that help file. Don't waste that money. Use it. After you've been through all the tutorials, you'll find that everything you need to do in order to make sculpties (or anything else) will almost automatically make sense to you. You'll still have more to learn, of course, but you'll have a really solid mastery of the basics of the program. From there, you'll be able to branch out into any specialty you want, with relative ease, sculpty modeling included. So you know, in the very beginning, sculpties in particular are especially problematic for the new user. Sculpties are just plain weird. They're entirely unique to SL, and the way we work with them is almost completely bass ackwards from how we work when creating any other kind of models. Bottom line: making sculpties won't teach you much about Maya, or about 3D modeling in general. But learning Maya, and learning the basics of 3D modeling, will absolutely teach you to make sculpties. I hope that makes sense. Once you've got a good handle on the basics of Maya (which will happen sooner than you might think, via those tutorials), you'll find that sculpties will be almost absurdly easy for you to make. But in the here and now, if you keep focusing on sculpties themselves, you'll unfortunately find that learning Maya will be extremely difficult, and it will only continue to get harder as you keep going from that direction. So, at the risk of beating this into the ground, I'll say one more time, the best thing you can do for yourself right now is put the sculpties on hold, and spend the next couple of weeks diving into those Getting Started tutorials. Think of it is a temporary step back, in order to make a giant leap forward. Sculpties will be here waiting for you when you're done. Also, I should mention, the tutorials are fun. So don't feel like this is going to be a chore. Learning Maya is a highly enjoyable process. Have a good time with it. That said, if I did indeed misinterpret, and you're already proficient with Maya's basics, then feel free to ignore all of the above, and read on. Oromis Dragovar wrote: Hello all. I get this error if I select the object using the button "select by hierarchy and combinations", The sculpty exporter doesn't understand heirarchy or combinations. It's not designed for that. The error is triggered because you haven't selected the actual surface(s) you want to generate sculpt maps from. You've only selected a data node that references the object(s). You can't make a sculpty out of that little data node. It's not something that has any shape in 3D space. It's little more than a piece of text. You can only make a sculpty from an actual surface, something that has a geometric shape to it. Make sense? Oromis Dragovar wrote: I started creating a NURBS cube This is a really common "rookie mistake". As Avaline said, the NURBS cube isn't a real primitive. It's just six planes. If you really want to make your SL object from six individual sculpties, then you could use the NURBS cube, no problem. But I doubt that that's actually what you want to do. The way to make a sculpty "cube" is to deform a sphere into the shape of cuboid. This is virtualy the same thing you'd do if you were making a polygon-based sculpty cube in Blender or any other program, by the way. You don't start with a poly cube in those programs either, as poly cubes do not have sculpty-compatible topology and UV layout. You start with a sphere or cylinder, and then you deform that into the shape of cube. Here's an example of how a NURBS sphere can morph into a cuboid: And here are instructions (which I've posted MANY times on the forums), for how to do it: 1. Rez a 16x16 NURBS sphere. 2. Select all the control vertices along a longitudinal hull, except for the the points at the poles and the one at the equator. This is most quickly done in top view. First, select the hull itself. Then ctrl-drag over the pole to deselect both poles at once, and then ctrl-click the equatorial CV to deselect it as well. 3. In your Move tool settings, disable Retain Component Spacing. Then snap all the selected CV's into alignment with the equatorial CV you just deselected a second ago. To snap to vertices, either click the button toward the top of the screen that looks like a horseshoe magnet with a little dot near it, or hold down the hotkey V while you're moving things around. (Note, when snapping, move along just one axis at a time, by dragging on one of the arrow-shaped control handles on the manipulator. Do not drag from the center circle of the manipulator, or you'll snap on all three axes at once, collapsing your selection to a single point. The result you want here is columns, not points.) 4. If you did the above steps correctly, you've now got a capped cylinder, the center shape shown in the above image. You might be wondering why you didn't transition through that pill shape shown in between the sphere and the cylinder. That's just because it's an unnecessary transition. I only included it in the image in case anyone doesn't read the directions. I think it helps visually demonstrate how a sphere could morph into a cylinder. If you really want to make that shape, just select less CV's along each hull before snapping them into place. The less CV's you snap into columns, the more dome-like the caps on each end of the cylinder will be. Snap them all, and you get a cylinder. Snap none, and you've got a sphere (duh). Snap any amount in between, and you get a pill. 5. To bigin turning the cylinder into a cube, simply snap the columns of CV's to the grid. To snap to grid, either click the button at the top of the screen that looks like a horshoe magnet next to a grid, or hold down the hotkey X as you move things around. 6. If you did all of the above correctly, you should now have a shape that looks like the second one from the right in the picture. It's almost a cube, but it still lacks sharp vertical corners. To make the corners sharp, simply move the columns of vertices that are near the corners closer together You should have three columns at each corner. The closer you move any three together, the sharper each corner will be. For a razor edge, snap them together. For a more rounded (and frankly more believable) look, leave a little space. 7. If you've done everything right so far, your shape should now look very similar to the cube on the far right in the picture. There are just a couple of last tweaks to do. First, you'll want to flatten out the top and bottom. Since the starting shape was a sphere, the distance from pole to pole is slightly taller than the distance from the uppermost longitudinal hull to the lowermost one. So, grab the that uppermost hull, and snap it into alignment with the north pole. Likewise, snap the lowermost hull into alignment with the south pole. 8. You're almost done. The final step is to make the top and bottom edges have the same degree of roundness as the vertical edges. Again, you want three groups of hulls to form the corner. I'll assume you left a little bit of a round-over, just as I did for the cube in the picture. (After all, totally sharp edges do not exist in RL. If you're gonna go that route, you might as well use regular prims. The whole point of sculpties is to make things that are more natural looking.) In your Move Tool settings, enable mirroring on the Y axis (assuming your Maya scene orientation is Y-up). Grab the uppermost hull, and scale it down a little, bringing all its CV's just a little bit toward the center. Grab the next hull down, and snap it up into vertical alignment with the first one. Finally, grab the third hull down, and move it upward to be close to the second one, so that all three hulls are about equidistant from each other. The distance between them should be roughly the same as the distance between the three columns at each vertical edge.r If you did everything right, your cube should look just like mine. Now just scale it to the right size to fit your clip, and then bend it to its final shape. For the bending, you can either rotate the hulls by hand, or you can apply a simple bend deformer. Either way, remember to delete history, freeze and reset transformations, and then delete history again, before exporting your sculpt map. This may all seem like an enormous amount of work, all written out like this. But that's only because describing it is much harder than actually doing it. Really, it only takes a minute. Plus, you only have to do it once. Save a copy of the cuboid, and then just reload it every time you need to make something based on it. Oromis Dragovar wrote: 32x31 (U patches: 32 and V patches: 31) . The best number of sections and spans to use is 16x16 (for a non-oblong sculpty). Technically, you can have as many or as few as you want, but things can get confusing fast if you have too many or too few. Generally speaking, you want one section/span in Maya for every two quads the in-world sculpty is going to have. All (non-oblong) sculpties have 32x32 quads in them, so 16x16 sections/spans is ideal.

Eidolon Aeon wrote: The texture I am using is a crushed velvet 512 x 512. I definitely get your point, Chosen, about not always needing to see perfect detail, but in this case, I was losing even the suggestion of what it was. I woke up this morning realizing I'd need to stretch the highlighting/shading over a vertically doubled texture (looks almost as good at 2/1 as at 2.5/1) rather than squishing the texture down, exactly as you mentioned. It worked beautifully. I rarely go above 512 with any of my texturing (except to combine smaller textures into one conglomerate), but in this case, 512 x 1024 was the thing that worked. Many thanks for the extra tips and suggestions. I'm glad you got it to work out, Eidolon. Since you mentioned crushed velvet, here's an easy way to simulate it in Photoshop, in about 10 seconds: 1. Create a new image, RGB any size you want (preferably a power of two). 2. Set your foreground and background colors to two different shades of the same basic color (light red and dark red, or light blue and dark blue, or light gray and dark gray, etc.). 3. Filter -> Render -> Clouds 4. Filter -> Noise -> Add Noise. If your image is fairly large (512x512 or so), then set the amount to a low number, like 5% or so. If it's a smaller image, increase the amount a bit. In any case, set the distribution to uniform, and check the box for monochromatic 5. Fiter -> Artistic -> Sponge. Set the brush size to zero, the definition to 1, and the smoothness to 1. 6. Duplicate the layer, and click Filter -> Stylize -> Glowing Edges. Set the edge width to a low number, like 2, the edge brightness to a high number, like 18, and the smoothness to a mid-low number, like 4. 7. Make sure the layer you just applied to glowing edges to is above the other one in the layer stack. Then set the upper layer's blending mode to Overlay. This will serve to greatly increase the contrast of the layer below, providing the kinds of highlights that crushed velvet so often has. If you feel the effect is too strong, lower the opacity of the overlay layer. There you go, a passable crushed velvet base texture in mere seconds. It won't be super realistic just yet of course. That's where your shading comes in. This is just a base for the diffuse coloring. If the base doesn't look quite how you want it, try again, but play around with settings on the filters. You may also want to adjust the levels, to increase or decrease the contrast, and/or adjust the hue/saturation to alter the coloring. Alternatively, you can always just photograph or scan a real piece of crushed velvet, of course.

Josh Susanto wrote: Wasn't SL at some point doing 384 and 768? Nope. I actually made the same mistake of thinking that, myself, several years ago. I can't remember why I thought it was true, but I ended up incorrectly arguing the case right here on the forums. After someone suggested I go in and take a look at the actual texel dimensions in-world, I then came back and posted about how wrong I'd been. A friendly Linden even joined the thread (which should tell you how long ago this actually was, since Lindens don't generally do that anymore), to confirm that at no time had SL ever had the capability for non-power-of-two textures. The reason for the power-of-two restriction, by the way, is that it used to be a requirement within OpenGL. From what I understand, modern versions of OpenGL can now support arbitrary sizes, but not all graphics cards are OK with it. Some crash instantly upon encountering "odd" sized textures, in fact. Therefore, most OpenGL applications, SL included, still maintain the restriction. Josh Susanto wrote: It seems to me that is was when I was still using Emerald, at least. I've never used Emerald, so I can't speak intelligently on it. My guess is that if it did allow it, it was probably just for temporary images. Technically, one could hack a viewer to handle arbitrary sizes, if one were so inclined. But I would hope there are server side safeguards in place to prevent upload of non-power-of-two images, since "normal" viewers might crash upon trying to display them. And some hardware configurations certainly would crash, even if the viewer itself were OK with it. Josh Susanto wrote: In principle, images with prime numbers of pixels on each side should distort the most... correct? I can see why one might make that assumption, but I'm not sure it's actually true. Perhaps someone with a better understanding of the actual algorithms involved could chime in with a definitive answer, but in the mean time, allow me to theorize for a few moments. It's easy as a human, who's used to thinking of everything in terms of decimals, to assume that prime numbers would probably be the worst candidates for resizing cleanly to powers of two (or to any other numbers besides themselves). But in practice, I don't know that scaling 521 down to 512 is going to look any worse than scaling 520 or 522 to 512. None of those numbers can resolve cleanly into 512, or into 256, or into any othe power of two. Massive re-interpolation of the image is likely going to have to take place, in all three cases. It's equally easy, as a (non-computer-scientist) human, to assume that something like 768 might divide very easily into 512. But agan, in practice, it might not actually be true. As a human, removing a third is an easy concept to deal with, certainly much easier than removing, say, nine 512ths. But again, that kind of thinking doesn't necessarily speak to how the math is actually done. Computers don't conceptualize like people do. Here's something to think about. For the sake of argument, imagine the math were to be done decimally, Thirds would then be a nightmare to deal with. After all, a third, by definition, has an infinite repeat in decimal math, and computers don't tend to deal very well with infinity. (Just ask Redjac from Star Trek!) There's going to have to be a round somewhere, and with rounds come artifacts, always. Now, I highly doubt that decimals play a role at all in what really happens, so please no one get too caught up in arguing about that specific exmaple. My point is simply that many of the concepts we humans think of as simple and clean can very quickly become quite complicated and messy when you try to apply various mathematical models to them. If even the most familiar of mathematics (decimals) can get thrown for a loop by a concept as simple as a third, imagine how convoluted things could get when you factor in the far more complex math that computers actually do use for these kinds of operations. With that in mind, how do prime numbers stack up against any other type? I'm afraid I'm not qualified to answer that question for sure. In the absence of more definitive information, the best I can say for now is this: "It doesn't matter anyway, so quit making my brain hurt! You're gonna use powers of two, young man, and you're gonna like it. Them's the rules." (And I mean that in the nices possible way. )

Heh, thanks Void, for the beating. I did in fact use paragraphs, as always. But for some reason, the forum didn't preserve them the first time I posted. So, I had to go through and re-break the paragraphs on edit, and then it worked. Gotta love new software, huh? Hopefully whatever happened was just a one-time glitch. If it keeps happening, that's gonna get really annoying really fast.

Care to post one of your textures, so we can see what's going on with it? Ican think of two possible reasons for the problem you described, plus an aside reason, not directly related to texturing. I'll take them one at a time: The first possibility would be if the texture were already maxed out on pixels (1024x1024), and you absolutely need every single one of those pixels in order to communicate the message of the imagery. This is VERY rarely the case, though. It's not often you need to go bigger than 512x512 for anything, sculpties included. 256x256 is usually plenty. The answer in this case, obviously, would be just to use a less detailed texture, which would be better suited to survive the downsizing process. In most cases, this won't be a problem at all. The circumstances in which a texture unequivocally needs so much detail that it actually requires a 1024x1024 are so rare, I could probably count all the times I've ever encountered that situation on one hand. Remember, success in creating good content for real-time 3D applications, especially for SL, is NOT about packing as much detail as possible into your textures. What it IS about is striking the right balance between visual quality and performance requirements, always. Think about this. In RL, does one need to be able to see every grain of sand on a beach to know that it is in fact a beach? Must one examine every last stitch on a piece of fabric to realize that fabric is indeed what it is? No, obviously not. Well, it's really no different in the simulated world. So, don't make the mistake of getting so caught up in trying to preserve every single detail that you never get to see the forest through the trees. Focus instead on getting the message across in the most practical way you can. The second possibility would be if your texture were already a good small size, but then by reducing it to 40%, you end up making it so small that it's no longer well recognizable. 40% of 256, for example, is only 102 pixels, which is not a lot. In this case, instead of donwsizing the existing texture, the answer is to upsize the canvas, and repeat the full-size texture across it. If you're starting with a 256x256, then upping the canvas size to 512x512 will give you four repeats at full magnification. If you want 2.5 repeats in each direction, then you only have to scale the source image down by 20% instead of 40%, which will likely look much better. And of course, if you were to take the canvas all the way up to 1024x1024, then you would have up to 16 repeats at full magnification to play with (but again, it's unlikely you'd need to do that). The third possibility, which as I said, does not directly relate to texturing itself, is that your sculpty may be inefficiently designed. If that's the case, then you may be wasting a significant portion of your texture canvas. A well modeled sculpty, created with texture efficiency in mind, will have as much polygonal area as possible exposed, with very few, if any, polygons locked away into crevices, corners, or hidden areas. Remember, you've got 32x32 quads to work with on every (non-oblong) sculpty. Make them count. You want as many of those as are exposed as possible, always. Granted, that's not always easy when you consider the tricks we have to pull in order to "LOD-proof" a sculpty. But still, considerable attention should always be given toward making every sculpty as geometrically efficient, and as a direct result, as texture-effiecint, as possible. For example, say you're making a couch cushion. The inefficient way to do that would be to make it from a sphere or a cylinder, in which case it's likley that half the polygons, or more, would end up facing the interior of the couch, instead of facing outward where they can be seen. In that case, you'd be wasting at least half your texture resolution, right along with those hidden polygons. The efficient way to make the cushion would be to use a plane, so that no part of the sculpty needs to be hidden. Remember, unlike in RL, the cushion in SL doesn't need an underside, or a back side. It just needs a top side, a front side, and maybe a left and/or right side. That's it. By not including the hidden parts in the sculpty geometry, you effectively double the texture resolution on the parts that are visible, with the same size texture. Make sense? And and even more effiecient way to go might be to make three adjacent cushions from a single oblong plane, instead of one individual cushion from a single non-oblong. Keep your mind focused on optimization as you work, and these possiblities will constantly reveal themselves. All of this is speaking very generally, of course. We can't really tell what's going on with the specific textures you're working with, unless we can see them. Post some images, and we can talk a little more intelligently.

Josh Susanto wrote: ...768 ..384... Just to be clear, so nobody gets confused, 768 and 384 are not directly usable texture sizes. Only powers of two can be utilized in SL. If you upload a 768, SL will downsize it to 512, and if you upload a 384, SL will downsize it to 256, the nearest power of two down in each case. 1.5 times a power of two is not a power of two. Photoshop, and other similar programs will almost always do a better job of resizing imagery than the SL uploader will. For best results, ALWAYS size your images properly to a power of two, prior to upload. I never ever want to just let SL "squish pixels into each other". I want to control how my textures turn out.

Eidolon Aeon wrote: I am curious about what I'd read some time ago: that using four 512's combined in a 1024 (as an example) makes for quicker loading because there is only one texture to read, rather than four. Is this accurate? Yes, and no. The yes part is that if you have four 512x512's combined on a single 1024x1024 canvas, you'll cut down on network load, because you only have to request one asset instead of four. This may or may not translate to faster load time, though, since there's usually no particular rhyme or reason to the order in which things load. The only thing guaranteed is that when all four panels are part of the same texture, then all four will load at the same time as each other (since they're really all just one). If the 1024 happens to be the first thing to load in the scene, then all four of its 512x512 panels will rez right away. But if the 1024 happens to be the last thing to load, then those four panels will all seem to load slowly. The no part is that it doesn't actually have to do with "reading the texture", in the sense that you were probably thinking. The main benefit, again, is cutting down on network overhead. That doesn't really speak to how the graphical data is "read" after the image file has been downloaded. Bottom line, it's generally best practice to combine textures wherever and whenever you can. Say you've got eight different 256x256 textures, and two 512x512's that are all going to be in the same build. In that case, it makes sense to put all of them onto a single 1024x1024. One asset is way more efficient than ten. But there are cases in which it might be best to keep them separated. If you want to be able to swap textures in and out with relative ease, or if you need a texture to be able to repeat more than once across a surface, then having everything combined could be problematic. So, as with anything else, weigh all the options, and make the best decision you can for each case.

I'll second Torley's recommendation for FilterForge. It's a wonderful program, well worth the investment, especially considering that it's available at three different price points ($149, $249, or $399), depending on what features you want/need. Even the pro version isn't terribly expensive, as graphics software goes. However, the recommendation comes with a couple of caveats: First, be aware that FilterForge has no editing or painting tools of its own. It's not a full fledged texturing tool. In most cases, it will give you a great starting point for a texture, not a completed texture in and of itself. So, be prepared to use it in conjunction with Photoshop or an equivalent image editor/paint program. Second, realize that most, if not all, of the existing filters on the site are in very widespread use, which means you could easily end up making an image that is 100% identical to other images made by thousands of other FilterForge users. So again, undestand that FilterForge is meant to be used in combination with other programs, not just by itself. Any images you make with it should almost always be further refined in Photoshop (or whatever your image editor of choice happens to be) afterward, to add uniqueness. As for the question of how to make a seamless texture by hand, there are about a thousand ways to go about it., of course, but here's one of the simplest methods, using Photoshop: 1. Create or open an image file. 2. Click Filter -> Other -> Offset, and offset the image by half its height and width. The edges of the image will now be in the middle, so you can see how they butt up against each other. 3. Use the clone stamp, healing brush, or spot healing brush to blend out the seams. Depending on the complexity of the image, the blending should take you anywhere from just a few seconds to a several minutes. Either way, it's pretty quick, and relatively painless.

Ah, thanks, Paladin. I feel better now. Lindens, I've got no other complaints so far about this new setup. I'm sure I'll discover a headache or two as I use it more, and I'll let you know when I do, but as of now it's all good. Nice job, guys. Thanks for having this feedback thread, by the way.

I'll second Henry's comment. The inability to edit posts is a showstopper. We MUST be able to correct mistakes, reword things better after a retrospective read-through, etc. Without that ability, the forums as an educational medium, or even a meaningful discussion medium, are almost useless. Please fix this ASAP!

Here's a copy of the guide I wrote on texture memory, file formats, texture sizes, and how to choose the right size for the job, which was stickied at the top of the old 1.0 forums, and which was subsequently published in in Brian White's book, "Second Life: A Guide to Your Virtual World". There doesn't seem to be a link to access that old archive anymore -- the current forum archive only seems to show stuff from the last version of the forums, not the one before that -- so I figured I'd repost it here. There's obviously a lot more to say about optimization than just this, but the information in this post is THE place to start. In order to be able to optimize at all, you have to know a bit about how image size and bit depth affect performance. This post provides a nice, easy overview of the concepts involved. It's a must-read for any budding texture artist. File Size vs. Texture Memory It's not uncommon for those new to texturing to assume they should use highly compressed formats like JPEG out of the mistaken belief that keeping file sizes small will increase performance. People usually come by this presumption as a result of every day experiences using the internet, where it's easy to see that web pages load faster with smaller image files than with larger ones. For the novice, the expectation that this same behavior would apply equally to graphics applications is logical, but it's incorrect. In truth, this perceived correlation between file size and speed on the web is merely an illusion, which has nothing to do with graphics processing. Where the internet is concerned, speed is primarily determined by the rate at which files can be sent from computer to computer. Since smaller files have less information to deliver, of course they get delivered faster. The speed at which graphical images are processed on screen actually has nothing whatsoever to do with file size. Graphics processing is all about texture memory, not about storage space. Texture memory is always determined by the amount and depth of the actual pixels in the image, not the bits and bytes in which the file is stored. While any given image’s file size can vary depending on in what format it is saved, its actual texture memory consumption will always be the same. The amount of pixels in an image times the number of bits in each pixel will always equal the amount of texture memory the image uses, no matter what. Why that's important to the SL texture artist is pretty simple. Knowing the rudimentary mathematical principles of how images affect performance enables you to optimize your textures so you can ensure your creations are as lag free as possible while also being as high in quality as they can be. The key to success in any real time graphics application is always finding the right balance between detail and speed. Make your textures too big, and you use too much memory, slowing down your frame rate (and everyone else's). Make them too small, and while your system performance will be relatively good, your imagery might look terrible. File size is not part of the equation when thinking in this context. What's relevant to performance and visual quality are the actual images, not the files that store them on hard drives. Graphics performance is affected not at all by file size, but by texture memory consumption. Texture memory is determined by the amount of pixels that make up each image, and the amount of memory bits in each pixel. That's it. For more on bits per pixel, see the Transparency Guide, stickied at the top of the Second Life Texturing Tips forum. How to Calculate Texture Memory Determining how much texture memory an image will consume is fairly straight forward. It's basically a count of the total amount of pixels in the image, multiplied by the number of bits in each pixel. RGB color images without transparency have 24 bits per pixel, and those with transparency have 32 bits per pixel (see the Transparency Guide for more on this). So, for example, if you've got a non-transparent color image that is 1024x1024 pixels, here's how the math would break down: 1024x1024 = 1,048,576 total pixels 1,048,576 x 24 bits in each pixel = 25,165,824 total bits in the image 25,165,824 bits / 8 bits in every byte = 3,125,728 bytes, or precisely 3 megabytes Pretty simple math. A 1024x1024 image (sans transparency) will always use exactly 3 megabytes of texture memory. That's regardless of whether or not the file is compressed for storage. As far as the graphics card is concerned, an image is just a collection of pixels to be drawn, not a file to be saved. Just for informational purposes, here's a quick breakdown of all the texture sizes SL allows, and their corresponding texture memory requirements: Notice how much memory the larger textures demand. It doesn't take all that many to overwhelm a 256MB or 128MB video card. The biggest reason SL operates as slowly as it does is because of poor texture management on the part of resident content creators. Many people use textures that are simply way too big, and as a result, video cards choke. The average video card can only process a few hundred megabytes worth of textures at a time. Professional game artists are well aware of this, and so they make sure to optimize all their textures to keep them as small as possible. SL, as a mostly amateur-created environment does not tend to benefit from the same professional wisdom, and as a result, an average busy scene in SL can have literally gigabytes worth of textures on display. Obviously, that's not a formula for effective real time performance. For everyone's sake, always keep all textures as small as they can be. I usually suggest as a rule of thumb that about 80% of textures should be 256x256 or smaller, about 15% should be 512x512, and about 5% should be 1024x1024. SL is extremely good at displaying small textures on objects at full screen size, better than just about any other program I've ever seen, in fact. It's not often that there's a legitimate reason to go much larger than 256x256. Choosing the Best Texture Size For the Job The two most important factors in determining what size to make a texture is to think about how much screen real estate that texture is likely to occupy, and how much fine detail does it really need relative to its size. For example, if you're doing a life size replica of the Sistine Chapel, with giant ceiling murals that are likely to fill the entire screen, and with lots of fine details that people are likely to zoom in on and study, go with 1024's by all means. However, for the parts that aren't likely to fill much of the screen, like your little donation box next to the front door that no one's gonna look at, use something MUCH smaller. Of course, just because something will fill the screen doesn't automatically mean it demands a large texture. A brick wall, for example, is just a repeating pattern. The pattern itself doesn't need to be very big to be effective. You could paint just a few bricks in exquisite detail at maybe 128x128, and then repeat the texture across the wall surface many times via the repeat and offset settings inside SL. If the wall needs other details embedded into it like windows, doorways, creeping vines, etc, then it's no longer just a repeating pattern; it's a whole painting. In that case, you'll need to go larger with the texture to fit all those things in. What you want to avoid is doing things like slapping a 1024x1024 on a little 2-word sign that no one's ever gonna zoom in on. For that, something as small as a 64x64 would probably be plenty. Always make every texture only as large as it needs to be, not one pixel more. Again, it's all about finding the optimum balance between texture memory and texture detail. That means using good, sound judgment. Choose your texture sizes carefully. Make appropriate decisions. Usable Source File Formats For SL Textures SL allows you to use any of three different image formats as your source files for uploading, TGA, BMP, and JPEG. Here's a bit of brief info on all three: TGA - TARGA File Format Advantages: High quality Entirely lossless Supports transparency Entirely predictable file size Simple bitmap formatting is easy for all computers to read Industry standard format for textures, also used extensively in video applications Disadvantages: Large file size Not readable by low-end graphics programs or by programs not intended for serious graphics work (you can't view a TGA in Windows Picture Viewer, for example) Not well suited for printing History: Invented in 1984 by Truevision for TARGA graphics cards Upgraded to its current version in 1989 Stand for Truevision Advanced Raster Graphics Adapter Was the first file format to support truecolor on IBM compatible PC's BMP - Windows Bitmap Format Advantages: High quality Entirely lossless Entirely predictable file size Simple bitmap formatting is easy for all computers to read Disadvantages: Large file size Does not support transparency Not well suited for printing Not a common format of choice in the graphics industry History: Developed in the 1980's by Microsoft as an image standard for the Windows operating system Today, it's used for simple things like desktop wallpaper images, not much else JPEG - Joint Photographic Expert Group Format Advantages: Small file size Viewable in almost all programs Disadvantages: Lossy compression Image quality degrades every time it's saved Does not support transparency Not well suited for printing History: Invented by the Joint Photographic Experts Group in 1986 Today, it's the most commonly used image format on the web, the last place where file size is still more important than image quality. It's also commonly used in digital cameras, but that's changing fast. PNG – Portable Network Graphics Format Advantages: Small file size Lossless compression Supports transparency Disadvantages: While arguably superior, PNG is not as widely supported as JPEG or GIF Not well suited for printing History: Invented in 1995 Originally intended as an no-license-needed, visually superior alternative to GIF PNG is sometimes interpreted to stand for the recursive “PNG’s not GIF” Note, when you upload an image to SL, it gets stored on the server in JPEG2000 format, an optionally lossless type of compressed file. Your original source image file never actually leaves your own hard drive. When you hit the Upload button, SL makes a JPEG2000 copy of your image, and it is that copy that gets uploaded. I won't bother posting much information about JPEG2000 itself, since SL's implementation of it is outside our control as users. If you're curious, you can read all about it at http://www.jpeg.org/jpeg2000/index. For best results in SL, I recommend always using TGA as your source file format. It's long been an industry standard for texturing and other on-screen graphics work.. I recommend not using JPEG ever for texturing. It's great for web pages, but it's not well suited for 3D work. Since the SL servers will store your images as JPEG2000 anyway, there's no need to be concerned about file size, which nullifies JPEG's one and only real advantage, leaving you with nothing but all the disadvantages. It's a lossy, low quality format. Also, since SL's implementation of JPEG2000 is a bit lossy, using a JPEG as your source image just compounds the problem. When you source your upload from a lossless TGA, you only compress once, and only lose quality once. When you source from a lossy JPEG, you compress twice, and lose quality twice. It's akin to the "copy of a copy" effect. If you're a web designer, use JPEG all day long, by all means, but if you're a 3D texture artist, steer clear of it. For texturing work, like I always say, use TGA, every day, TGA all the way.

Nice work so far, guys. Looks like there's a lot of potential here for simple, straight forward, low-barrier, entry into SL. It seems to work quite well as a very basic viewer. I only found two major annoyances: First, load times were atrocious for me. It took several minutes for my avatar's hair to appear. I attended a concert, and the stage didn't appear until about 10 seconds before the end of the last song. Until then, I thought the singer and the dancers, were just performing in mid air the whole time. Not everyone seems to be reporting such slow load times, though, so maybe it was just a temporary glitch or something. Second, and this one was much worse, there doesn't seem to be any way to adjust the volume, or mute parcel media streams, without muting everything. If you hate the music on a parcel, but you want to hear other things, you're out of luck. I'd suggest addressing this ASAP if you guys want widespread adoption of this. I'd imagine nothing will turn people away faster than being forced to listen to music they don't like. Other than that, it was a pleasant experience. Keep up the good work. Can't wait to see how this progresses.