Chosen Few

Your computer is up to snuff, hardware-wise. I'd still recommend updating your graphics drivers, if you haven't done so recently (or even if you have). When I asked about your 3D settings, I was referring to the in-document render settings. Sorry if I was unclear. To access what I'm talking about, click 3D -> Render settings, in the main menu bar.

It looks like a contrast problem, not a pixelization problem. Your system isn't showing you enough shades of gray. This could be due to bad settings, or it could be a driver or hardware problem. What 3D display settings are you using in Photoshop? How new are your graphics drivers? Is your graphics card fully compatible with CS5?

Paladin Pinion wrote: How many frames could I put into an image that size without making each "cell" so small that all detail and resolution is lost? Has anyone experimented with that? There can be no singular answer to that question. Just as with any non-animated texture, how many pixels you need will be entirely dependent on what details you need the imagery to be able to show. That factor will vary with every single image you might ever make. To illustrate this, let's go with some extreme examples. As our first example, let's say you just want to animate a black square to bounce around a white canvas. The square itself could be as small as a single pixel, and the canvas could be as small as 8x8. In that case, you could fit 16,384 frames (128 frames per side) on a 1024x1024 filmstrip. To go to the opposite extreme, say you've got something with a ton of fine elements that have to be very clearly visible, like perhaps a paragraph worth of text that absolutely must remain legible. In that case, it's unlikely you'd be able to go any smaller than 256x256 per frame before the text would blur too much. That would give you just 16 frames (4 frames per side), on a 1024x1024. If it's two paragraphs, you might need 256x512, which would cut it down to 8 frames (4 horizontally x 2 vertically). As always, the only universally binding answer is this. Take a good hard look at each texture, on a case by case basis, and make appropriate, intelligent decisions, each and every time. Beyond that, there's really not much else to say, in terms of a one-size-fits-all kind of response. Now, if it helps you envision what's possible, take a look at your forum avatar portrait. It's 36x36 pixels. Obviously, that's enough to make it recognizable as a face. It's not a particularly detailed face, of course, but it is clearly a human head with a face on it. Remove 4 pixels from each side, to bring it to 32x32, and it would divide neatly into 1024. You'd (coincidentally) have 1024 frames (32 frames per side), in that case, which is a TON. If you were to up it to 128x128, you'd have sixteen times as much room for detail, and 64 frames to work with (8 frames per side). Generally speaking, that's more than enough for a compelling animation. The background image your avatar portrait is sitting on is 174x232. It's got plenty of detail in it. You could reduce it to 128x256, and it would still look quite good. On a 1024x1024 filmstrip, that would give you 32 frames (8 horizontally x 4 vertically), with a quite a bit of room for good-looking imagery. Rolig, you mentioned your example has 34 frames. That's a little bit puzzling. Was that a typo for 32? If it's really 34, how is it arranged? The only factors of 34 (besides 1 and 34) are 2 and 17. If your canvas is really 1024x512, then the only frame size that would fit those factors would be roughly 60x256 (assuming you don't just have a bunch of empty space after the final frame). That would be pretty strange, not to mention a bit sloppy looking, since there's no way to divide a power of two evenly by 17. If it's 32 frames, then each one would be 128x128, in an 8x4 configuration, or 256x64, in a 2x16 configuration. Either of those would make a heck of a lot more sense.

Void, yes, I thought it a bit overzealous of the mods, myself. I'd even made a point of including a disclaimer, jovially emphasizing that I don't work for Filter Forge, I don't own stock in the company, I'm not having mad animal sex with anyone who works there, etc., etc., etc., so I don't benefit in any way, shape, or form, if someone decides to buy their product. I just happen to like the program, and thought others here might want to know that there were some killer deals on it for a few days. But apparently, that wasn't cool. Ah well. Of course, I don't know for a fact that anyone actively deleted the post. All I know is it disappeared after just a few hours. So, it's remotely conceivable that some random software glitch catapulted it into a black hole, completely on its own. Or, perhaps it was covered up by the perpetrators of a vast alien conspiracy, deeply seated in the highest levels of government. Yeah, taht's probably it. After all, I did recently misplaced my tin foil hat. Guess I had it coming, then, right? In all seriousness, I do understand why a zero tolerance policy makes sense, if indeed that's what's been instituted. One innocent heads up about a discount today could easily become the linkomatic, compltely unusable forum of tomorrow. If you allow it for one, you have to allow it for all, and that's dangerous.

