animats

The delays are definitely server-side. I can teleport to a new sim, or fly over terrain, and wait tens of seconds for the geometry and textures to come in. I'm seeing CPU utilization of about 20% on my machine, network utilization around 10% (of 30Mb/s), low disk traffic, and no shortage of free RAM. Plenty of local resources. The delays are coming from the server side. Are the servers still in 32-bit mode? By now, they should be 64-bit machines with lots of RAM.

I'm continuing to work on making vehicles cross region boundaries better, with some success. I bought a motorcycle with full perms, and started working on its script. The first step was to log speed at sim crossings and do some driving. Not much goes wrong below 5m/sec. The second was to calculate the distance and time to the next sim crossing, based on current position and velocity, and hit the brakes before getting there. This gets through most sim crossings. It causes a slowdown when approaching the annoying region boundary in the middle of Kama City streets, but only when you're on course to hit the boundary. Straighten out and the brakes release. I've been having fun zooming around Kama City for the last hour or so. I can get up to about 50m/sec (112 mph) on Kama City streets without region crossing problems. The bike slows automatically for each region crossing.This is about as fast as I can drive on roads with arrow keys. If only scripts could read the joystick. I'm enjoying touring Zindra island. I start out out at my own property in Valllone and drive. There's a problem with sim crossings on roads on hills. There is sometimes open space between the road and the ground. It's possible to get into a situation where the bike is below the road, in open space, and the avatar is above the road. This creates huge forces in the physics engine, which is trying to pull bike and avatar together with an object between them. This is one of the problems that causes the avatar and vehicle to fly apart. The vehicle script is still running in that situation, and it may be possible to detect the problem and make it recover from this by turning phantom to release the physics stress, moving to a safe height, and turning phantom off. More on that later. It's quite possible to improve the vehicle experience in Second Life. This makes vehicles far more useful and fun.

Working on that. Currently trying to build Firestorm, build failed about 30% through, found a bug in the build procedure for Linux, filed a bug in Firestorm's JIRA.

Some questions about viewer internals: The host (sim) side has a physics engine, and the viewer side also has a physics engine. The sim side treats avatars as a capsule. The viewer side apparently treats avatars as a mesh object. Or at least that's what you see if you turn on Developer->Render metadata->Collision skeleton. What is that collision skeleton used for? Clothing? As far as I can tell, the only thing the viewer-side physics engine does is breast jiggle. It also apparently helps with uploading collision meshes for objects. Does that mean it's calculating the convex hulls? What does Firestorm use for a physics engine, if anything? I came across a reference to Bullet, but don't know if that's actually in. Is there anywhere this is discussed by people who actually know how it works? I've read through what passes for internal documentation for the viewer, but it doesn't mention physics at all.

Second Life succeeded at making online sex somewhat fun. That's turned into a problem for Linden Labs. It kept SL from becoming an advertising-based service, which is where all the money is. SL dates from when AOL was big and customers paid the bills. Hence Sansar, which may turn out to be about promoting major media franchises.

I'm not promoting it. It's just that there's a large abandoned temple around, and the original poster seemed to need something like that.

If some new religion wants a temple in SL, there's a large Indian-look temple complex available. It's in Kama City at Vallone (232, 108, 35), and for sale or rent from, inevitably, LIFE Properties. They're asking L$2100/week, but it's been vacant for a long time and that price might come down. The sale price already dropped. Six buildings, plus some elephants, minarets, and trees. (I own property nearby, but have no connection with this parcel.)

SL doesn't seem to fully recover from some kinds of packet loss. Check those colored bars at the top right of the viewer window. One of them is the packet loss rate. If it goes red, things may start to go wrong.

In Alchemy, I get the message "Could not connect to the voice server" at startup about one time in three. I only have 6mb/s bandwidth. I suspect that the problem is network overload. When you start a viewer, there's an enormous network load as it starts up and loads all that content. After startup, load goes down.This network overload may interfere with the initial connection to the voice server. The voice server connection code should probably do a few retries before giving up. It gives up within seconds of login, which is too soon. If this is intermittent, that's probably the problem. The developers may not be testing this on low-bandwidth connections.

