Down with poseballs....

I'm making a bed, and I'm really sick of all the baloons hoverin' over my bed, obscuring my view, makin' me type hide/show a buncha times.... this is silly.

What I want to do is put my poses in the prims of my furniture, but this has it's own set of problems. Messin' around with that sit target and trying to eyeball those rotations is really an exercise in frustration.

What I'd like to do is put a pose on a primA (with a near-zero sit target), which is sitting near primB. Then I'd like to issue a command (like 'find target' or something) and have it give me the sit target and sit rotation that I would use to get the pose in the same place, but relative to primB instead.

I'll pay for this, if someone can help me out.

should be able to devide the rotation of object B by the rotation of object A and multiply in the rotation you want.

Not exactly sure about which needs to be multiplied by what or devided by what. rotation multiplication isn't reciprocal (think thats the term for it).

There are built in variables into LSL that deal with avatar height. There's no reason this could be integrated to deal with differences in AV heights.

wasn't the post about sit targets and not heights ^_^'

ah well

Do we really divide to get the difference between rotations? What about in the case of zero_rotation?

Not that I know what I'm talkin' about, but are we talkin' about the same thing?

I would have though that I would just subtract.

Rotations are quats. You can multiply them either by converting them to euclids first (function to do so is in game already) or but just practicing good quat math

That being said, quats make little children wake in fright in the middle of the nights.

Here's some links...
http://www.badgeometry.com/wiki/rotation
http://www.badgeometry.com/wiki/Quaternions

Once you grok quats, you are truly one with all 3D

I've been starting to create my own line of pose-enabled furniture that does this same thing, and am having the same headaches with relative position/orientation/etc. I'm working on a building a set of 'helper' prims that make this easier - one to represent the ball location, and one that one sits on and can be used to position the avatar, then report the details needed for the SitTarget.

Once I have a basic version working, would be more than happy to send you a copy.


- Newfie Pendragon

The real reason I find myself using pose-balls instead of just scripting the prims while making myself my own furniture for my home is actually the poses themselves: Each of them tend to place your avatar somewhere a tad different then the others and then you have to sit and compensate.

I'm afraid that there is no script function for finding out where your avatar's bum is going to end up at once you activate said pose, and its body orientation.

well, the butt is just below the waist. The waist is where the avatars elevation is calculated. So minus 5% or 10% of that or so, disregarding pacman avatars and the like. Even if the avatar is sitting, you should be able to come up with something reasonable for the body parts. 90% or so should be the mouth... something like that. Avatar width and depth are fixed values though, I think I read that someplace. So I think we need to start hittin' the lindens up for better avatar functions.

I was kinda pondering a control panel of sorts for the furniture... something that a piece can rez and derez to let you adjust all of the different targets. That would be a proper implementation, I think.

Poseballs take up prims, which we all know are a scarce resource. And imo, they are the lazy way out. But I am a stickler for realism, so maybe I'm just bein' a snob.

I can see it now, "llGetTushPos()"

llPushTush() would be more fun

- Ace

I'd settle for llUpDateSitPos(vector, rotation)

Or you could just take the easy way out and make the poseballs disappear automatically when somebody is on them. HEYO!

So didja read the whole thread, there, Nick? The point is to not have poseballs at all.... not to come up with a cheesy workaround. Poseballs in any fashion = cheeze imo. And those autohiding poseballs are really not well implemented as far as I have seen. I can't say I've seen every piece of furniture, so I don't mean this as a sweeping generalization really, but the ones I've seen have sloppy state work. If I say 'hide', the ball shouldn't show up when I stand up. Also my opinion, but it doesn't seem like I should have to issue extra commands for something like that.

Poseballs are easy, but when people start makin' quality furniture without them, I think you'll have a hard time sellin' stuff that still has em. Innovate, or be left in the dust!

And 'me too' on the llUpdateSitTarget();

So if you abolish pose balls. How do you handle multiple seats in a link set? Do user start clicking on pillows, table legs? I'd would assume you'd leave the scripted seats at the top of the link set. Sure it saves one primitive, but it's allot of work, and it make it harder for user to quickly identify what object to click on.

I've been toying with the idea of a 3d interface, for sitting, but I always remember about the limitation in spawning object. or the possible problems of an interface imbedded into a link set. If one of the goals is to save primitive, to have it in a link set generates more primes. mean while spawning doesn't always work, and it's complicated in comparison.