"Suspicious" might not have been the word I would have gone with, but to answer your question, Ravalgo, the reason people are reacting negatively is because you've thrice broken the forum rules. First. posting the same topic in multipe forums is not allowed. It wastes space, and more importantly, wastes everyone's time. If you're not sure which forum something belongs in, just flip a coin and pick one. Second, even though your intentions were good, advertising third party websites isn't what these forums are for. The mods used to look the other way when it was useful stuff, but since redesign, there really seems to be a zero tolerance policy. Heck. just last week, one of my threads was removed, and all I'd done was post a heads up about a discount on Filter Forge. Third, and most importantly, don't ever re-post something after moderators have deleted it. That's a formula for getting suspended or banned. It reads as brazen defiance of the rules on your part, as if you're a deliberate trouble maker, which is never a good idea. I doubt that's how you meant it, of course, but nonetheless, that is how it is likely to be interpreted by many.

Hi Winter. Some of your information isn't quite accurate. Allow me to clarify, if I may. Winter Ventura wrote: OpenGL is notoriously bad at understanding what to do when two 32-bit textures overlap. Just so you know, it's not an OpenGL issue. DirectX behaves exactly the same way. It's an inherent property of how realtime rasterization works in graphics cards. There's no such thing as being "bad at understanding" it, as far as OpenGL or any oher graphics language is concerned. Alpha sorting works exactly as it was designed to work, without exception, every single time, whether in an OpenGL environment or not. With that in mind, I would word the issue quite the opposite of how you put it: it is SL users who are notoriously bad at understanding how alpha sorting works, and who consequently, are notoriously prone to misusing it. There are only two reasons you see alpha sorting 'problems' happen in SL. First, SL's content is user-created, and most users (quite understandably) have no idea what the frell they're doing. Second, the camera has entirely free range of motion, so there's no way to predict the angles at which people might be viewing things. Further, there is only one reason you never see these kinds of problems with 32-bit textures in professionally built games. Professional game artists know how to work within and around the the issue. We either design in such a way as to make sure that 32-bit textures never overlap, or we actively take advantage of the sorting behavior, so that certain objects become much easier to construct (trees, plants, fire, chandeliers, etc.). We also make sure to use camera constraints, to ensure that users can never view a scene from such an angle that any two 32-bit textures could come into any unfortunate alignment. Winter Ventura wrote: I've found that the SL image uploader doesn't reliably process 24bit (solid) PNG files properly I've never ever seen the uploader malfunction. It works exactly as designed. Yet 'accidental' 32-bit textures sourced from PNG are indeed rampant in SL. Why is this? Well, as much as nobody ever wants to hear this, the problem ALWAYS comes down to simple user error. It's due to the fact that the PNG format supports multiple forms of transparency, including so-called "simple transparency", or "WSIWYG transparency". Thus, if so much as a single pixel in the image is anything less than 100% opaque, the entire image will read as 32-bit when converted to JPEG2000 by the SL uploader. After all, the uploader has no way of knowing that you didn't actually want that pixel to be translucent. This is one of the primary reasons I don't recommend using PNG for texturing. It's just too easy to make a mistake with it. Winter Ventura wrote: a PNG on my HD that's perfectly flat, will upload as a 32bit image to SL. I'm not sure what you mean by this. An image that is "flat" is one that does not contain layers. Thus all PNG's are flat, by definition, as the PNG format does not support layers in any way, shape, or form. Was your use of the word "flat" a typo, where you actually meant to use the word "opaque"? If so, then I'd question whether the images you're talking about were indeed PERFECTLY opaque. If you were to examine them pixel by pixel, I'll bet you any amount of money you'd care to name that you've got at least one pixel in there somewhere that is not totally opaque. Even if one pixel has an opacity value of 254 out of 255, that's enough to make the uploaded texture become 32-bit. To have no transparency, each and every pixel MUST be a perfect 255 on the opacity scale, no exceptions. It can be hard to ensure that with PNG. Winter Ventura wrote: it's a bit more time consuming to make textures as TGAs I'm always a little baffled when people say this. In truth, alpha mapping is not any more time consuming than any WYSIWG procedure. In fact, it's often MUCH faster. It does require a little bit of extra learning in the beginning, since the kind of metaphorical thinking it requires doesn't tend to occur to the layman, right off the bat. People all too often confuse extra mental effort with extra time. But in actual practice, alpha channel work flow is incredibly fast, and very, very simple to execute. This is why it has remained in existence for the better part of 40 years now. Alpha channels were invented in the 1970's. It stands as testament that while so many other aspects of computing have changed exponentially, and continue to change around us as we speak, the alpha channel has remain a foundational staple of modern graphics, and will likely continue as such for decades to come. The alpha map is one of the rare examples in computing of something that was gotten right the first time. It just works, period. It's fast, reliable, and super easy, once one understands how it works, and has had a little practice with it. By the way, it may be worth noting that the alpha metaphor far predates the advent of the alpha channel itself. It goes all the way back to analog matting and compositing techniques that were in use long before computers had ever even been dreamed of. Old black and white photographers in primitive darkrooms were using the same metaphor to composite photographs, practically since the invention of the camera. The alpha channel simply integrated the principle into digital imagery, in a manner that could be self-contained. Don't fear the alpha!