I've seen that too, working on my own script for my own simple test vehicle in a mostly empty sandbox. I had to create a new script, copy the text from the old one, paste it into the new one, delete the old one, and rename the new one. Then the script worked again. "Reset scripts" didn't help. I'm doing a lot of region crossings in tests, and that may affect this.

I really didn't want to get into the internals of the viewer. But here's the viewer-side problem. Look in https://bitbucket.org/lindenlab/viewer-neko/src/36e2757983861221749f2e24348eea68cb4ed258/indra/newview/llviewerobject.cpp?fileviewer=file-view-default around line 2505. There's the predictor which extrapolates moving object positions during lag: // Calculate predicted position and velocity LLVector3 new_pos = (vel + (0.5f * (dt-PHYSICS_TIMESTEP)) * accel) * dt; LLVector3 new_v = accel * dt; The code above is guessing, in the absence of update messages, where the object now is. Mostly that works. But when you cross a region boundary, there's often a small change in position, and probably in velocity and acceleration, followed by about a second of no updates. That code amplifies any small change followed by lag into a huge change. There's no bounding, other than some code which prevents huge out of range values, and no low-pass filtering. There's code that stops motion after no updates for a while, but that takes seconds to kick in, because the sim doesn't send frequent updates to the viewer during normal motion if the normal motion isn't changing speed and direction. The viewer assumes that no update means keep going in the same direction at the same velocity, with acceleration applied. This is purely visual; you'll see it in the viewer, and when the next update comes in, the position will come back to where the sim thinks it is. With velocity interpolation off in the viewer, that doesn't happen, but movement becomes jerky. Try turning off velocity interpolation in the viewer, which lets you see just the positions the simulator send sends you. Walk your avatar in a straight line. You''ll move in big jerks, several seconds apart. That's the don't send an update optimization in action. Now try walking while turning. This forces the simulator to send frequent updates, and the viewer will now update rapidly. There are real glitches and stalls at region-crossing simulator handoffs, but they're usually not that big. I've been testing with velocity interpolation off. This viewer artifact makes them look much worse. Then the user makes bogus steering corrections in response to the bad imagery, and screws up the real position. What's needed is something like a Kalman filter to maintain a smoothed velocity in the viewer, to be used for interpolation. Maybe clamp velocity to a low value during region crossings.

I realize that. But try turning off "Velocity Interpolate Objects" and watch what happens. I've been testing in a large multi-sim sandbox island with little or no construction or activity, to see a clean situation. After waiting for everything in the sim to reach the viewer, network traffic finally drops off and there's little lag. With Velocity Interpolate Objects off, walk the avatar, holding down the up arrow key. The avatar will be stationary for 10-15 seconds at a time. That's because the server doesn't send frequent updates to the client when the avatar is moving in a straight line. Let go of the up arrow key, or turn, and the avatar is updated immediately. Usually, you don't see this effect, because the movement "interpolator" (really an extrapolator) hides it. This makes avatar movement look much better. Now try a fast vehicle across the sim boundary. Usually, there's about a 1-second pause and a rise of about 1 meter maximum. That's good; that means the server side is doing an OK job. (Sometimes the sim does come unglued, and you get messages such as "llStartAnimation: Script trying to trigger animations but agent not found". This is a known problem since 2013. There is a known workaround for vehicle scripts. That's all server-side. But flying through the air after crossing a server boundary and then coming back to normal is a client-side problem in velocity interpolation. That could be fixed in viewers. Since there are non-Linden viewers, it can be fixed without help from Linden Labs.

