Chosen Few

Avant Scofield wrote: So, apparently alpha textures become ugly invisiprims when they're used on rigged mesh? This bug was first reported about a year ago, and it was one of those particularly odd ones that only seemed to affect some people. not everyone. I was never able to reproduce it, myself. It was supposedly fixed in a subsequent viewer update, not long after it was first reported. Your case is the first I've heard of it since then (although that doesn't necessarily mean it's the first instance of it in that time, of course). Out of curioisity, what viewer are you using? Have you tried looking at it in different viewers? Sometimes, detaching a rigged mesh, and then re-attaching it can solve certain graphical glitches; have you tried that? Also, what graphics card are you using, and how current are its drivers? What OS?

I'm glad it was just a borked scene, and not something more serious. As for the sizing issue, I'm guessing you probably haven't changed your working units in Maya from the default centimeters. SL wants to see meters, so if you don't change it, your model will be 100 times too small, in-world. To stop that from happening, you can reset the working units to meters in your Maya preferences (Window -> Settings/Preferences -> Preferences -> Settings category), or you can edit it after the fact in the .dae file. Or if it doesn't bother you, just resize in-world after upload. Now that you've explained a little more about your process, and shown a wireframe, I have some additional tips for you. First, I'd highly recommend you work directly with polygons, from start to finish. Otherwise, you're only making things a lot harder than they need to be, and you're creating a ton of extra work for yourself. If you're used to the constraints of NURBS modeling, the increased freedom of poly modeling will take you a little getting used to, as will the mesh-specific tool set. But once you do get used to it, you'll never want to go back. To give you an idea of how easy poly modeling is, you could have solved your curvature problem simply by inserting a couple of edge loops, rather than doing the whole conversion from NURBS all over again. Alternatively, you could have just moved some of the existing edge loops, in the same manner that you're probably used to moving isoparms when you work with NURBS. (To select an edge loop in Maya, simply double-click on any edge in the loop.) Also, so you know, it would behoove you to work with quads, rather than tris, for many reasons. One is that Maya isn't always able to determine edge loops with tris. Another is that when you need to subdivide, tris can get all kinds of messy. It's best to keep your geometry as clean, and easily manipulable, as possible while you're working. Once the model is done, go ahead and triangulate it, but not before. I also have to point out that your model looks extremely poly-heavy, for what it is. Because your source surface was NURBS, your polygon distribution is very even, in both directions. As a result, you've a ton of polys where you don't need them. For example, you don't need nearly as many sections around the circumference as you've got. You could safely eliminate at least half to two thirds of them, and circumference would still read as round. Additionally, the areas you labeled as "yuck" and "ew" and whatnot look perfectly acceptable for any real-time model. That's about the level of curvature one would expect to see in those same areas on any professionally created game model. Consider how small those areas will be on people's screens, and that they'll be surrounded by additional objects (the other locks of hair). Nobody's ever going to notice that they're a little bit angular. The edge loop your "mmm..." arrow is pointing directly at does not need to exist. The span that that loop transects is more or less straight. If you were to remove the loop, the model's appearance would not change in any noticeable way. There are a couple of others that could maybe go as well, but that one is the most glaring. All told, you could likely reduce the poly count by up to 75%, and the model would look just as good as it currently does. That would also allow you plenty of overhead to increase the curvature in the "yuck/ew" area, if you really feel it's a must. While we're on the subject of reducing poly counts, here's a quick public service announcement. I realize there are some mesh modelers in SL who seem to think unnecessarily high poly counts are some kind of badge of honor. They tend to say things that amount to, "Hey, check out this shiny new belt I made from 150,000 polygons. It looks so smooth. I did such an amazing job on it." They get a few pats on the back from fanboys who have no idea of the realities of how these things actually work, and they convince themselves they're gods among men. What those people don't realize is they're actually the laughing stock of the 3D modeling community at large. Sorry, but it's true. I encourage everyone not to fall into the same trap that those people have put themselves in. Folks, when your poly count is so high that at typical viewing distance your individual triangles become smaller than the pixels that draw them on screen, you're doing it wrong, very very wrong. There's no other way to say it. A great mesh modeler is one who has mastered the art of doing more with less. It's about using only as many polygons as you actually need in order to convey a shape convincingly, no more. It's about striking the best possible balance between visual fidelity and performance, at all times. It's about being mindful of the technical constraints of the platform you're modeling for, and doing what creates that best possible balance, on that particular platform. It's NEVER about just throwing more and more polygons at the problem until you simply bury it, rather than solve it. I really can't stress this point enough. Keep those poly counts as low as possible, at all times. Constantly look for ways to refine your models, and your own work procedures, in order to convey the same shapes with less polygons. The more effectively you do that, the better a modeler you are, and the more respect you will earn from your peers all across the 3D modeling world. (I know you're not one of the people I'm talking about, Avant, so please don't take offense that I happened to make the comment in your thread. I've just seen enough exposition from that crowd lately that it was on my mind.)

