Pose Ball Phillosophy

Not one who likes to do things a certain way just because they've always been done that way, I was wondering if someone could explain something to me.

Are there any benefits and/or drawbacks, for that matter, to having a separate prim containing only your animation and pose script that is linked to your build, as opposed to just including the animation and the pose script in one of the prims of the build... say, for instance, the root prim?

It just seems if you could lose the hovering blue or pink ball it would make SL a much more beautiful place.

All thoughts, comments, suggestion are welcome.

Bartiloux Desmoulins
Bartiloux's Den of Sadistic Madness

I AGREE.

i have modded one of the freebie pose ball scripts i riped it out of the poseball and edited the sit target and rotation some to make the AV sit correctly in the chair. they look much better with out the balls hanging around AND on large build can save you a nice chunk of prims. i know of one scifi build that saved over 50 prims because of changing to this system.

NOW what would be even better would be to find a WORKING multipose script. there was one floating around but it had some issues that most people wouldnt be able to over come in the script. The multi pose script would be needed for a chair because different animations offset your AV different amounts on top of the different genders have the same problem. it would also be nice to be able to chose the anim you want for either your gender or your attitude or both.

The only benefits, IMO, is that they make it more clear where people can sit. That and since most furnature makers, I think, don't also make poses, it's easiest to integrate them into the object by just linking the bought poseballs in..

Not that those are really good reasons - they're just reasons.

There's discussion and some scripts intended to make it easier to move anims from poseballs into furniture prims, at .

Thank you for the replies as well as the link to the thread to assist with sit target positions.

To throw just a slight monkey wrench into the equation, let's say you put the sitting and animation smarts in one of the prims in the build instead of in a separate prim / pose ball. If your application requires that prim to then be rotated 90 degrees, will the avie that's presently sitting on the prim rotate as well, or will the avie remain in the original position indicated in the sit target?

Thank you again,
Bartiloux Desmoulins

If it's the root prim with the llSitTarget on which the avatar is sitting, then the avatar (and any other linked prims) will rotate. If the sit target is in a child prim, then the avatar will remain stationary--however, one can use llSetLinkPrimitiveParams() to rotate the avatar, too, at the same time the child prim is rotating, if that's desired. Or, for that matter, if the avatar is supposed to stay stationary with the root prim sit target, one could rotate the avatar *back* to the original location also with llSetLinkPrimitiveParams().

One added complexity: although the child-prim-seated avatar doesn't rotate, after that avatar stands, the next time the sit target is used the sitting avatar will assume the rotated position.

I absolutely detest poseballs in our furniture and toy builds and found my salvation in one tool

Primsitter

Absolutely does what it says with no problem. Usual setup time from dropping the Primsitter scripts into a prim to adding in the final position/rotation to the sit script in the prim - 5 minutes. Bam. Done.

The Creator of the item mentioned in the preceding post is a regular contributor to this forum. (It's not entirely kosher to mention products here, but I'm not gonna object--especially since some other merchant is offering a competing product, but mentioning this product's name in the classified ad.) I'd just mention, first, that the thread I cited above was started by a scripting "hero" of mine, so visit that person's shop, too , and that the freebie script I posted toward the end of that thread is intended to make it especially simple to use pre-existing poseballs as the origin of the to-be-embedded animation (and took a fair bit of experimentation and a little algebra to figure out ).

Another advantage of poseballs for furniture is they make clear whether the pose is masculine or feminine.

Search this forum for "easy sit target" for a free set of scripts, and I'll be posting a more complete freebie fairly soon.

I don't know how you figure that. If you're referring to the text, you don't need a poseball to have text display.

They are useful for cuddling or other couples poses, so that each person can easily find the right place to click. I also find them useful on couches for which some cushions don't have any pose, though I suppose one could argue that every cushion on a couch should have a pose.

Er.. Blue is for boys, pink is for girls?

Thanks Meade! Of course, you can put floating text on the cushion prims -- which is worse, the balls or the text?

In any case, I made my system available (free). See if you're interested.

Hmm, perhaps I should include a SetText script in my system, for convenience. Maybe next revision.

Color coding like that went out with the sixties.

Besides, it's unreliable. Most poses are gender neutral. There's no law that says the female has to sit on the male's lap, or that two men can't cuddle. So without descriptive text with more details, you don't really know what pink and blue mean.

Been to Bits & Bobs lately? Abranimations?


Uh.. Blue is for boys and pink is for girls?

I still use some poseballs in some applications (like baths, lawns, etc) where there are way more places to pose than there are structural prims, or where the center of any structural prim is far from where the posin' is gonna happen. FWIW, I've quit using pink vs blue, in favor of marble vs metal. Nobody seems to find it confusing.

I was designing a chair for myself this week, and was going to do that very thing, throw out the poseballs and use animations directly in the seat of the chair, using Easy Sit Target tool by Lex Neva to make sit targets. But then I came up against an issue. I wanted to have multiple sits, and each animation has a different sit target. Guess what, when you change the sit target, your AV doesn't use the new target until you get up and sit back down. So now, I'm going back to a poseball, as the ball can be moved and rotated into the correct position without the AV having to stand up. So there are good reasons for poseballs.

But now, with llSetLinkPrimitiveParams, you can move the AV around after they sit (where the AV is just another prim in the linkset).

I've used (but not created) furniture with both options. I agree with poseballs if the animation "spot" is out in space. Sitting by the edge of a pool for example.. its a visual indicator that 'this spot is interactive, come see'. And it is universally understood within SL as the metaphor is established.

I've also used furniture with text labels on cushions and such. If the text is managed well it works very well within the confines of a sofa or something similar. Its less gawdy in my opinion, but both text and poseballs can be hidden when in use so it's probably a matter of taste.

I've ALSO used furniture that was simply click and sit with no indicators whatsoever, or done scripted rotations through animations that I could not control. I HATE that ever since my avatar sat down and crossed his legs and winked like some desperate bar cougar might. Jumped off that chair, never sat down again!

Which tells me nothing about the animations.

oooh! great idea! thanks