Dresden Ceriano wrote: Though, to my knowledge, if a creator wants to put restrictions on their full perm items such as this, they'd have to state that before you purchase their product. That's a common misconception. In truth, it's exactly the opposite. Creators cannot be obligated to put such restrictions on their items because those restrictions are already in place automatically, under the law. Legally, you cannot do anything at all with someone else's IP unless they have expressly granted you permission to do it. That includes copying an item to another grid. Unless the creator has told you can do that, you can't, no matter what the in-world permissions might be. There are three principles that are crucial to understand when talking about this: First, always remember that when you "purchase a product" in SL, you're not actually buying an item. What you're purchasing is a very limited set of usage rights, within the confines of the SL grid, nothing more. Second, under no circumstances is an IP owner ever obligated to tell you what you can't do with his or her IP. The law already covers that for everyone. Simply put, you automatically cannot do anything that the owner has not expressly told you you can do. Licenses exist primarily to tell you what you CAN do with someone's IP, not what you can't do. Any use that hasn't been expressly allowed is automatically a no-no.* Third, the SL permissions system exists only to tell you what rights have been granted to you inside SL itself. It has nothing to do with anything outside of SL. So, even if you've got full perms on an item in SL, that doesn't mean you have any right to take the item outside the SL grid. Add all that up, and here's what we get. If you as a content creator were to give (or sell) me an item with full permissions on it, I'd of course be free to do whatever I want with the item inside SL, but I absolutely would NOT be allowed to copy the item to another grid, unless you've expressly told me that I can do that. If you want me to have that right, then you could include a notecard with the item, saying that that's your intent. If you don't want me to have that right, then you don't need to do anything at all, because I already don't have it. Until and unless you grant the right to me, I can't do it. Make sense? * Note: Some license writers tend to make a point of including a laundry list of things you can't do in ther licenses. Usually, this is just for the sake of being thorough, in case the purchaser is ignorant of the law. More rarely, a license may require (or attempt to require) the purchaser to surrender rights her or she would ordinarily have. The latter really isn't applicable to the subject we're discussing here, though, so it's not really worth spending time elaborating on it.

Just one word of caution. Keep in mind that when you change your LOD factor, you're only changing how things look on YOUR machine. Most people won't have made that same modification to their viewers, so they'll continue to see things the standard way. A much better strategy is to rework your sculpties so that they look good at all levels of detail. That's not that hard to do with something as simple as a pillar, especially if you're using megaprims, which have a much further LOD falloff distance than regular sized prims. I've built entire cities from megasculpties, and they've looked perfect, even at very low quality settings. Generally speaking, the key is simply to make sure that the low-LOD vertices are at the corners of your structures. That way, when the higher-LOD vertices gets culled over viewing distance, the overall shapes of the objects won't change. Combine that with good texturing, and you'll almost never have any problems. The downside is that sometimes you won't be able to make a particular shape from just one sculpty. That's OK; use two, use three. Maybe intermix regular prims with the sculpties. Do what you have to do to make it work. For an outdoor scene, I'd always much rather invest a few extra prims here or there, to ensure that things look great at all distances, than try to be too miserly, and have it all fall apart. For indoor scenes, I take the opposite approach. If I know something is only ever going to be viewed from up close, then I squeeze every last detail I can out of each individual sculpty. LOD falloff is irrelevant, after all, if nobody's camera can get far enough away for the culling to kick in.