just my opinion but i think the biggest problem with poseballs is all the ones that have listeners. you find a room with 20 balls all listening individually for show/hide and that's a big hit on the sim from what i read.

i tried making a system with a helper ball to tell me the offset and rotation during like my second week in sl. ah to be so foolish and naive. granted i'm a newbie etc etc but i ran into problems finding the rotation since it seems like some animations have a visual offset even when everything says your avi butt is glued to the prim. you're three feet away rotating around that center when it says you're rotating in place on top of it. messed up all my rotations.

I haven't given it so much thought that I can say that there is never a time when poseballs are better, but why have five of them hovering over a couch? And why not click around? Surprise poses anyone? I'm working on a bed and I definitely don't want 25 balls hovering over it. A bed is symmetrical and it doesn't take a lot of thought to figure out how that might work.

And if a pose goes in a prim, the correct solution is to give it the correct offset anyway. Whether it's a lot of work isn't really important to the discussion, if you ask me (no disrespect intended there). It's still the correct implementation.... it's just that no one has taken the time to do it. I think once something like this hits the market, all this still will seem obvious. But who knows. I'll let you know how it sells

Hay would any one be interested in starting or joining a sls animation group. It would be an easy way to network with other scripters. As sls is updated, some script break, as people who script devices to trigger or stop animations, we probable come across the same problems. Aa group all of us could save time. Through mutual sharing and or consulting, (insert your own ideas here). Plus if some one was looking for a scriper experienced in animation scripting, the group would probable be the first place they would look.
Plus it would be a way to organize, giving us a chance to push our own agenda. Like getting all animation to have key, and to show up on get animation list. Or getting an llUpdateSitPos. I'm sure there are other things that would greatly improve animation scripts that I don't know about, but you do. Like the ability to write and read to desc field of animations in the innovatory of a primitive. Or a sure fire way to detect if the default sit animation is or is not playing.
By being a group we would be a much more tangible group. Showing linden labs that their is a demand for specific functions.

Plus we could look into the idea of an open standard, so we don't have our script conflicting with each other.

of corse it's just an idea.... and all other sequential ideas fallow.
What do you think?

Oh, i read it. I was just being silly. I tried to work around them in the begining but after strange occurances with SitTarget i gave it up.

Spend all the time and energy building the perfect solution and you'll go the way of Howard Huges, well... without spending quite so much money first I imagine

well, another thing you can do is have the ball go invis when you sit on it, and have it become visible when you get off.

This way you dont need to type anything, and you dont have to fuss with the sit positions and rotations.

it's posible to rig clicking to show / hide the sit prims. With a timer to auto hide after say a minute, and auto hide on sit.

Listeners and timers are BAD! I don't use them unless I have to... and as animator.. designer... island owner/club owner/mall owner I would not purchase your items for that very reason... Multiple listeners and timers can be very damaging to the performance of a sim/island.

umm ok, but I don't remember saying any thing about using a lisson. I remember some one else suggesting to use a lisson to hide show pose balls.

I was suggesting clicking as an alternative to lissoning. And then suggesting a timer for clean up. A timer would only need to be running for a minutes at most. (Right after some one clicks, and only after a show click, and of corse kill the timer on a hide click.) Witch is allot less sim intensive then a lisson, especially a lisson running 24 hours a day.

seriously after having door that open, and windows, extra. People just wondering around opening , closing, and using things. No one really bothers to close things when they're done. Clean up saves a tone of time. If you ever have a door or windows that opens, and you don't use clean up. I guaranty after a month. You will, because it's a pain to run a round and clean things up by hand. Every single day.

btw when I do make a script that uses a lisson. I make sure the lisson isn't running all the time. and I never use multiple lissons. Plus many of my scripts that do use lisson, I offer alternative scripts that use clicking when ever possible. And if some one wanted to use a lisson script in mass, i'd of corse be open to being hired to program a single lisson object. To talk to all scripts in a linked set.

I'm designing a new animation ball that requires only 1 ball per simultaneous user, multiple anims, easy to use changing between anims, and other features that will make this revision of ball technology a breakthrough.

This will be a move away from having to waste lots of prims on ballsets. It should cut lag because it will mean less listens, and it will provide developers much greater flexibility on what they create.

In the end, it should result in some pretty swank items for consumers.

I will announce more details, including the vendor who will be releasing this technology, at a later date once the script(s) is(are) written.

i fail to see what is so amazing about poseballs.