Jump to content

animats

Resident
  • Content Count

    1,927
  • Joined

  • Last visited

Everything posted by animats

  1. It's a Linden road hitting a sim corner at a 45 degree angle. One of the worst cases. It's not the corner itself that causes the problem. it's two sim crossings very close in time. Somewhere there's a race condition in the software. I've tried this about thirty times now, with two failures. This may be associated with "Unable to create pending connection" errors.
  2. There are still sim-side problems. Like this one. This is on Circuit le Corse, at http://maps.secondlife.com/secondlife/Pearl/-1/245/28. I've had this happen here twice. The vehicle script reports animation permission errors. The rider is unseated, but stuck. Cursor keys do nothing. It's hard to get out of this. Even after the bike times out and derezzes, the avatar doesn't get the cursor keys back. "Reset skeleton and animations" will restore the ability to rotate the avatar, but not to move it. I've seen this failure many times. Sometimes some of the cursor keys are returned to the avatar; sometimes none of them are. This time it's so bad that nothing short of logging out will fix it. More later.
  3. Vehicles tried so far: Sport motorcycle: https://marketplace.secondlife.com/p/SPORT-BIKE-M1-Motorcycle-boxed/1340735 Speedboat: https://marketplace.secondlife.com/p/Anna-Erotica-Speed-Boat/7723235 Boat: https://marketplace.secondlife.com/p/Belleza-Sport-Powerboat-v10-Boxed-boat-speedboat/1165949 Bus: https://marketplace.secondlife.com/p/BUSCOACH-by-Arcadia-Revisited/12873964 These are all L$10 and under, so feel free to buy your own to get further information.
  4. More development and testing today. Found the cause of the "sideways jerk" problem and fixed that. The clipping code in the viewer must allow locations outside a region when the sim gives it such a location. This happens routinely just after a sim crossing, before the gaining sim takes over. The viewer just can't make guesses that go outside the region; the guesses will be awful. With this fix, hitting a sim crossing at an angle now works better. There's no "sideways jerk". I built a test road in an big sandbox to check that out. With the new code working in Firestorm, I went off to enjoy it. For a pleasant evening, I started with a ride around the Circuit de Corse on a motorcycle. This has lots of off-angle sim crossings. No problems with those. The roads on the Circuit de Corse seem to have duplicated prims in the under-road layer that cross the sim boundary from both sides. They have to, or the off-angle road crossings wouldn't work at all. At each sim crossing, there's a freeze for about one second. The motorcycle sound stops for a moment, then picks up. No jerk, no drama, no steering corrections needed at sim crossings. Just drove around in Gear 3 of 6. Faster than that, and I can't keep it on the road. I made it around the circuit in about 20 minutes. It's not bug-free yet. The "loss of animation permissions" problem came up several times. That's a known problem and can be worked around in vehicle scripts, but the bike I'm using doesn't have it. It'a stock bike, and does not have my "automatically slow down for sim crossing" code. I wanted to test without that. At http://maps.secondlife.com/secondlife/Venostrate/11/3/28 I was thrown off the bike. I want to go back there and look closely at the road, but today I was just doing this for enjoyment. I've been asked about other vehicles. So I started at my little cafe in Vallone, where i have a parking area for rezzing vehicles. I rezzed a VTOL aircraft and flew it over Kama City, trying to stay over streets to avoid hostile security orbs. (Security orbs need to be more tightly regulated. I've had aircraft shot down by zero-delay security orbs. That's griefing.) Flying worked fine. At each region crossing, there's the usual one second pause. This is made more annoying by bad camera control - the camera gains on the aircraft, then falls back once the aircraft gets moving again. Camera control with the motorcycle needs work, too. There's slow drift. The camera starts out behind the motorcycle, but after a few minutes, it's off-axis. Easy to fix, but annoying. I went out to the edge of the world past Kama City, and banged against it as a test. (The same code that does region clipping does world edge clipping, so that needed to be tested.) Banging into the edge of the world works the same way it used to. Then I flew along the coastline of the west edge of Zindra, looking for a rez area. I found one next to a dock, and landed the VTOL plane. There I rezzed a power boat, got it into the water, and started cruising around the bays to the west of Zindra. This worked fine. As usual, there's a one-second stall at every sim crossing. The engine noise stops, the flag stops flapping, and the water spray stops, which means the sim is telling the vehicle script that velocity is zero. Tried zooming around at 50 knots. Hit sim crossings. No problems. Tried zigzagging across sim crossings. No problems. Slowed down and went up the river in Zindra all the way to the dam. Nice sightseeing. Came out of the river, went north under the lift bridge, and around toward Horizons. Found a Linden dock on the Zindra side and docked. Stood up, and the Linden water area immediately de-rezzed the boat, dropping me in the water. (Come on, give people a minute on Linden land before you de-rez a vehicle.) Climbed out, and walked to a monorail station. Rode the monorail back towards Vallone. The monorail dumped me on the ground at a sim crossing. (That system needs work, not that anybody uses it.) Walked back to Vallone. Very slow sim crossings at some streets, as long as 8 seconds. Must be an overloaded server. Usual sink-into-the-ground Kama City intersections, as discussed previously. Back home at my cafe after about two hours. No teleports at any time. Vehicles are about to become much more usable in Second Life.
  5. The viewer fix definitely helps in cluttered environments. I've been testing in Kama City and on the Circuit de Corse route. The Circuit de Corse roads are good for testing - they have frequent, well-marked rez zones, road signs, and go through interesting country. There are hills and curves. I just rode a motorcycle around the circuit that starts at the above link, while using my modified Firestorm viewer and a stock bike. Took about 15 minutes. I didn't bother to slow down for sim crossings. There's a stall of 0.5 to 2 seconds at every sim crossing. Longer stalls usually mean a busier sim. Crossings hit off-angle produce a moderate sideways jerk. (I'll look into that. Might be fixable.) But there's no flying off into space. I can relax, ride, and enjoy the scenery. It's much better than with a standard viewer. The worst that happened was when I was trying to pass one of the Linden bubble cars (yes, I know they're phantoms and you can go through them) at a sim crossing. The avatar came loose and was re-seated, but not in the right place. That's a known problem in vehicle scripts. The fixes I've described to viewers and roads make driving in SL fun, and usable as a way to get around. SL is great for sightseeing with this. I want to see this fixed for everyone.
  6. I've been talking to a Firestorm dev. and have submitted a patch to the Firestorm JIRA. So the process of getting this fix deployed has started. The viewer side fix doesn't fix all the problems, but it prevents little twitches from turning into huge bogus movements that drive users nuts and make drivers crash. With that fix, you can see the real problems underneath, many of which can be fixed by simple changes to roads at sim crossings. Water is still a problem. That would require code changes in the simulator to fix. Roads can be fixed in-world, but not water.
  7. Air vehicles don't have the problems of road vehicles. See my linked topic on Vehicles vs. sim crossings for more info.
  8. Thanks. I checked out the road crossings at http://maps.secondlife.com/secondlife/Windermere/0/98/39 and http://maps.secondlife.com/secondlife/Buttermere/1/160/37 but neither is a good location for high speed vehicle testing. Both are narrow roads with turns. This needs some straight-line open space and a road modified near the sim crossing. The idea is to build a road with some overlap, and drive over it fast with various vehicles in a heavily loaded sim. This test works fine in empty, near-idle sandboxes, so the next step is to try it in a loaded one. Skyboxes are an option, but I'd rather do this at ground level. It's simpler.
  9. I'm looking for some land I can use to test region crossing issues for vehicles. What I need is: Two adjacent parcels in different regions with building permission on both sides. Enough space for a 64m x 8m road on each side. A busy sim with some lag and many avatars. (This test works fine in an empty sandbox.) Just a few days of use. See for the goal here.
  10. “Modified Firestorm Viewer?” Yes. I built the Firestorm viewer from source code and made some changes. See https://jira.phoenixviewer.com/browse/FIRE-21915 The velocity interpolation algorithm in the viewer amplifies problems at sim boundaries. That's easily fixable. Not enough information to be helpful. Are there viewable objects on all four sims, or are they empty besides your track? it's a nearly empty sandbox. That sandbox is both adult and premium, so it's not used much. Very little lag. This experiment needs to be repeated in a busier environment. Know any place that's busy and has a sim crossing where building is allowed on both sides? Are you wearing a lot of scripted objects? No Are you wearing a lot of attachments? No How is your avatar complexity? About 50K. Totally irrelevant to this problem.
  11. Tried that. Here's a worst-case test. Circular track across four region boundaries. Currently in Sandbox Teagano (20, 0, 32) . So here's a motorcycle, going round and round on a circular track across four region boundaries without problems. The track is 2m thick (1m is probably enough). Each quarter of the track is in its own sim, and has a 4m extension into the next sim. That's in translucent red here for visibility; the extensions would be set to totally transparent for real use. Each extension overlaps 4m into the other sim. Sim crossings appear stable. There's still about a half-second stall at each sim crossing, as the sim transfer takes place. If you're reading this before 3PM Linden time Friday, the track should still be there, so please try it. I'm using a modified Firestorm viewer on top of this, one that doesn't extrapolate motion across sim boundaries. Without that, the rotation from turning the bike incorrectly continues during the sim crossing stall, which confuses the rider. With the viewer mods, motion just stops dead for a moment. With both of these fixes combined, sim crossings are routine and boring. I've been going round and round for about twenty minutes with different bikes with no drama.
  12. This is the same person who posted "Looking for bad bitches to be friends with". Troll.
  13. Night in Second Life. A darker night than usual. Riding a bike with a working headlight. Kama City Cafe parking lot, Kama City Convenience store, Dark Alley The environment is Nacon's Natural Sunrise A, just before first light, with advanced lighting enabled.
  14. You are right. While a prim doesn't exist outside its own sim, it does exist beyond the region boundary for its owning sim. Overlap provides support during the sim handoff. I just set up this test in Bricker (premium sandbox, 4 sims in a square.) The road is 1m thick, about 1m above the ground,and there are two pieces, each of which projects 2m into the neighboring sim. The yellow object is a phantom to show the sim boundary. I've been running the most overpowered motorcycles I have across that boundary with no problems. There's no sag. I set up another bridge, identical except without the two meter overlap. The bike tilts downward slightly when crossing. This really works. The main problem with overlapping is that looks bad when textured. You have two textures at the same depth, and they interfere. That can be fixed; you'd need a road texture with an alpha channel that made the overlap part transparent. We need to convince Linden Labs to fix their roads. A good place to start would be Kama City. All the roads and intersections there are built from the same parts, the roads are straight, they're on sim boundaries, and they behave very badly. Kama City intersections are too thin and often have open space under them. If a few parts were redesigned and replaced in bulk, the road system would be drivable.
  15. You'd think SL would work that way. But it doesn't. Extending a prim into another sim doesn't make it exist in the next sim. This is easy to test. Here we are in Pristina sandbox. Pristina sandbox is good for region crossing tests, because it has four sims in a square and nothing near the sim intersection. Here I've created one big prim, 16m in X and Y, and 2m thick, at Pristina (1,1,30). The prim belongs to Pristina sim, and extends into three adjacent sims. Or it looks like it does. I can stand atop that big prim in Pristina sandbox. When I walk across a sim boundary, leaving the prim's home sim, I will fall through the prim to the ground. Every time. It's just not there in the other sims. This is an easy test to run. If you're not convinced, go to a sandbox with a region crossing and try it. Prims appear to cross sim boundaries in the viewer, but that's the viewer creating an illusion for the user. The viewer is talking to several sim servers at once. The sim servers themselves have zero overlap. Each sim is a standalone world with a cliff at the edge. Sim crossings work by letting you fall off the edge. asking the next sim to take over, and hoping the next sim catches you. Most of the time, it works. This is the fundamental reason sim crossings work so badly. SL is 1990s technology, remember, when physics engines barely worked at all. A true distributed physics engine was beyond the state of the art back then, so SL had to use this simple hack. Anyone know how OpenSim, High Fidelity, or Sansar, all of which are newer, handle boundaries? I've tried that. With "Developer->Network->Velocity Interpolate Objects" (an obscure viewer option, and really extrapolation) off, movement is in jerks, because the sim doesn't send the viewer an update until the velocity changes. Seconds can go by between updates, even for an object in motion. So you can't use SL in that mode, except for development and testing. The crazy movement sometimes seen at sim crossings, followed by a recovery, doesn't appear with "velocity interpolation" turned off. That crazy movement is the little dip as an object falls off the edge of the sim being extrapolated over time into a huge movement. (Crazy movement which doesn't recover in a second or two is a different problem, and sim-side.) So I fixed a copy of Firestorm to not extrapolate beyond the edge of a region. With that, everything crossing a region boundary freezes for a moment, then moves when the new sim reports in. This isn't a complete fix; it just keeps the viewer from amplifying errors on the sim side. The fix needs to be a bit smarter. The ordinary case of walking across a sim boundary has a visible pause with this fix.The velocity extrapolate normally hides that. Allowing a little extrapolation, maybe 2m, enough for a sim transfer at walking speed, would help. More than that, and the viewer is guessing too far ahead and will guess wrong. The tough sim crossing problem is what happens when a vehicle and its avatars(s) end up in different sims. When this happens, things get very bad. That's when you have avatars floating in space, still somehow tied to the vehicle but far from it. That's when you can't Stand. That's when some of the arrow keys stop talking to the vehicle script. That's when you get errors about not having animation permissions. That has to be fixed sim-side. What I'm trying to do here is to clear away all the lesser problems so that problem can be seen cleanly, and possibly fixed. Again, anybody know how the competing systems (HF, OpenSim, etc.) do this?
  16. animats

    Natural AO

    What drives me nuts are the stand animations that are so active you think there's someone driving the avatar while the user is out to lunch. You talk to them, there's no answer, you wait, and finally leave, frustrated. My own avatar is set to time out after 30 seconds of inactivity. The head tilts to one side, as if sleepy, and "Away" appears. That's a standard Firestorm feature, but you have to turn it on. One woman had something I liked. When she uses IM, her avatar brings out a cell phone. I've only seen that once. Great idea.
  17. I've been running for a while now with a Firestorm with this fix. It's a definite improvement. There are still artifacts at sim crossings, but they're not as bad. Driving a motorcycle works much better. Insane behavior at region crossings is way down. It's not a total fix, but it keeps sim-side movement glitches from being amplified into huge movements by the viewer. I'll probably submit a patch to Firestorm in a few days, after more testing. With this fix, other problems appear more clearly, because the viewer isn't confusing the issue. A few other region-crossing issues: It's well known that avatars and vehicles can fall through a surface at a sim boundary. This occurs when the floor or road is too thin (2m seems to be safe, 1m usually works, 0.5m usually doesn't) and there's open space below it. Worst case is open space below a road, but not enough open space for an avatar. This can result in a jammed avatar or vehicle, as the innocent physics engine tries to resolve constraints that are unresolvable. Some Linden road intersections in Kama City have this property. You can check by using the "De-render" option in the viewer on part of the intersection, to get a side view of the prims of the road. (This only affects your viewer, not the sim.) Vallone (253,5) has this problem. The general problem with sim crossings is sim side. Each sim knows nothing about the prims of the neighboring sim. Thus, when you move off a sim, you fall off a cliff for a fraction of a second. You see this whenever you walk across a sim crossing. Then the next sim picks you up, usually detects that you're partly inside one of its ground/floor/road objects, and tries to resolve the constraint conflict by pushing you towards the nearest edge of the prim, hopefully the top surface. This usually works. It fails when the avatar center is below the midpoint of the road/floor prim in the sim being entered. (This doesn't happen with ground, because ground is a height field, which has no bottom side and is thus infinitely deep.) This can happen either because the new prim is too thin, or because the avatar or vehicle is going so fast that it falls more than half the prim thickness in one time step. That's when really bad stuff starts to happen. The constraint solver in the Havok physics engine is trying to solve a problem for which there is no good solution. The cause of the problem is that the handoff process between sims passes off the object with its X and Y position in the new sim, and it's Z position as if it fell off the old sim. That Z position is a guess by the old sim, which doesn't know the prims of the new sim. It's a bad guess. A better guess would be to use the Z position from the last good position in the old sim, with the X and Y positions used now. Or at least a Z position no lower than the previous one.This would prevent the drop at sim crossings. It's a guess that you're crossing sims on the flat. What would it break? Not much. Only at steep hills at sim boundaries would it be noticed. Those are both rare and handled badly now. If the edge of the sim boundary really is a cliff, you'll still fall off, but it will take slightly longer for the fall to start. Assuming flatness at sim boundaries would be a win. This probably isn't a difficult fix. (I used to code physics engines. So I know something about how you get this problem and how to get out of it.)
  18. Get a UL-approved power supply. UL tests power supplies by loading them up to their rated load for hours. The power supply must not overheat, fail, or catch fire to pass. Despite this rather low standard, many non-approved power supplies from China won't pass it. Since SL use means running the CPU and graphics card hard for hours at a time, you need a reliable power supply.
  19. (If you're not familiar with the Uncanny Valley, please read the Wikipedia article.) Human acceptability of images of humans has a valley between "cartoon" and "indistinguishable from reality". As images get close to photorealistic, any tiny flaw breaks the illusion. This subtly upsets some people. SL remains on the artistic side of the uncanny valley - avatars look good, but not convincingly human. Here's one of the Sansar avatars with the new clothing. Are we in the uncanny valley yet? This is a real problem. Pixar deliberately dials back the realism of their humanoid characters to avoid this problem. The best movie animation techniques can reach the far side of the uncanny valley with convincing human characters. Just barely. Unreal Engine is getting close in real time, at least in rendering. When you get close to photorealistic, the motion has to be right, too, or the result looks awful. So do the facial expressions and eye movements. Is Sansar there?
  20. I built my own copy of the Firestorm viewer from source, and I've been modifying what it does at region crossings. As mentioned above, the existing behavior when the viewer isn't hearing from the server is to extrapolate position based on the previous velocity and acceleration. This is not a good guess at a region boundary. So the first thing I tried is clipping that extrapolation hard at region boundaries. With this, when an object reaches a region boundary, it stops dead until the simulator for the next region picks it up and takes control. This eliminates much sinking into the ground or zooming off into space, then snapping back. It's a big improvement for fast motion. But walking normally across a sim boundary results in a momentary freeze which wasn't there before. So the clipping needs to be smarter. Maybe allow 2-3m of extrapolated motion beyond the sim boundary in X and Y, and 0.25m in Z. If the new sim picks up in under a second on a slow sim crossing, that should look as before. Faster crossings will visibly stall until the new sim picks up, but that's much better than the viewer making awful guesses. When I have a good fix, I'll submit a pull request for Firestorm, so it can become a standard feature.
  21. I can see your profile - 9 years, and payment info on file. Nothing that indicates land ownership, although it's your choice to reveal that or not. See the note above from the "Adviser": "EDIT: Well I just went and looked up your account and it is completely empty. It looks like a "greifer" (sic) account (not saying that it is) and no payment info on file. So I can see why you might be having an issue with support." Now look up my profile. Groups, a few picks, and a picture under "First Life". And yes, that is me on the big white horse.
  22. Old accounts prior to 2016 can log into Aditi, according to "http://wiki.secondlife.com/wiki/Preview_Grid#How_do_I_log_in_to_Aditi.3F": where a note says "WARNING: June 2016, 2017 - If you are a new user and have never logged into ADITI, you will need to contact Support to gain access. This is supposed to be a temporary bug in Aditi login." Even Support admits that's still broken. I have a paid premium account and own land. Apparently, this person wasn't able to look that up properly. This person is an "Adviser?"
  23. The login for Aditi is so broken. You try to log in. It doesn't work. Then it turns out there are support pages which say it doesn't work automatically any more, and you have to ask support. Asking support gets a reply in a few days. Then the password email doesn't show up. Then support wants you to change your SL password and send them another message. LL really doesn't want people using Aditi.
  24. "Note that both the male and female avatars have baked-on underwear. No nudity allowed in Sansar!
×
×
  • Create New...