Thanks, Knowl. Regarding your point, about how some of the questions raised have been philosophical, ethical, moral, better aimed at the community than the developer, etc., please understand, it was not my intent to introduce any of those into this thread. There was plenty of discussion on all of that in the other thread, and I really wanted to keep the focus squarely on questions of the utility of the program this time. It just happened that some stuff from the other thread ended up bleeding into this one, for better or worse. Now let me respond to your questions. Knowl Paine wrote: Where in the Terms of Service, does it state that a person must protect other Users products? Oh, it doesn't, of course. Sorry for any confusion, as the conversation between the OP and me has unfortunately been spread across two different threads. I wish that had not happened. It's not surprising that it's a bit hard to follow. Let me try to clear it up. In the first thread, the OP was talking about offering his program as an online paid service (an idea he now seems to have abandoned). My comment about protecting customers' data was in regard to discussion we had had of that (hypothetical) service. I simply meant that if one endeavors to run an online service of any kind, and one does not take steps to protect users' data, one likely won't be in business very long. In other words, service providers have an inherent responsibility, both to their clients and to themselves, to take security very seriously. That's an entirely different subject than anything that is or is not in SL's TOS. Knowl Paine wrote: A person who illegally uses a Converter, is the Criminal; Not the person who made it. You're barking up the wrong tree. I fully agree with you that that's how it SHOULD be, but the US Congress does not. Under the Circumvention Clause of the DMCA, it is a federal offense to "manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof that... for use in circumventing a technological measure that effectively controls access to a work protected under this title." In other words, if your product or service circumvents DRM or other access controls, you are a criminal. Absurd as that may seem to you and me, it is the reality on the ground. Of course, the person using the product or service is also a criminal, as the law also sates, "No person shall circumvent a technological measure that effectively controls access to a work protected under this title." There are some exceptions built in for fair use, but they're not easy to use as a defense, far more difficult than other types of fair use claims that do not involve circumvention. You can read the full title at http://www.gpo.gov/fdsys/pkg/USCODE-2011-title17/html/USCODE-2011-title17-chap12-sec1201.htm . In the other thread, I cited the example of DVD decrypters. They have plenty of legitimate uses, but nonetheless, they are now illegal to create and distribute. You can find my full comments on that in the fourteenth post, in the other thread. It's the fifth comment section in the post. Had the OP gone ahead with what seemed to be his original plan, to run an online service capable of pulling sculpt maps directly from SL, I suspect the service could easily have been deemed illegal, under the Circumvention Clause, and he could well have suffered the same fate as companies such as 321 Studios. But now that the program has been changed to work just on locally stored sculpt maps, that's most certainly not the case, and he's got nothing to worry about. Since it is now a non-issue in this context, I wasn't planning to bring it up in this thread at all. I only mentioned it response to Helium's comment on the subject, since his (common sense) assumption about it was incorrect, just as yours was. Once again, I agree with you, and Helium, and pretty much everybody else I've ever discussed it with, that how it should be is exactly how you described. Only the person who misuses the tool should be at fault, not the maker of the tool. But whether we like it or not, how it should be is not how it is. If you want to see that changed, write your congressman. In the mean time, we all do have to abide by the existing law, whether we like it or not. Anyway, thanks again for your friendly, fair-minded comments, and for your engagement in meaningful discussion.

Madelaine McMasters wrote: Is the rain in Spain mainly in the euclidian plane? Only if the particle falls in an article written by someone smarticle.

emSynth wrote: Also, a few words are appropriate in response to Chosen Few's accusations. What accusations? I never accused you of anything at all, not once, ever. I don't know where you're getting this stuff. emSynth wrote: The threats were twofold. One person said that if I carried out my plans to offer a sculpt2mesh service, I should expect to hear from a lawyer, the obvious implication being that there could follow a lawsuit. You're kidding me. That's what you saw as a threat? Really? Wow. OK, let's recap what actually happened. You yourself mentioned part way through the discussion that many of the legal issues that had been raised were more complicated than you'd anticipated, and that some of what you had thought to be true of the law was incorrect. In response, I tried to help you by explaining some relevant need-to-know information, and I went on to suggest that you also keep keep an attorney on retainer, to help you deal with any and all legal issues that might arise. That's the exact same advice I'd give to anyone starting any new business at all. Now, is it true that you could potentially have been sued had you distributed a tool that would rip content from SL? Absolutely. Did I ever once imply that I would sue you? Absolutely NOT. And did anyone else in the thread imply that they would sue you? Not that I could see. For my part, it was quite the opposite. I was trying to advise you on how to minimize your risk. The whole thing was an attempt to help you, not threaten you. I really have no idea why you might have thought otherwise. emSynth wrote: The other was that someone might get angry at me and have a friend who was a hacker, and the implication was that I could expect to be hacked. That also was not a threat. Someone (not me) merely asked what safety measures your tool might have built into it, to protect her content from hackers, as at the time you were talking about running your service on a web server. That's a legitimate concern for anyone doing business online. How you went from receiving that innocent question to feeling that someone threatened to hack you, I simply cannot imagine. emSynth wrote: Rather than act fearfully as Chosen Few has suggested, I replied that I did not fear lawyers or hackers, and that their thinly veiled threats were ineffective. I did not suggest you act fearfully. I suggested you engage in the very same reasonable practices that anyone starting any new business should utilize. Having a lawyer on retainer is not fearful; it's the only smart thing to do. Taking measures to protect your clients' data from hackers is not fearful; it's your responsibility as a service provider. I would have thought all this was common sense. emSynth wrote: What Chosen Few has chosen to do is twist the situation around, implying that I am behaving in an unreasonable way. This is just one example of many such manipulations of the facts that clearly indicate deception and manipulation on the part of Chosen Few. Again, where are you getting this stuff? In the other thread, I was trying hard to help you, and in both threads, I simply asked you to explain the usefulness of the tool. Why you see fit to read more into it than that is beyond me. As for these "many such manipulations of the facts" you you feel so "clearly indicate deception" on my part, would you care to explain what any of them were? What is it you feel I've been deceitful about, exactly? What facts did I allegedly manipulate? And for what purpose? emSynth wrote: Yes, it does read like abuse because it is abuse. This is Second Life, Chosen Few, many of the participants of this forum are thoughtful and intelligent people who will read through your smokescreen of distorted facts and argumentative techniques. You are not helping your argument by behaving in this way. Please stop. Nobody abused you in any way, least of all me. If you feel otherwise, please tell me exactly what I said that you found offensive, and I'll be more than happy to try to examine it, to try to find where the misinterpretation may have occurred, and clear it up. I certainly did not try to say anything unkind. Same goes for the "smokescreen of distorted facts", as you put it. What facts did I distort? As I mentioned earlier, I've quoted you, word for word, each and every time I've responded to you, precisely to avoid the possibility of distortion. Do you really feel your own words misrepresented you? As I said earlier, if you feel I've misinterpreted any of your statements, go ahead and point them out. Tell me what I got wrong in my interpretation, and I'll be more than happy to take another look. As for the subject of whether I'm "helping my argument" or not, the fact is I was never trying to have an argument with you. I can't help an argument I was never engaged in. I tried to help you at first, and then I asked you a few questions about your product. Anything beyond that was introduced by you, not me.

