Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005256opensim[REGION] OpenSim Corepublic2010-12-06 17:592011-11-25 18:02
Assigned Tojustincc 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0005256: Inconsistent, jerky, avatar movement, even on a local standalone
DescriptionIt could easily have been overlooked as lag, as it looks like sim lag at first glance. However if you walk or fly for a few seconds in a straight line in any direction, even in a local standalone, inconsistent and jerky motion can be seen, rather than a smooth transform from point a to point b.

Some discussion in #opensim-dev revealed this could be due to avatar update priority, infrequent avatar update packets, or something else.

Would love to see this fixed, it'll drastically improve the "feel" of OpenSim on a fundamental level :)

Additional note: May be in physics? Melanie suggested ODECharacter.
Updated note: Possibly ruled out physics. Get same behavior in basicphysics mode.
Additional InformationThis occurs on all versions of OpenSim.
TagsNo tags attached.
Git Revision or version number72748746d53df1c033207452a4315d93bc780158
Run ModeStandalone (1 Region)
Physics EngineODE
Environment.NET / Windows32
Mono VersionNone
Attached Files

- Relationships

-  Notes
justincc (administrator)
2010-12-07 16:59

How jerky are we talking? Really bad rubberbanding or just a lack of smoothness?
razwelles (reporter)
2010-12-07 17:03
edited on: 2010-12-07 17:05

It's more like a lack of smoothness- or rather, inconsistent movement. I'm guessing it's been overlooked for this long because it was assumed to be a slightly lagged server.

You can see it best by flying in any direction, and watching your surroundings. You'll notice every second or less there's a slight holdup in your movement.

justincc (administrator)
2010-12-07 17:04

Yeah, that's been around for a long time, quite possibly forever. As you've outlined above, my guess is that there could be a number of factors, both scene loop delays and physics issues.

btw, I'm probably going to try upgrading our ODE soon, so you might want to wait and see if that improves the situation.
razwelles (reporter)
2010-12-07 17:06

Will do, I'll sit tight and hope for the best :) Estimate? I know it's holidays.
justincc (administrator)
2010-12-07 17:06

maybe tomorrow!
razwelles (reporter)
2010-12-08 12:41

We (Melanie, antont, and I) did some rough testing this morning. I think we've pretty much ruled out physics. Switched the standalone to basic physics from ODE and got the same behavior.
WhiteStar (reporter)
2010-12-08 13:34

Check your Viewer's Network Speed. If it's too high, it will result in such behaviour's. Step it down to 500kbps, then test, step up in increments of 250kbps till you find the Break Point.

This is especially worse on grids such as OSGrid where we generally recommend that people keep it at 500kbps.

On local systems it can also be a problem but much less so.

It's worth testing and discovering how it affects you and let us know.
razwelles (reporter)
2010-12-08 15:02

I checked it at 500kpbs, 750kpbs, and 1000kpbs. There was no change in the behavior.
Diva (administrator)
2010-12-09 17:18
edited on: 2010-12-09 17:44

Try this in OpenSim.ini under
ReprioritizationEnabled = false

See if it makes any difference.

Also, do you see the effect on a standalone with no neighbors at all?

Diva (administrator)
2010-12-11 15:45

It has been said that the Aurora sim doesn't have this behavior. I just booted up an Aurora sim, loaded it with exactly the same OAR that I use to test the normal OpenSim, and I see exactly the same issues that I see in OpenSim: a certain stuckiness every half-a-second. If anything, the Aurora sim feels a lot laggier than the normal OpenSim, it feels like the avie flies slower and struggles with movement.

So I'm not sure we are all talking about the same jerkiness.

It is true that Aurora seems to be capturing the nudge events, which OpenSim doesn't -- these are the immediate responses to the arrow keys, even if pressed for only a split second. But the snap is still there for me, for exactly the same test conditions.
alecia ashbourne (reporter)
2010-12-22 14:16
edited on: 2010-12-22 14:25

