OptimoMaximo

Kinda unrelated point. There's still skills to be learned, the difference sits in the media. Next one This is just stupid. It's not a matter of media used, it's a matter of skills to be learned. Things change for sure, but from a work of skills to asking in writing what you want and get a machine assemble it for you, it's not even remotely comparable. Next one Skills learning is ALL a matter of will and time spent to learn them. Of course the artists are pissed off about it. First of all the models STEAL others work with no credit nor compensation. Secondly, an artist should see the visibility of their skills buried in an ocean of other wannabe artists, that ruin the work market for them who put passion, time, money and sweat to get good and be chill and happy about it. Very fair. Now go ahead and jump all over me with your moot remarks. The matter of fact is these tools will lower the bar of quality and innovation just to have some lazy people be able to call themselves "artists". Clowns, that's what they are.

why not learning the craft instead?

The art goes down the sink for the wannabe clowns to self proclaim "artist". What a bleakness.

At that time we were not collaborating yet, but I'm sorry to hear it didn't do good for your purposes. I released MyAniMATE in 2017 and our collaboration started only in 2020, when I overhauled Mayastar with more features and rewriting existing ones from scratch. Cathy and I would love to see you joining our discord group and give Mayastar another try.

Sorry, I assumed Blender since every post I see on the forum is about the use of that software. I use Maya as well. I'm the developer of MyAniMATE (which is for animation) and collaborate in the dev of Mayastar (rigging mainly) with Cathy Foil. in the Mayastar shape editor, make sure to select the "mesh" shape, not "default" when binding your mesh body. All the joints should then have a scale of 1 on all axis, whereas the "default" has varying scales on their Y axis. You can save the current weights to file either using Maya built in xml weights exporter or the one provided with Maya star, and replying them after your adjustments and new binding. You should also make sure that your neck edge matches the default avatar that comes with Mayastar, as most of the head devs use that size for compatibility. Lastly, if you go to the modeling tab, you'll find a tool to transfer the vertex normals from head neck edge and body neck edge, so that the seam will not be visible.

My 2 cents on the issue: First thing to check is if you weighted the body on the avatar in what avastar calls neutral pose. The default already IS a custom shape. In Blender it is not evident because it doesn't support bind poses, but the default shape already has some scaling applied. Set that to neutral and you'll see a difference in shape across all body. At that point remove the skinning, adjust the neck if needed, and bind the body again to neutral shape. The second thing to check is what weights other devkit body meshes use on the neck and weight accordingly , exactly as found there. I would not assume the collision volume bone to be alone in that area, perhaps the mNeck joint has some influence. Also, I would not assume the Ruth and Roth to general examples to follow, check more bodies.

What did you expect from LL? The switch to a system without tracking numbers alone should have had many eyebrows raised. No tracking number, and the sole existence of a ticket can be denied, no proof of it to be found anywhere to back up claims of otherwise. Just face it: the user is an annoyance that they have to pretend to listen to. Always been like that, the hopes of change about this is just delusional wishful thinking.

If the copies that were taken, as you state, are the result of a shift-drags copy done by an alt of yours with edit permissions, it's likely that what happened is that the alt has taken the shift-dragged item, which is the original, and left the actual copy on the platform, therefore applying next owner permissions masks to you.

Not much. Just tedious and maybe long for the correct wording and correctness proofreading. The users. This spares LL the effort and a few coins.

That's driven by an animation over the earrings attachment points, with the mesh being rigged to them. A chain would need way more effort.

It looks like you need some reference info... Bvh file format IS raw motion data. Whether it was captured or not is another bag. Bvh files do not imply "a human skeletal system", you can really dump any hierarchy to it. There is no fixed or standardized naming convention, anyone can output any skeleton really. There is also no obligation whatsoever in regard of world orientation, joint orientation and rotation order. If you take a SL Bvh animation and compare it to any random Bvh file non SL specific, you'll notice soooo many discrepancies between them. There is one factor that may prevent an animation to upload, and that's its final size once converted into the native file format SL uses, the anim format. The limit is 250kb size OR 60 seconds length, which ever is being hit first.

Still not explaining what's the point of comparing two softwares, painter and zbrush, which fields of use are completely unrelated to each other's. Anyway, good luck with Blender trying to cope with the polygon numbers that zbrush can handle without breaking a sweat.

