Chosen Few

If you search the marketplace, there are tons. They're also pretty easy to make, if you want to learn how, or you could hire an animator to make them for you. I know Medhue Simoni sells a bunch of food items with animations incliuded. You might want to ask him if he'd sell you the animations alone, without the models.

The answer is no, you cannot copyright a recipe. Under the legal definition, a recipe is not a work of literature, but rather is a set of instructions and/or a list. If a recipe is unique enough, it can be patented, but that's a whole other subject. What can be copyrighted are accompanying materials, such as the 3D models we've been discussing here, or pictures, or expressive literary descriptions, or anything else that sufficiently meets the legal definition of a creative work. As for the notecard thing, I really wouldn't worry about that. Making it no-mod wouldn't prevent anyone from copying and pasting the text, and making it a texture wouldn't stop anybody from just retyping it. If somebody wants to copy it, there's no technical means to prevent it. No sense wasting energy on things you can't control. As with all other media, most people will buy, some will steal, and the world will keep turning.

Good call, but why stop at just a notecard? How about having it launch a web page with nicely formatted instructons, when you click on the model?

What does it look like in the bind pose? If the pose in the second pic IS the bind pose, then that's likely a big part of your problem right there. Put the skeleton back in its original position, and zero out all the bone transforms. Then use an animation to pose it the way you want it in-world.

Not only is this a fantastic idea, it's among the most practical uses for virtual world technology one could think of. In essence, you're selling a 3D cookbook. Instead of having to settle for mere pictures of the food, the customer gets a fully interactive 3D model of it. That's huge. I wouldn't limit this idea to just SL if I were you. I'd also turn it into a mobile app, so people can use it right in their kitchens as they cook. I could see this being tremendously popular if you do it right.

Thanks for the kinds words, Phoenix. Yes, I have thought about doing a tutorial series. I've also been back-burning a Photoshop for SL users book, for years now. These things are all on my "when I get around to it" list, which is not exactly a short list, if you know what I mean. Anyway, yes, Rhakis is correct. You can certainly copy weights from model to another. There are a number of ways to do it, in fact. One way to do it is to export the weight maps from the source (Skin -> Edit Smooth Skins -> Export Skin Weightmaps), and then import them onto the target (Skin -> Edit Smooth Skinds -> Import Skin Weightmaps). This requires the UV's be identical, of course. Another other option is simply to use the Copy Weights command (Skin -> Edit Smooth Skins -> Copy Skin Weights). This will work whether the UV's are the same or not, and will even work on dissimilar geometries, as long as you use the right settings. If the models are very different, you'll probably have to do some clanup afterward with hand painting, but even with radically different geometries, Copy Skin Weights will still usually provide a pretty decent starting point. Like just about every other command in Maya, these commands have options boxes, so open them up, take a look at the options, and then click the help to learn what they all do.

Pheonix Mistwallow wrote: I3) I'm beginning to wonder if Maya has superiority in rigging to blender. I've downloaded the Maya trial but while I can find loads of tutorials for modeling and some for rigging there isn't much out there relating Maya to Second Life rigging. Since I use a separate program for the 'creation' I really only need Maya for rigging only... and those tutorials are hard to come by. The ones I have seen jump around and aren't all that informative. I'll leave the Blender questions to Blender users. Maya does indeed have a mirror skin weights command. In the Animation menu set, hit Skin -> Edit Smooth Skin -> Mirror Skin Weights -> options box. Take a good look at the options, and then hit the Help at the top of the options box, for a complete explanation of what they're all for. You can also paint on both sides of the model at once, while you're painting weights (just as you can with any other brush in Maya). Go to the Animation tab in the shelf, and double-click on the Paint Weights Tool, to open its attributes. Expand the Stroke secton, and you'll see an opton for Reflection. You can reflect across any axis, and you can choose whether to reflect across the object's center, or the world origin. As for SL-specific ttorials, don't bother searching for those. Rigging is riigging, is rigging. Just learn the subject itself. You'll follow the same procedures whether your target platform is SL or any other game engine. The best place to begin when learning Maya is the help documentation that comes with it. That's how every single Maya user starts. Go through all the tutorials in the Getting Started section, in order. Don't skip over any, even if you don't yet understand how it's relevant to what you're looking to do. It's all relevant, whether you realize it or not. Once you've been through all of those, you'll have a really solid working mastery of the basics of Maya. From there, you can begin to specialize, and expand your knowledge toward specfic areas. The general basics absolutely have to come first. There's no other way. The reason the other tutorials you found may have appeared to skip around, or to assume a certain knowledge level, is because literally every single Maya user on the planet started the same way, with those Getting Started tutorials in the help. Anyone creating additional tutorials will naturally and automatically assume that the user has already been through those. That said, if you're going to spend the money to purchase Maya, I do hope you'll use it for more than just rigging. $3750 for a rigging program is pretty steep! For starters, I'd suggest you use it to retopologize those cloth sim models. By definition, cloth simulators never produce content that is optimized for usage in real time. The poly counts are always excessively high, the topology is always unlclean, etc. Anything produced from a cloth sim should be considered concept art, not game-ready product. That's just the nature of the beast. By the way, if cloth sim is your thing, you'll find that Maya's tools in that regard are quite good. I don't know what other program you're used to, but since you're diving into Maya anyway, probably should check it out. Save it for after you've learned all the basics, though, of course.

