Wulfie Reanimator

Bento is not what people use to rig things to the body sliders. That's a much older (relatively speaking) Fitted Mesh feature. 2013: http://wiki.secondlife.com/wiki/Mesh/Rigging_Fitted_Mesh 2015: http://wiki.secondlife.com/wiki/BentoSkeletonGuide P.S. 2020 is making me feel older and older...

The teeth being no mod would definitely not cause what you're describing. The head itself is no-mod too, but that doesn't seem to be breaking the HUD, right? But out of curiosity, are the eyes/teeth attached to something on the head? (Like skull, left eye, mouth, etc.) All attachments on the head are hidden during mouselook, not sure if rigging counts, but if they are not hidden in mouselook, they could possibly block the HUD even though they're not "on" the HUD. For example, zooming into the edge of a prim shows it "cutting through" HUDs because of the math involved in the rendering.

You can hold a button to gain control of the cursor while in mouselook. I believe it's Alt. There's also a setting to either keep or hide the HUD in mouselook. I'm not sure what the exact issue/cause is, though. From what I understood, attaching the eyes/mouth makes the HUDs break, but work if you don't have them attached. If that's correct, I'm clueless.

Actually, pretty accurate. r/storiesAboutKevin Not so much about being entitled, but dumb, arrogant, and selfish/spiteful.

I was going to come here to post the same thing. This set of layers works amazingly, since every skin I have has too much built-in boob-shadow. Izzy indirectly made the chest a viable purchase.

Yes, you can mix genres just like in any other art. "Chibi" tends to go hand-in hand with kawaii because it's just a fact that humans find round shapes to be more "cute" and the whole point of chibi characters is the cuteness. It's not binary ("that's chibi, not kawaii") like your comment implies. It's not even uncommon to find kawaii mixed with pain/blood/horror elements. Especially bruises and bandaids, I imagine because being easily bruised implies frailty, which again fits with the kawaii theme. See, photos: example, example, art: example, example, art (blood): example, example, example Anyway, the above examples aren't the type I see on SL (nor one I really get), but yeah. My point is you can mix with literally anything.

Like others have already kind of pointed out "kawaii" in this context refers to the Japanese "culture of cuteness," specifically all things "lovable" or "adorable." There are many sub-types like lolita-fashion or idols. In SL it seems to primarily fall into the gothy categories. "Pastel-goth" was mentioned and that most accurately describes what I come across the most in random (not kawaii related) sims. Anyway, to appeal to this crowd in general doesn't require much beside making it pink and low-contrast. The item doesn't matter. It can be anything from frilly dresses and thigh-highs to 6-inch combat boots and syringes. Anything can be kawaii. P.S. The kawaii aesthetic caters to me so much.

Are you 100% sure you don't have a global and local variable with the same name? string input = "Not much, how about you?"; default { state_entry() { string input = "What's updog?"; llOwnerSay(input); } touch_start(integer n) { llOwnerSay(input); } } The local variable in state_entry will "hide" the global variable. If you try the above script inworld, it says different things in state_entry vs touch_start. Edit: Wow I'm tired. You literally answered this question... My bad. Still, that's basically the only thing that could be happening. If you successfully save the input to a global variable, it WILL be available in the next event, unless you override it again before using/outputting it. Edit2: I've seen the script now, it was exactly what @KT Kingsley and I were guessing.

Look, I like helping. But the script I've given you is incredibly simple to edit, there's even a comment for the part you need to change. I'm looking at the object you sent me and two of the links are spinning, just not the ones you want. You only need to change one link number. If you can't pay enough attention to notice/fix that on your own, I lose motivation and interest. Look at the script for one minute. Think about it.