(Jerky) Here are some points that may be a useful reference … this is something I have been struggling to resolve also but as yet to no avail. Its quite extreme and I'm surprised I haven't heard more of this issue, a better description may be a smoothed jerkyness O.o where the clients tracking of the avatar is very smooth and consistent yet the environment seems to be updating at an irregular rate with reference to the avatar – rather like inconsistent cam lag it's more noticeable if you move in a straight line 'close to prims' then the effect becomes quite evident.

Up until v0.6.9.1d4d6c8 this was not an issue, however all versions 'post fixes' onwards 3 things changed that for me were major – firstly the linear 'x' axis behaviour changed and vehicles I had previously scripted in v0.6.9.1d4d6c8 no longer referenced / recognised the local 'x' axis and only recognised global 'x' axis, secondly 'same vehicles' bounced horrendously upon contact with terrain (note: not on prim surfaces only terrain) and thirdly a “smoothed jerkyness” which I initially put down to perhaps a grid problem as I was running a 9 sim megaregion on osgrid. After quite a bit of head scratching trials and errors I reverted to v0.6.9.1d4d6c8 until I could no longer use this on osgrid, I recently took the logical plunge into the new Diva distro and I have to say I'm hugely impressed with this release – an immense step forward for opensim and idiot users like myself, so much so I decided to get stuck in to these issues as all 3 are also present in this release and the 'smoothed jerkyness' now being far more extreme.. I have hacked the first 2 issues rather than fixed them with some quite mad scripting namely for the lack of local rotation reference I now use a formula to constantly update the rotational behaviour of the vehicle with reference to the region not exactly elegant .. but it emulates angular and linear motors to a usable degree but is a bad substitute for real motor function. The bouncing on terrain .. again is a hack rather than a solution I simply apply -z force enough to stabilize the vehicle .. and again is just masking the issue – I have tried everything I can think of in the ini but nothing seems to fix it.... ok .. the last issue and the subject of this post the jerkyness.. I have no solution for, I've fiddled with this and that in the ini and nothing .. no change.. I cant script around this as the affect is not related to vehicles but to all motion .. I have tested also with vehicles and the jerkyness is evident in exactly the same way (cam or no cam) ..I've tried installing cam fixes with cam scripts and this makes no difference. And also tried Diva's suggestion (ReprioritizationEnabled = false ) ... Nada.

I don't believe this is either a network or client issue .. I'm off grid also so its not a grid issue also accessing via network or locally its the same. I have a very fast machine and graphic card I have 5 meg upload available and consistently above 20 meg download also so I'm confident non of these are issues, I've also tried this with as many clients as I can lay my hands on and with both windiows and linux also the same.

So to re cap .. I believe this is a server (software) issue and I'm not sure even its a physics issue ( although I eagerly await justincc's ODE update ) .. as physics seems to behave very well in all respects .. with the exception of the problems I have noted - and without wishing to sound vague .. It seems to be a problem with the way the information is being streamed to the client from the server, I know there are so many ways to interpret that … but I'm not a coder or a compiler and so that would be my guesstimate.

Sorry I cant add anything constructive .. Its just been bugging me and I noticed this post.. so I hope my comments at least offer some reference.

Teravus (administrator)
2010-12-22 14:21
edited on: 2010-12-22 14:23

How's your time dilation? (That's a joke, although, not really.)

It's a joke because I don't expect you to see anything less then 1.0 even if it's 0.98

alecia ashbourne (reporter)
2010-12-22 14:27

razwelles (reporter)
2010-12-22 15:31

Posting this as a "current state of the issue" as best as I can recall.

The jerkiness I encountered was when running in a straight line- Aurora is smooth, but OpenSim is not. However when flying, both server softwares exhibit jerkiness, though I believe for unrelated reasons as Aurora's flying glitches seem to behave differently from OpenSim's.

iirc, Diva and the others concluded it was a fault of the client (please correct this note if I recalled incorrectly)..