Knutz Scorpio wrote: I noticed that prims do not stop light Correct. Prims do not block light at all. In fact, nothing at all blocks light, under SL's current lighting model, which is why no objects in the world, be they prims, avatars, trees, whatever, cast shadows of any sort. All the graphics engine knows is that if a surface is facing a light source, it should be more brightly lit than if it's not. The question of whether or not there might be another surface in the way is never taken into account at all. Even the foot shadows that show when your avatar is standing on the ground aren't really shadows, by the way. They're just a couple of small polygonal planes attached to the avatar mesh, which show a translucent black foot-shaped silhouette texture when you're standing, and show a completely transparent texture when you're flying. A MUCH better lighting model is in the works, though. It's still experimental, but if you've got a good enough computer, you can use it now. Here's how: 1. Make sure the Advanced menu and the Develop menu are visible in your viewer. Press ctrl-alt-d to show the Advanced menu, and then ctrl-alt-q to show the Develop menu. 2. Click Advanced -> Show Debug Settings 3. In the Debug Settings dialog, select renderDeferred from the dropdown menu (or just type it in), and set it to true. 4. Now, click Develop -> Rendering, and enable the various options under Lighting and Shadows. The first option will allow objects to cast shadows from sunlight, moonlight, and local light sources. The second one enables screenspace ambient occlusion, and allows for smoother shadows. The third turns on global illumination. If your computer can handle all that, it looks quite nice. If it can't, then either your frame rate will drop to single digits, or you'll crash, or you just won't be able to enable those features at all. Even with all of these features enabled, though, you still can't block out all light entirely. Only direct light sources cast shadows. Ambient light still permeates. Anyway, none of that has anything to do with what we've been talking about here. Even with shadows enabled, you'll still see all the same seams between prims that you were seeing before. Depending on the specific lighting conditions, a particular seam might happen to shadowed instead of lit, but it's still there, and just as visible, either way. In fact, sometimes having shadows enabled will make the seams even more glaring. Light can bleed through the cracks to slice right through the shadows, drawing yet further attention to the fact that an object made of prims is not in fact a single contiguous surface. This is just the nature of what happens when you butt two surfaces up against each other in a 3D simulation. There WILL be a seam there, no matter what, and very often, that seam will be visible. When mesh goes main, we'll have a lot more options at our disposal to eliminate and/or hide seams. An entire house could be a single seamless mesh, for example, instead of a collection of individual building blocks. Or two adjacent mesh objects could be beveled in such a way that their corners could intersect in a manner that appears to be seamless. There are lots of possibilities for these things with arbitrary meshes. But until then, SL remains a blocky prim world, and seams are just inherent to that condition.

By "get a photo", I assume you mean you're taking your own photograph of your own pair of shoes, rather than just grabbing some random image off the Web, right? Please respect copyright. Even if it weren't for copyright issues, most photographs of shoes won't do you a whole lot of good anyway, as you've discovered. Most existing photos that are out there tend to be taken from the side, or from a 3/4 view, but the templates have the foot laid out partially as top/bottom, and partially as front/back. From about the ankle down, it's top/bottom. From there up, it's front/back. If you want to do high tops, boots, etc., you need to break the shoe into pieces, across both areas. Not that it can't be done, but it's quite a challenge to turn a side-view photo into an overhead view, let alone break it up accordingly if it's tall. Generally speaking, it's a lot less work just to paint your own shoe, from scratch. The easiest way to see how any part of the templates falls on the avatar is just to go ahead and wear the templates as clothing. If you're using Robin's templates, she's got colored areas, which are meant to help you identify what's what, as well as guide you in how the seams match up. If you're using Chip's, he's got less colors in the default templates, so you might also want to take a look at his topography guide images. I'm not sure if these are still available publicly. Here's the lower body one, in case they're not: Blue areas face sideways, reds face frontward and backward, and greens face up and down. You can also take a look at the avatar base skin files, which are in your SecondLife\character directory on your hard drive. The one called lowebody_color.tga shows how the avatar's naked foot falls on the texture canvas. From that, it's pretty easy to figure out what part of the shoe would go where, to cover the foot. Don't expect to be able to create a very detailed shoe. The entire upper foot area on the template at 512x512 (on-avatar resolution) is only about 120x200 pixels. That's not a whole lot to work with. This, along with the fact that the avatar foot just doesn't have a very nice shape, are the reasons why people started making prim shoes in the first place.

If that directory is the only problem, you could always just make a backup copy of it, and then restore it after installing the mesh viewer.

I get what you mean about being able to live with it, as long as you know you've done everything you can. That's the right attitude to have, as far as I'm concerned. The only potential problem there is just in determining at what point to you declare that you really and truly have done everything possible. So, I'd just caution against getting too wrapped up in questioning yourself, if that makes sense. As for TPV's, I have no idea. I've never used one. I'm just too paranoid about my login info, I guess.

I used to do it the hard way, by selectively resizing various details along the edges, so that all details end up the same size, and in the same relative locations, on both sides of each seam. It's a painstaking process, that can take forever and a day, for even a moderately complex texture. Now, I use Mudbox, and I can be done in seconds. Photoshop Extended is great, too, and I also use that. But the majority of my Photoshop work is done on the 2D canvas. I only use Photoshop's 3D paint engine very occasionally. When it comes to 3D painting, Mudbox is much faster, and far less quirky than Photoshop. I guess that's the difference between a 2D app that's had 3D added to it, and one that was built for 3D from the ground up. Mudbox can use Photoshop brushes, by the way, and it works with layers, so if any diehard PS users haven't wanted to sacrifice your brush collection or your existing work flow style, by using a different 3D painter, that's a non-issue. Mudbox and Photoshop can work toegether quite seamlessly. If anyone who's interested in this subject would care to search through the old forum archives, you might want to check out the post I wrote, about how I created 50 unique alien skins in just two days, using just Modbox and Filter Forge. Sorry, I don't have the link. I don't feel like searching for it myself right now. To summarize, the skins were highly detailed, totally seamless, and each one was done in just about 10 minutes. I simply whipped up some freaky organic looking patterns in Filter Forge, and projection painted them onto the avatar surface, from various angles. Ordinarily, I'd spend more than 10 minutes per skin, of course. But I was facing a very tight deadline. It worked out quite well.

