animats

Vehicles vs. sim crossings, why it's so awful

Recommended Posts

 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

Edited by animats
More info.

Share this post


Link to post
Share on other sites
9 hours ago, animats said:

 I've been looking at why vehicle behavior when crossing sim boundaries is so bad.

Sim crossings generally are "bad" as SL is really really bad at handling them, this is a SERVER side problem inherent in the sim to sim transfer process...

1. The sim you are on bundles up the current state of your inventory, every parameter of every face of every 'prim' of every object you wear or have in inventory, the current state of every script, every memory variable, the whole damn thing.

2. You inventory is fired at the asset servers

3. you are fired at the target sim, naked, bald, and ruthed

4. The target sim decides if it wants to accept delivery of you

5. The target sim sucks down your total inventory state from the asset servers and tries to figure out which bits of it are supposed to be attached to you

6. The target sim starts up any scripts in the stuff thats been attached, cue massive lagspike as your script cpu time goes up about 900% for several seconds

7. Congratulations you have arrived

Now on a TP, all this take  place under cover of a blank screen with a loading bar... But at a sim crossing, this has to be done live in full view...

Add in the complication of a rezzed prim thing that you are SITTING on, and it gets tricky, add in thge complication of people who think, based off "client side content storage only" computer games, expect to be able to whizz from 'map' to map' instantly at high speed, and things get nasty.

The classic case is the "I R Leet gamerz wot play MMOs all da tyme an i no all abut grafix" types who buy a supersonic jet fighter, and then attempt to scream across sim crossings at a speed that will have them LEAVING the destination sim before it's finished RECEIVING them, and BOOM

"I R leet gamerz an i no get whi crossins r so bad in my noob editun Supa-Jet-MMO-Idiot-Fita, r dis a bug wid the browsa?"

...

PS. Second Life doesnt have 'browsers' it has 'clients', and no that's NOT the same thing at all.
 

  • Like 2
  • Haha 2

Share this post


Link to post
Share on other sites
5 hours ago, Klytyna said:

Sim crossings generally are "bad" as SL is really really bad at handling them, this is a SERVER side problem inherent in the sim to sim transfer process...

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.

 

Share this post


Link to post
Share on other sites
10 hours ago, animats said:

Now try a fast vehicle across the sim boundary

You kind of missed the point son...

You do not take 'fast vehicles' across sim boundries because, SL cant really cope with that. There are unwritten rules, you don't cross at corners, you try not to cross at shallow approach angles, you keep your inventory small, you travel slow etc. because SL isn't "World of ePeener-vs-ePeener Jet Combat Deathmatch Simulator Online".

People keep coming to SL from radically different environments, with totaly different client and server mechanics, intended for a totaly different gaming experience, then whine like spoiled brats when they discover that SL really really sucks at Racing Games, Flight Sims, ePeen vs ePeen First Person Shoot-em-ups, etc., etc., etc.

EVERYTHING you THINK you know about client/server gaming based on World of Canoes, Medal of Duty, Call of Battle, Italian Plumbers vs the Croco-Turtles of Doom Online  or whatever, all that presumed knowledge of Leet Gaming, means exactly DIDDLY-SQUAT in SL.

You still haven't grasped the essential truth... This 'Game' is NOT stored on your bloody hard drive.

Servers here don't simply send "draw game char at coordinates x.y.z on map 27, move to coords a.b.c, trasition screen load map 33, draw npcs #35, #46,#72, start ambush script 69"

EVERY SINGLE mesh, texture, sound, animation and 'map' is live streamed, constantly updated, as you encounter it, unless, you have it temp stored in the cache, and it doesn't need updatng just now.

You will NEVER get SL to perform like your favorite Type-with-your-thumbs style console-peasant friendly preloaded FPS RPG MMO.

Every visit to a particular sim is potentially different from day to day, hour to hour, minute to bloody minute.
 

  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, animats said:

 That could be fixed in viewers. Since there are non-Linden viewers, it can be fixed without help from Linden Labs.

 