Also some claim that they don't see any jerkiness when connected to a separate box and believe it's a function of being connected to a local standalone. I haven't been able to test that case to confirm, and other grids I connect to, my ping rate is high enough that I can't distinguish network lag from software jerkiness.
Digi Fly (reporter)
2010-12-22 16:41
edited on: 2010-12-22 16:42

What razwelles descripe i see under linux since version 0.7 is deployed.
Its worser when there are more objects in the region.

The terrain dont move smooth under the avatar if you fly,
walking you see it to but a bit less Im not the only one with this problem.

right now i use the osgrid version 25ecd62b1feed16d12d6f5e5ef00bddf7dbf0547
builded on linux 64bit with mono 2.8.1

Digi Fly (reporter)
2011-09-26 13:46
edited on: 2011-09-26 13:49

This problem still exists, its under linux worser then under windows, under windows it can be complete smooth to.

It looks that its getting worser with more cores in the cpu.
i did run 16 regions on sempron with windows server 2008 and that where
suprissed good. on multi core systems its getting a bigger problem for me
to keep avatar flying above ground smooth. this days where upto mono 2.10.5
It gets also worser in more filled area's

It also seems that regions can get hicks when you have (dead) neighborns.

alecia ashbourne (reporter)
2011-09-26 15:41

I agree Digi.. it's worse under Linux .. at least 32 bit I haven’t tried 64 - interesting you say about it being worse also with more cores.. this was my finding but I didn’t mention it in my previous comment, but under windows I set affinity to 1 core only and this makes it much better! also much better for physics vehicles, I've tested this on a few pc's now all good performers and all render the same results - single core is definitely a big improvement but it doesn’t eradicate it .. it's unfortunate that the script engine is (I believe) coded for multiple threads - so using single core affinity makes a nonsense of that, however .. having said all that .. I'm not sure the 2 things are related .. but I don't know that - its just a gut feeling, that isn’t to say that either way it doesn’t warrant some investigation, as either one or both .. weather Opensim /Opensim Osgrid /Opensim Diva /Windows /Linux and a host of clients either open jpeg or kdu - this problem is inherent and persists right up to the latest releases.
justincc (administrator)
2011-10-13 16:49

People might want to try the changes outlined in [1], which greatly reduces jerkiness for me (assuming that the sim isn't spamming you with many packets)

[1] [^]

Interested in any feedback. This change is experimental and not a complete final solution.
Digi Fly (reporter)
2011-10-14 07:17
edited on: 2011-10-14 07:31

I have implemented your settings on 2 regions.
1 seems to work pretty smooth now, but the other have rubber banding every 2 seconds. Need to experiment and check more.

Note 1 : i just see that my neighborn is down/crashed. and that create rubber banding to.

Note 2 : The rubber banding comes from the down neighborns. some problem i see more the last weeks.

justincc (administrator)
2011-10-14 11:48

I wouldn't worry about trying this approach too much. This is because it would be much better to fix the problem where extrapolated movement consistently fails to match ode movement. This would allow us to send one or very few packets for avatar movement (with the same smooth result) rather than send a constant stream of packets, which isn't good for the connection.
Digi Fly (reporter)
2011-10-14 12:20

Ok, justin. but this setting makes it under linux with mono 2.10.5
ver smooth movement. so cant wait for the day we can do it with less packets :)
Digi Fly (reporter)
2011-10-14 12:31

Must say that the higer packetrate have a s good side effect that prim loading
from sim and neighborns have a much lower impacht on flying to. it keeps more smooth.
justincc (administrator)
2011-10-14 14:38

Ok, you can ignore the changes I suggested above. Instead, try git master 03102864. This fixes ODE to have the same step size as the main frame, eliminating the viewer extrapolation/ode position discrepencies, hence removing the need to keep sending location update packets.

As before, my subject experience is that this is much smoother once the avatar gets up to speed and the viewer isn't having to process anything else. Acceleration is still a bit juddery.
Digi Fly (reporter)
2011-10-14 15:50
edited on: 2011-10-14 15:58