I've been looking at why vehicle behavior when crossing sim boundaries is so bad. One problem is viewer-side. The effect where vehicles go flying off into space at a sim crossing and then come back is a viewer-side problem. Whatever extrapolation algorithm "Velocity Interpolate Objects" uses is flawed, at least in Alchemy. Try driving a vehicle at moderate speed over a sim boundary on a connection with some lag. You'll probably fly off into space and then come back. Now turn off off "Velocity Interpolate Objects" in the Develop menu, and repeat. Now you stall for about a second when crossing a sim boundary. That shows what's really happening back at the servers. Is this a problem in the SL browser, too? (I'm on 64-bit Linux, so I can't run the SL browser easily.) Please check, so a bug report can be submitted. The extrapolation algorithm needs to be fixed. It needs clamping, or a low-pass filter, or it may even be differencing two positions from different sims and getting some huge velocity. Or it may be a straightforward math bug. Extrapolation from derivatives is always touchy. But those huge bogus velocities that rubber-band back to normal are a viewer-side problem. Sim-side screwups don't return to proper positions. See, for example, [1]. This is the kind of bug that doesn't show for devs working on high speed connections with low lag to the servers. (There are other server-side problems at sim crossings, most reported about ten years ago and not fixed. But this one is viewer-side and probably not hard to fix. [1] https://jira.secondlife.com/browse/SVC-22

Yes, the virtual-experience VR market is crowded. The problem with SL as a business is that users need a lot of free time. This limits the market. Sansar is go in, have the experience, go out. It's like the difference between Everquest and Angry Birds.

"Kama City is one of the 3 largest urban structures of the grid. ... capital city of Zindra ... From all urban places, Kama City is the most populated of all." - Second Life wiki. Kama City looks quite impressive at first. Roads, traffic signal, monorail tracks. But very few avatars. It's such an empty place. Where there are people, they're often in a skybox. Or they're dummy accounts running dancers or sales reps in empty nightclubs or stores. The real estate situation is dysfunctional. Most of the buildings are empty dummies owned by Love Life or some other big realty agency trying to sell them. Nobody even rents them. Four abandoned parcels recently went up for sale. I bought one, a friend bought one, and the other two were bought by real estate flippers who immediately put up For Sale signs at twice the price. Next door is a large temple in a combination of Indian and Moorish styles. It's empty and for sale. Real estate is far overpriced for the demand. This makes no sense. Maybe Linden Labs should adjust the tier rates to make land-hogging unprofitable. Don't offer discounts on tier for owning large amounts of property unless the properties are contiguous parcels. That would eliminate the advantage real estate brokers have, while allowing large projects to get a discount. Anyway, I set up a small outdoor cafe in Vallone. It's a technology demo - you can knock all the furniture around, and when everyone leaves, it will all return to normal. Or you can just sit at a table and enjoy the fountain. Few people will ever walk by, but it looks nice.

Fixed the problem by talking to the neighbors. Object entry ON, scripts OFF was just a bogus setting that they were given after a land auction. That setting breaks other things. If there are wandering birds or cats around, they'll die when they cross a property with those settings. So don't set your property that way. To see this working, visit my little cafe at Vallone/240/21/36. Sit in one of the chairs and enjoy the fountain. Then wreck the place. All the furniture, plants, and bottles can be knocked around. When you leave, everything goes back as before. Use weapons if you like. Let me know of any problems. Thanks.

OK, the normal cases work fine. I've been able to deal with region crossings. (Turn PHANTOM and PHYSICS on, apply a velocity towards home until in the right region. Then use llSetPos.) But I've found a case that doesn't work. There are some problems if the object goes into another parcel with certain settings. A parcel with total keep-out for other objects is fine. The object hits the permissions wall, doesn't enter the parcel, and the script brings it home. But if the permissions are set to Object entry for Everyone ON, Run scripts for Everyone OFF, the object can get in, and then its come-home script dies. This leaves the object stuck, perhaps in mid-air, in phantom mode.The property owner or the object owner can return or delete it, but otherwise it's stuck there. Other than that, it's looking good.

Get an account on the beta servers. No upload charges.

There are areas which look full, but almost everything is for sale or lease. Real estate operators fill up land with large unused buildings, creating the illusion that there's something there. But there isn't. Look at the world map, with all those sims with 0 to 2 avatars in them.

Just saw the trailer for Ready Player One. It's like an ad for Second Life, or maybe Sansar. Amazon is funding a series based on Snow Crash. Second Life is basically Snow Crash's "metaverse". Will Linden Labs use this opportunity to promote their products?

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.