emSynth wrote: Well, in regard to the issue of answering anyone's questions regarding the uses of sculpt2mesh, I do not see how I am responsible for that. It is a data converter. It converts one form of data to snother. It was a programming exercise to implement it. I gave the source code to the community. Those are the relevant facts and my responsibility ends there. Any arguments regarding usefulness or suitability for purpose may be carried out by others as far as I am concerned. I am not championing this tool or suggesting that you use it, I am just offering it to whoever wants it. End of story. emSynth Great. That's a perfect answer. If for you it was just a programming exercise, which you acknowledge may or may not be useful to others, that's wonderful. I congratulate you on the successful completion of the exercise, sincerely. That explanation does appear to run contrary to what you said in the other thread, and in this one, but I guess there's nothing to be gained in questioning that now.

Helium Loon wrote: Sorry, Chosen, but in this case I'll have to side with the developer of the converter. No need for apology, Helium. I'm glad someone is willing to engage in meaningful discussion about the potential value of the program. That's all I wanted. Helium Loon wrote: He did give answers. You don't like or agree with those answers. That's fine, but don't say he didn't give them. Let's be clear. I never said he did not answer. I said he did not answer satisfactorily. That modifier at the end of the sentence makes a world of difference. Here's my issue with the answers he gave. They did not meet the criteria of the questions that were asked. It would be like if I asked you what color the sky is, and you answered to tell me why color is better than black and white. Just because the question and the response were both about color wouldn't mean they fit each other. In that example, I would then have to ask you again, in order to try to get an answer that did actually fit the question. That's all I've been trying to do here. Helium Loon wrote: I have a lot of scuplt maps I've created over the years. I'm lucky if I can find the hard-drive they are on (if it even still functions!) Having the ability to deconstruct them to OBJ format isn't a bad thing. And sure, I could install Blender (if I didn't already have it) and take up 20-30 Mb of space and plenty of time downloading and installing. Or I could use a command line tool. And what about if I have a whole directory of sculptmaps I want to convert? I haven't discected the applescript to see if it handles wildcards, but a quick shell script could do that and call the script for each. Doing that through most plugin GUIs in a 3D modeller isn't possible. You're making some of the points I'd expected the OP would have made. I'm glad someone finally is. I'm still not impressed that the use you describe is entirely practical, though. It seems you've got three main points, which I'd love to discuss. These are that conversion of sculpt maps to OBJ isn't a bad thing to do, that the application is small and light weight, and that it possibly could be set up to handle batch operations, correct? Let take them one at a time. First, OBJ. This is one of my primary issues with the program. As we all know, since SL cannot import the OBJ directly, the file needs to be converted to COLLADA first. To do that, the user user would have to employ a 3D modeling program. With that being the case, use of the command line converter becomes a completely unnecessary extra step. The modeling program itself could do the conversion straight from sculpt map to COLLADA, all by itself. So why bother with the other program at all? Where's the benefit in using it? If the OP's program were to output to COLLADA, I'd have far less reason to question its usefulness. I'd still wonder why anyone might rather use it than a 3D modeling program, of course, but that would just be a head-shaker, not a showstopper. In summary on this point, it's all about the fact that one step is better than two. Second, hard drive space. Before we dive into it, let me make state a minor point of accuracy. My Blender installation is actually around 100 MB. Is yours really only 20-30? If so, I wonder what the difference might be. In any case, I'm sure you'd agree that if 20, 30, or 100 MB is a lot of space for somebody, they really have no business creating 3D content at all. This is 2013. You can get a full TB hard drive for all of $85. Heck, even the 5-year old Palm cell phone that I still have sitting on my nightstand as a clock wouldn't blink at the prospect of storing 100 MB worth of whatever. While in principle, I can't disagree that there's no sense wasting even a single byte, if you can avoid it. let's be real. In practice, 100 MB will never make the slightest dent in anyone's hard drive capacity. And practice is my main focus here, as I keep saying. Third, batch conversion. Great point. The ability to convert a folder full of sculpt maps into mesh models could certainly be useful. But I fail to see how this command line tool makes the process easier than just running a batch in any capable 3D modeling program. This is especially true when you consider that you expect you'll need to employ additional scripting in order to get the command line program to run the batch in the first place. You could utilize similar scripting in any full featured modeling program. While your answer here is leaps and bounds better than the OP's answer, and I'm now considerably closer to seeing a potential purpose for this app, I'm afraid I'm still not quite there. Helium Loon wrote: And it should be mentioned that just because something CAN be used in an illicit manner does not preclude its usefulness outside illicit activities. VCRs and now DVRs both have illicit uses. But they also have perfectly acceptable uses. And while there are other ways of accomplishing the same activities without using them, that doesn't always mean it is the most efficient, or the most convenient. That's all well and good, but nobody said anything about using this tool for nefarious purposes. A few people in the other thread did raise questions about copyright concerns, but they were only questions, and they haven't resurfaced at all in this thread. The OP seems to want to react at times as if he expects people to go there, but really, no one has, and I don't expect anyone will. That's just not what this discussion is about, at least not from my end. That said, since you brought it up, I do have to say there are unfortunate legal realities these days that sometimes creep up, in defiance of common sense examples like the VCR and DVR. Under the DMCA, it is now a federal crime to distribute a product that can be used to circumvent digital rights management. I'm sure you and I both agree that that particular point of law is absolutely ludicrous, but our opinions aren't what matter. The law has teeth, and it's been used to shut down plenty of products and services that also had legitimate uses. In the other thread, I mentioned to the OP that if someone were to argue that DRM circumvention (such as ignoring the SL permissions system) is what this tool is for, the he might find himself in trouble. At that point, he was talking about making a business out of it, and it was implied that the tool would be capable of ripping sculpt maps directly out of SL, without regard for in-world permissions. Now that it's clear that the tool only works on sculpt maps the user already has on the local hard drive, that particular potential danger for the OP is almost certainly a non-issue. Helium Loon wrote: And even if there were no particular use for it, it can serve as a basic algorithm for those wanting to understand how to write their own utilities for dealing with sculpt maps. *shrug* If that's the case, great. The OP certainly could have said so. If he'd even said something to the effect of, "I don't much care whether it's useful. I just wanted to do it just because I wanted to do it," that would have been a perfectly acceptable answer. He's been presenting it as something that does have practical use, though. So naturally, I asked about that. He promised to get back to me, but never did, so when I saw him pop up again with a new thread on the same topic, I asked again. I don't understand why anyone might think there's anything wrong with that.