The main problem is that your input is already in degrees but you still had input*RAD_TO_DEG, which converts radians to degrees. You were essentially scaling up the degrees by a lot, making it spin way too fast. Here's a fixed version of your code: integer input = 10; rotation rotate(vector axis, float angle) { vector V = axis * DEG_TO_RAD; V.z += angle * DEG_TO_RAD; return llEuler2Rot(V); } default { state_entry() { llSetTimerEvent(.05); } timer() { // Remember to change these. integer center_box = 2; integer outer_box = 3; integer axis = 4; rotation r = rotate(llRot2Euler( llList2Rot(llGetLinkPrimitiveParams(axis, [PRIM_ROTATION]), 0)) * RAD_TO_DEG, input); vector box1pos = ZERO_VECTOR; vector box2pos = <0.25, 0, 0> * r; rotation box1rot = r; rotation box2rot = r; llSetLinkPrimitiveParamsFast(1, [ PRIM_LINK_TARGET, center_box, PRIM_POS_LOCAL, box1pos, PRIM_ROT_LOCAL, box1rot, PRIM_LINK_TARGET, outer_box, PRIM_POS_LOCAL, box2pos, PRIM_ROT_LOCAL, box2rot ]); input += 10; if(input > 360) input = 10; } } I should also point out that all of the LSL functions return rotations expressed in radians. So llRot2Euler(some_rotation) would return a vector where all of the three values are in the range between about -3.14 to 3.14. That's -180 to 180 degrees, so you can see how radians are a much smaller unit. (Specifically, one degree is about 0.0174 radians. Very small!) That's why we have the DEG_TO_RAD and RAD_TO_DEG constants to convert between the two types of units. So, because it's much more intuitive for humans to think in degrees (because that's what we commonly use), I initially wrote my function to expect degrees, because I assumed you wanted to type in the angle and vector yourself. But if you're going to get the input directly from another object with the rotation functions, You could change things a bit like this: rotation rotate(vector axis, float angle) { axis.z += angle * DEG_TO_RAD; return llEuler2Rot(axis); } ... timer() { rotation r = rotate(llRot2Euler( llList2Rot(llGetLinkPrimitiveParams(axis, [PRIM_ROTATION]), 0)), input); Now the code is simplified even further, since we don't need to convert the values related to the axis at all -- only the angle that's getting added.

PRIM_ROTATION / PRIM_ROT_LOCAL are just different coordinate spaces. They both want quaternions, they just have different uses and aren't directly related to llGetRot. Don't think about it too much, I used _ROT_LOCAL because I want the final positions of the two cubes to always be relative to the root. Besides, your code works for me: https://puu.sh/G3Qdq/aaaa291e26.mp4 rotation r = rotate( llRot2Euler(llList2Rot(llGetLinkPrimitiveParams(4, [PRIM_ROTATION]), 0)) * RAD_TO_DEG, llGetTime()*RAD_TO_DEG );

<-39.442190, -34.623080, -37.278190> is just an arbitrary axis I used as an example / for testing. It's the orientation of the pink cone (which isn't linked to the script). Basically: llRot2Euler(llGetRot()) * RAD_TO_DEG; You can use any vector to any direction you want. The code will always make the object spin around the given vector. For example, I'll write a couple lines of code to create a vector that constantly changes direction: https://puu.sh/G3Q3b/975a29d29d.mp4 default { state_entry() { vector initial = <1,1,1>; while (1) { rotation axang = llAxisAngle2Rot(initial, llGetTime()); llSetText((string)[axang], <1,1,1>, 1); llSetLinkPrimitiveParamsFast(0, [PRIM_ROT_LOCAL, axang]); llSleep(0.066); } } } Then we just add that into our previous "rotating cubes" code: rotation axang = llAxisAngle2Rot(<1,1,1>, llGetTime()); vector axis = llRot2Euler(axang); rotation r = rotate(axis*RAD_TO_DEG, llGetTime()*RAD_TO_DEG); Now we have two cubes that are spinning around an axis that also spins around... https://puu.sh/G3Q5E/896477dbe0.mp4

I was trying out a bunch of things and after I got something working, I was able to reduce it down to this: (@Rolig Loon, look!) rotate(vector axis, float angle) { vector V = axis * DEG_TO_RAD; V.z += angle * DEG_TO_RAD; llSetText((string)["V ", V, "\n"], <1,1,1>, 1); llSetLinkPrimitiveParamsFast(0, [PRIM_ROT_LOCAL, llEuler2Rot(V)]); } Calling this function multiple times with the same input will keep the object static. Seems to work with every angle: default { state_entry() { while (1) { rotate(<-39.442190, -34.623080, -37.278190>, llGetTime()*RAD_TO_DEG); llSleep(0.066); } } } Output: https://puu.sh/G3F8q/8a8252cab3.mp4 So with a couple minor changes (like changing the function to return a rotation instead), you can make it rotate two linked prims without affecting the root (or other links) : rotation rotate(vector axis, float angle) { vector V = axis * DEG_TO_RAD; V.z += angle * DEG_TO_RAD; return llEuler2Rot(V); } default { state_entry() { while (1) { rotation r = rotate(<-39.442190, -34.623080, -37.278190>, llGetTime()*RAD_TO_DEG); vector box1pos = ZERO_VECTOR; vector box2pos = <0.25, 0, 0> * r; rotation box1rot = r; rotation box2rot = r; llSetLinkPrimitiveParamsFast(1, [ PRIM_LINK_TARGET, 2, PRIM_POS_LOCAL, box1pos, PRIM_ROT_LOCAL, box1rot, PRIM_LINK_TARGET, 3, PRIM_POS_LOCAL, box2pos, PRIM_ROT_LOCAL, box2rot ]); llSleep(0.066); } } } Output: https://puu.sh/G3Fm9/98e6ecc449.mp4 (The grey pyramid and two cubes are one linkset.) You could get rid of the DEG_TO_RAD calculations if you made sure your input was already in radians. And honestly, the way I figured this out was just from trying to create the "spinning" effect by hand through the edit window. Edit: To be fair, I tried to do all kinds of rotation-based things first. Conventional wisdom didn't work so I went back to basics. In hindsight the solution is extremely obvious. I inadvertently even explained how my solution works, earlier. The difference in those two bits of code is that one uses a specific axis to rotate around (axisAxis), while the second always rotates around the world Z axis (axisAxis = <0,0,1>). When you imagine a vector representing a rotation, the vector's "local space" is such that the Z axis points straight up. This means when you change the Z angle, you are causing the vector to "roll" or spin around itself rather than tilting into any direction. Think of when you have an object at ZERO_ROTATION. Changing the Z angle will cause the object to spin horizontally. The same applies when you turn the object upside down at a weird angle. If you change the Z angle of the rotation, the object will still spin "horizontally" in its own "local space," not region coordinates. Also, llAxisAngle2Rot doesn't do what you might assume. If you give it an angle of 0, you will always get ZERO_ROTATION, because llAxisAngle2Rot returns the rotation required to reach that destination. 0 change = ZERO_ROTATION.

And fix this. It shouldn't be that high. Running SL in 4k is not exactly what I would recommend either.

The difference in those two bits of code is that one uses a specific axis to rotate around (axisAxis), while the second always rotates around the world Z axis (axisAxis = <0,0,1>). If the axis is supposed to be tilted, the second one will break.

Don't worry, what you described could still be literally anything, so your idea is still safe with you. But if you can't get any help through this thread, you could send me a private message through the forum with the code. I won't share or judge.

Oh, I get it now. You want the objects to not move if the function is called repeatedly with the same angle. I'd also appreciate an answer then, because I asked the same question some time ago and nobody had the answer back then. I might be able to figure it out now, I have an idea in my head, but no time to get on SL to try it.

I don't quite understand what you're asking. Does the code actually do what you want? Do you just want to understand what it does? Or does it not do what you want and you need something changed?

No, just another meme. Both hairs you've shown are "alpha-based," or what we would call "alpha-blending." You can tell they are both alpha-blending because both of them have partially transparent pixels in the texture. They fade out smoothly. The other type would be called "alpha-masking." The difference is that alpha-masking textures can only have fully visible or fully hidden pixels in the texture. Hard, sharp edge. It can be used for hair but if you try to enable alpha-masking on traditional SL hair, you'll get pretty gross results. The reason why one hair works and the other doesn't is mostly up to chance. The other "working" hair will have similar glitches. When or where is hard to determine because this is just a quirk of SL rendering (that is also common in other places). I won't explain it in detail since I'm tired and it benefits very little. The creator of the second hair was smarter though, since they included a solid mesh piece for the main Volume of the hair, while the first one glitches all the way to the skull.

I'm a bit confused. The LL UV has both legs mapped separately -- you can have separate tattoos for each leg without anything special. The actual foot -- below the ankle -- is indeed duplicated. For that, you'd need a mesh body where each foot had its own material, or use one of the aux channels for BOM.

But what did she mean by this? 🤔

It's okay, I rarely read the viewer source too (hopefully one day I'll be fluent enough on C++ to do that), but I have a lot of "general knowledge," some practical knowledge, and the benefit of reading a lot of discussions specific to SL