Icarus Lytton wrote: - prims are saved in memory with text - what is saved is the UUID of the textures and all the settings of said prim. The viewer basically applies these settings to the prim and since the prim is hardcoded, it doesn't have to be cached as mesh - sculpties = cached as a texture, NOT polygons. - avis and everything else mesh = hardcoded into the viewer. User-made mesh is loaded in memory as mesh - not as text, not as textures - so it IS the first time the viewer has to constantly load and unload mesh into memory. Your apparent definition of "saved in memory" in this context is very incomplete, and phrases such as "cahced as mesh" or "constantly load and unload mesh into memory" are potentially misleading. If I'm reading you right (which I very well might not be), you seem to be implying that parameter lists and file formats that are used for storage and network transfer somehow play a direct role in what's going on in the graphics pipeline. I can promse you, they don't. Before we go any further, let's make sure we're comparing apples to apples. By the logic you seem to have outlined, if prims and sculpties are not "cached as polygons", then neither is an arbitrary mesh. Allow me to explain. The file that describes a user-made mesh is just a text file, fundamentally no different from the text file that describes the parameters of a prim or a sculpty. At that point in the pipe, it's all just text. Further down the pipe, the data that gets sent to your graphics card is always the same kind of data, whether the object being described is a prim, a sculpty, or an arbitrary mesh (or an avatar, or a tree, or anyhting else). At that point, it's all geometry to be drawn, not files to be stored. Your graphics card does not know or care about prim parameters, or sculpt maps, or anything else along those lines. Its only concern is for the actual polygons and pixels that make up the 3D scene. Here's a more accurate (yet still drastically over-simplified) description of the process: All of the parameter lists and mesh descriptions in the first stage of the chart are text files. In the second stage, the infomration from those files is compiled into somehting graphics pipeline can use. That process happens in the exact same way, regardless of wherever the various components from the first stage happened to have come from. And of course, by the time it gets to the third stage, it's purely graphics data, which no longer has anything directly to do with anything from stage one. I did not include texture files in the chart, in the interest of keeping it simple. For those, just add another box to stage one. The rest of the chart remains the same. I hope this makes a little more sense now. Icarus Lytton wrote: I also did quite a few tests with my friend and we found out the following: It's not about how complex the mesh is. It's a problem with how it caches it. I spawned about (and I'm not kidding) 500 mesh items with each item having over 30k polygons. that's 15 million polygons and I got 45fps. I THEN zoomed in, hiding my avi (and its mesh hair, boots, etc.) and zoomed back out and the exact same scene suddenly saw my fps drop to 0.8fps. And it remained there indefinitely. Please someone explain to me how this is NOT a viewer problem - because it seems to me that when I zoomed out and it had to load the mesh on my body, it started to spaz out.. Unfortunately, anecdotal experiments like this can lead to all sorts of false conclusions, based on the experimenter's preconceptions about how things MIGHT work. As others have stated, your experiment as described was unscientific. Where's your control, for example? You rezzed 15 million polygons worth of mesh models, but you did not rez an equivalent amount of prims or sculpties for comparison. For that you'd need 7325 twisted toruses, and then 7325 sculpties. Then you'd need to ensure that the LOD's for the mesh models are created such that the total poly count at each level will be equivalent to the poly count of the pirms and scupties at the same level. Also, for best accuracy, you really should be working with the same amount of objects in each case, which means 7325 mesh models, each with 2048 faces, and the correct number of vertices and UV points at each level. (I think it's 1056 for both, at highest LOD, but don't quote me on that, as I don't have it in front of me right now to double check. I don't recall off hand what the lower LOD's are, and frankly, I don't recall off hand what all the lower LOD's are.) Finally, each set shoud contain the same assortment of object sizes and polygon sizes, in the same configuration, as in each other set, to ensure that the LOD switching happens at the same point for all. Once you've repeated the experiment several hundred times, with all three types of objects, then and only then will you be able to say you've got something you can actually learn from. Until then, all you've got is anecdote, which could mean anything (or nothing). Icarus Lytton wrote: Okay I'm going to write a nice and long reply to this: I've tried a million different settings, all sorts of stuff, and it all boils down to this: the performance is completely random and when I get 80fps one minute, I'll get 1fps another minute when nothing new has appeared. My graphics card isn't taxed, my memory hasn't run out - yet my entire PC is down to a crawl. It's like some bad code in the viewer is sending stuff in an endless loop. So does anyone have any ideas now? I do appreciate all the answers but it's not the solution and this lag shouldn't happen so drastically. The randomness only underscores the non-science in your experiment. Your assumption about "bad code in the viewer" and "endless loop" is just a speculative and untested hypothesis, as I think you know. I wouldn't even go so far as to call it an educated guess; it's just a guess at this point. As for a solution, there's a fairly obvious one, right of the bat. Don't put 15 million polygons in a scene!

