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
  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 qu
  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 search
  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
  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 wit
  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
  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 d
  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 mor
  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
  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 Blen
×
×
  • Create New...