animats
-
Posts
6,172 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by animats
-
-
2 minutes ago, Love Zhaoying said:
Sounds bad, not everyone uses RLV. I realize you are targeting FireStorm.
I agree. This is to demonstrate that it's possible to fix the problem. It would be much better if LL fixed it sim-side.
I've discovered that sometimes it takes more than one teleport to get the avatar unstuck. A region cross and an avatar teleport are much the same thing underneath, Oz Linden pointed out to me. The teleport just comes with an animation and sound effects. You know how sometimes teleports fail, and you have to try again? I now suspect that failed region crossings are the same failure. Maybe the answer is simply that sims need to retry region crossings a few times before giving up. That's what I'm doing here, with scripts and RLV, and it works.
This makes sense. A region crossing is a network operation between different computers. You have to assume those will fail some of the time, and be able to deal with that.
-
1
-
-
And three weeks later, someone with a bigger, better plane carried the first passenger across the Atlantic.
Script state size is never more than 64K bytes. Number of prims seems to be a much bigger factor than script count. Each object apparently requires a database lookup. (It definitely works that way in OpenSim; for LL's implementation, the source code is proprietary.) The 10-second crossings reported for large ships are for ones with very complex geometry.
Try a free bike with most of this implemented. Take a copy of the yellow and black test bike here. This one, if you come off at a region crossing, will try to teleport you to the bike's location, but won't sit you back on it. You have to do that yourself. No RLV required, but it asks for teleport permission. It doesn't seem to have a region crossing delay problem. It carries a lot of debug and logging code the production version won't need, so this is a worst case.
-
1
-
-
8 hours ago, Rolig Loon said:
Yes. This doesn't call for an animation, but for some sleight of hand in scripting, which may or may not work.
I'm trying for a subtle effect here. I've developed a fix for the Firestorm viewer that eliminates most bogus motion at region crossings. Instead of bogus motion, the vehicle or avatar stops dead for a second or two at each region crossing. Here's what that looks like. With the old viewer, the boat not only moves strangely at sim crossings, it goes underwater twice. I've written about this over in the "vehicles and sim crossings" topic.
The old behavior was awful, leading to drivers crashing because they tried to make steering corrections when the viewer showed them bogus positions. But for slow sailboats, it looked OK. Up to about walking speed, region crossings on water look good. The boat seems to glide smoothly across the region crossing. Then it is suddenly jerked back when the sim handover completes. The jerk-back is so fast that users can ignore it, and enjoy the peaceful experience of sailing slowly. Some users like that behavior.
So I'm trying to figure out how to give sailors the pleasant experience of a smooth region cross at slow speed without big bogus motion at higher speed. What I want to do is to animate the vehicle and avatars so that they appear to move smoothly across the region boundary during the stall. This means animating them moving forward at slow speed during the stall. This is illusory motion, viewer side only, like all animations, and can run during sim handoff. After the transfer to the new sim, the vehicle and avatar are being displayed ahead of where they really are. We have to take that extra motion back. But rather then moving them back in one big jerk, we do it slowly over 5-10 seconds, more slowly than the real motion is moving them forward. That way, there's always smooth forward motion, although the speed varies a bit. (There's no way of escaping that as long as region crossings take time. But we can mask it.)
This would be a script and animation you put into slow boats to improve the visual experience, similar to a wake animation.
So that's what this is all about. I just want suggestions on the right tools for the job. I may end up creating BVH files from a spreadsheet.
-
1
-
-
Well, I finally found a way to recover from the "half-unsit" failure at a region crossing. But the driver/passenger has to wear an RLV relay.
- Detect half-unsit in vehicle script.
- Stop vehicle from within script.
- Get location of vehicle.
- Find clear space near vehicle where avatar can stand. (Not on top of the vehicle; the "sit" step may not work.)
- Teleport avatar there using RLV command: @tpto:Fenfarg High/242/254/66=force
- Check location of avatar. If it's not at the desired destination, teleport it somewhere safe, then try again. Sometimes the first teleport/unsit won't work right.
- Put avatar back in vehicle with RLV command: @sit:98128b10-54b7-c788-8fd9-d322571470af=force
- Reset vehicle and avatar animations, take controls, and return control to the user to drive again.
This workaround is clunky. But it works. It demonstrates that "half unsits" are recoverable. I'll make up a demo bike that does this and let people try it.
I now have fixes or workarounds for almost all the things that can go wrong at region crossings.
(This really should be fixed by Linden Labs on the sim side, of course.)
-
2
-
12 minutes ago, Love Zhaoying said:
Ok, never heard of using an animation for a vehicle, maybe keyframe motion..
The "keyframe" system, I think, is equivalent to calling llSetPos(). That won't work during a region crossing, because the script is stopped during handoff between sims. But animations, which are viewer-side, can continue to run.
-
1 hour ago, Love Zhaoying said:
Is the vehicle mesh, and you’re planning to use animesh features?
Not animesh. May be mesh. It's about creating the illusion that a boat is seamlessly crossing a sim boundary, even though there's really a stall during sim handoff.
-
I want to animate a vehicle's position, moving it a few meters from its actual position. This is related to my region-crossing work. I need a position-only BVH file. It only needs one track. What's the recommended tool for this? There's lots of information on line, but most of it is a decade old.
- "qvimator" seems to only be good for skeletons. Also, what are qvimator's position units? They're not meters. They're not centimeters.
- "bvhacker"'s site says it's only for editing existing files, not creation.
- What's the unit used for position in BVH files?
Also, if I animate the root prim of a vehicle, do the avatars follow along, or do they each need to be animated separately?
-
44 minutes ago, Luna Bliss said:
Aye, the most wondrous beauty is but a longing..
If you want land in the middle of nowhere with mountain views, it's not hard to find in SL. There are lots of abandoned parcels in isolated areas. If you have a premium membership, you can request that an abandoned parcel be auctioned by sending in a support ticket.
- http://maps.secondlife.com/secondlife/Blanda/165/101/139 Underdeveloped Heterocetra
- http://maps.secondlife.com/secondlife/Simcoe/106/44/97 Abandoned mainland. Looks like the surface of the moon.
There's lots more.
-
OK. Is this documented by LL somewhere?
-
If you don't want to be in a shared world, build in Sansar. It's all about private spaces.
-
Give them one of these.
I just sent the original poster one of these obelisks. They're free to copy. I found one on Heterocera.
-
Here's a list of bugs in the JIRA listed as closed and fixed, ordered by when the bug report was submitted.
- Bugs reported in 2017 now fixed: 1.
- Bugs reported in 2016 now fixed: 2.
- Bugs reported in 2015 now fixed: 1.
- Bugs reported in 2014 now fixed: 28.
- Bugs reported in 2013 now fixed: 75.
- 2018: 1.
- 2017: 3.
- 2016: 4.
- 2015: 24.
- 2014: 65.
- 2013: 87.
-
What operating system? What viewer? What time does your clock say? Do you have your time zone set correctly?
-
Whatever happened with the 64-bit Linux viewer? That's mentioned in various places as "real soon now", but the downloadable viewer is 32-bit only. The latest Linux desktop distros are 64-bit only. Nobody runs 32-bit on big machines any more.
Apple just announced end of life for 32-bit applications.
(I just need to run the SL viewer to report bugs.I run Firestorm for real use.)
-
7 hours ago, Theresa Tennyson said:
I would like to suggest an additional optional mode where instead of stopping at the region border, the vehicle is drawn continuing on a straight line at the constant speed and direction that it hit the border.
During the sim crossing, the vehicle really doesn't move, because simulation was stopped in the sim being left and hasn't started yet in the sim being entered. If the viewer fakes forward motion, there has to be a "yank back" to get viewer and sim back in sync. For boats, the "yank-back" isn't too bad visually, because all water looks pretty much the same. By the same token, a stall on water isn't too bad visually, if the flags and sails can be kept flapping and the audio keeps going. That may need a little work on the script side. Vehicle scripts do need sim crossing awareness to deal with some of the problems.
If you show the user a phony position for a land vehicle, they'll make bogus steering corrections and crash. That's unacceptable. One major SL bike builder tells me that turns off some real bikers from trying SL bikes. They have the reflexes for driving, and SL's artifacts make them do the wrong thing.
Find me a cheap SL boat with full perms, and I'll try to improve its sim crossing experience. Thanks.
-
2
-
-
A Linden Labs promotion for Second Life.
But the only reason I found this was because I was reading the forum for High Fidelity. Is this being run as an ad, or what?
-
2
-
-
Further progress.
The viewer fix is going into the Firestorm beta, so everyone will have a chance to try it. I've been using it for weeks, and it's a clear improvement. No more strange looping and twisting at region crossings. There's still a stall; that's inherent in the SL architecture. It's usually about 1 second for small vehicles. I've tried some larger boats; they take several seconds, but in open water you don't notice.
I've been able to improve a few things at region crossings via more checks in the vehicle script. It's common for the camera to get out of position at a region crossing. Also, sometimes the avatar's driving/riding animation stops. Both of those are fixable.
After every region crossing, the vehicle script checks the distance between vehicle and avatar (this sometimes gets large for a moment), that the avatar links back to the vehicle (that link is broken momentarily at sim crossings), that all the proper permissions are still set, and that the avatar is sitting. This is checked every 100ms after a region crossing until all tests pass. This indicates a successful region crossing. Then all the camera parameters are reset and the driving animation is restarted. The visible result is that the camera doesn't jerk and the avatar animation doesn't stop.
I give out full-perm demo bikes with these fixes to vehicle builders so they can see how this works. If you're a vehicle builder or vehicle script writer, contact me and you'll get one of my test bikes with bright yellow stripes.
The big remaining problem is the "half-unsit" described previously. That seems to happen when the vehicle makes it across the sim crossing but, for some reason, the avatar does not. In that situation you can't unsit. This is clearly a bug. Only LL can fix that one. I'm trying to develop an un-deniable test case. It's much easier to see this bug with all the other stuff fixed.
-
3
-
-
I was thinking vendors, too. I was expecting to find some abandoned store with a wall of dead vendors. But no.
-
6 hours ago, Theresa Tennyson said:
If you watch the statistics bar you'll notice that Vallone normally runs about 100% of the scripts in every frame, but every so often you'll notice that this figure drops dramatically, meaning that more scripting wants to be run, and these increases in script time coincide with the drops in simulator frame rate.
You'll also notice a couple of lots that have build turned on for everyone and no auto-return set.
And this is why we can't have nice things.
I've been looking around, and I can't find anything exciting on the lots that have build turned on for everyone. No signs of squatting or dumping.
What may be causing the peak load is unwanted synchronization. If you write a task that uses shared resources, then waits for N seconds, and run a lot of copies of that, all the tasks will sync up and try to run at the same time. (This is a classic result from operating system theory.) So maybe somebody has a lot of objects with a script with a 10 second wait in it.
I just spent an hour peering into everything in the sim, all the way up to 4096 meters. Found nothing that could explain the lag. There's a nice garden that has animated leaves falling and butterflies, but those seem to be looping animations, not active scripts. Saw various sky boxes, sex rooms, and abandoned builds, but nothing that looked like it did anything. I peered inside the three parcels that have ban lines, and there's nothing there to cause lag. I was looking for something like a store full of identical forgotten vending machines, all trying to phone home to some defunct web server. The statistics window shows huge amounts of "Pump IO" when the sim is lagging. But no.
Are there any tools to help with this? Per-parcel statistics?
-
21 hours ago, animats said:
Sometimes lag may just be a bug. Vallone, which usually has zero or one avatars in it, has a huge lag every 10 seconds or so during which the frame rate drops to zero. I have a lag meter on the corner. It's just Vallone. Kama Center, across the road, is fine.
With broken Vallone sim to test on, I've been logging and recording video of this. What happens is that, about once every 10 seconds, Vallone sim stops sending object update messages. You can turn on a feature in the viewer (at least in Firestorm) where little squares appear above an object as updates for it come in. During these stalls, those totally stop.
Sims don't send object position updates if the object is moving with the same velocity (both linear and angular) and acceleration as previously sent. Viewers extrapolate from the last update when no updates are coming in. This works great when updates are coming in on time, and terribly when they're lost or sent late.
Lack of an update causes velocity interpolation to extrapolate from the last frame, which, if the object is doing anything interesting like turning, extrapolates too far and is usually bogus. Velocity interpolation knows about "sim running slow", and the sim slowdown factor is applied to velocity interpolation. But that only works if the sim is consistently slow. The viewer finds out about intermittent lag too late, after the lag is over. The update message after the lag has a slowdown factor update. This class of lag is the cause of most bogus motion not near a sim boundary.
I'm looking at this in detail because I've been working on that section of code in the Firestorm viewer, improving region crossings. There are viewer-side workarounds which could make things look a bit better. If no packets are coming in from a sim for any object, assuming the sim is running slow or there's packet loss is a good guess. I'm reluctant to put that in, though without coordination with the LL sim side. It's guessing in the absence of information, after all. All the viewer can do is turn a sim stall into a visible stall. It can't fix the lag.
-
1
-
-
Sometimes lag may just be a bug. Vallone, which usually has zero or one avatars in it, has a huge lag every 10 seconds or so during which the frame rate drops to zero. I have a lag meter on the corner. It's just Vallone; Kama Center, the next sim over, has an identical lag meter, and theirs doesn't show this. With one avatar on the sim, the lag is much worse. (It's not just me; I've had others come over for test purposes.) Walking around, your avatar stalls totally during those periods. Vehicles are even worse.
I put in a support ticket (#204301), and the sim has been restarted twice, with no effect. Izzy Linden looked for the problem, but couldn't find it. Somewhere on Vallone, or possibly on the machine hosting it and other sims, something is using heavy simulator resources. Ot hasn't been found yet. Most of the sim is for rent or sale; there's not much going on there.
Anyone seeing this elsewhere? It's really obvious if you have a lag meter column - it stays green most of the time, then drops all the way to zero, going red at ground level, then comes back up.
-
Ah. The problem here is that you're setting what SL calls "omega", which is the angular acceleration vector. If that value is very small, it will be treated as zero by the physics engine, to reduce load on the simulator. If you want really slow rotation, like 1 RPM or less, you'll probably have to compute and set angular position directly. Try using llSetLocalRot on your planetarium objects, and update the positions from a timer. See http://wiki.secondlife.com/wiki/LlSetLocalRot
-
3
-
-
11 hours ago, Qie Niangao said:
I peeked in on the sim to see if I could find any of "the usual suspects" for Mainland lag, but this one is different than I usually see. The only lag I found was very spiked "Pump IO". Performance will be cruising along perfectly normally for a few seconds and then suddenly add hundreds of milliseconds of "Pump IO" to the simulation frame. A little slice of the spikes get accounted to "Net Time" but the vast majority goes to "Spare Time".
Vallone is running BlueSteel 18.01.08.511751 -- not sure if this warrants a jira, or if anybody would want to investigate what's happening before a restart removes all evidence.
It's a spiky problem, as you said. No lag, then huge lag for a second or so, then no lag again.
I put up a "lag meter" column on my lot. It drops to yellow and red briefly every 10 seconds or so. If I cross the street from Vallone to Kama Center, with zero avatars now in Vallone, that stops. But the neighbor across the street has an identical lag meter (mine is a copy of his) and it doesn't drop to yellow or red when I'm on that sim. I don't have an exotic avatar or any unusual outfits. I've tried going back to a standard-issue newbie avatar from White Tiger, and the lag still happens.
If you want to see this, go to Vallone (249, 7, 36). Try crossing the streets while watching the lag meter at the corner.
-
Could that be some kind of attack? That's a common form of web attack, asking the user to install some fake "plugin".
Facebook
Instagram
Twitter
YouTube
Flickr
Vehicles vs. sim crossings, why it's so awful
in General Second Life Tech Discussion
Posted · Edited by animats
The useful insight here is that a region crossing is just a forced teleport followed by a forced sit, minus the swirling animation and the "whoosh" sound. The things that go wrong with region crossings are the same things that could go wrong with a forced teleport and a forced sit.
What really seems to happen in a region crossing is this:
Trouble occurs when the avatar can't catch up to the vehicle. This is why double region crossings often fail. Vehicle is teleported from sim A to sim B, avatar starts teleport from sim A to sim B, vehicle moves out of region B into region C, vehicle starts teleport to region C, avatar arrives in region B, avatar is ordered to sit on a vehicle no longer in that sim, avatar gets stuck in sim B.
The bug is that the current sim side code just gives up when the sit fails, leaving the user with a stuck avatar. That's no good. It's necessary to detect that the avatar forced sit failed, find the vehicle, teleport the avatar there, and try to sit it again. I'm doing that with scripts and RLV, which is clunky, but indicates that the sim has all the information it needs to fix the problem. It's interesting that a script in the vehicle can do a llTeleportAgent on an avatar attached to the vehicle even though the avatar is in a different region. The vehicle script still has control over all the disconnected parts.