I'm assuming these are purple warnings, not red errors, correct? When Maya says something in purple, it basically means, "I shouldn't have to do this, and I really don't want to do it, but I'll do it. Just don't blame me if it breaks." When it says something in red, it's pretty much, "Oh, hell no!" In this case, it sounds like the FBX plugin, for whatever reason, doesn't like the transform node that it itself wrote when it exported the file. The warning, if I understand it correctly, is simply informing you that Maya is disregarding the node, and applying the translation, rotation, and scale info directly. What options do you have enabled in the exporter? When you select each of the objects before export, and after import, what nodes are present in the attribute editor? What does your scene heirarchy look like? Are objects perhaps parented under null nodes? If disecting the scene further isn't your cup of tea, here's a band-aid approach that will probably work. Export to OBJ, and then import the OBJ into a brand new scene. Since OBJ can't include anything other than geometry and materials, problems related to scene structure and such should go away. Sometimes that's the best way to clean up a borked scene. By the way, does this problem happen with eveyrthing you export, or just with this one?

I've got nothing substantial to contribute to this thread, but I did have to chime in to say I absolutely love the title. "Is there rain without particles?" I feel like it should be the title of a great work by a philospher poet, or a theoretical physicist, or both.

Avant Scofield wrote: Hi again Chosen You're still here being helpful as ever after so many years. LL should really be throwing money at you for this. Heh, wouldn't that be nice? Avant Scofield wrote: I went ahead and tried your suggestion, but no dice. Downloaded this guy: http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=16126812 and did the conversion, yet I still get the same tiny mess. Hmm. I guess it's not a COLLADA version problem, then. What happens if you import the results back into Maya?

Knowl Paine wrote: Valid questions have been asked, and the OP answered. If you don't like the code, don't use it. The thread reads like it is harassment. The questions have been asked, yes, but not answered satisfactrily. There's nothing wrong with asking for better answers. It's not about liking or disliking the code. It's about how the tool could possibly be useful for legitimate purposes. If so much as a single use that is both legal and practical can be cited, we'll no longer have a need to keep asking. But this has been going on for almost a month and half now, and no one, least of all the OP, has been able to come up with one. Perhaps you can? As for harrassment, had anybody made the threats that the OP imagined out of thin air in the previous thread, then yes, that would have been harrassment. But nobody did. In fact, no one has said anything even remotely rude or unpleasant to the OP in any way. All any of us have done is request information, in good faith. I'm sorry if you don't see it that way, but that doesn't change what it is.

Glad to hear things are going better, Spinell. To answer your questions: Spinell wrote: How do you paint the inside of the mesh when your brush can't really get in there I'm not completely certain what you mean by "inside". If you mean you've got hidden polygons that won't be seen, the answer is don't paint them; just delete them. It's never a good idea to waste resources on anything that people won't see. If you mean the avatar is wearing more than one garment, and they're each meant to be individually removable, then paint them one at a time. Turn off visibility on the outer ones, in order to get to the inner ones. If you mean you were thinking of painting the backfaces, there's no need for that. If you meant something else, please explain. Spinell wrote: and do you need to add weights to the pelvis bone? It depends on the model, of course, but usually the answer is yes. The pelvis is the root of the skeleton, so the things that should be weighted 100% to it are whatever areas of the skin that you want to be absolutely unmoving, not influenced by any pull from the extremities or upper body. On a nude human model, this would generally include the tailbone area, some parts of waist, the perineum, possibly some of the lower abdomen, etc. On a poofy Victorian skirt like the one in your picture, you'll probably want a good portion of the upper part of it to be married to the pelvis. In RL, that area would be held up by a bustle, and so would be quite rigid. The lower portion would be only minimally impacted by the legs, since the fabric drapes so far from them. Women wearing those dresses tend to appear almost to float, more than walk, across the ground. I'd suggest, therefore, that the lower portions of the skirt be heavily weighted to the plevis, and just very lightly weighted in the front to the ankles and knees. The effect will never be truly realistic looking, though. In RL, the front of the skirt gets kicked as the woman takes each step. It flies forward a bit, in response to the kick, and then falls back to its passive vertical hang afterward. There's no way to replicate that in SL. Also, sitting will likely break the illusion completely, so you might want to include a second version of the skirt, modeled in a seated pose, and swap visibility between the two versions. Once again, a perfect rig is out of the question. The best you can do is a half decent one.

Thanks for the kind words, Devriv. Much appreciated.

Avant Scofield wrote: No, I get an error from the Collada exporter when I group anything. I just select all parts and Export Selection. That sounds about right. See my other post from a second ago. Avant Scofield wrote: I'm using Maya 2013 with the included DAE_FBX exporter. Chances are your exporter is writing the wrong COLLADA version for SL. Try exporting to FBX, and then use Autodesk's stand-alone FBX Converter (free to download from Autodesk's website, if you don't already have it) to convert the file to COLLADA 1.4. If that works, then you can be relatively certain the problem was indeed the COLLADA version. You can then try installing an older COLLADA plugin (2011 or older). Assuming you get the plugin to work, it should solve the problem. If not, the FBX Converter only takes a second. It's less than ideal, of course, but hardly a showstopper.

Vendetta Fhang wrote: When you imported them seperately were they at least grouped together in maya? If they were grouped in Maya, that might be part of the problem. COLLADA exporters don't always understand heirarchy, and among those that do understand it, not all will deal with it in a way that SL can understand. Whenever you're creating content for any external platform, it's best to avoid using anything that actively transforms or modifies the objects in the scene. Heirarchy is one of those things. To keep your scene organized, use layers instead of groups. Layers are just a part of Maya's GUI, are entirely passive, and are completely ignored by exporters.

What version of Maya are you using, and what exporter?

