yamaarashi27

Oh okay cool, yeah that's what I meant. So interesting that, that is how this all works!

What? How can the book just hover and float around if it hasn't been animated to? The attachment point surely has been told to rotate and move? That's what the animation does right: rotates and moves that Bento bone?

Say you're holding a book. a decent example is "/Vae Victis\ - "Aza Empyrea"". It's not animesh, it just floats up and down. I am assuming that, that is bento and it's just... moving to different bones in front of my body? Okay cool, this is a new area for me and I appreciate this information. I was definitely under a different impression but now I'm starting to understand how it functions. I'll run some tests later

Hey CrystalShard, I'm refraining as much as possible from using animesh, considering its limitations on players firstly, and secondly I have items on my character that aren't animesh but can still fly around so I know it's possible; they have animations on them. (But thank you for the link, it'll be good to make animesh stuff that I can continually rez)

Attempt #7: BVH animation Explanation: So I added bones to my blender cube and re-did the animation, exported it, finally managed to import it into SL. I was getting a dumb error about the root name. I edited the BVH file and just changed "Bone" to "hip" and it seemed to allow the import. I tried adding the animation to a block, and a script to run it. It then complained about not having appropriate permissions to run the animation. I already knew this was going to be annoying and treated as a character animation. But I programmatically made it request permissions first, and well yeah in the end it was trying to animate an avatar. Problem: How do all these creators animate objects!? How is it possible they all have animations that are DESIGNED for a skeletal system just float objects around??? TL;DR: Eughhhhhhhhhhh

Epilogue I don't know anything about animation lol. I hear key words like "Animesh" and "Bento" thrown all over the place and I've never incorporated animation in my hobbies or designs before; but I would love if the workflow could be as streamlined as creating something in Blender and exporting it to import to SL. Ideally, I'd prefer to not do an Animesh route (which I think is more an object property than it is an animation type?) due to the limitations on avatars equipping. I've searched the official forums, other forums, every youtube video I could find. Nowhere clearly explains a solution.

The Backstory I am a software engineer IRL so I seem to target most creation problems from a scripting POV. My first creation was a back halo that scripts some rotation; works well. To give it some more depth, I wanted to make the smaller inside disks float backwards and forwards through the bigger outside disks. I'm relatively new getting back into SL after many many years and I've researched the heck out of this problem and prototyped a lot as well but still to no avail. The Goal The goal is to have a set of linked attachments sliding forwards and backwards out of sync. The Attempt Log Attempt #1: llSetPos on a loop Explanation: The idea is simple, we figure out how much movement along a given axis we'd need to get from A to B in the desired time. We would then use llSetPos to do the moving inside a loop. Problem: Super visibly clunky. The prim would obviously jolt-hop along each axis no matter how many steps I made it travel to smoothen it out. TL;DR: Transition is not smooth; too clunky. Attempt #2: Import an animation from Blender Explanation: To help figure this out, I started to analyze objects that did what I wanted, and what I noticed was that they all had an animation attachment and a script to probably kick-start it. That makes sense, no way all those complex animations happened through scripting alone. Problem: When I went to export the animation, it exported as an FBX extension which you all probably predicted ahead of time would be useless because SL only allows the import of BVH & Anim extensions. TL;DR: Can't import .fbx files. Attempt #3: Format the extension Explanation: My next train of thought was to see if I could just cram it into a different file type or converter and watch what happens. Problem: Obviously this didn't work, I also went as far as to import an open source second life animation export extension from github and no surprise it threw an error when I tried to export my fbx animation as that. TL;DR: Don't try to push the cube in the circle hole. Attempt #4: llSetKeyframedMotion Explanation: I stumbled across some amazing performance from the llSetKeyframedMotion scripting function. After running my tests on a rezzed prim, it seemed perfectly smooth; much smoother than llSetPos. Problem: It was wishful thinking, because although I read on the documentation page for llSetKeyframedMotion that it wouldn't work for attachments, I just wanted to rule it out. Low and behold, when I equipped the item, the animation didn't function. TL;DR: Not compatible with attached items. Attempt #5: llSetLinkPrimitiveParamsFast Explanation: I came across a forum post that sort of addressed this by setting the primitive params in a while loop. This kinda goes against my philosophy because I'm pretty sure this function is only supposed to be used on initialization, not as a hack to mimic llSetPos. After attaching it to my regular back piece, I was surprised to see it function so fluidly: I had finally achieved a lateral floating effect. Problem: The problem came once I tried to apply the effect to more than one link in the group of linked prims on the back piece. After going to a scripting island, I bought a book that contained all the tutorials, and after some skimming I managed to find some scripting that worked on linked nodes and quickly realized how this could help performance by requiring only one script. TL;DR: Misusing code. Mysterious malfunction across linked family members. I could theoretically set a single script on my back piece that references each prim in the collection of links, and asks them to move forward and back. The Root Node In practice this gave me more hell than I wanted. By attaching the script to the root node and calling the script like this: llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]); The entire set of prims moved forward and back. But if I was to say link 2 instead of LINK_THIS, then the second link wouldn't move at all (which seems weird but might have to do with the whole initialization misuse thing I was talking about earlier). A Child Node Next plan of attack was to try and attach the script to a linked child node. This actually worked great because when I set it to the 2nd link, and updated the script to talk to link 2, it became isolated and the second link hovered. However, when I then set a second reference of the line (and even experimented with just one line to get the same result) to the LINK_THIS (the root node), the entire script ignored the llSleep that enforced the delay, and sped off into the horizon. Removing the "Fast" from the function call let me watch helplessly as it just block-hopped away lol. This seemed dumb to me and I still don't know why neither link could house a script that spoke to another link (so any answers on that would be helpful) Separate Nodes At this point I was going completely against what I set out to do - which was having one script to rule them all. I added a script to each individual link and made it refer to each individual link. Now the problem was that there's a performance dip although both links do their own individual movement. The performance drop was far too much to be considered acceptable. I found this frustrating and called my friend into a sandbox to demonstrate the bizarre phenomenon. However once they came in, the script didn't work at all. I tried relogging, I tried resetting the script, I tried changing sandboxes, nothing seemed to make it run although it was running fine on my current back piece. After looking it up, there were a few forum posts about sketchy halting performances relating to this function. Because of all this, I had to abandon the use of llSetLinkPrimitiveParamsFast to move on. Attempt #6: "Nah I don't buy it, it has to be an animation thing" Explanation: So my friend showed me their back halo(linked here) and I was flabbergasted at how beautiful and elegantly it did what I intended to do, but not only what I intended to do, but it was resizing and gently transitioning all over the place like I had dreamed of. I asked them immediately to tell me what they saw in the content section of the item. It revealed 2 scripts (anim script and texture script by creator definition) and 5 animations. At this point I convinced completely that it had to be an animation thing. Problem: I'm stuck in my head about what second life wants and what I can do to get around it. Second life clearly allows animations, but what it considers an animation is specifically motion capture data. This really really confuses my way of thinking and so I was convinced that my best bet was to reach out to a forum and get help from the great minds lingering around online. TL;DR: Please for the love of god I'm loosing my marbles. So yeah, I guess at this point you get how it's all going. If I can't get detailed help from anyone here, are there any in-game seminars I can attend to learn all this information because it's completely halting my creative process. Thank you, Marty ❤️