Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by animats

  1. “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.


    • Like 2
    • Thanks 1

  2. On 12/27/2017 at 5:28 AM, Parhelion Palou said:

    I make the prims transparent and usually embed them within the road/bridge/path that's crossing between regions. It's an extra 1 LI cost for each region, but that's no biggie.

    Tried that. Here's a worst-case test.circulartrack1_002.thumb.jpg.1877880c29230817cccfc98c41bdd3ee.jpg

    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.


    • Like 2

  3. 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.


    • Like 1

  4. 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.




    • Like 1

  5. 6 hours ago, Theresa Tennyson said:

    The standard solution for roads crossing borders is to have the road prims extend into the next region - i.e. the road prims extend out from both borders like diving boards and overlap - one of the overlaps may be invisible. It sounds like you're dealing with improperly built roads. Note that you drop moving from Kama Center into Vallone, but not from Vallone into Kama Center.

    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?


    Also, remember - the real physics model is what you see with interpretation switched off.

    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?



    • Like 2

  6. 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.


    • Like 2

  7. 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.)

    • Like 4

  8. (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?


    • Like 1

  9. 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.

    • Like 2

  10. 5 minutes ago, Rhonda Huntress said:

    Can you tell if I am a premium or basic account?  Can you see if I own land?  Why would you expect another resident to be able to do that?


    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.

  11. 19 minutes ago, Chic Aeon said:

    Well as a test I just logged a very old dusty alt who had NEVER  been to the beta grid onto the beta grid.

    Aside from the fact she was a cloud, she was there and could upload.  So something else must be going on. Perhaps your account is too new? I didn't look to see how long you have been here.

    Anyway the beta grid is not broken and folks that haven't been there before CAN login.

    Just for the record :D.  


    PS. It IS possible that you might need payment info on file.  So if you don't have that, it could be the reason. 


    EDIT: Well I just went and looked up your account and it is completely empty. It looks like a "greifer" 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.

    Good luck working that out. 

    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?"

    • Like 1

  12. 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.

  13. There's a long road, Circuit le Corse, across many sims. That road has frequent rez areas, so you can bring in vehicles easily. Here's a typical rez zone: http://maps.secondlife.com/secondlife/Timescape/160/67/66

    At least two  speed cameras are on that road. I  just got

    YD Speed Camera: 
    USA Motorcycle v0.10b, 
    Owned by  animats Resident
    55.393681 KpH
    Fine L$25

    It didn't deduct from my balance, though.

    I've written a motorcycle script that can handle region boundaries without much trouble, so I can go cruising along, passing a region boundary every five seconds.  It's a good ride.


    • Like 4

  14. 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.

  15. 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.

    • Like 2

  16. Some questions about viewer internals:

    1. 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?
    2. 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.
    3. 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.

  17. 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.)




    • Like 1
  • Create New...