emSynth wrote: Alright, I'll tell you what. I am sick and tired of dealing with people who blindly insist on arguing the lost position that a data converter has moral implications. Who said anything about moral implications? I certainly did not, and neither has anyone else here. I do have to say I find it very interesting that that's where your mind went. Do you think there's a moral argument that should be had? Once again, I simply asked you to cite a use for your program that is both legal and practical at the same time. That's really not a lot to ask, and it's absolutely nothing for you to get bent out of shape about. As I said several times already, if you believe in your product's usefulness, you should welcome the opportunity to talk about it. emSynth wrote: What's done is done, the cat is out of the bag, the source code has been released. Now you have to deal with the reality of the situation. The only one who seems to be ignoring the "reality of the situation" in this discussion is you. I'm asking you to explain the usefulness of your program, nothing more and nothing less, but for reasons that escape me, you seem to keep wanting to turn that discussion into something it's not. Last time it was imaginary threats that no one made. This time it's questions of morality that nobody's raised, or even implied. Care to explain your thinking on that? emSynth wrote: I suggest you do so rather than attempt to put words in my mouth, paint me in a bad light by taking my words out of context, or craft imaginary scenarios implicating the criminalization of this inevitable step forward. Words in your mouth? Really? I've been working from exact quotes, the entire time (as always), precisely to avoid doing that. If you feel that I have misinterpreted your meaning on anything you've said, please explain, and I'll be happy to reassess. I'm sure the same is true of everyone else here. Bottom line: if your tool is indeed useful, we'd all love to use it. If it's not, we won't. It's that simple. emSynth wrote: And if that isn't enough to fry your noodle, try this one on for size. There exist three types of objects in Second Life and the rest of the Metaverse: prims, sculpts, and mesh. That means that there exists the possibility to create a total of six categories of object data converters. These are listed above. Eventually all of them will exist, to one degree of automation or another. I suggest you prepare for the inevitable. emSynth I hate to burst your bubble, but just about all of these already do exist, and have for many years. Perhaps you were unaware of that. Allow me to explain. Prim to sculpt - There have been in-world solutions for this since just a few months after sculpties first hit the grid. I myself have never had cause to use one, but from what I understand, they are useful (with varying degrees of success) for people who don't care to learn 3D modeling software, and would rather work entirely in-world. Prim to mesh - There are in-world solutions for this as well. Again, I've never used one, but I can see the utility in them, for those who don't want to use real modeling software. I think it's a shame that there are people who insist on keeping themselves in such a handicapped position, but that's another subject. Sculpt to prim - I've never heard of an automated solution for this, so yeah, it would be a new one. I can't imagine how it would be in any way useful, though. What possible advantage could there be in replacing a sculpty with a bunch of prims? If you think it would be useful, I invite you to explain how. Mesh to prim - There have been countless solutions for this, over the years, almost all of which have been highly useful. Before sculpties, and way before mesh support, this was the only way to build for SL in external 3D modeling programs, after all. I could go on all day listing the various plugins and data converters that people came up with for all the major 3D modeling programs. There were lots and lots of builds in SL that were created this way. (Along similar lines, I'll mention I used to use an OBJ replication system a lot, which was developed by SL resident Jeffrey Gomez, back in 2006. It would reconstruct the triangles in an OBJ file with prim triangles in-world. As long as the source model was built intelligently, the system worked brilliantly. I routinely used to use it to create complex curved surfaces in SL that could not have been done practically in any other way at the time.) Mesh to sculpt - Well, this one's just a given. Every sculpt map exporter in every program converts mesh data to sculpt map data. So, "the inevitable," as you put it, has long since arrived. I'm not sure why you think "preparation" would have been needed beforehand, by anyone. The tools were developed, and those who found them to be useful used them, while those who didn't find them to be useful did not use them, just like with any other tool that's ever been created in the history of the universe. Once again, all I'm asking you to do is explain how this tool that you've created is indeed useful. For that, I've requested that you to cite at least one example of a case in which the program would be both legal and practical to use. Thus far, you've been unable to do so. Can you? Will you?

