Jump to content

Quarrel Kukulcan

Resident
 View Profile  See their activity

  • Posts

    530

  • Joined

  • Last visited

 Content Type 

Everything posted by Quarrel Kukulcan

  1. Quarrel Kukulcan
    I guess my first question is, why are you baking an animation? Are you merging multiple separate ones? Are you trying to generate an explicit keyframe on every frame instead of relying on computed easing? Did you check the baked animation to make sure it has no keyframing on any bones but the wings? SL's importer should ignore all bones that have no keyframes (or that do but never move at all).
  2. Quarrel Kukulcan
    An animesh object is a mesh object that animates itself by running its own animations on its own bones (as opposed to the older, clunkier technique of assembling prims and running a script that constantly rotates and slides parts of itself). It can do this either while attached to you or while rezzed on the ground. The animations it plays on itself don't affect your avatar. Now, it might also animate you, but that's because any object can animate you -- mesh or prims, attached or not.
  3. Quarrel Kukulcan
    Key point: Second Life does not have a master idea of "what pose your bones are really in" due to the fact that animations are not synchronized between different residents' screens. Also, as far as the server is concerned, animations are phantom and don't actually move anything. If I start dancing Tango37, all the server knows is that my avatar is executing Tango37. It doesn't have an authoritative, "true" idea of what frame of that animation I'm on or where any of my bones have moved to. Instead, every single resident who can see me (including me myself) generates the animation's effects individually within their own viewer. Every resident's viewer does this separately, just for them, and none of them are the "true" version. When someone new teleports in, the server tells their viewer I'm dancing Tango37 and that's all. It has no other information to give. So, that newcomer's viewer has no choice but to display my avatar starting that animation at frame 1 on their screen, while everyone else sees me as farther along. Complicating that even more is the fact that avatars can be impostered (rendered at a lower LOD and/or with sporadic animations) or jellydolled if their rendering complexity is too high. That also ruins the idea of forcibly synchronized animations on everyone's screen. Plus some viewers support making all animations run faster or slower, or overriding them with custom poses. Second Life was originally coded this way because it was a much more feasible way of handling data loads on the slow computers and internet of 2003. The more content residents created over the years, the more disruptive it has become to rewrite everything so the server does have a master idea of my "true" animated state and constantly feeds it to everyone in the region to keep things synchronized. And that's the change that'd have to be done to give you the feature you want. It's a major restructuring and it would cause immense side effects, so while it's possible...
  4. Quarrel Kukulcan
    DM sent.
  5. Quarrel Kukulcan
    You will probably need to experiment with Z offset too, or else have to adjust hover height later. SL doesn't automatically adjust for shorter or taller avatars.
  6. Quarrel Kukulcan
    Upload your textures separately and assign them to the model's faces after import. It's the most straightforward way. It sounds like you forgot to check "Include joint offsets" in SL's import options. Also, is it the right size in Blender? Make a comparison object, like a 1m wide x 1m deep x 2m tall box. Don't export it or anything, just use it to judge sizes.
  7. Quarrel Kukulcan
    I think you exported with default DAE settings. You need to choose the "Second Life + OpenSim Rigged" pre-configured setting, which you can get to by clicking the options gear on the Blender export panel. Again, this will be different for you than from that video because you don't have her add-on.
  8. Quarrel Kukulcan
    It doesn't matter whether you rig it first or shrink it first, just apply scale before you export so your armature and mesh are both the size you want and at scale (1.0, 1.0, 1.0), and use "Include joint positions" when you import.
  9. Quarrel Kukulcan
    That's an Avastar armature. If you're not using that add-on you'll have to rotate manually toward +X before you export. I tried auto-weighting to it myself with plain Blender 2.92 and got a distorted mesh when I didn't rotate and a correct one when I did. Another option is to use the Bento armature at https://blog.machinimatrix.org/wp-content/uploads/2011/08/angel_2017-01-09.blend. It's facing the correct direction. More importantly, it also doesn't have any Fitted Mesh bones. Those are the bones with ALL_CAPS names. They're extra-complicated and best avoided for your first couple of projects -- if you weight your mesh to them like normal and export with plain Blender, you'll also get a distorted mesh. To avoid that, you have to either A) use a Second Life-specific add-on, or B) start with a different armature that contains special, extra information, and then check an extra option during export as well. Make sure you apply scale before you export too, then, and check the "Include joint positions" option in the SL import panel. BTW, if it looks wrong in the preview panel, it's generally a waste of Lindens to confirm the upload. Also, you should absolutely be uploading to the Preview Grid first so you can test things using Fake Test Lindens instead of spending real ones. It'll take a couple of days for LL to activate your account on that server and you'll have to enable mesh uploading there separately, but it's worth it. http://wiki.secondlife.com/wiki/Preview_Grid
  10. Quarrel Kukulcan
    The first thing I'd try is rotating your armature (and your mesh, if it's not childed) to face toward +X and Apply Rotations to both (in the Object menu while in Object Mode). Second Life expects models to be facing that direction. It's kind of annoying because many of Blender's automatic mirroring and symmetry options only work if your model faces toward +Y or -Y. (This streamer isn't using plain Blender. She has a commercial add-on called Avastar. Among other things, it corrects for this rotation during export so you can leave your model in a Blender-friendly facing the whole time.) Also, where did you get the armature you're rigging to, and is it in a proper T-pose?
  11. Quarrel Kukulcan
    Here's something I posted a short while ago that should cover this: This is probably the "SL treats 1 unit = 1 inch" issue with BVH importing. If you move mPelvis, say, 0.9 units down in Blender because your model scale is 1 unit = 1 meter, it'll only move down 0.9 inches when the animation plays in SL. The scale factor I mention above can fix this. Yes, but you have to keyframe that bone's location too, not just rotation. And use the export scaling option. And do NOT check "Root Translation Only". Plus you should be aware of possible deformer or shape slider interactions Make a 1- or 2-frame animation that changes the locations of those bones, export it with all the options from last paragraph, and import it as a looping animation that holds on the last frame and has high priority. (With vanilla Blender and typical SL viewing programs, that's priority 4). You'll also need a script in a body or HUD attachment that keeps that animation running. One big word of warning: deformers interfere with each other and with SL's avatar shape sliders. They all work by changing bone locations (and, for the sliders at least, sometimes scale). And the location changes tend to overwrite one another instead of getting added together. If you want to be super-sure, you can delete the bones you don't want to affect from your armature before exporting. Just make sure you delete all the way out to, and including, the last child, and don't delete any parents or grandparents of the bones you're moving. However, you should also be able to get this result by never giving them keyframes. SL ignores -- or at least, it SHOULD ignore -- any bone that never changes at any point in the animation (even if it starts in a non-default pose!) (*) Any of your bones that has no keyframes, or only one, or several but they're all identical, shouldn't get animated when you import and play that animation in SL. In theory. (*) There is one exception: if you manage to export a BVH with exactly one frame, SL will import and affect every single bone in it. A tailwag won't have one frame, though.
  12. Quarrel Kukulcan
    😠
  13. Quarrel Kukulcan
    What error exactly? I've never gotten an error message, but I've gotten plenty of incorrect animation behavior. Rotations don't work right because SL applies rotation components in a different order. To make bone rotations that import correctly, use this workaround: https://www.youtube.com/watch?v=LfYG9Dq-pTA. (Text version: Face your armature and model toward +X with +Z up. Apply rotations. Rotate your armature (and mesh if it isn't the armature's child) so it's lying on its back with the face toward +Z and the head toward +Y. Apply rotations. Rotate it back to how it was the first time and don't apply rotations. Animate from there. You don't even have to do step 5, really, if you don't mind animating a reclining character.) Location changes don't work right because SL is hard-coded to expect a scale of "1 unit =1 inch" in BVH files. To make bone translations that import correctly, use a scale of 39.37 in the export options panel. That's assuming you're using Blender's default measure of "1 unit = 1 meter". If you're using something different, enter a scale of however many inches are in 1 of the units you're using. (0.3937 if you're in cm, 12 if you're in feet, etc.) As of 2.90 it does not.
  14. Quarrel Kukulcan
    If I recall correctly, the importer strips unconnected vertices, with one exception: it'll keep the very first vertex listed in your export whether it's connected or not. I'd go with small triangles or a single corner-to-corner triangle if you have a material to spare to make it transparent.
  15. Quarrel Kukulcan
    This is not a scripting question, but... 1. Not even avatars have this feature. Yes, I can attach a box to one bone of my avatar, but other residents can't sit on that box. So letting you attach objects to an animesh object won't let you make a moving, sittable saddle. (And if it did, well, then I could hold a box, and you could sit on it, then you could hold a box and that other woman could sit on it, then she could hold a box and that that guy over there could sit on hers, and and and BOOM, you've broken SL with your crazy-long attachment chain.) 2. Animations only change visual positions, not objects' actual positions or their physics shapes. And the physics shape is what you sit on. (This is the result of how SL's animation handling had to be programmed 18 years ago due to how limited computers and the internet were back then, and now we're stuck with it because changing it now is too much work and would break too many existing scripts and objects to be worth the gains.) Just like playing a constant animation that lifts your AV ten feet off the ground doesn't stop you from bumping into ground-level objects as you walk around, playing an animation that makes your dragon rear up won't move an avatar that's sitting on it (or on anything theoretically attached to it).
  16. Quarrel Kukulcan
    The full answer is that that's an entire field of skill that'll take time and practice to get good at. The immediate answer is heavier weight if you want a vertex to track closer to that bone and lighter if you want to inherit a smaller fraction of the bone's motion. A few Blender-specific suggestions: Normalize all your deform bone weights: weight paint mode, select all verts, "Weights" -> "Normalize All", then check the operation options (should be in the lower left) and make sure they're set to "Deform Pose Bones" (for newer Blender versions, or "All Groups" for older versions that don't have it) and you do NOT have "Lock Active" checked. This will use the magic of ALGEBRA to ensure all your vertex weights add up to exactly 1.00 while also maintaining their proportions if it needs to adjust them. This way, your weights and colors will accurately reflect what percentage of bone motion they'll copy. Results will be more intuitive and you'll see errors easier. Turn on Auto Normalize in your brush options. This will keep your weights normalized as you paint, and, again, give you the motion you expect. Turning on X Mirror (and pointing your model toward +Y so mirroring X means mirroring left/right) is a very good idea if your clothes are symmetric. A simple example tutorial is at https://www.youtube.com/watch?v=Tl4qTgwQwYw. If you don't mind quite condensed information, there's also https://www.youtube.com/watch?v=v6_m3xFSlIU and https://www.youtube.com/watch?v=rG82fogtuCg. (Don't worry about the Preserve Volume setting, that doesn't affect SL.)
  17. Quarrel Kukulcan
    If you have a dev kit or other correctly-weighted copy of the specific mesh body you made the clothing for, you should start by transferring weights from the body mesh to your object. That way it will flex and reshape the same way. Only do manual painting to fix errors after that. (If you don't, you're going to have an extremely hard time getting the positioning, the joint bends or the slider responses right...let alone all three.)
  18. Quarrel Kukulcan
    It's because the area of the lower body texture dedicated to the foot simply isn't very big. The entire top and sides of the foot only cover about 240 x 405 pixels on the largest legal texture size (1,024 x 1,024). The sole is even smaller, plus the joining edges aren't the same lengths or angles, so there will be distortion and pixel misalignment at the seams. On top of that, I don't know what you're doing to make the sole that tall, but that's also going to stretch your texture out. There is only one mapping, so if you give your foot shape a tall sole or heel, SL will stretch the texture instead of pulling in extra pixels from elsewhere.
  19. Quarrel Kukulcan
    There's a note in the group notices history that it had to close early. Oh well.
  20. Quarrel Kukulcan
    There's nothing there but an empty field and some for-rent signs.
  21. Quarrel Kukulcan
    I was wrong. My export worked because the dev kit mesh had no Fitted Mesh weights. (I presume it relies on Avastar to auto-generate them during export.) I tried a different one and it failed the same way as yours.
  22. Quarrel Kukulcan
    For two reasons: Number one: The armature in an animesh object can't affect anything outside that one object. Even if the animesh object is the parent object in a linkset, the other objects in that linkset can't be attached to or weighted to its bones. Not even if they're that way in Blender. Second Life simply doesn't support that. The children will import as if they were attached rigidly to the parent's base position and won't animate with it. (You CAN attach separate objects to avatar bones, yes, but animesh objects lack this feature.) Number two: Animations only change where an object's mesh is drawn. They don't change where the object actually is or which direction it's really pointing. They also don't change its physics shape -- and the physics shape is what avatars sit on. If your animesh jumps or twists or dances via animation, an avatar sitting on it won't track with it. You have to figure out another method to animate them the same way. Probably. I think every technique AKK used is still available. And it should be usable with an animesh mount as well (which is good, because the rider can't be moved in the ways you assumed it could be from your Blender experience).
  23. Quarrel Kukulcan
    That looks like missing Fitted Mesh info from the way the chest and biceps pull in. I'm not sure what the fix is if exporting with bind info didn't work. That's how I succeeded with the Kemono dev kit. Is the Solarian kit free access?
  24. Quarrel Kukulcan
    Banning new ones. A person who can't afford a new car and has their existing car die will be in the same situation they would be today: needing to buy an affordable used one.
  25. Quarrel Kukulcan
    Well, initially I didn't think it was possible to export a SL-usable .dae file from an Avastar-specific save file using vanilla Blender, but I tried it again just to make sure I don't mislead you, and I actually succeeded. The only steps you mention that I had to follow were reorienting toward +X (and applying) and exporting with bind info. Color me surprised. What's the nature of the distortion? Can you post a screenshot? Deflated limbs and chest indicate bad or missing Fitted Mesh bind info. Limbs zig-zagging or swung forward and back are an orientation problem. Regarding and You don't want to do either of these. If you're making clothes to fit a dev kit body, your first step once your clothes are modeled is to transfer weights from the body to your clothes, then maybe do some fine-tune painting. The only bones SL cares about either start with "m" or are in ALL_CAPS. (Well, plus attachment point bones, but those aren't intended to be weighted to.) Anything else in your armature is added by Avastar for its own internal use and excluded from the export. If your mesh is actually weighted to these non-SL bones, I suspect Avastar does internally during every export what you manually did yourself. If the dev kit rig lacks SL's m-bones, I'm not sure you can reconstruct the basic SL skeleton simply by renaming Avastar's internal-use bones. There could be all kinds of subtle internal transforms it puts those through behind the scenes.
×
×
  • Create New...