RangiUtu wrote: A secret you'll never hear on this forum or any other forum inhabited by "creators" and those who bring it up are generally ganged by the mob and shut down. MESH LAGS. Sorry, RangiUtu, but that statement smacks of so much deliberate ignorance on the topic, it almost defies description. First, saying "mesh lags" as an absolute is like saying "cars crash" as an absolute. Fact: Cars only crash when they're driven improperly or poorly minatained, and mesh models only cause lag when they're made iproperly or used unwisely. As I said a moment ago in my reply to the OP, a properly created mesh model will ALWAYS create LESS lag than an equivalently shaped prim model. Prim models, by definition, are chock full of extra polygons that do not contribute the models' outward appearance. Arbitrary mesh models can eliminate all that waste, thereby greatly reducing lag. Second, you seem to be completely oblivious to the fact that EVERYTHING you see on your screen in SL is a mesh model. That includes all prims, avatars, trees, land, sky, sun, moon, everything. The only difference is that those items happen to already be loaded into the system, whereas newly created models have to be imported first. Once they're in, they're all the same thing. This is a basic fact of graphics. It cannot be otherwise. RangiUtu wrote: And yes it can nearly freeze you if you're close to it with an older PC especially. If it's badly made, sure. If it's well made, that will never happen. The problem is that not all content creators in SL understand how to make their models correctly. From the attitude you're expressing here, it seems clear that you fall squarely in with that crowd, and that's where you want to stay, which is really unfortunate for you. If you'd just open your mind a little toward learning how this stuff actually works, you could make your lag problems disappear tomorrow. RangiUtu wrote: Mesh aircraft..you know the ones uploaded fropm turbosquid and resold here as original work... (not all mind you but at least one "popular" jet builder has been caught at it) with rotating mesh blades are the worst. I don't know what models in particular you're referring to, but it goes without saying that not everyhting for sale on Turbosquid is meant for use in realtime environments. The fact that it's an aircraft, or that it as rotating parts, has nothing to do with it. If it's an inefficient model, it's an inefficient model, no matter what it looks like. Once again, if the model is properly made, it will cause far less lag than its prim-based counterpart ever could, whether we're talking about airplanes or anything else. RangiUtu wrote: Unless you desire some odd shape that only LLMesh can provide, then try using legacy prims/scuplts since everyone can see those. Many can not even see mesh still because the mesh viewer LAGS and not everyone is wealthy enough to go buy a new computer everytime the mob here tells them to. Sorry, but you're once again ignoring the facts. The vast majority of SL users are now using mesh-capable viewers. I believe the latest published statistic was well over 90%. For any creators to invest in the past in order to cator to those few stubborn holdouts would be unwise at best, and utterly ridiculous at worst. You've clearly got some kind of irrational bias against mesh, which I'm not going to try to pretend to understand. Your words don't change the facts, though. As a wiser man than you or I once famously stated, "Facts are stubborn things." As for this "mob" you claim goes around telling people to buy new computers, they must be really effective as secret societies go, because I've never seen or heard of them. I've been here on a regular basis for well over 9 years, and I honestly can't remember the last time any person suggested that any other person buy a new computer, in any of the content creation forums. That's not to say it's never happened, of course. It's probably happened many times. People talk about all kinds of things. But it certainly doesn't happen often enough to be of note. That said, the fact (yeah, facts again, I know, annoying, right?) is SL is not an easy program for any computer to run. It never has been, and likely never will be. Even state of the art, ultra high end gaming rigs have their share of troubles with it. If you want decent performance, you should have a machine that is up to the task, and there's nothing wrong with saying so. If you can't afford one, so be it, but nobody's in the wrong if they happen to suggest you'd have a better experience with a better machine. I'd have a better driving experience if I owned a Ferrari instead of a Dodge, but is that really worth making a stink about? Plus, if you really do have an under-powered machine that's all the more reason to embrace mesh. As I've said umpteen times now, a properly created mesh model will be friendlier to your machine than an equivalently shaped prim model. Again, this is just a fact. It's unfortunate that so many SL content creators are so ignorant of how to properly optimize their creations for good performance. You'd do well to aim your rhetoric toward that subject, if you really want things to improve. RangiUtu wrote: This goes double for clothing. If you want to be seen by everyone in SL, instead of as a half-naked blob by many, the wear legacy prims. I'm fine with being a half naked blob to the extremely small percentage of people who refuse to use a modern viewer. As I said a minute ago, investing in the past is just silly. RangiUtu wrote: Mesh looks no better than any other clothing or build. While it's true that a bad artist will produce bad looking work, whether it's made from mesh or prims or what have you, a good artist can produce far better looking (and better performing) results with mesh than with prims or sculpties. If you happen to be under-capable as a mesh artist, so you personally have not been able to reap the visual benefits, that's your problem. It's got nothing to do with mesh as a medium. RangiUtu wrote: It..is...not...."better".......except for the "builder" (Uploader). Not sure what you mean by that. Care to explain?