Installed git 3102864, disabled your lines in opensim.ini.
But more p[ackets give a much better and smoother result then now with normal flying. The terrain etc. still choppy when you fly. not saw that with more packets. It looks like sim (neighborn) loading have a bigger impact on smooth flying when it send less packets.

Walking is nice and smooth. Running seems not to bad to.
Anyway it seems te be smoother in some cases.
I go try it later with the higher packet rate as test.

note 1:

Seems smooth when you fly straight. as soon you make a turn it get yerky.
its seems to be between more smooth and no difference with default packetrate.

Digi Fly (reporter)
2011-10-19 12:40

The advise and change from justin (2011-10-14 14:38)
is very good. things run much nicer now. changeing parameters with new ode change have not much impact.

- Issue History
Date Modified Username Field Change
2010-12-06 17:59 razwelles New Issue
2010-12-06 17:59 razwelles Git Revision => 72748746d53df1c033207452a4315d93bc780158
2010-12-06 17:59 razwelles SVN Revision => 0
2010-12-06 17:59 razwelles Run Mode => Standalone (1 Region)
2010-12-06 17:59 razwelles Physics Engine => ODE
2010-12-06 17:59 razwelles Environment => .NET / Windows32
2010-12-06 17:59 razwelles Mono Version => None
2010-12-06 17:59 razwelles Viewer => Imprudence
2010-12-07 16:51 razwelles Description Updated
2010-12-07 16:59 justincc Note Added: 0017449
2010-12-07 17:03 razwelles Note Added: 0017450
2010-12-07 17:03 razwelles Note Edited: 0017450
2010-12-07 17:04 justincc Note Added: 0017451
2010-12-07 17:05 razwelles Note Edited: 0017450
2010-12-07 17:06 razwelles Note Added: 0017452
2010-12-07 17:06 justincc Note Added: 0017453
2010-12-08 12:41 razwelles Note Added: 0017461
2010-12-08 12:42 razwelles Description Updated
2010-12-08 13:34 WhiteStar Note Added: 0017462
2010-12-08 15:02 razwelles Note Added: 0017463
2010-12-09 17:18 Diva Note Added: 0017491
2010-12-09 17:44 Diva Note Edited: 0017491
2010-12-11 15:45 Diva Note Added: 0017532
2010-12-22 14:16 alecia ashbourne Note Added: 0017667
2010-12-22 14:21 Teravus Note Added: 0017668
2010-12-22 14:23 Teravus Note Edited: 0017668
2010-12-22 14:25 alecia ashbourne Note Edited: 0017667
2010-12-22 14:27 alecia ashbourne Note Added: 0017669
2010-12-22 15:31 razwelles Note Added: 0017670
2010-12-22 16:41 Digi Fly Note Added: 0017671
2010-12-22 16:42 Digi Fly Note Edited: 0017671
2011-09-26 13:46 Digi Fly Note Added: 0020043
2011-09-26 13:49 Digi Fly Note Edited: 0020043
2011-09-26 15:41 alecia ashbourne Note Added: 0020045
2011-10-13 16:49 justincc Note Added: 0020151
2011-10-13 16:49 justincc Status new => feedback
2011-10-14 07:17 Digi Fly Note Added: 0020155
2011-10-14 07:21 Digi Fly Note Edited: 0020155
2011-10-14 07:31 Digi Fly Note Edited: 0020155
2011-10-14 11:48 justincc Note Added: 0020156
2011-10-14 12:20 Digi Fly Note Added: 0020157
2011-10-14 12:31 Digi Fly Note Added: 0020158
2011-10-14 14:38 justincc Note Added: 0020159
2011-10-14 15:50 Digi Fly Note Added: 0020160
2011-10-14 15:58 Digi Fly Note Edited: 0020160
2011-10-19 12:40 Digi Fly Note Added: 0020175
2011-11-25 18:02 justincc Status feedback => closed
2011-11-25 18:02 justincc Assigned To => justincc
2011-11-25 18:02 justincc Resolution open => fixed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker