Jump to content

Feynt Mistral

Resident
  • Content Count

    392
  • Joined

  • Last visited

Community Reputation

6 Neutral

About Feynt Mistral

  • Rank
    Advanced Member
  1. Something that's been bothering me for a long while is when I go to import the skeleton into Blender, it makes no sense. All of the bones are only relationally connected. They're often super tiny and hard to find. When I make a rig of my own, unless I specifically want an offset (like hip to leg offset) they're connected end to end, and aren't pointing all in the same direction. Can I just make my own skeleton with bones named the correct way and use the "export to SL" option to make the bones work? I'm fully capable of rigging, it's just this one janky thing about the publicly available skeletons being so off in Blender.
  2. Thanks for the responses. In order: Thanks for the info about maintaining the hierarchy. I figured I would have to, but it's good to know I can get rid of the wings and hind legs if I don't need them. Kind of a shame I still need the extra spine bones considering how hard it is to pick out just the normal bones, but ah well. Constraining skeletons to skeletons sounds like such a pain. >P Shame they still can't be used for animation uploading. Missed opportunity there. I figured the head was considered the "true location" and the tail was used for the "rotation". To answer the question about where I got my skeleton, I picked it up from http://wiki.secondlife.com/wiki/Project_Bento_Testing. Per polysail's comments, I actually didn't notice an option to fix bone chains and clicking that does import the bones all linked up properly. If I also check "fix leaf bones" it'll also orient the end bones and stray bones (like in the face or finger tips) so they're pointed in the right direction. If zeroing out the rotation of the bones isn't a valid fix though as Matrice Laville suggests, I guess I'll have to just import without fixing the bones and do the constraints. >/
  3. Been taking a break from SL and just now getting back into things. Glad to hear Bento's progressed so far. One thing that's caught me up in the past (which I'm now tackling because I'm getting deeper into 3D modelling) is the bones not being arranged right. I'll import the collection into Blender using the Collada files, but they're all miniscule and not attached to each other. Instead, they're offset parented, almost every one of them, and X aligned (again almost all of them. The new mSpine# bones are the only ones which are correctly linked to each other. Unfortunately SL's searching is still ass so I can't find any posts regarding this. So a few questions are in order: Do I need to keep all the bones? I don't think I'll be using the hind legs or wings any time soon for example, and I probably don't need all the spine bones. Can I relink everything so they're properly oriented and relationally everything makes sense at a glance? (applying rotations afterward of course) Are Collada files acceptable for animations yet? Or are they still just for mesh and bone positions? Assuming I can't relink all the bones, what is considered the bone's location? Blender doesn't use the bone's mid point, it only gives the head and tail positions.
  4. Actually another thought came to mind. FaceRig makes you do animations for its various facial positions when you want to make a new avatar. It's basically asking for morph targets to blend between, the same as the SL avatar for various states. Rather than adding more bones, couldn't you just tell us the animation names we'd need to specify to get blending to work as it does with the default avatar? I mean I assume there's a "avatarSkinny" and "avatarFat" animation a piece to differentiate between those two states on the body thickness slider, right? Any words on that, LL?
  5. Right, like I said, if you can export scale somehow then the first translation applied will work just fine. It's when multiple translations come into play that things bork. It's a minor issue to me though. I think animations targeted at a specific rig are the natural way to go, and if you're doing animations for your own rig, you know what not to mix together to cause these issues. The average person who knows nothing beyond "I click the button and I start to dance" won't know or care how someone else's animations don't work with your avatar. They just care that they don't, and someone is to blame. So we need to explain this to people before anything animation format wise is made concrete in a way that doesn't satisfy.
  6. That sad face totally looked like Mike Rowe. >3 Excellent rig though. I'd love to have that in SL.
  7. Oh I totally agree. Animations for different characters should not be general. But they are, effectively, at the moment. A dance works the same on every avatar in SL at the moment because it's all rotations (even if it looks wonky for a horse to suddenly stand upright and do a waltz). And that's what LL wants to preserve. The reality is they shouldn't, but nobody wants to catch flak for making animations potentially break when you start stacking translations in them. So that's my option 2 from an earlier post: We tell the community at large that translations in animations won't work with all avatars, and tell them we want to go this way so that facial animations will look better when they're made for a given avatar. The rotation vs. translation examples supplied earlier are good for showing the difference to the community at large, because let's face it, not a lot of people out there are techies and/or modelers. So the short of it is, make cool **bleep** that makes use of translations. Hopefully we can get LL to put up some sort of announcement for those gathered here to express the choice of supporting translations in favour of universal animation support.
  8. It's not just facial animations though. Say you have an animation that moves bones that aren't in the face, like moving the arms back as someone mentioned a half dozen pages back to get a horse with two bones in its neck. Only this isn't a one time offset, it's something you change constantly for whatever reason in the default avatar's skeleton (hide avatar arms, translate arm bones for wings on back, start flapping. Yes, we have new bones to do that, work with me here). Works great for normal human sizes. But when you get to the really small or really big sized avatars, the translations don't make sense anymore. On a tiny avatar the bones would probably cross past the midpoint axis if they were supposed to move inward. On a giant one the bones would barely move at all. What's 0.3m movement when your shoulders are 8m across? Now say this was a common animation; the flapping arms I mentioned, or a dance, or a walk, something that involves translation in the bones and not just rotation. This doesn't work for anyone who's got a non-standard avatar. Granted, feral furries have come to terms with this ages ago (human animations on a non-human skeleton arrangement, d'uh), but the rest of the SL community that doesn't understand technobabble and wouldn't care to know what it all means, outside of "my animation doesn't work." Yes, it's a fringe case. Most animations outside of the face will feature rotations and not translations. But for those less than 20% cases, it's kind of a big deal. ----------------- Now, scaling and rotation, those both multiply together properly. If you scaled a body up (or down) 10 times, translations applied to that 10 times scale would work. Offsets in the model file however don't relate a scale though. So if you moved your bones out to their appropriate positions in a large scale model, you would also encounter this "0.3m movement on an 8m wide shoulder" issue. Offsets are translations after all. If there was a way to import scale though rather than bone absolute positions at export, that would resolve a lot of the issues for facial animations via translation as well. You still run into the case where applying multiple animations that have translations wouldn't work, but that's an even more fringe case (maybe less than 2%) and I don't think enough people would care at that point.
  9. Poor choice of words. From a non-technical aspect, they don't scale. Like how a 286 can't scale to meet the requirements of a modern business (or in fact, any modern activities, besides Doom perhaps). You are right, you can mix a scaling operation with a translation operation. You can't translate bones and then translate them from origin again and get the expected results however. For example: A micro, a norm, and a giant all walk into a bar, err store. Stop me if you've heard this one. >V The norm finds a facial gesture that makes his eyes shoot open wide in amazement and jaw drop to the floor. "This is hilarious!", he exclaims, and recommends his friends try it. The micro tries it out. His eye lids basically triple his height and his jaw sinks through the floor five or six times again his height. "This is broken." He exclaims, and leaves the bar/store in disgust. The giant tries it next, and her eyelids barely move, with her jaw opening slightly as if to sigh. "Well that's a let down." She grumbles, shrugs, and looks around for more. And that's assuming the animation's translations are relative to the bones current positions rather than from the skeleton's origin. If it were, you'd see the heads (or at least faces) of the other two resize to the norm and zip back to about 1.8m up from the ground before performing the animation as intended. This is probably the worst case scenario. Animators would have to export different animations for different sized bodies, one where the micro's eyes moved maybe a centimeter, and the giant's a few meters, but both give the same results of the norm. But if someone were in between these sizes, new animations would again have to be made to look "correct". How giant is giant? 4m? 10m? 30m? I've seen some which are 50m tall, some which are 20m tall, and some which are just a few heads above norm. How micro is micro? 1m? 0.25m? I've seen both as well. Rotations however do scale for where ever you happen to offset bones to. If done correctly, the micro, norm, and giant would all see the same animation in spite of being so ridiculously disparate in size. And unlike translations, you can multiply two rotations together to get a mixture of the two (animation blending). A subtle eyebrow waggle could be mixed with a surprised raised eyebrow for example.
  10. As a multiclassed programmer/artist I feel I can understand both sides of the equation a bit here. Vir's previous statement confirming their .anim file is some made up format and not the known .anim file out in the wild is one problem, I'm sure. The other side of it is confusion about why translation isn't possible when it's the norm in animation for some parts of animation (most appreciably squash and stretch animation for cartoony characters, as well as in the facial animations). The technical side wouldn't understand the outcry for this, but translation of bones makes animating a lot more practical, realistic, and simplier. It's also a performance boon, because as mentioned you need a ridiculous amount of extra bones to get the same results through pure rotation. The other way around, I believe the cause for LL to have taken this stance is because translation doesn't scale, but rotations do. You can't say arbitrary animations that translate bones will work properly with another pre-existing translation. Rotations will however work with a single bone offset, and multiply amongst themselves. This is their solution to the "everything must still work together" problem. From a programming standpoint it's sound. So there's only two ways around this solution, for the community: Come up with some mathematical way to allow bone translations to build off of each other so that animations look right on a giant, a normal human, a miniature person, an animal, and Chairface Chipendale. If someone can solve this I think a lot more than just LL will be happy to hear about it. Speak for the whole community and abandon the idea of "animations work on everything", explaining to everyone who isn't an animator or tech savvy that certain animations (those which rely on bone translation) will only work properly on specific sized bodies and faces so that LL doesn't have to and won't receive the ire of hundreds of thousands of people. Otherwise, we're stuck with rotations, unless another solution can be raised. Moving forward though, I believe it's a very good point that a standard be taken up, one that publically available tools can export to already (like BVH, but more appropriately FBX, or COLLADA since it's a more open format). I'd like to help out, programming side, with a conversion tool to actually do this change. If all the current animations in SL can be converted seamlessly to a standard format with no change in functionality, that opens the door for importing of a standardized format that is known and reinforced by trusted companies (Autodesk and Blender for example). Likewise if the current format is the issue behind "we're disabling bone translations in animations", this resolves the issue. I just need a structure of what the internal .anim format looks like and I can get to work on making it convert to something else. Is this translation of animation formats already done in the publicly available code? If so I can poke at it.
  11. You're right, the original skeleton wasn't zeroed for the base pose. I did apply the rotations, but I don't think that made a difference. I was still encountering the rotation issue. I believe however it's an issue with previewing animations, perhaps a Firestorm issue entirely. The default stand pose was for some reason skewing the rotation, even though I'm moving every bone on every axis (rotation and loc), even if just a little, from the default, and even through priority 4 on the animation. Changing the preview pose to something else like flying seemed to correct the issue.
  12. I'm still wrestling with this rotation issue. Is it common for an avatar to appear rotated slightly clockwise when previewing animations? It's rather annoying. It would be great if someone else could confirm this issue. A link to my current work can be found here. It contains the BVH I exported with the default Blender 2.68 scripts and the blend file.
  13. It made sense to me that where ever the bones happened to be when you set a keyframe, that's where they would be when you turned off IK. Silly me for using logic on artist tools. >D Anyway the good news is that the output for Blender 2.68's default BVH exporter seems to work just fine. The bad news is there's a slight rotation issue which I can't account for where my dude in Blender is just rotated perpendicular to the ground, but in world I'm rotated similarly but also slightly askew on the X axis (so that I'm banking to the left, if I were flying). I'm sure it's just that I didn't turn something slightly to make SL pick up on that one bone (somewhere in this skeleton) as a clue that it should animate that too. SL is very particular in how it takes its animations. If it were a coffee patron, I'd hate to the barista that got its order wrong. I'd end up with hot coffee on my face. >S
  14. So apparently I was doing it wrong. I was keying the bones, however I should have been doing the keys on the controllers alone and then exporting the bones. I've been able to get proper outputs now. I'll have to do some additional testing to see if the default Blender exporter will work, and if so I can release my changes for public consumption as just the blend file. Not having to replace scripts would be ideal.
  15. I believe I've discovered the issue. For some reason the rotations of the control objects aren't translating to the bones. So no matter what positions I put the IK controllers into, they always end up being in the initial T pose. To confirm I set up an IK/FK switch in my scene. Sure enough, when I turn off IK, even though my figure's bones have been keyframed in various poses, every frame of the animation is a T pose. When I export FK animations from this blend file though, everything does export properly and I do see an animation occur. I should point out I'm a programmer, not a Blender head, so I'm not really sure how this isn't working. If I default to my programming skills I can make the exporter ignore bones which have certain naming conventions (like .IK.), but I think there's a better way. Anyone out there have any ideas? If I can finish this, it'll certainly be an asset to the Blender community on SL.
×
×
  • Create New...