Icarus Lytton wrote: It seems to me that there's some bug in the code with how it handles and loads mesh As others have already well stated, the problem you're describing can only be the result of one or more improperly created models. It's absolutely, positively NOT indicative of any sort of bug in SL, or problem with mesh itself as a medium. Let me state a few facts about how it works, and then let's talk about how to solve your problem. You mentioned both handling and loading. Let's talk about each. The first thing you MUST understand is that every single item in SL (and in every video game you've ever played) is a mesh object. Prims are mesh objects, trees are mesh objects, avatars are mesh objects, even the land, the sky, and the sun are mesh objects. The fact that SL now has the capacity to import and use externally created models, whereas before it could only use that small set of models that had already been built into it, does not change how the system works at the base level. In other words, the "new" mesh cannot and does not handle any differently from the old items, in terms of live performance. They're all the same thing, as far as your computer is concerned. It cannot be otherwise. This is a fundamental principle of how computer graphics works. As for loading, all assets load pretty much the same way. But even if they were somehow to load in different ways, that wouldn't affect your continuous FPS. Loading of an item only happens once, after all. It's not an ongoing thing. (It's astounding, by the way, how some SL users are under the ipression that mesh is this newfangled thing that LL invented. The truth is mesh is everywhere, and has been since the dawn of modern graphics. It's been in use for at least 30 or 40 years now, and likely will remain in use for the next 300 to 400 or more. It's as intrinsic to computer graphics as oxygen is to breathing. The word "fundamental" is actually an understatement to just how elemental it is. It's the core of just about everything.) All that said, the trouble you're experiencing is obviously very real. So let's talk about the causes for it, and how you can solve it. The "new" mesh in SL can be used wisely or unwisely, just as anything else can be. When mesh models are properly made, they'll actually increase your FPS, rather than decrease it, relative to equivalent prim or sculpty builds. But when they're improperly made, then yes, they can and often will act as FPS vampires, lagging the hell out of everyone around. An unfortinate fact of SL is that a lot of content is badly made. That vast majority of content creators, and content consumers, have absolutely no idea what they're doing. Those who know how to optimize their builds properly will expreience consistently high frame rates, while those who don't will suffer. When models are not made correctly, it's not SL's fault, not the model's fault, and certainly not mesh's fault. It's the fault of the person who made it, and the person who bought it. In other words, poor performance boils down to simple human error. That's the good news. It means you can take steps to fix it. I picked oxygen as an analog a moment ago. Let's stick with that, to illustrate this point. Used correctly, oxygen keeps you alive. Used incorrectly, it burns down your house. If the latter were to happen, would you say there must be a bug in how the house handles oxygen? Or would you put the blame where it belongs, on the whatever human idiot did whatever humanly idiotic thing that sparked the fire in the frist place? The moment LL flipped the switch to allow import of arbitrary mesh models in SL, they basically handed a giant box of matches to a group of six-year-olds. Some of the kiddies will learn to handle the power responsibly, but a certain percentage are just going blow things up, and that's that. Modeling for realtime environments like SL is all about finding ways to do more with less. But some people in SL just don't get that. They pile on the polygons, by factors of ten, a hundred, a thousand, or even ten-thousand times more than necessary, and then they say, "Look what a great artist I am!" What these people don't realize (as I've said before, and I'll keep saying) is that they're the laughing stock of of the 3D modeling community at large. I don't mean to be rude, but really, when someone uses 50,000 polygons to express a shape that could be made just as well from 500, we absolutely do laugh at them, and rightly so! Seriously, it comes up in conversation far more often than you might think. Don't get me wrong; anyone who's been on this form for more than a day or two has seen the lengths I go to to patiently educate people, without judgment. I'm here to help. My point is simply that if I of all people can't help but join in the industry-wide laughter about this, it speaks volumes about just how deep the problem goes. As a consumer, the best thing you can do for yourself is look before you leap. If you're interested in a model that is for sale, look at the actual model, not just the picture, before you buy. Examine not just its land impact, but its display cost. Take a look at its wireframe. If it's nice and sparse like it's supposed to be, then go ahead and buy. If it's overly dense, then steer clear of it. Remember, LL's primary focus is on land impact, because land is how they make their money. Land impact is a direct analog to server resources, and LL is, more than antyhing else, a server host. YOU, on the other hand, are an end user, not a server host. YOUR focus, therefore, should be first and foremost on client side performance. The ONLY way to ensure good performance is to make sure the poly counts in the models you buy are never any higher than they need to be. If a model is very poly-heavy, just don't buy it Look for an alternative that is better made (or better yet, learn to make it yourself, and you'll never ever have this problem again).