And what would the criteria be for such shift in the choice between these two softwares? Substance Painter is a texturing program and ZBrush is meant for sculpting (can also texture, yes, but its main use is sculpting)

No, it's common sense. Being in the year 3000 or in the 900 bc doesn't make any difference. It's a matter of being able to use the brain.

Oh and another detail that is important: during the registration process to aquire the pioneer license NO CREDIT CARD info was ever asked. So, no end of the year surprises, just renew it manually.

I've got it and as I said, the terms of service as currently stated when acquiring the "pioneer license" state that it has to be renewed yearly, because of the possible revenue changes that may have occurred in the meantime. Also, this was discussed on their LinkedIn page's comments and they stated they will address this point in the near future to make it more clear. But as the current state of facts and statements, this licensing scheme is there to stay. In any case, if you have to adopt it, remember that instamat does in one software what Substance has split in separate softwares: Designer, Painter and Alchemist (which has been renamed but to be honest I can't recall the new name). Plus, instamat can manipulate meshes and make LoDs using algorithms from INSTALOD, their dedicated LoDs software. At the same subscription price as Substance. I'm definitely switching to it, just the nPassGraph feature alone makes it worth it to me.

There is no gotcha with the current licensing terms. It's a business model started by Epic and that many follow now, with a "pay us when you succeed" kind of mentality. I mean look at what happened with the latest move from Unity last September. And many are just going to move on anyway, regardless of the latest adjustments they made to the policy (which still is in place, starting 2024 and from the next release Unity6, BTW). Besides that, since they're battling a giant like Adobe on their most recent acquisition Substance Suite, they have to fight for adoption in the industry. So the most users they can collect, also among students, the higher the chance that at some point studios are going to hire some of their users. If Autodesk did that with Maya and 3dsMax, today Blender either would not even exist or would have died off long ago.

I'd be interested to know exactly how the constraint offset is being calculated. Go heavy handed with vector/quaternion/matrix math if needed, I'm well versed with them. I never had the time to figure it out since the docs do not detail that (or I haven't found the relevant info).

It's the same for both, animesh inherited that limit from the animation format* for avatars because, well, it is an avatar. Anyway, the limit is +/-5 meters in parent space, which for the mPekvis equals to that 5 meters from the avatar box. * to be precise, that is a clamping actually enforced within the anim format data serialization. I believe there is no enforcement other than that, when the animation is de serialized and played back in the viewer, but I may be mistaken since I've never dug into the viewer code (not that I'm interested anyway). I believe that if a technical requirement like this can be circumvented , it really should not be.

Oh, what an unexpected news...

No, animation does not affect the character box in world regardless of the tool used. What you have to do, is to make a script to move the avatar in world while playing back the animation, which has to be designed without forward motion (in place). As an end result of the two actions in the script (physical movement in world paired with the animation) would give you the final result you're after.

Decimating isn't going to give you any advantage in terms of optimization. What avatars compression is likely doing, instead, is analyse the animation curves to determine, for each joint, where a significant rotation / position change, compared to previous frame(s) is happening, and marking that set of frames as good to sample. Of course, this process can reduce the motion fidelity by not writing down too subtle movements based on a given threshold. What you can do to optimize your animations is not a series of actions on the animation curves nor anything similar. In that context, there is nothing you can do to drive the compression behavior. However, what you CAN do is to play with the fps setting in conjunction with retiming your animation accordingly. The lower the fps, the fewer frames there will be to describe the same motion at the same speed of execution. This way, you'd give the compression system less data to chew and make decisions upon, ensuring that the compression would still do its job, but you would have started that process with the minimum number of frames that still describe the motion well and, therefore, end up with a considerably smaller file size.

No benefit of doubt to LL, Niran. All they do is always blatantly pulled in from the minimum acceptance criteria since time immemorial. If you should do X, they call it good to go at X-100 and then "we'll keep further development for a later time / project" which translates into "we're done with this, IF we come back to it, it will be in a decade... perhaps.."

Disagreement is always personal. One person disagrees with another, that's how it goes. On the other hand, the expectation of any debate to be agreeable, all smiles and pats on the shoulders is quite delusional. If that's the case, let's shut down any existing forum and get it over with.

Yep I guessed that much. With LL it's always a race towards the minimum