[giant sculpty wang appears]

You made me do it. It's a little more nuanced than that. Let's say you're trying to render a scene with a simple cube in it. 6 sides, 2 triangles per side, 12 triangles. Let's ignore the texture on it. Rendering one on the screen is fine. Creating 300'000 copies of that cube would mean that your computer would have to sort 3.6 million triangles* (to determine which ones are facing the camera, or behind other triangles) and then put pixels on the screen one by one. Depending how the code is written, the same pixel might be drawn-over multiple times. Infinite memory still means your computer has to spend time doing many more calculations before generating an image. This is what causes your framerate to drop. It simply takes longer to render a single frame on the screen because there are more things to take into account (mesh, textures, everything). That's why additional copies of the mesh still causes lower framerates, why heavy mesh is Bad, and why "just buy more RAM" isn't a solution after a certain point. Larger textures can also take longer to draw onto the screen, but I don't know if that's the case with SL. (It depends entirely on how the code is written.) When you start running out of memory, the problems just get worse because now instead of just "drawing an image," your computer has to spend time figuring out which textures it can discard, and possibly load new ones from the (relatively much slower, even SSD) hard drive. VRAM stands for "video memory," or "Video Random Access Memory" if you really wanna spell it out. It's the amount of memory needed specifically from the graphics card, not just the regular RAM that your processor uses. When you create copies of an object, it needs to be stored somewhere so information about it can be tracked (location, scale, rotation, etc) and sent to the graphics card. So for every copy of an object, there is some memory cost even if the mesh and textures were "100% all shared." Otherwise you'd only render one thing, or all of the things identically on the same place. * 3.6 million triangles is not hard to reach, considering how Bad most mesh content is (especially as attachments). Your naked mesh body alone can put you halfway to your first million, or more. (Looking at you Legacy...) It has become more and more commonplace to see a single avatar reach the million-mark, I would even call it the norm.

Nope, I don't know if it ever was. To give a more concrete example, here's one mesh: Here's two of the same bed: Note: Faces/Triangles go up, but texture count, TMem (Texture memory) and VRAM (mesh included) remains the same. Without taking a deep dive into the memory management of the viewer (or explaining very technical details like the memory overhead of just keeping track of instances in memory), that's the easiest explanation I can give.