You'll see gray until the texture fully loads. The copy you see in preview is the one that's already on your hard-drive, so of course you see that one right away. But that isn't the same file as the one that gets delivered in-world. A few things have to happen before you can see the in-world version. First, when you hit the upload button, your local viewer prepares a copy of the image (in JPEG2000 format), and it is that copy, not the original file, that gets uploaded. From the upload server, it then goes to the asset sever for storage. The asset server then delivers it to the sim (the server for whatever region you're on), and the sim then delivers it to you so you can see it in the viewer. Oh, and if all that wasn't complicated enough, it's not just one version of the texture that gets uploaded, but four, at various levels of detail. In short, after you upload the image, you have to wait to re-download it before you can see it, if that makes sense. Usually, this whole process only takes a few seconds, tops. But if you're on a slow internet connection, or if you've got a slow computer, or if the SL system itself is currently experiencing a slowdown, it can sometimes take a while. Every so often the asset server decides to freak out a bit, just so you know. When that happens, all kinds of things go wrong in SL. It occurs far less these days than it used to, but it still, it does happen. On rare occasions, it's as much as 24 hours before all four levels of detail for a texture become loadable. I know this isn't a fun answer, but give it a day. If tomorrow you still can't see the textures you uploaded today, then you know something is actually wrong, and then you can start trouble shooting. For now, even though it sucks, jsut be patient, and try to keep in mind that orniarily textures appear in a matter of seconds, so don't get discouraged. By the way, if you haven't done so already, read the stickied thread on texture optimzation, at the top of the forum. The larger your textures, the longer they'll take to load, and the more they'll slow down your (and everyone else's) frame rate. If you're trying to load a bunch of big textures at once, it can be a good long time before they appear. Always keep your textures as small as possible. The guide I posted in the thread will give you a good overview of what sizes you should be using.

As Mot said, you can type way more than just 3 decimals into the standard viewer, and the numbers WILL take. The display will be rounded off to three decimals, but the actual positioning of the prim will honor whatever you've typed (up to six decimals if I'm not mistaken). Also, the scripted tools you mentioned use a whole lot more than just three decimals (again, I think the cap is six), as do the on-screen rulers. And by the way, if you haven't been using the on-screen rulers for alignment, you absolutely should. They're WAY faster and more convenient than any of those scripted tools. However, even with all of the above being the case, understand that the graphical anomalies you're seeing may very well have nothing to do with the absolute size and position of the prim objects. If the system were capable of allowing it, and if you could type fast enough to make it feasible, you could enter in a million decimal places, for what would be precision down to the micron in RL, and you'd still see those gaps flicker in and out of existence on-screen, as you move the camera around. The issue has far more to do with how real pixels are drawn by your graphics card and monitor than with the precision at wich imaginary objects are placed in an imaginary world by imaginary measurement units. If you've got a good system, with components well designed for realtime 3D graphics, and you've got it set well (anti-aliasing to blur object edges, anisotropic filtering to keep textures in proper focus over all viewing angles, high quality poly counts, etc.), then the artifacts will be kept to a minimum. If you've got a lesser system, and/or you're using lesser settings, then they'll become more exaggerated. Remember, we're not talking about RL physics here. Solutions that would be perfectly intuitive and natural to figure out in RL do not always apply. In RL, what we see is in perfect harmony with how things actually are (assuming you've got clear eyesight, of course). But in a 3D simulation in a computer, that's not the case at all. The visual and the physical are entirely separate things, governed by entirely separate rules. What you're seeing on the screen is never anything more than the computer's approximation of what it thinks it should be showing you, based on the information available to it at the time, for each frame. On-screen display is largely about angular mathematics. If a surface is X meters wide, and the camera is looking at it from a Y-degree angle, how many pixels will it take to draw that surface? If another object that happens to be parked next to it is the same size, and it's being viewed from exact same same angle, how many pixels will be needed to draw that one? The number can't be the same for both surfaces, because of foreshortening, the natural consequence of displaying 3-dimensional image on a 2-dimensional screen. So, after the right amount of pixels has been figured out for the drawing of each surface, the next question is which particular pixels on the screen will be used for each of the two objects? Put all that together, and you just MIGHT get the two objects appearing to seamlessly butt up against each other. ...or you might not. And here's (an oversimplified explanation of) why. That question of how many pixels are required to display the surface is almost never going to be answerable as a whole number. Just about every time you do the math, you're going to end up with some fraction of a pixel as a remainder. Since there's no such thing as a fraction of a pixel on a screen, the results of course need to be rounded to whole pixels. If each of the numbers is rounded up, then you get a one-pixel overlap. If they're each rounded down, then you get an empty pixel in between the two surfaces. If it's one up, one down, then there's no seam at all. Factor in the calculations are redone for each frame, and there's your flickering seam right there. Anti-aliasing, in theory, will blur over the overlap/empty pixel, and the seam will disappear. But as we all know, theory and practice aren't always the same thing. If your computer isn't good at AA, or if the calculations are such that it doesn't think a particular pixel needs to be blurred over, or if it's not being blurred quite enough, then all bets are off. Even ultra high end non-realtime 3D simulations, like big budget Hollywood animated movies, end up with per-frame artifacts. It's not unusual for artists to have to go in in post to clean things up. And all of that's before you take prim drift into account, which happens all the time in SL. I'd strongly encourage you to let this obsession go. There's no way to ever fully overcome the problem.

Did you remember to set the stitching type to torus on the sculpty in SL? The default is sphere

Foro en espanol: http://community.secondlife.com/t5/Foro-en-espa%C3%B1ol/bd-p/SpanishForum

How are you defining "quadrilateral"? That word could describe literally any four-sided shape (rectangle, parellelogram, rhombus, square, kite, trapezoid, etc.). How about posting or linking a picture of what you're trying to make?

Looks like you're making great progress, Eloise. What an amazing difference. Those new eyes look very good. Strictly speaking, the irises are still not quite realistic, in terms of their structure, but that's perfectly OK. The shading in them is very pretty, and more importantly, you've created a great sense of liquidity in every part of the eye. Those eyes look moist, reflective, three-dimensional; there's a very convincing illusion of depth behind the lenses. Nicely done, really. I'd call it a very effective example of illustrative realism. Kalyn, yeah, there's no substitute for a Wacom tablet. By all means, if you've got one, use it. (And for anyone who doesn't have one, get one!)