emSynth wrote: I do not recall making any "promise" at all, however I am happy to list some legitimate uses of the sculpt2mesh tool. Thank you for responding. Allow me to refresh your memory. The promise I spoke of was in the link I posted. In case you don't feel like clicking the link, here's the relevant excerpt. Your exact words were: "Chosen Few, I have read your post and I will be happy to explain the advantages of using sculpt2mesh, however at the moment I am going to hang out with some friends... Have a grat evening and I will get back to you as soon as I can!" That's where we were five weeks ago. Let's not dwell on it, though. I'd rather focus on where we are now. Again, thank you for responding to my question here. While I do appreciate the response, I also have to say that I find your answers a bit bewildering. Allow me to address them, one by one. I have comments and questions about each. emSynth wrote: One is the situation where a resident has created a sculpt using a tool that does not have mesh output. OK, but how is your program, which requires command line input, and which can only run on a Mac, more beneficial than simply importing the sculpty into a 3D modeling program, and then exporting it to .dae (or whatever other format one may choose)? Seems to me, the two clicks needed for import and export are a heck of a lot simpler than the command line. What am I missing? emSynth wrote: Another is when the source materials, tools, or computer, or operating system used to create the sculpt are no longer available. I'm not following you on this one at all. As you must know, all that is needed to recreate a sculpty is the sculpt map itself. This is just as true with your program as with any other. In this context, whatever source materials, tools, etc., may have been used in originally creating the sculpty are completely irrelevant. How exactly do you feel your program makes any difference, in this regard? emSynth wrote: Yet a third reason is when a resident has permission from the sculpt creator to perform the conversion. You seem to be trying to express circular logic on this one. How does simply obtaining the creator's permission to use your program constitute a practical need for using it? Permission simply makes the use legal; it doesn't create need. The same exact permission would be legally required, no matter what program or technique is being employed. So, the question again becomes what does your program bring to the table that a simple import/export operation in any capable 3D modeling program does not? emSynth wrote: A fourth reason is when it is desired to enhance the sculpt with one of the advntages of mesh (which at your request I will not list here). In order to enhance it, one would need to edit the model a 3D modeling program. In such a case, the modeling program itself would handle the conversion, so how would your program be of aid? emSynth wrote: A fifth reason would be to add detail or sharpness to a sculpt beyond the capability of sculpts. Same question as above. In order to add details to the model, one must edit it in a modeling program. Once again, how would your program possibly play a role in that process? emSynth wrote: Sixth, one might wish to combine two or more sculpts together or combine with a prim2mesh tool (which I have also created), thus turning any SL object into a mesh only object. Are you saying that your program can take two or more sculpt maps at once, and automatically combine them for output as a single mesh object? That wasn't mentioned in your usage instructions. If that's indeed the case, then I'm having a really hard time imagining how a command-line-only program can do the task more easily than a modeling program with an actual GUI. The size, rotational, and distance relationships between the various objects would need to be defined, as would the UV mapping and material assignments. Why would anyone want to do all that via text command, rather than visually? emSynth wrote: There are six reasons, all legitimate, and I am sure there are more. Unfortunately, by my count, we're still at zero, not six. My definition of "legitimate" required both legality and practicality. You've posed some scenarios under which us of your tool could be legal, but I have yet to see you state any under which it would also be practical at the same time. I don't see anything in your list that couldn't be done far more easily via a few clicks in any modeling program than via text in your command line. Got any uses in mind that do fit both requirements? emSynth wrote: Please do not be afraid of a simple data converter. What on Earth makes you think I'm afraid of it? That didn't even cross my mind. I cannot imagine why it ever would. I simply asked you to explain why your program is worthwhile. I'm sure you'd agree, that's hardly an outlandish request. I'd ask the same question if you were showing me a new car, or a new TV, or a new anything else that I might use. Explain why it's a good idea that will save me (or the general public) time, money, effort, etc., or at least increase my enjoyment, all without breaking any laws or infringing on anyone else's rights, and I'll happily be onboard with it. Anyone presenting any new product that he or she truly believes in should jump at the opportunity to make such a case. When you instead turn defensive about it, you imply that you don't really believe your product does any of those things I just mentioned. Your statement (plus your earlier words in the other thread, about imagined threats and whatnot) suggests that it is you who are afraid of the question. emSynth wrote: When Linden Labs introduces a new technology there are always implications, not all of which are viewed as favorable by all people. I'm not sure why you mentioned this. First, your program wasn't introduced by LL. It was introduced by YOU. Second, mesh isn't exactly "new" technology. It's the oldest form of 3D content there is. SL's support of it happens to be relatively new (although it's already a few years old now), but mesh itself has been around for almost as long as graphics-capable computers have been around. I think you may be missing the point of the questions that I, and others, have asked about your program. This isn't about anyone's opinion of mesh, or of sculpties, or of mesh vs. sculpties, or anything of the sort. It's only about asking you to explain how your program could be beneficial to users, in a manner that is both legal and practical. Once again, if you believe in the product, you should welcome the opportunity to explain exactly that, without assuming people are fear-mongering. Keep in mind, if people weren't interested, they wouldn't ask. Questions like this are postive, always. emSynth wrote: Rest assured that sculpt2mesh will not replace sculpts, as sculpts are the clear choice for many applications, especially in terms of land impact, but also for other reasons. Again, I'm having trouble following your apparent line of thinking. Why would you assume I thought your program would replace sculpts? That doesn't even make any sense. In order for your program to exist, sculpts have to exist. That's just elementary, isn't it? That said, if sculpties were to disappear from the grid tomorrow, you certainly wouldn't see me shedding any tears over it. Sculpties resource-inefficient, overly complicated to produce, and just plain wacky. At the time they were introduced, they were a clever solution, implemented by an exceedingly clever man, to make the most of SL's then limitations, but the truth is those limitations never should have been there in the first place. If it were possible to redo the last ten years all over again, I'm sure no one would disagree that SL should have had mesh support at the very core of its architecture, since day one. Sculpties never should have needed to exist. The entire rest of the 3D modeling world is all about mesh, has been for decades, and will continue to be for decades to come. The fact that some SL users seem to think it's this newfangled thing that LL came up with is beyond laughable. In any case, SL is what it is, and yes, sculpties do still have their place. Circumstances under which they are still advantageous to use are quite narrow, but not entirely non-existent. I'm not sure what any of this has to do with the subject at hand, though, which is your particular conversion program. If there are uses for it that are both legal and practical at the same time, great. I'm still having trouble thinking of any, though. emSynth wrote: Fear not The turning wheels of progress! Of course. Progress is to be embraced. I'm not sure why you keep circling back to fear as the emotion to associate with any of this. I guess your mind works differently than mine, in that regard. I just have to question whether the development of a product for which no legitimate use can be posited can be defined as "progress". As I've said many times now, show me how it's both legal and practical, and you'll have my full support.

I'm still waiting for you to explain how you envision this to be useful for legitimate content creators. You promised you would explain five weeks ago, but you never did. Many of us asked questions in that other thread. You at first appeared to be receptive and open to discussion, but after a short while, you said you felt threatened (for reasons I don't think any of us understood), and then you simply stopped responding. Now that you're back, I hope you'll be willing to pick up the discussion where it left off. Once again, I have to ask, what is the (legitimate) use case for which you feel your process will be helpful? As I mentioned throughout the other thread, I can only think of two use cases, myself, and neither of them are positive. One would be if the user does not own the sculpt map, in which case the use of your converter (or any converter) would be illegal. The other would be if the user does not know how to use 3D modeling software, in which case he or she almost certainly would not be able to make use of the resultant OBJ model that your program spits out. So, as I asked several times in the other thread, what is the third use case you envision, which I have not thought of, which is both legal and practical? As a reminder, I'm not asking you to cite the many advantages of mesh vs. sculpties in general. That's a given, and we all already know all about it. What I'm asking for is an explanation of how your tool could benefit actual human users. You promised you would explain. Please keep that promise.

Evhalyn Serpente wrote: Edit* So after scrolling through the forum I am hearing "Aditi" mentioned a lot, I assume this is where I need to head (how)? please. Just to be sure you understand, Aditi is he beta test grid. You can upload things to it for free. It's not exactly the "temp mesh" feature you asked about -- that doesn't exist -- but it will allow you to test your creations in-world, without cost. As Aquilla mentioned, you will see L$ appear to be deducted from your in-world balance. But don't worry, none of the balances in Aditi are real. It's just play money on that grid. Your real balance on the main grid won't be affected. Also, you should know the balances on Aditi are reset regularly, so don't worry about running out of the fake money. You'll get more.

