Alex Carpenter

I just wanted to add in my two cents here. Similarly to what another user was suggesting, I think it could be neat to integrate product vending into the core of the SL experience. Perhaps one way to do this would be to add special LSL functions to link into a marketplace store and allow purchasing and redelivery in-world. I have no idea what this would look like to implement, but I think doing some work on reducing script burden so events and other places with a lot of in-world vendors running can operate more smoothly would be beneficial.

The problem with gachas and the problem with the 'conveyer' proposition is that it exploits customers in the same way. It's not delivering the content the customer wants to buy, but a randomized chance that they will get the item they want. And that will, in a large number of cases, cause the person to unintentionally spend more than they intended. The only difference between gacha and 'conveyer' is 'when' the randomization occurs. Moving the random aspect one step back does not change the fact that the way many, many merchants use this has more in common with a slot machine than anything else it's argued to be. I think people defending gachas and whatever this 'new' form it is are just accustomed to the income that comes from making customers gamble instead of selling them what they want to buy. I don't have any sympathy for such people and my respect for them is waning fast. Personally, I hope SL shuts down breedables next. They can be just as 'loot-boxy' as gachas, if not worse in some respects. They're also a pain to deal with from a lag perspective.

Good riddance to this horrible sales tactic.

Unfortunately I don't currently have access to Maya, so I can't 'work both sides of the equation'. The workaround has done well for fixing the scale issues. However I'm still having trouble with joint orientation. When the collada file imports, if there were bind pose rotations specified the armature skews from the preview I'm able to look at using FBX Viewer, then gets bound to the skin that way. So far none of the math I have tried is able to get the joint orientation data from the library_visual_scenes section of the file into a form that solves this, and further, attempts to animate or pose the character in Blender goes wonky for the affected bones. So as an experiment I deleted the joint orient data in question from the collada file by hand. I can then import the file and get exactly the same result as if it had been there. After looking at the source code for collada in Blender I'm wondering if any of the translate/rotate/scale values in that section of the file are used; it seems to try and derive all of that from the inverse bind pose matrix in the skin data instead. I'm just a novice here, but shouldn't Blender try and do something with the translate/rotate/scale stuff in the joint node tree (in library_visual_scenes)? It looks to be part of the collada specification and not a vendor-specific extra. There are <extra> tags in that section, below the data, referencing 'fcollada', but they only seem to be defining some sort of visibility.

And sure you can use it (Avastar) to get your mesh rigged with its original weights and later imported to SL without need to calculate matrix parameters for bone scaling or so... Could I ask how? Is this written down anywhere? I've tried migrating the avatar to the avastar skeleton and rebinding the mesh while keeping the weights. In the case of migrating, I end up with an enormous mesh perpendicular to the skeleton. In the case of reskinning, the mesh ends up smaller than the armature and proportioned incorrectly. Is there a way to make the mesh 'wrap' around the new skeleton and preserve the scale of the original? Thanks, --Alex

Again, thanks for the reply. Were it not for the information you've provided here and elsewhere I'd likely never have gotten this far. I had actually already purchased Avastar back when I started trying to work on this, and before I had started to get any sort of mental foothold with regards to the problems I've been trying to work around. At that point I had tried to use its exporter and ran into errors, more than likely because it wasn't designed to do what I was trying to make it do, and I need to read the manual. :matte-motes-big-grin-squint: Since the steps I took to get the results I have now are almost exactly what you described in the mesh survival kit, I feel relatively confident that my issue is resolved to the best extent I can hope for in pure Blender, at least for the moment. I plan on continuing to tinker though, starting with reading Avastar's manual, in hopes of coming up with something a bit nicer to work with. Thanks again, --Alex