The "F**k off" part might have been less than professional, but overall, it sounds like the motivation for your response was justified. It was honest, in any case. Assuming your story is accurate, then the person in question WAS an idiot, at least for right then and there, in that moment. It's one thing to arrive at a misunderstanding, due to ignorance of how something works. It's quite another to refuse the given explanation after having asked for it. So, I can't say you were wrong for calling it like you saw it. I can understand why it's probably rattling on your conscience a little, though. Negative encounters like this are always a little unsettling. I don't think I personally would have responded quite the way you did, but that's just me. I don't think you did anything wrong, for what it's worth. For what it's worth, the same thing happens here on the forums from time to time, so I can relate. Someone asks a question, and then I volunteer considerable time and effort to offer as detailed and informative of an answer as I can, only to have the person lash back at me in anger. I've never understood why people do that. I've been able to make peace, at least to a degree, with the fact that a certain percentage are just going to do that, and that's all there is to it. I know it's beyond my control, so intellectually I'm aware that I shouldn't be bothered by it. People will do as they're going to do. But still, whenever it happens, I always do feel a bit unsettled afterward. There's never any gettting around that completely. It's just one of those unfortunate things we have to deal with in public spaces like SL and its forums. In any case, I'm not sure what point he was trying to make with the full perms sculpty thing. If you had sold a full perms sculpty, and someone else snagged the map, that quite obviously wouldn't have anything to do with why your name was on this guy's glasses. Needless to say, all it would do is enable that other pesron to make their own sculpty be shaped just like yours. Plainly, the "dude"'s glasses have nothing to do with that, one way or the other. Was that presented as a spearate point from the link issue, or was he trying to say they were one in the same?

I have no idea what the problem might be, sorry. But perhaps you've found your niche as SL's foremost creator of nightsticks? Paint that sucker black, and you're in business!

Care to post a link to the tutorial in question, and a more detailed description of what you did and what you were trying to do? Without knowing more about what you were doing, it's hard to pinpoint where you went wrong. I'm a little confused as to why you might be trying to alter the UV mapping of sculpties. The correct mapping is already in place on the sculpty template objects. Sculpties do not support arbitrary UV layouts or arbitrary topology. Every sculpty's UV layout is the same, just a perfectly uniform grid. If you change that, your sculpties won't be sculpties anymore; they'll be arbitrary meshes. I suspect maybe we're having a terminology mismatch. When you say "UV map", do you perhaps actually mean "diffuse map"? Just to clarify, UV maps depict the locations of vertices from the 3D model on the 2D texture canvas. In other words, they show how the 3D surface unfolds into a 2D surface, similar to how a globe might unwrap to form a geographical map. UV maps tend to look like grids or frameworks. Diffuse maps are the kinds of images we refer to as "textures" in SL. They depict the coloring, the 'paint job', of a model. If you did in fact actually mean UV map, then I'm not sure what you mean by such phrases as "the map doesn't show on the image" or "I don't see the map on the image". If you're having trouble making your diffuse texture appear on the model surface, did you maybe forget to refresh the view after you assigned the texture to the model? I haven't used Wings in a while, but I do seem to recall that that was a necessary step. Maybe this would help. I just found this tutorial on working with UV's and textures in Wings: http://www.pagodaproductions.com/tiki/Wings3D%20UV%20Mapping.html . It seems to cover all the bases. Give it a whirl.