go ahead and surprise us with your 3rd party viewer, the code is open source.

Share this post


Link to post
Share on other sites
10 hours ago, Alwin Alcott said:

go ahead and surprise us with your 3rd party viewer, the code is open source.

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.

  • Like 1

Share this post


Link to post
Share on other sites
7 minutes ago, animats said:

 But here's the viewer-side problem.

according to your posts you found the problem, and know how to solve it.... so do that, and write us a repaired viewer without this.

  • Like 2

Share this post


Link to post
Share on other sites
On 12/1/2017 at 11:40 AM, Alwin Alcott said:

according to your posts you found the problem, and know how to solve it.... so do that, and write us a repaired viewer without this.

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. 

  • Like 1

Share this post


Link to post
Share on other sites

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 1

Share this post


Link to post
Share on other sites

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.

Edited by animats
Mention fix.
  • Like 2

Share this post


Link to post
Share on other sites

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 3

Share this post


Link to post
Share on other sites
On 12/24/2017 at 11:38 PM, animats said:
  • 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.)

It would break airplanes coming for a landing.

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.

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

 

  • Like 1

Share this post


Link to post
Share on other sites

This work seems very interesting and I hope firestorm will adopt the improvements.

I also want to say that I would treat klytyna's post with some scepticism, I have not noticed any noticeable difference between avatars with different inventory sizes crossing sims. my experience is between my main avatar with 150,000 items in inventory and alts with less than 10,000 and I do alot of sailing and sim crossings. Maybe what she said was true at some point in the past but it is not my experience over the last few years. Numbers of worn items and scripts you are wearing, yes that seems to affect the crossings, but not inventory.

 

Edited by Aethelwine

Share this post


Link to post
Share on other sites
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?

Quote

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?

inpristina.png

fellthrough.png

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, animats said:

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

 

That's why I said you need prims on BOTH regions that BOTH extend into the other region and OVERLAP. I have property on the border between two regions and drive on mainland roads frequently. If the roads are built this way there's little problem of diving at the region border; I've built roads like this myself.

  • Like 2

Share this post


Link to post
Share on other sites

@Theresa Tennyson is correct. If you have a prim that extends beyond the edge of a region and you walk off of the region on that prim, the simulator keeps you on it until you either go off the end or the next region takes over. The other region needs one that crosses into the first so that the trick works when going from that region into the first. It's an old trick that works well.

  • Like 2

Share this post


Link to post
Share on other sites

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.

 

simcrossingbridge.jpg

simcrossinggood.jpg

  • Like 1

Share this post


Link to post
Share on other sites

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. From what I've heard (and experienced), some of the Linden roads do have the region-crossing prims, but not all. I think there was a thread long ago that listed some of the ones that needed fixed.

Off-topic: It's fun to set the water height to significantly different values in adjacent regions. I'd love to be an estate manager for the Blake Sea.

Share this post


Link to post
Share on other sites
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.

circulartrack1_001.jpg

  • Like 2

Share this post


Link to post
Share on other sites

“Modified Firestorm Viewer?”

Not enough information to be helpful.

Are there viewable objects on all four sims, or are they empty besides your track?

Are you wearing a lot of scripted objects?

Are you wearing a lot of attachments?

How is your avatar complexity?

Share this post


Link to post
Share on other sites

“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

Share this post


Link to post
Share on other sites
13 hours ago, animats said:

 

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

 

 

Thanks for your patience in answering. I see that you have moved on to look for places to test that are more representative of SL. Kudos on your viewer modifcation: if you can do testing in non-sandbox regions with plenty of objects with within view range, normal lag, etc. and your modification still shows improvement, then you should be able to interest the viewer development community in your suggested changes.

  In fact, I suggest you try to work with the Firestorm devs. Why not?

  P.S. I am a developer with 35+ years experience. I do not work on SL viewers, so sorry to say I cannot join your quest.

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now