Thanks for the reply. The avatar dummy mesh I'm trying to work with is likely liquid mesh, as some parts of the mesh do change when appearance is edited, but not all of them, and it was created before the introduction of fitted mesh. I understand it works on basically the same principle though. Additionally while in Blender everything looks perfect thanks to the import options you mentioned. But upon upload, the mesh becomes a stick figure (after being rotated to face positive X anyway). What I meant about 'restpose_*' props was basically a very inelegant attempt to describe the same thing your fitted mesh survival kit does in the last section. By taking values found in <scale> tags nested within <node> tags of type 'joint' in the <library_visual_scenes> section of the collada file, using a formula to convert the scale values to global space, and inputting them into the appropriate properties, I was able to get the blender-exported mesh really close to what the original one looks like when worn, which I'm hoping also means if I develop clothing with it, it will work. However it looks really weird in the preview, and is not exactly like the original. I suspect a loss of decimal precision when I converted local bone scale to global might explain some of it, but also admit I'm really new to all this. After all of this, I have to ask, is there a more elegant way to do what I'm trying to do? The mesh I'm working with does not seem to have any collision bones to work with. Is it possible to rerig a mesh in Avastar without losing its original weights? Thanks, --Alex

Hello, I'm trying to solve an issue I'm having trying to import a collada file originally exported from Maya into Blender 2.73a. I have managed to get a successful import of the rig, and all looks well, until I try to export it again for testing in SL/OpenSim. I managed to solve some of the problems it has by rotating the entire armature 90 degrees on the Z axis, but the bone scales are still very badly broken. I have also tried manually adding the data I found in the collada xml to custom 'restpose_*' props, but this doesn't quite produce the results I'm expecting, which I suspect has something to do with the props being global in scope rather than inheriting from the parent bone, but I'm not sure. Questions I have are: Is there detailed documentation anywhere about the latest collada importer and exporter for Blender? I'd like to be able to find out what the importer reads, what it expects, what happens if it doesn't get what it expects, what it converts and how, and what, if anything, it ignores, and compare this to the raw XML of the file I'm trying to import.It's strange to me that the armature looks and behaves perfectly fine in Blender but breaks on Opensim/SL. Is there anything about the collada exporter that could explain this behavior, even when the appropriate preset is used?Are the custom 'restpose_*' props calculated as if they are global or do they follow the parent/child inheritance structure of the armature? Specifically I'd like to know how restpose scale is handled. As I said above, I suspect they're global (while the values from the file are local) but I want to be sure.When a file is imported that uses Y_UP, what is Blender doing to the data to convert it to its native Z_UP space? If there's something that I would need to convert manually I'd like to know roughly what steps to take. Related, what steps would need to be taken on fixed data if the whole armature were rotated as it was in the case above?From what I know of the math behind it, the formula to convert local restpose values to global ones, if indeed that be needed, would be something like 'global = local * parent_global'. Is this correct or is there something I am overlooking? Thanks in advance, --Alex

And to think I was almost ready to try out premium on an alternate account that I would use for R&D... This single issue negates any real benefits the Premium membership would have granted me. Sure, it'd be easy enough to mark the day of renewal on a calendar and downgrade before its up, but I would have to cut it very close to the deadline in order to maximize value. That combined with payment issues scarcely seen anywhere else makes a subscription seem a fair bit risky, seeing as not only do you lose your land holdings, but also access to your avatar if something goes wrong and the downgrade doesn't 'stick' in time. I have seen premium residents burned in more ways than just this, of course, which is also factoring into my decision. Though I have never had a subscription, I rent land in Second Life, and know how annoying and even traumatic it can be to get your builds returned or have to remove your build in order to move away from potentially unfavorable business agreements. And from that experience it is my belief that having your land repossessed and your builds returned is penalty enough for a monetary delinquency on your account. I think at the very least there should be an account option where subscribing residents may choose how delinquency is handled, choosing between account suspension or loss of land holdings and downgrade to basic. I also think in either case there should be a 1 week to 1 month grace period, and one's payment plan should be adjustable even during that grace period, perhaps adding a fee of $10 USD or so as a late fee. Another way to set this up would be to do away with the subscription-based premium membership entirely, or offer a completely prepaid way for residents to get the benefits premium members enjoy, perhaps at slightly higher rates than a subscription (analogous to a contract), if that matters to LL. The main difference would be the ability of residents to pay for the services they want in the same way that one would rent from a private estate, for instance. If they don't want or need a particular service anymore (such as land or a Linden home, or a stipend, or anything else LL offers), they can easily cancel it while keeping what they do want/need. If tier were also restructured to be a flat rate per square meter, or even a flat rate per 512 square meters, I imagine there would be a lot more people willing to pay LL more money. Fingers crossed that the Lindens are paying attention... ~Alex