Spinell wrote: I hate rigging. Don't take this the wrong way, but that's the number one problem you NEED to solve, before you even try to tackle anything specific that went wrong with this particular rig. Hating it is always a result of not fully understanding it, and you'll never become good at it if you don't understand it. Once you do understand it, there's really nothing about it worth hating. The key thing to realize is that rigging is just like any other part of the 3D modeling process. Just as with all things in the digital arts, it is 50% technical, 50% artistic, and it only becomes highly enjoyable, once you resolve to embrace it equally from both sides. If you see it as just one without the other, it's inevitably a horrible experience. Without the artistry, it's tedious, and without the technical, it's nebulous. In either of those scenarios, it's painfully frustrating. But when you approach it properly, the experience is engaging and gratifying. From what you've written in your post, it sounds to me like you've been over-valuing the technical, and almost completely ignoring the artistic. So, OF COURSE you've been hating it. You simply can't enjoy it under those circumstances. No one could. Now here's the good news. You WILL find that when you accept rigging as both an artistic process and a technical procedure at the same time, it instantly becomes fun and rewarding, and the difficulties and frustrations you've been hampered by thus far will simply vanish. Then, and only then, will you find yourself getting consistently great results. My best advice to you right now is to let go of everything you know, or think you know, about rigging, and start over, mentally and emotionally. I know that's easier said than done, especially if your dislike of it has been festering for a long time. But really, it's the only way you'll be able to become effective. Bottom line: anyone who can't bring him/herself to learn to like it for what it is just shouldn't be doing it. If you're going to be doing it, you MUST learn to enjoy the process of it, both artistically and technically. Spinell wrote: I've never been able to perfectly rig any of my meshes. Before you beat yourself up too badly for that, you may want to consider that no real-time rig will ever be perfect. This is especially true when it comes to SL, since the platform allows so few options. There will always be things that cannot work flawlessly. For example, without a cloth solver in place, or at the very least, the ability to add bones to the skeleton, there's no way to well simulate flowing or loose-fitting fabrics. Without a dynamic system for muscle simulations or morph target animations, there's no way to make the various body parts deform realistically as they move. The list goes on and on. The limitations we have to work with are extreme. The best you can really achieve in SL at this point is a semi-passable rig. A really good rig, let alone a perfect one, is entirely out of the question. That said, you can, of course, attain far better results than what is shown in the picture you posted. You're just going to have to be willing to get your hands a bit dirtier than it sounds like you have been up until now. Read on. Spinell wrote: 4. Use the bone-weight copy script There's your main culprit, right there. You're looking to an automated one-button action, and expecting it to act as a solution to what ultimately is an artistic problem that requires a human touch to solve. Remember, rigging is an artistic process to be practiced and applied, not just a button to be pushed. Copying weights is only a first step in what needs to be a multi-step journey. You now need to finish the job with additional (basic) techniques. Your first task, if you haven't already done it, is to develop your weight painting skills. This is an absolute MUST. I simply cannot stress the point enough. Expecting to be able to rig successfully without becoming an accomplished weight painter is like expecting to be able to cook without first knowing how to boil water, or expecting to be able to read and write without first learning the alphabet. Yes, it's that basic, and that crucial. There's absolutely no way around it (nor should there be). I'm afraid I won't be able to dive into specific how-to's for Blender, since I'm not an active Blender user (Maya is my weapon of choice). However, I can certainly give you general pointers that apply equally to all programs. In most cases, you'll find that the weighting process works best when you start from the extremities, and work your way inward. For example, start by painting a hand to be 100% weighted to the wrist joint. You'll inevitably bleed a little onto the wrist skin area of the forearm. Just let that happen. It's a good thing. Now, paint over the whole forearm, additively, to weight it to the elbow joint. You'll add elbow weight to the parts of the forearm that were already weighted to the wrist, and a little bit of that bleeding from the hand will remain. That's exactly what you want. If you did it right, you'll now have a perfectly functioning wrist. If the wrist area distorts badly as the wrist bends, that's a sign that you haven't yet weighted the area strongly enough to the elbow, so just add a bit more paint. (Those wide sleeve cuffs in your picture, by the way, should likely be weighted 100% to the elbows.) Repeat the process, working up the chain, from wrist to elbow, from elbow to shoulder, from shoulder to spine, and you'll have a well rigged arm. Do the same for a leg, starting at the toe, then working to the ankle, to the knee, to the hip, to the pelvis. Finally, do the head, then the neck, then each spine joint, all the way to the pelvis. You'll find that by working this way, from the outside in, you'll get good results, fairly quickly. I do not recommend trying the opposite, working from the inside out, as you'll end up having to subtract weight instead of adding it, and then you lose a lot of control. You can end up spending all day playing whack-a-mole with stray vertices that won't cooperate. As soon as you squash one subtractively, another pops up to misbehave somewhere else. By working from the outside in, entirely additively, you'll never encounter that kind of trouble. A rig that might have taken you a whole day or more to do subtractively can be done additively in an hour or two, or in many cases, just a few minutes. To put it in terms of hierarchy, it's always more effective add your way up from the bottom of the chain, than to try to subtract your way down from the top of the chain. If any of what I just said does not make sense to you yet, that's OK. Consider it confirmation of what I said earlier, that you really do need to reboot your rigging experience, beginning with the very basics. There are plenty of tutorials on the Web for weight painting in Blender, and there are lots of Blender users here on the forum, who can help you with the program specifics. So you know, getting that dress from where it presently appears to be, to where you want it to be, constitutes only a few minutes worth of work, once you've got a mastery of the basics of weight painting.

