animats

I've been looking at what comes back for the bounding box during standing vs. sitting. The bounding box while standing is reasonable, and when sitting, the bounding box gets smaller in Z. But not by the right amount. It drops about 0.2m for a 2 meter avatar with about 0.5m lower legs. That's just wrong. Is there an explanation anywhere of exactly what the SL server knows and what the client knows about avatar position? I know that animation is purely visual and entirely client side, but sit/stand appears to be server side. Which side calculates object collisions? Both sides seem to have a physics engine. Is all this documented somewhere?

New Babbage is very well built. They have a building code, and the buildings from different people match well. They also have an annual Oiling Festival, where everyone tries to clean up outstanding problems.

Frame rate is a client side issue. It depends on client CPU and GPU power, and how much geometry has to be rendered. The client should be reducing level of detail when necessary. It does, but not very well. SL doesn't seem to be very good at reducing level of detail. Probably because game LOD technology is much better now than it was 15 years ago, and SL hasn't kept up. A big push to modernize SL's LOD technology on both the client and server side would make SL far more usable. One way to do this would be to have the server generate a textured low-resolution elevation map of each sim. Maybe 1 meter resolution. Also generate a version with maybe 4 meter resolution. Those would be sent over early in the update stream, and that would be what you saw of other sims until the prims were delivered over the network. No more looking at water where there's really land. Reasonably good looking when flying. Not too hard to retrofit. Second level fix - compute bounding boxes around buildings, and ship the outside over the net before the inside, unless the avatar is very close. This would help with buildings appearing from the inside out, which looks silly. (Won't help oversize "sky boxes". They'll render slowly. Might help to discourage sky boxes.)

So I try the same experiment at a different location, another 2 sim island that allows building, but with a short return time. There, the ball sinks into the ground at the sim crossing, but can be moved across it with the Move Tool. There are no error messages. What's going on here?

I've been trying to get a clear understanding of how the physics engine behaves at sim crossings. I've been testing in a sandbox that's an island of two sims. It's a pure sandbox, cleared every 4 hours, and there's almost nothing there. Landowner of both sims is "Governor Linden", group "Maintenance". So it's a clean test situation. I can rez objects on either side of the boundary. I can move non-physical objects across the boundary with the Move Tool. But if I rez a simple physical object ("Beach Ball"), from Library, and try to push it across the sim boundary with my avatar, I get "Can't move object ... because your objects are not allowed for this parcel". If I try to move a physics object with the Move Tool, I get "Can't reposition - permission denied". That's more restrictive than I'd expected. Physics objects are clearly locked into one sim here. None of this is well documented. I found an old Region Crossing Test test plan from Linden Labs. If SL passed that test, region crossing would work a lot better than it does.

I have a good solution working now. The object starts with physics off, waiting for a collision event. So the object can't move and is at its build location. On a collision event, the home location is captured. That's where it will go when moved back. Then, physics is enabled for the object, and we go to "hit" state. The object gets knocked around by avatars and other objects. A timer is running. Every 5 seconds, llSensor is called, and if a no_sensor event is reported, indicating no nearby avatars, the object is moved back to its home position. No need for "touch" events. Moving the object with the build tools works. Rezzing and derezzing work. The only remaining concern is what happens if the object is shoved into another sim, and returning to the old position using llSetPos isn't enough. Need to check for that. Anyone know of a sandbox which crosses a sim boundary? I have a little bar fight scene set up, with chairs and tables, bottles and cans. Everything can be knocked over. Bottles fall off the table and roll around. Looks good. Works OK for objects sitting on other objects, such as the bottles and cans. When physics turns on for the table, the bottles and cans get a collision event, and physics turns on for them, too. The mess persists as long as anybody is nearby. When nobody is nearby, it all resets successfully. There's an amusing side effect. When you sit in a chair that uses this script, physics turns on for the chair. That's fine.You can still sit in the chair. You can stand up and leave. It acts like a normal chair. But if someone else bumps into the occupied chair, the avatar gets banged around, still sit-locked to the chair. Sitting on an object with physics gives the avatar physics. The avatar can escape from this by standing. This may be useful in some roleplay scenarios. Makes the world more dynamic and lively.