While it is technically usable, Sketchup is among the very worst of the worst of all possible choices. It offers absolutely no way to control the topology or UV layout of your models. It's a toy, not a tool; there's a HUGE difference there. Do yourself a favor, and learn to use a proper 3D modeling program. If you learned Sketchup, you can learn something else, too, so don't be intimidated by the fact that other programs can do so much more. Whether you're swimming in a kiddie pool or swimming in an ocean, you still swim in just the few feet of water that are immediately around you. The actual process of swimming is identical in both (as is the process of drowning). The only difference is the ocean has a whole lot more to offer. If you just want to do the kind of extrusion modeling that Sketchup does, just about every 3D modeling program in the world can do it, just as easily, if not more easily, than Sketchup can. But you'll also be able to control the topology and UV layout, so you won't end up with a mess. Not only does that mean your models will be cleaner and will perform better in any realtime environment, it also means their land impact in SL can be kept to an absolute minimum. You'll also find that once you dare to venture past simple extrusions, there are all kinds of other methods that make the modeling process even better and easier. You'll naturally learn these as you go, and before you know it, you'll be producing things in minutes that might have taken hours to do in Sketchup. Ditch the toy, get a tool, be happy. Here's a story that might help illuminate the problems with Sketchup. A while back, I was hired to take over the content creation for an OpenSim-based project, for a large high-tech manufacturing company. Before they brought me on, the management consultants they'd hired to head the project thought they'd save money by grabbing a bunch of Sketchup models for furniture, props, etc. The simulation was riddled with problems, and some of the people involved were convinced it was because the version of OpenSim they were using must be borked or something. Well, it wasn't long before I discovered the real cause of the issues. Those Sketchup models were completely unsuitable for use in a realtime engine. The first example was in the form of a couch that they asked me to texture. I was horrified when I brought it into Maya, and saw how it was put together. First, it was 70,000 polys, when all it really needed was about 700. Yes, it was literally 1000 times too heavy! Second, and arguably important, given the way SL/OpenSim streams data, the UV setup simply could not have been worse. It consisted of hundreds of individual UV sets, and thousands of tiny islands. Almost all of the islands were tangled messes, spewed all over the canvas. Needless to say, it was completely untexturable. So, I said to the management consultants, "This 'free' couch model is going to cost your client about $600 by the time I spend the amount of hours that will be necessary for cleaning it up to make it work properly, or I can just make one from scratch right now, in about an hour, and it will work just fine." Needless to say, they went for option B. There's no way any human being, even the most insane, masochistic, delusional, or just plain stupid, would ever produce a UV mess that elaborately awful. It would take literally days of dedicated work to pull it off. Clearly, the problem was that the software that had been used to build it whacko. The person who made the model was probably blissfully unaware that topology needs to be a consideration, or that UV's even exist. And that was just one model, among hundreds of such models the project managers had placed all over the sim. Not all of them were as bad as that couch, but a great many were. A few were workable, but not many. I ended up having to replace about 85% of them. And guess what, the simulation ran just fine after that. In their quest to save money by raiding the Google 3D warehouse, those project managers almost torpedoed their own project. By the time I'd dug them out of the hole, they ended up spending more than they would have if they'd just hired me to create sensible content in the first place. My own experiments with Sketchup have confirmed the hypothesis. The results it produces are quite often simply ridiculous when you examine their structure afterward.