Jennifer Boyle wrote: I do wonder about one thing: Why would it be more important tor LL to be able to identify up loaders of meshes that infringe copyrights that to indentify uploaders of infringing proms or images? Very good question. The answer, of course, is that all types of assets are equally important, and LL really should have required ID verification for all uploaders, all along. (In fact, if you scour the forums for previous discussions on this topic, you'll find a few posts from various Lindens, in full agreement with that sentiment.) It just happens that they didn't think of it way back in the beginning, and they didn't implement a system for it until mesh support came along. Had SL been launched now, instead of 10 years ago, it's very likely that everybody would be required to verify before being allowed to upload anything at all. I'd imagine there's probably a healthy debate among policy makers at LL these days about how, when, and if to expand the verification requirement from uploaders of mesh content to uploaders of all content. Obviously, those of us who are concerned about IP rights would welcome such a change. But of course, the potentially huge down side of that is that people like the OP, as well as people in certain countries, wouldn't be able to upload anything. It's not an easy dilemma to resolve.

Lutricia Roux wrote: I export the skin weight maps, fix the UVs, import them back and try again. I'm not sure why you chose to go about it that way. Exportation of the the skin weight maps is only necessary if you're going to detach the skin from the skeleton, and then re-bind it later. Did you do that, and just forget to mention it, or did you not do it? So you know, you don't actually have to detach. You can adjust the UV's while the model is still rigged. It's hardly the recommended approach, but you can do it, as long as you don't perform any operations that might conflict with the existing history. Be sure to delete non-deformer history very often, as you work, and absolutely remember to do it at the end. The only history that should still exist when you're done is the deformer history (so the skeleton can function). To avoid conflicts, it is often better to make a copy of the model, make your UV changes on the copy, and then after you're done, copy the UV's over to the original. This way, there's far less chance for things to get borked, since you're only making one big change to the original, instead of a million little changes. You'll still need to delete non-deformer history afterward, of course. Lutricia Roux wrote: Q1: This step puzzles me, should this really be possible, isn't the skin weights reliant to the UVs and the actual rig would be destroyed now by me editing the UVs after the actual weight painting? If you altered the UV's on the model, then the old weight maps should no longer have been applicable. Something must be missing from your description of what you did. Did you perhaps add a second UV set? If so, you could have kept one set for weight mapping, and used the other for texturing. This, just as above, is another example of where making a copy of the model could have been the best solution. After the UV changes were done, you could have copied weights from one model to the other. The Copy Weights function doesn't have to care about UV's, and since you weren't altering the actual geometry of either model, you would have gotten a perfect 1:1 projection from one to the other. Lutricia Roux wrote: Q2: Do anyone have an idea of what it is that makes Maya crash on export like this? I never experienced similar. Without examining your scene file, I can make some educated guesses as to what might be going on. My first guess is the one I already mentioned. Perhaps you've got multiple UV sets in place, and the exporter doesn't understand the structure. Another possibility is that in having done so many things out of the typical order, you may have created a mathematical impossibility somewhere, which Maya is unable to resolve for export. Every Maya scene, under the hood, is a large database of equations and variables. When you perform operations out of order, and especially if you don't delete history at the right times as you go, it's easy to create paradoxical situations, in which the math simply can't work anymore. I probably don't have to tell you this, but to avoid such problems, you should do things in the expected order. If you find you need to make changes later that go out of order, whether because you forgot to do something or just because you changed your mind about something, you should take whichever path is least likely to cause conflicts. If I were to find myself in a situation in which I needed to alter the UV mapping and material assignments of an already rigged model, here's how I would handle it: 1. Make a copy of the model. Set it invisible, so it can't be messed with, and leave it alone, for now. 2. Detach the original skin from the skeleton. Delete history. 3. Make the needed changes to the UV map. Delete history. (Note: This would be a really good spot for an incremental save, if you haven't been doing them regularly all along. Save the scene as a new file, with the same name, but with a number after it, such as _001.) 4. Make the needed changes to the materials. Delete history. (This would be another really good place for an incremental save (_002).) 5. Bind the skin to the skeleton. 6. Make the copy visible, and copy weights from it to the original. (_003) 7. If you're satisfied that the original is now functioning properly in all respects, delete the copy, and clean up the scene. (_004) 8. Now you can safely export, and upload. Of course, it's also possible that the scene file simply got corrupted, through no fault of yours at all. It happens. Either way, it's crucially important to do those incremental saves regularly as you work, so that if and when there is a problem, you can step back to an earlier version of the scene, from before the problem existed. That way, you only have to redo some of the work, instead of all of it. Lutricia Roux wrote: Q3: Suggestions of things to try to enable to export, is it my computer lacking enough memory, can I alter some settings in Maya etc? I think it's unlikely that the problem has to do with computer memory or Maya settings. Since the weight maps worked when they shouldn't have, and since problem started after material assignments, my best guess, again, is that you've got multiple UV sets in place, and possibly something in your shader networks is royally messed up, as well. If you want to try to save the scene, I'd suggest you dig deeply through your UV set editor, hypergraph connections, outliner, and hypershade, to look for anything that might be out of whack. If you find anything at all that doesn't absolutely need to exist, nuke it. If you find any improper connections, break them, and reestablish them correctly. Etc., etc., etc. Of course, this assumes that you already know what all the correct structures should look like in the first place. If this kind of thing is beyond your knowledge or comfort level, don't attempt it, because if you don't know exactly what you're doing, you could easily make things worse. It doesn't take much to utterly destroy a Maya scene, if you just start poking it with a stick. Sometimes, the best solution is simply to start over. You mentioned the model isn't terribly complicated. Chances are it won't be difficult for you to recreate, then. And the good news is you're all but guaranteed to do a better job of it this time around, since you're now intimately familiar with what mistakes not to make. You'll certainly UV it, and get all your materials in order, before you rig it this time.

There's only one skeleton. There's no such thing as "male" or "female" with regard to it. All that happens to it when you change your avatar's gender is a few bones move. It's just a change of pose, not a change of actual skeletal structure. For example, when you change from default female to default male, the hips narrow, the shoulders widen, the height increases, along with some other really minor tweaks. The skeleton you've got is in the neutral bind pose. It happens to fit the default female shape just because the avatar model itself happens to be female by default. The model is called Ruth. There is no separate male avatar model. Every avatar variant, whether male or female, is just a morph of Ruth. Some of the morphs include changes to the skeleton's pose, some don't. None make any changes to the skeleton itself. If you want your mesh model to use a pose other than the default for its bind pose, that's what the joint positions option is for in the mesh uploader. While it might be useful to have the default male pose as a preset option, it's hardly necessary. If you really want that pose, you can create it yourself. Or you can just leave the default alone, and not worry about whether it happens to be labeled "female" or "male". All that really matters is that it's a functioning humanoid skeleton. The outward appearance of the mesh model can be male, female, space alien, robot, manbearpig, or what have you, no matter what the bind pose happens to be named. The word "female" in the appearance editor is just the label for the bind pose. It doesn't mean anything beyond that.

There have been a lot of unfortunate rumors about this, over the past couple of days. The whole thing is a gigantic misunderstanding. Adobe is not giving away CS2 or any other Creative Suite products. All they did was change the license activation process for CS2. You still need to have purchased it in order to get it. See post 7 of this thread for details, and a link to a statement from an Adobe staffer.