It's hard to answer the question without seeing what you've made. "Extra holes" could mean any number of things. My guess is you made the model as an arbitrary mesh, without consideration for the requirements of sculpties. If that's the case, the answer will be to remake it with the proper topology and UV structure in place, from the start. Sculpties are like origami. They're made by taking an existing surface, and bending or folding it in 3D space to form a 3D shape. Think of it a bit like wrapping a Christmas present. The wrapping paper takes on the shape of the gift, but ultimately, it's still just a piece of paper, nothing more than a 2-dimensional rectangle. Sculpties are just the same. No matter what shape you make them take on in 3D, they have to remain rectangular in 2D. If you haven't done so already, watch the Machinimatrix tutorials for making sculpties with Blender. It's a really fantastic series. http://blog.machinimatrix.org/3d-creation/video-tutorials/ By the way, just in case you didn't already know this, arbitrary mesh support in SL is currently in public beta, and will be implemented into the main grid in the coming months. (Don't ask for an exact date, because no one knows.) Once it hits, the need to bend over backwards to make things out of sculpties will all but disappear. You'll be able to make any kind of mesh model you want, and import it directly. Sculpties will still have some uses, but at leas 90% of the uses they have now will be better served by arbitrary meshes.

Thanks for the link, Penny. It's good to know that LL is on the case, regarding this issue. However, I'm still not convinced the word "bug" is comletely appropriate. From Nyx's comments, it seems they're addressing the issue by implementing a design change to what factors are included in the computation. Nowhere on the issue tracker page did Nyx actually use the word "bug". Call it a matter of semantics if you will, but I have a hard time referring to each and every problem as a bug. I think this one was simply a design flaw from way back. To give you an idea of where I'm coming from on the difference, here's a somewhat similar example. Lots of people refer to the alpha sorting glitch as a bug, even though it's not. Alpha sorting works exactly as it's designed to work. To the untrained eye, it can seem a bit unpredictable, and it's certainly not always convenient to have to work with or around it, but there's nothing actually broken or malfunctional about it. I don't see the avatar height issue as all that different. In both cases, you've got something that was designed originally to work a little differently from how the user would intuitively expect. To me, a bug is when something doesn't work as the designer intended. It hardly matters what we call it, of course. If you prefer "bug", I'm happy to agree to disagree agreeably. I just thought it was an interesting topic to talk about was all. The important thing is that the issue itself is being corrected (largely due to your efforts to spotlight the problem, by the looks of it). Thanks for helping to lead the charge to spur LL into action on this, Penny. I'm sure a great many SL residents, myself included, will be grateful.

Most pro builders will tell you that making buildings 25-50% larger than RL measurements is the magic proportion. Any smaller, and not only do things tend to look short next to the typically too-tall avatar, but nagivation becomes challenging. (SL's movement controls are clunky. Avatars need a fairly wide berth to keep from bumping into things.) Any larger, and things just start to look cartoonishly big. Anywhere inside that 125% to 150% range is safe. Ceilings are a notable exception. In RL, they're about 7.5 to 8' high, in most rooms. In SL, they need to be at least 4 meters high (well over 13 feet), which obviously is way more than 150% of RL height. Most builders tend to go even higher than that, at 5 meters or more. But you can go down to 4 without causing camera problems for the majority of users. You can even go to 3.5, which would put you almost exactly at 125% of RL, to match the proportions of the rest of the room, and most users' cameras will still be OK. However, things start to feel pretty cramped when the ceilings are at that level. For whatever reason, we just require ceilings on-screen to be higher than in RL, in order to feel comfortable with what we're looking at. Even in first person shooter games, in which avatar height is never even seen, and camera placement is never an issue, ceilings still tend to be disproportionately high. Remember what Ted Striker said about coming in low? "Coming in low is part of every text book approach. It's just what you gotta do when you land." Well, it's kind of like that, except we're talking about 'coming in high' instead of 'coming in low'. To paraphrase, you might put it like this: "4+ meters high is part of every on-screen ceiling. It's just what you gotta do when you build." To summarize, just remember 25-50% larger than RL for floorplans, and 4 meters or higher for ceilings, and your builds will always work. Happy building. Now that that's been said, I'd like to address one point that was rasied by Penny, if I may. Penny Patton wrote:. LL needs to provide accurate height information to residents who are editing their shapes. Currently, LL shows incorrect height information. The height displayed in the appearance editor of LL's own viewers is off by about half a foot or more. LL is aware of the bug, they simply have yet to correct it. I agree that there should be a better system in place for determining the actual height of an avatar. However, I'm not sure it's quite fair to call the current measurement system a bug. The word "bug" would imply something is broken, or not working as intended. But this is not the case here. As far as I know, the measurements are in fact accurate, and the system works absolutely as designed. The problem is people don't tend to understand what the measurements mean, due to poor wording. When the system reports that "your avatar is 2 meters tall" what it actually means is your avatar's eyes are 2 meters above the ground. But it doesn't come out and say that. It just says "your avatar is ___M tall", which is somewhat misleading. If they were simply to change the wording of the message, the apparent 'bug' would cease to exist. People would immediately understand what's actually going on. I suspect the "height" measurement has more to do with camera docking than anything else. The altitude reported is the position your camera will dock to when you're in mouselook mode. I would assume that this system was probably put in place long before the actual avatar model was ever even built. The original avatar, when SL was first under development, was just a crude collection of geometric shapes. Once they had a humanoid model in place, it was probably only then that somebody realized, "Oh yeah, we need to look through its eyes, not through the top of its head." By then, it was probably too late to bother with changing how the height reporting worked, since much larger priorities were no doubt on the plate. In any case, to do the kind of height reporting you're looking for, we'd first need a solid definition of what "height" even means. If an avatar has an afro or a mohawk, is it "taller" than one that is bald? If it's got horns or a top hat or a big old tree growing out of its skull, is it even taller than that? If you want to go by RL human standards, then you might say "height" is measured to the top of the cranium, not including hair or attachments. In that case, you'd be talking half a head above eye level, since the eyes (on a human) are centered vertically on the face. This is why a seemingly 6' male avatar with idealized proportions would actually be 6'5" tall. An ideal male is 8 heads tall. If the eyes are at the 6' mark, then 7.5 heads equal 6'. That's 9.6 inches per head, which means 76.8 inches in total height. Consider that most people give their avatars pretty unrealistic proportions, and it's easy to see how discrepancies of a foot or more can come into play. And that's just for humans. Not all avatars fit that description. What if my avatar is a robot or an alien or a dog or a beach ball? What's my "height" then? How do we even begin to define it? And if you think it's bad now, wait 'til mesh arrives. The days of relying on the existing avatar model will be long gone fast. Rigged attachments of every variety you could imagine, and millions more you couldn't, will be the norm. Such quaint notions as "height" will no doubt be largely thrown out the window. Even if we put the eye-height/total-height issue aside, the avatar size still remains problematic. I've long suspected that the avatar was created by a wholly separate person (or group) from the people that first created land in SL. My guess is the avatar was done by some contractor, since to my knowledge, no Linden has ever taken credit for it. The reason I think these things were done separately, and then only brought together afterward, is for two main reasons. First, the avatar does not seem to correspond at all with SL's notion of a "meter". Second, SL only gets that notion as a direct result of how land works. A "meter" is simply 1/256 the width of region. Take the land out of the equation, and the "meter" is completely arbitrary. It's only in the context of land that the meter can have any fixed definition, and once again, that definition quite obviously has nothing whatsoever to do with how avatars work. I once wrote a fairly in-depth analysis of this on the old-old forums. One of my primary arguments illustrating how avatars don't jive at all with the SL meter was the fact that it's damned near impossible to create a realistically proportioned avatar when the height is within normal human range, as measured in meters. Ankles, knees, elbows, wrists, etc., all become quite disproportionate, compared to the rest of the body, when the overall height gets that low. There's no perfect way to fix this. It's only when the avatar is allowed to be freakishly tall, compared to the SL meter, that realistic proportions from body part to body part become possible. So, either the avatar is allowed to be too big for the meter, or it's forced to be out of proportion within itself. Needless to say, most people will opt for the former. Apparent giantism can be forgiven far more easily than ugliness. The title of my analysis was "Avatars Are Not Too Tall; Meters Are Too Short, Seriously". I still believe that statement was true. After all, the 'measuring stick' we all go by in SL for everything from hats and skirts to furniture and vehicles to doorways and buildings is the "average" avatar. Our objects that are in perfect fit with our avatars all contain "too many meters". Therefore, meters in SL are smaller than they should be, relative to the avatar, and as a consequence, relative to everything else (except land). Again, the only thing we know for sure about what defines a "meter" is that it's 1/256 the width of a region. Other than that, it really has no function. The avatar is what we must measur everything against, if we want anything to look right and be functional.