Looks like you neglected to upload the sculpt map losslessly. Make sure the box for lossless upload is checked in the upload dialog, and make sure the map is small enough that the option can apply to it. 64x64px is ideal. That said, since you said you're really enjoying using your modeling program to make every kind of shape you want, I have to wonder why you're even bothering with sculpties at all. The sculpty workflow is unnecessarily awkward, highly restrictive, relatively time consuming. You'll get much better results much more easily simply by creating arbitrary models, exporting them to COLLADA format, and uploading them to SL as is. Sculpties were a clever solution back before SL had support for arbitary polygonal models. Now that it does, there's almost no reason any more to keep using sculpties.

There are lots of different ways to make a sphere, and even more ways to UV map it. Just saying "sphere shaped object" doesn't tell us enough to fully help you. The kinds of spheres in common use include the following toplogies: Revolved (globe-type) - has two poles where its edge rings converge, like lines of longitude on a globe, and its edge loops run parallel, like lines of latitude. Geodesic - made entirely of evenly distributed triangles, think Epcot Center Soccer ball - made of hexagons and pentagons Tetrahedral - made from four triangular faces that are subdivided and curved in 3D space Hexadronal (cubic) - made from six rectangular faces are subdivided and curved in 3D space Octahedral - made from eight triangular faces that are subdivided and curved in 3D space Dodecahedral - made from 12 pentagonal faces that are subdivided and curved in 3D space Icosohedral - made from 20 triangular faces that are subdivided and curved in 3D space Panel-type - lines of longitude are parallel and perpendicular to the lines of latitude, forming four or six poles, rather than just two Of the lot, revolved spheres and cubic spheres are the most commonly used in every day 3D modeling. Most 3D programs (including SL) use revolved spheres by default The most common way to UV it is as a uniform rectangular grid of quads, with saw teeth at the top and bottom to represent the ring of tris at each of the polar regions. If this is the kind of sphere you're using, and you're determined to paint the texture in 2D, rather than in 3D, then the polar coordinates filter in Photoshop is your friend. If you're using one of the other types, or something else entirely, then we'll need more information from you before we can know where to steer you. Of course, if your modeling program allows you full control over the UV layout of your model, you can always just arrange the UV's to fit the texture, rather than worry about how to warp the texture to fit the UV's. Or you could upgrade to Photoshop Extended (or ZBrush, Mudbox, etc.), and simply paint the texture directly onto the model.

You're right, of course, Drongle. Even if repeating some materials, though, I still recommend putting each separate part into its own UV tile space, rather than overlapping them. It just makes it easier to select things, and to keep everything organized.

My guess is it's there, but it's 1000 times too small, so it's hard to see. SL uses meters as its units, whereas MD uses millimeters by default. If your avatar model is 2 units tall, it's going to be just 2 millimeters tall in MD. Change the scale to 1000x in MD's Import OBJ dialog, and you should be good to go. As for the secondary pose that was mentioned, that's only needed if you wante to be able to morph from one pose to another. That said, I hope you don't expect to be able to use clothing from MD direclty in SL. As with most cloth simulators, the geometry that MD generates is not at all optimized for use in a realtime environment. It's super high poly, and the tesselation is awkward at best. It's just not meant for this sort of work. If you want to use MD as a design tool, that's fine, but you should think of the results as concept art, not as game-ready assets. You'll need to retopologize the models (or recreate them from scratch) in a proper 3D modeling program (Maya, Max, Blender, etc.) before you bring them nto SL. Any time the promo video for any digital arts product says, "_______ is hard, but our program makes it easy," that should be an instant red flag. It's hard for good reason. There can never be any such thing as a single universally applicable solution. There's far more at stake than just how something looks on screen in one program. If you're a RL fashion designer who wants a relatively simple-to-use means by which to experiment and showcase your designs digitally, using the RL pattern-making skill set that you already have, then MD is great . Thats precisely what cloth sim technology was first invented for. However, if your goal is to create assets for use in realtime 3D environments, that's an entirely different skill set, and cloth simulation programs like MD are not terribly useful. By the time you properly retopologize the models, you could have made twice as many from scratch. Once again, as I find myself saying at leat 10 times a week lately on this forum, the only place to find a "make it easy button" is a Staples commercial. In the real world, there's no such thing. For everyone's sake, either learn to do it right, or just don't do it.

Rahkis Andel wrote: the biggest threat to SL's usability right now are people who don't know what they are doing, but get a "simple", specialized tool like Zbrush and think they can just use everything they sculpt right out of the (mud)box. With the power to make multimillion poly sculpts, comes the great responsibility of understanding topology and the limits of game engines. QFT!