I looked at how the library "Domino" works. That has physics off until a collision is reported. Then physics is turned on, and the domino can be knocked around. If it moves with physics off, it has to be the build tool or some script doing it, not action in the world. So that's how "domino" solves this problem. About half the time, though, you can walk through the stock domino without setting off the collision. Try it. (The "touch event" approach won't work. The goal here is to have an environment avatars can mess up, but which is reliably reset after a while. Can't let anybody but a builder change the home position.)

Using "touch" to update the home position means "touch" can't be used for other purposes. Also, anybody can "touch"; only people with build privileges should be able to move it permanently. I'd also rather not have a timer running; that uses resources on objects that are doing nothing. moving_start() and moving_end() might help, but they're broken. Reported as a bug in 2007: https://jira.secondlife.com/browse/SCR-82? Closed as "Won't fix" in 2012. I tested a little; it's possible to move something via "build" and not get a moving_end event. Needs more thought.

So I have an script which, for a physical object, returns it to its starting point after a while. Works fine. When the script is initialized, or the object is rezzed, it captures the current position, which becomes its new home position. It returns to there. But if someone re-arranges the objects with the build tools, the script does not know this. So it returns to the old position. Having the builder manually reset the object scripts works, but it's a pain. I'd like this to Just Work. Any way to detect "build_end"?

Right. But I think that's saying that, while the position and rotation are off, they're off by the difference between AVATAR_CENTER and the position of the root prim. So it may be possible to correct for this. Anyway, there's enough there to try things. Thanks.

How about this approach? The avatar starts this by touching an object A. Object A then rezzes a test object B (say a small ball), and somehow communicates with a script in B to tell it what avatar to talk to. B then does llRequestPermissions(avatarkey, PERMISSION_ATTACH | PERMISSION_TRIGGER_ANIMATION); B waits for "run_time_permissions" event. Then B does llAttachToAvatarTemp(attach_point); Useful attach points: ATTACH_PELVIS, ATTACH_BACK, ATTACH_LFOOT, ATTACH_RFOOT, ATTACH_BELLY. Now, use llGetPos in B to get its position, and also get the root position of the avatar. Transmit those back to A's script, or use the info to move the avatar. When done, detach the test object. The test object doesn't have to be visible, of course. Will that work? (But see llGetPos "Caveats". This won't return the actual position of the attachment if animation is involved. Animation is entirely client-side. But it should get the basic position when not being animated.)

OK, llGetAgentSize gets the bounding box info as if standing and massages the numbers a bit. Thanks. Can I measure an avatar by moving around another sensing object until it collides with the avatar, then recording the collision position? Suppose I wanted the offset of the back/buttocks from the center of the root? If I slowly move an object until it collides with the avatar, I should get a collision event. But what collides? Can I get mesh/mesh collision detection? Prims only? Or just the bounding box? Thanks. (Goal: automatic pose ball adjustment.)

The free Avatar Ruler measures the height of an avatar accurately.How does it do that? It gets the right answer even when the avatar is sitting. That means it cant be using the bounding box dimensions; those change when sitting. It doesn't work by lowering a measuring object until it gets a collision, since it gets the same result for sitting and standing. It doesn't force the avatar into a standard pose. Can't read the script, unfortunately. Anyone know how that's done? I want to get dimensional information from an avatar to adjust animations.

I had the same problem as a new user - worked once, didn't work again. Found the solution. If you get the message "Allow ... to animate your avatar", and you accidentally click on "Block", the object goes on your block list and can never pop up a menu for you again. So the object appears broken. Fix: Go to People->Blocked, which also has a list of blocked objects, and remove the necessary items from the block list.

I found and read the New Babbage web site.

As a new user, the sheer emptyness. Parts of the world are beautiful, but so unused. So much real estate for sale. So many vacant buildings. In one deserted club, I tried the DJ station, played one song to an empty room, turned off the sound and lighting effects, and left. There are impressive, well-built places such as New Babbage. That city has so much beautiful detail, and there's so much to find. There are few people there, though. Its heyday was five to ten years ago. The factories and trams still run, empty. It's sad. I went to a party there two days ago, and most of the ten or so people who keep it going showed up for an hour. Not enough for a small city.