Very interesting thread so far. A lot of good advice has already been given, but I figrued I'd throw my two cents in, as well. Some of this may repeat what some others have already said, but much of it will be new. First, let me show a few different ways I might UV a spool. The main thing to keep in mind as you look at the above examples is that a spool, topologically speaking, is no different from a torus. In fact, I made the above spool from a torus in Maya, in about 10 seconds. Before I talk about the UV's, I'll say a few things briefly about the model. This model is of course not as organically shaped as the one in the original post, but that's not the point. With a few more clicks to add some beveling and smoothing, it would look just like it. I decided to leave it in its base form, though, in order to most easily showcase the basic UV layouts, with as little distraction as possible. I did include the geometry of the inner wall of the hole (or more accurately, I did not remove it), so nothing is see-through. Alright, now let's dive into the UV's. The layout on the left is basically the default torus layout, with the horizontal edge loops proportionally spaced for minimal texture stretching. This is first layout one would expect a spool to have, and really doesn't NEED to be changed in any way. It's as efficient and simple as could be. The only very minor drawback to this layout is that the top and bottom of the spool will be very slightly challenging to paint in 2D, without any visible stretching or distortion on the model. Given that the OP is using zBrush, and so will likely paint the texture in 3D, this is probably a non-issue. However, if 2D painting is preferred, that's what the other two layouts are for. Read on. The layout in the middle is mapped pretty much how a cylinder would be mapped by default, with just a little rearrangment of the islands, to best accomodate the inside of the hole, while maintaining maximum canvas usage. This would absolutely be among the easiest possible maps for 2D texture painting. It's immediately obvious what goes where, and it leaves very little canvas space unused. The layout on the right takes utilzies the same cylinder logic, but reduces the amount of islands from four to two. In SL, this will reduce the download weight (assuming soft normals). Use of canvas space is maximized by rotating the whole thing by about 45 degrees, although it stil does leave more unused than the middle one. The biggest single advantage of this layout is that the texel density is almost perectly uniform across the entire model. There's virtually no stretching, anywhere. If uniformity is the goal, this one wins by miles. For 2D painting, some may find it slightly awkward to work at the 45 degree angle at first, but that initial discomfort should go away pretty quickly for just about anybody, once you get into it. And of course, for 3D painting, it'll be a breeze. So far, this all assumes that the goal is to use a single material for the whole spool. If we get into multiple materials, there are some other really easy possibilities. Here are a couple of examples: The extra materials allow more flexibility, but of course, they significantly add to the download weight in SL. So, as always, make decisions intelligently. All of these examples were created in just seconds or minutes, using a program that has excellent built-in UV mapping tools (Maya). As has been mentioned, zBrush's UV tools are not the greatest. zBrush isn't designed to be a one-stop-shop for 3D modeling, but rather is meant to be just one part of a larger toolbox. In a professional development pipeline, the primary modeling and the UV'ing, would be done in something like Maya or Max, and then zBrush (or Miudbox) would be used to add surface detailing and for texture painting. But of course, as was already mentioned, the average person in SL is not a professional, and is not likely to have access to the likes of Maya or Max, let alone be well versed in multiple applications. Everyone can afford Blender, of course, and for some, that's a great solution. (In fact, I'd go so far as to say that for most people, it's the best solution avalable, given how much better its interface has gotten over the last year or two. It used to be a nightmare, but now it's quite good.) Still, as it's a full featured 3D platform, rather than a specialty program, it remains bigger fish than some people would prefer to tackle. If you'd rather do all your modeling in zBrush, I'd suggest at the very least you grab yourself a stand-alone UV mapping program. There are good ones out there to choose from, some of which are free. Roadkill UV, for example, isn't a bad place to start, as freebies go. It's fast, and very easy to use.

You upload a sculpt map the same way you upload any other image: Build -> Upload -> Image, or ctrl-U. ETA: Whoops, looks like I misread your post. I thought you said you "can't figure out how to make the map upload to second life," meaning you had already made the map, and just didn't know how to get it into SL. I see now that what you actually said was, "can't figure out how to make the map to upload to second life," meaning you need to know how to make the map itself. Those two little letters make such a difference! Sorry about that. As Knutz said, the easiest way to do it is to use PrimStar. Or, if you're so inclined, you can create your own shader to map the XYZ values to RGB. That was how people did it before plugins like PrimStar were readily available. I'm guessing you don't want to do that, though, or you just would have done it, rather than ask. For what it's worth, I also agree with Knutz that just makng ordinary mesh models is, in nearly all cases, the better way to go. Sculpties are a kluge that were added to SL before it had support for arbitrary mesh. It was a way to get SL to do a little more with its exisitng architecture, while proper mesh support was still in the works. Sculpties have no place anywhere besides SL (and OpenSim), and barely have any place anymore even there. Generally speaking, you'll have a far easier time, and will produce much better looking results, simply by modeling the same way you would for any other platform, and exporting to COLLADA for upload to SL. Sculpties are barely worth your time.

Thanks for the heads up, Ackley. I'd just about given up on Autodsk ever getting around to releasing this, as it's been so long since they shut down Evolver. Looks like Autodesk's site is amazingly slow, compared to the old Evolver site, which is annoying, and there are a lot less options. It also displays far less information. For example, it doesn't tell you poly counts or bone counts, or anything else along those lines. Still, it's good that they finally have put it back online. When I get a little time to play, I'll output some models, and see how they compare with the handful of Evolver models I've got on hand. I'll be curious to see what, if anything, has changed.

It would help if you'd say what software you're using. In any case, it sounds like you've got the same texture assigned to both materials. If your software has a shader network graph, or a connection editor, go in and break the connection between the texture file node and one of the material nodes. If it doesn't have that kind of an editor, chances are you can do the same thing through whatever dialog you'd normally use for assigning textures to materials. In short, assign a unique texture file to each material.

Unless the models are radically different, chances are you can use the same weghting for all of them. Get one of them weighted properly, and then just copy the weights to the others. (Skin -> Edit smooth skins -> Copy weights)

Wow, that is indeed very interesting, Codewarrior. I had no idea you guys were having to pay so much more. The $3500 price is what it cost in the US last year. It went up a little this year. I guess maybe they haven't updated it yet on the page you liked. I cannot access that page from here to take a look. It errors out when I try. In any case, sorry to hear the European prices are so high. But hey, at least you have health care.

Victoria Squall wrote: Are there real life classes that I can take to learn how to make mesh like a community college or so somthing?Somthing that would teach me how to use the 3D software programs? Yes, Victoria, many colleges offer 3D modeling classes. If a community college near you does not, changes are high that a state university will, and the cost will likely be the same (depending on what state you're in). Private colleges and universities will likely offer it as well, but it will probably cost more. You can also look into adult education, corporate training centers, even some media production houses offer classes in off hours. Beyond that, there are practically unlimited resources, all over the web. Digital Tutors, Lynda.com, Gnomon Online, and many, many other sites offer excellent self-paced training courses. Some are subscription based, and some are free. There are also tons of books you can buy on the subject. If you decide to go with an Autodesk product (Maya or 3D Studio Max), it will come with incredibly good introductory training, and the best help documentation on this planet. (Part of the reason these programs are expensive is because the documentation is so good.) If you choose Blender, you can find a good set of online courses for free at blendercookie.com. If you feel college courses are the best option for you, I wouldn't get overly concerned about which particular software they're teaching (unless it's a total oddball). While the specific tools are different in each program, the fundamentals principles behind them are the same in all. Transitioning from one to another can be painful, but if you have a solid mastery of those principles, it's hardly a showstopper (especially if you're a hobbyist who isn't uder the pressure of project deadlines).

Codewarrior Congrejo wrote: (example: Maya Autodesk 2013 - single user license - windows - download version = 5.828,25 Dollar) I'm guessing you're not talking about US dollars, Code? Your number is about 60% higher than the current price of Maya, in US dollars. The actual number is $3675 for a single Maya license. The Creation Suites that include Maya are either $5775, $6825, or $8395, depending on what group of programs you want included with it. Your point still stands, of course, that the prices are out of range for most people. For professionals, it's a business investement that pays for itself in one or two jobs, but for hobbyists, it's generally not an option. For anyone who doesn't have thousands of dollars burning a hole in your pocket, Blender is the best way to go, by far.

Whystler Courtois wrote: I selected one vertex, and I rigged it at .001 (.1 %) weight to every bone that it wasn't rigged to. That's probably your issue right there. SL supports a maxium of four influiences per vertex. You've got a vertex with 26 influences. You seem to have misinterpreted whatever you read about the mesh needing to be rigged to all the bones. Assuming it was true information, all it would have meant was that all 26 bones must be correctly listed and accounted for in the COLLADA file. If a particular bone is not actually influencing any vertices that's fine; it just has to be there. It's also possible that the bone you moved could be screwing things up, depending on how you moved it. All bone rotations should be at zero. So you know, here are some additional common causes for the skinweights options to be grayed out in the SL uploader: 1. One or more bones is incorrectly named. Make suire they all have names like mPelvis, mTorso, mChest, etc. Some programs will add prefixes or suffixes to the names of imported objects. If that happened, make sure to delete the extra characters from the names. 2. Not all bones present in the COLLADA file. All 26 bones must be listed 3. Too many influences per vertex. As I said above, you can only have up to 4 infulences on any one vertex. 4. Wrong COLLADA version. SL supports COLLADA 1.4. If your exporter is writing to a different version, you can have all sorts of problems. 5. Wrong type of skeletal bind. SL supports smooth binds only. Again, I don't know enough about Max to know what other kinds of bind options it has. I'm sure some of our Max users here can comment more intelligently on this.