Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007813opensim[REGION] OpenSim Corepublic2016-01-15 02:542016-11-02 03:12
Reporteraiaustin 
Assigned ToRobert Adams 
PrioritynormalSeveritymajorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformPCOSWindowsOS Version10
Product Versionmaster (dev code) 
Target Versionmaster (dev code)Fixed in Version0.9.0 
Summary0007813: Bulletsim regions... avatar movement continues to drift slowly forward or backward on level ground
DescriptionI have noticed that in the last few weeks the avatar after arrival on a region creeps forwards or upwards very slowly... and that continues until the avatar is moved explicitly.

It is happening on very latest dev master as of today... opensim-0.9.0-240-g22501ea.zip ... I am using the default BulletSim on all regions. This happening before... I first noticed it maybe before the new year (??)
Additional InformationA visitor to the Openvue Grid (Windows 10, BulletSim, opensim-0.9.0-235-gee15c51) noticed this too and says it happens on forward and backward motion, with slow drift continuing. But that left or right avatar movement stops the drift.
TagsNo tags attached.
Git Revision or version numberopensim-0.9.0-235-gee15c51
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Environment.NET / Windows64
Mono VersionNone
ViewerFirestorm 4.7.5
Attached Filespatch file icon 0002-Avatar-should-no-longer-drift-in-fly-mode.patch [^] (3,055 bytes) 2016-01-16 14:24 [Show Content]
jpg file icon Feet-Position-when Gliding.jpg [^] (134,294 bytes) 2016-01-18 08:17


jpg file icon Glide-Goes-Thru-Solid-Surfaces.jpg [^] (60,644 bytes) 2016-01-18 08:25


jpg file icon Avatar-Does-Not-Glide-Even-On-Steep-Normal-Terrain-Slope.jpg [^] (62,211 bytes) 2016-01-18 13:52

- Relationships

-  Notes
(0029968)
Robert Adams (administrator)
2016-01-15 07:42

When you move the avatar, does it snap back to its original position? That is, is the avatar really moving to the new location or does it just look like they are drifting until you touch them?

BulletSim has a bunch of logic to keep an avatar in one place and not drift down hills, etc. That logic was recently loosened so llPushObject could move an avatar slowly. The INI parameter [BulletSim]AvatarStopZeroThreshold=0.1 is the velocity that, below which, it is presumed the avatar should be stationary. Maybe this is a little low.
(0029969)
aiaustin (developer)
2016-01-15 07:56
edited on: 2016-01-15 12:06

No Robert, even after taking hand off the movement keys, the avatar continues to drift very slowly in the direction it was moving in.. it does not stop or snap back. On level ground that is. On several tests just now it happens EVERY time by the way.

Billy Bradshaw visiting our regions reports that if you hit left or right movement keys then the drift stops. I just tried that and I had to hold the left or right arrow or press it a few times to stop the forward drift. but it then is at the location it drifted to... no snap back.

(0029970)
aiaustin (developer)
2016-01-15 08:08
edited on: 2016-01-15 08:08

I just tried Openvue grid with

 [BulletSim] AvatarStopZeroThreshold = 0.2

and the avatar still continued to drift.

I then tried

 [BulletSim] AvatarStopZeroThreshold = 0.5

and it does not. So what is a better default value that still achieves what you want with Push?

(0029972)
Robert Adams (administrator)
2016-01-15 23:10

When drifting, what is the avatar standing on? A mesh? A prim? Terrain?

There should be friction between the avatar and whatever they are standing on that should slow down the avatar's movement.

I will play with the AvatarStopZeroThreshold default value and see if your number works.
(0029974)
aiaustin (developer)
2016-01-16 01:14
edited on: 2016-01-16 08:01

On the location I reported this on, they were on a level prim surface... a courtyard made up (old style) of 10m x 10m x 1m cubes linked together to be a 50m square area. Defaults on the properties of the cubes except the texture, so friction was 0.6.

hop://virtual.aiai.ed.ac.uk:8002/Openvue/128/128/22 [^]

I will test later on level terrain and level mesh surface.

(0029975)
tglion (reporter)
2016-01-16 01:28

I am not sure, this is the same issue I have noticed on fly-mode.
I have added a patch, which stops the drift issue in my case.
(0029979)
aiaustin (developer)
2016-01-16 07:51
edited on: 2016-01-16 08:04

I checked a region with the default [BulletSim] AvatarStopZeroThreshold (i.e. the value is not explicitly altered to a custom value in OpenSim.ini) and the avatar continues in the direction of last motion drifting slowly on a level prim surface.

But it does not drift on level normal terrain. However, it does slide down the terrain rather easily if it has a very slight slope. E.g. the slope on the default pin head island, the avatar if not centrally placed will slide down the pin head sides and off into the water. It did not do this before. The slide starts downhill even when the avatar is walking UPHILL before you stop.. so it looks like its purely a lack of friction. It seem like the avatar is on ice. It builds up enough speed on the slide off the pin head island that at a certain point the avatar changes direction to face into the direction of slide... I assume that's triggered by the avatar speed.

By the way its in normal standing pose mode and walking, NOT when in fly mode. I just wanted to check you understood that.

(0029980)
aiaustin (developer)
2016-01-16 08:07
edited on: 2016-01-16 08:09

tglion, the patch is odd with a check on !IsSatOnObject inside a block where the code already verifies that constraint. The "!IsSatOnObject &&" inside there is not needed.

(0029982)
tglion (reporter)
2016-01-16 14:26

Oh, sorry, my fault (past and copy-error).
Uploaded a new patch, this is hopefully correct now.
(0029983)
aiaustin (developer)
2016-01-17 08:10
edited on: 2016-01-17 08:16

Robert, I went on a pinhead island region on the Openvue grid where I had changed OpenSim.ini to have

 [BulletSim] AvatarStopZeroThreshold = 0.5

and the avatar dopes not slide as easily down the slope of the island shape.. but when I get about 16m from the central 128,128 position it does still glide slowly. So 0.5 is probably not enough... if its only the AvatarStopZeroThreshold that is affecting this and that changed from previous behaviour.

I tried
 [BulletSim] AvatarStopZeroThreshold = 1.0

and then the glide does not start until just about the about the water edge of the default pin head island. i.e. about 20m from the central 128,128 position. E.g.

hop://virtual.aiai.ed.ac.uk:8002/Vue-Port/115/108/20 [^]

(0029984)
Robert Adams (administrator)
2016-01-17 12:05

First of all, thanks for doing all this testing and the recording of it here -- it's great to hear the needs and problems along with numbers and tests. This makes OS development a lot easier.

The attached patch (0002-Avatar-should-no-longer-drift-in-fly-mode.patch [^] (3,055 bytes) 2016-01-16 14:24) is a code cleanup in ScenePresence.cs and only effects how often the avatar position update is sent to the viewer. The operational change in the patch is the change in VELOCITY_TOLERANCE which will mean the terse position update will be sent more often. Not sure about that change since it doesn't effect the drifting problem itself.

The cleanup also changes the logic a little in that the original code makes sure to send the position update if position has moved just a little and velocity is very low. This logic would be fixing a problem with avatar drifting in the viewer. To smooth movement, the viewer uses the last received velocity to keep any object moving in the view. There is logic scattered around the simulator to force the sending of zero velocity when something stops so the viewer doesn't keep moving the object/avatar.

I'll incorporate the code cleanup but keep the last test.
(0029987)
Robert Adams (administrator)
2016-01-18 07:06

As to the drifting, all the OpenSimulator physics engines have logic to keep the avatar from sliding or drifting. The problem is knowing when an avatar should be stationary and when moving. BulletSim has all this logic in BSActorAvatarMove.cs which keeps the avatar stationary if not flying, walking (force being applied), or colliding with a moving object. It also includes the logic for walking up stairs (moving up when colliding with a short, vertical surface) and other things like jumping and falling (not flying but moving).

The testing has gotten complex over the years to enable things like standing on elevators and moving along with trains or rotating surfaces that are being stood on. The most recent changes were for llPushObject() which can push an avatar. The logic added was to not force the avatar stationary if the avatar had some velocity. That change created this bug because just looking at velocity is not sufficient to tell the difference between drifting and being pushed.

I'm thinking the real fix is to change the 'force stationary' logic in BulletSim. So, in the short term, I will revert the speed threshold test (and thus break the fix for llPushObject (Mantis 7779)) since drifting seems to be a worse effect.

Check to see if the changes checked in fix drift.
(0029988)
aiaustin (developer)
2016-01-18 08:16
edited on: 2016-01-18 08:26

Okay testing now with the latest commits Robert... I am using opensim-0.9.0-243-g35d4298.zip

On level terrain the avatar does NOT now glide along after arrow key motion is stopped. I also tested on the pin head island and motion along the flank stops when releasing the movement key all the way down the shape right to the sea bed. I think that's how it worked before the Push fixes... so that's good.

But on a simple level default properties prim surface (e.g. the central plaza on Openvue region on the Openvue grid) the motion is JUST still present after releasing the motion key. Slwer than before. But glide continues as far as I can tell forever... it never stopped in two minutes, all the time I am typing this comment, anyway. Its moving about 5cm a second.

Very oddly, when it got to the edge of the primn surface the glide continued even over normal terrain, and the avatar did not shift down the 15cm or so it should have had it detected it was off the prim... where there was a step down.

I checked and avatar feet are connecting to the floor, shoe attachments are a few cm under it in fact. See Feet-Position-when Gliding.jpg

Interesting... this time when I hit the move keys, I DID get the avatar snapping back to the place it was when the gliding started! But then it glides forward again.

(0029989)
aiaustin (developer)
2016-01-18 08:25

Whooo, the slow glide continues right through solid prims... See Glide-Goes-Thru-Solid-Surfaces.jpg
(0029990)
Robert Adams (administrator)
2016-01-18 10:52

I think I got it this time. The logic for being stationary has been cleaned up and the movement tests simplified.

See if BulletSim is not drifting avatars.
(0029992)
aiaustin (developer)
2016-01-18 11:04
edited on: 2016-01-18 11:04

Before testing, note that the test region I am using has About land -> Options -> No Pushing ticked, and has had all along.

Also, I noted then when I turned off (or turn on) the avatar AO it stops moving, but glides whether or not I have the fairly standard OpenSim [RUGGED AO] on.

(0029993)
aiaustin (developer)
2016-01-18 11:17

Testing now with opensim-0.9.0-245-gddd59fa.zip

Sorry to say the drift still occurs on level prim surfaces on Openvue region on Openvue grid... same speed as last test as far as I can see. As before the drift continues straight on "forever" and the avatar goes through solid walls and prims.
(0029994)
zadark (reporter)
2016-01-18 12:02

When testing, what value is preferred for AvatarStopZeroThreshold ? In keeping with other comments this is the only parameter we have changed.
(0029995)
Robert Adams (administrator)
2016-01-18 12:10

AvatarStopZeroThreshold is no longer used as the logic has changed.
(0029996)
zadark (reporter)
2016-01-18 13:00

Test Version: OpenSim 0.9.0.0 Dev ddd59fa

AvatarStopZeroThreshold appears to still influence behaviour.

AvatarStopZeroThreshold = 0.5 Both on-prim and undulating terrain appear stable. With the line removed from [Bulletsim] in opensim.ini the drift returns.
(0029997)
aiaustin (developer)
2016-01-18 13:12
edited on: 2016-01-18 13:24

On the grid and regions I tested on where I still had gliding on level prims I had removed the earlier added line for AvatarStopZeroThreshold to increase it significantly beyond the default you stated was 0.1.

(0029998)
aiaustin (developer)
2016-01-18 13:24

To test what @zadark reported I modified the OpenSim.ini on my Openvue which is now running OpenSim 0.9.0.0 Dev ddd59fa to add back...

[BulletSim]
    AvatarStopZeroThreshold = 1.0

and I can confirm that adding in this line DOES stop drift every time, so the parameter is being used somewhere.

Without that line it drifts consistently every time on a level prim.
(0029999)
aiaustin (developer)
2016-01-18 13:47
edited on: 2016-01-18 13:53

I have tested OpenSim 0.9.0.0 Dev ddd59fa on VERY steep terrain... up to perhaps 85 degrees and the avatar does not move or glide on regions without the AvatarStopZeroThreshold parameter in OpenSim.ini

See this image where avatar is not gliding even after touching a move key for down slope...
Avatar-Does-Not-Glide-Even-On-Steep-Normal-Terrain-Slope.jpg

So I think Robert has fixed the problem on normal terrain completely. I believe this restores the previous behaviour.

BUT on prims, even level ones, the glide occurs unless you set (say)

  AvatarStopZeroThreshold = 0.5 (or 1.0 both work for LEVEL prims)

I have not yet tested the effect on level or sloping mesh terrain.

(0030003)
tylexon (reporter)
2016-01-18 19:00

Just want to add a "me too" to this bug.

Version: OpenSim 0.9.0.0 Dev 22501ea (SIMULATION/0.3 - SIMULATION/0.6)
OS: Ubuntu LTS 14.04.03

Using the default I tend to drift very slowly forward until I move left/right and it normally moves me back to where it started.

Setting "AvatarStopZeroThreshold = 0.5" Has fixed this issue for me.
Tested it on flat terrain and a flattened cube of 5x5.
(0030004)
JoeRadik (reporter)
2016-01-19 08:30
edited on: 2016-01-19 11:39

I'm still seeing this. I'll describe it as "avatar float." The avatar will slowly drift in the scene. I've even seen the drift on the Z-axis once. When I press a movement key the avatar moves back to the original position before executing the movement. Sometimes the drift continues after the intended movement, sometimes not.

I created a short video demonstrating my experience: https://youtu.be/iVfq-GzjxD0 [^]

(0030007)
aiaustin (developer)
2016-01-20 05:57
edited on: 2016-01-20 05:59

For me now using the latest version on Openvue and AiLand grids as at 20-Jan-2016... opensim-0.9.0-246 33af419

The recent fixes by Robert seems to have corrected the problem of glide or slide downhill on normal terrain, even up to extreme angles, restoring the previous behaviour.

On level prims, I get no glide so long as include this line in the OpenSim.ini [BulletSim] section. if its not present the avatar always glides after motion.

     AvatarStopZeroThreshold = 0.5

On mesh terrain, I do not appear to glide with the above settings.

So, unless there are knock on effects, we do need to amend the default AvatarStopZeroThreshold from 0.1.. to something like 0.5.

(0030008)
aiaustin (developer)
2016-01-20 06:01

I notice that AvatarStopZeroThreshold is NOT included in OpenSimDefaults.ini or in OpenSim.ini.example.

It should be in openSimDefaults.ini at least if its a parameter set in the code.
(0030009)
aiaustin (developer)
2016-01-20 06:04

@JoeRadik ... In the video, is that mesh terrain or normal terrain... and which version of OpenSim is in use. Also do you have AvatarStopZeroThreshold set to a specific value in your OpenSim.ini?
(0030010)
Robert Adams (administrator)
2016-01-20 06:34

The drift I'm seeing is 'viewer drift'. That is, the avatar drifts very slowly (through objects) but will snap back to its real position when any movement is done. And it does seem that setting AvatarStopZeroThreshold to 0.5 does stop the drifting. But that doesn't make sense as viewer drift is caused by not sending a final zero velocity to the viewer and AvatarStopZeroThreshold shouldn't have any effect on that happening.

I'll checkin a setting of 0.5 for the moment but I need to do more investigation.

Also, AvatarZeroThreshold is not the sort of parameter anyone should need to tune. Putting it in OpenSimDefaults.ini is not a good thing. You can look at BSParams.cs to see the zillions of other parameters available for tweeking.
(0030011)
aiaustin (developer)
2016-01-20 07:06

Got it.. I will remove the current setting when you check in the change and its available on OSGrid too. they just updated to penultimate GIT Master (256)
(0030012)
JoeRadik (reporter)
2016-01-20 07:16

Version: OpenSim 0.9.0.0 Dev ddd59fa: 2016-01-18 10:50:28 -0800 (SIMULATION/0.3 - SIMULATION/0.6)

normal terrain

I can't find where AvatarStopZeroThreshold is set in any .ini file.

I would have to describe what I'm seeing as viewer drift also.
(0030068)
Robert Adams (administrator)
2016-03-06 15:06

@JoeRadik: the parameter is not specified in OpenSimDefaults.ini but is settable in any of the INI files. There are zillions of OpenSim parameters that are not exposed.

I checked into 'master' some BulletSim changes on 20160306 that should reduce the drift problem. Tell me if you're still seeing it.
(0030077)
JoeRadik (reporter)
2016-03-08 01:33

@Robert Adams: It appears fixed to me. Well done.
(0031222)
aiaustin (developer)
2016-11-02 03:12

This is resolved.

- Issue History
Date Modified Username Field Change
2016-01-15 02:54 aiaustin New Issue
2016-01-15 02:54 aiaustin Status new => assigned
2016-01-15 02:54 aiaustin Assigned To => Robert Adams
2016-01-15 07:42 Robert Adams Note Added: 0029968
2016-01-15 07:56 aiaustin Note Added: 0029969
2016-01-15 07:57 aiaustin Note Edited: 0029969 View Revisions
2016-01-15 07:58 aiaustin Note Edited: 0029969 View Revisions
2016-01-15 07:58 aiaustin Note Edited: 0029969 View Revisions
2016-01-15 07:59 aiaustin Note Edited: 0029969 View Revisions
2016-01-15 08:00 aiaustin Note Edited: 0029969 View Revisions
2016-01-15 08:08 aiaustin Note Added: 0029970
2016-01-15 08:08 aiaustin Note Edited: 0029970 View Revisions
2016-01-15 12:06 aiaustin Note Edited: 0029969 View Revisions
2016-01-15 23:10 Robert Adams Note Added: 0029972
2016-01-16 01:14 aiaustin Note Added: 0029974
2016-01-16 01:15 aiaustin Note Edited: 0029974 View Revisions
2016-01-16 01:16 aiaustin Note Edited: 0029974 View Revisions
2016-01-16 01:26 tglion File Added: 0001-Avatar-should-no-longer-drift-in-fly-mode.patch
2016-01-16 01:28 tglion Note Added: 0029975
2016-01-16 07:51 aiaustin Note Added: 0029979
2016-01-16 07:54 aiaustin Note Edited: 0029979 View Revisions
2016-01-16 07:54 aiaustin Note Edited: 0029974 View Revisions
2016-01-16 07:56 aiaustin Note Edited: 0029979 View Revisions
2016-01-16 08:01 aiaustin Note Edited: 0029974 View Revisions
2016-01-16 08:04 aiaustin Note Edited: 0029979 View Revisions
2016-01-16 08:07 aiaustin Note Added: 0029980
2016-01-16 08:09 aiaustin Note Edited: 0029980 View Revisions
2016-01-16 14:24 tglion File Added: 0002-Avatar-should-no-longer-drift-in-fly-mode.patch
2016-01-16 14:24 tglion File Deleted: 0001-Avatar-should-no-longer-drift-in-fly-mode.patch
2016-01-16 14:26 tglion Note Added: 0029982
2016-01-17 08:10 aiaustin Note Added: 0029983
2016-01-17 08:16 aiaustin Note Edited: 0029983 View Revisions
2016-01-17 08:16 aiaustin Note Edited: 0029983 View Revisions
2016-01-17 12:05 Robert Adams Note Added: 0029984
2016-01-18 07:06 Robert Adams Note Added: 0029987
2016-01-18 08:16 aiaustin Note Added: 0029988
2016-01-18 08:17 aiaustin File Added: Feet-Position-when Gliding.jpg
2016-01-18 08:20 aiaustin Note Edited: 0029988 View Revisions
2016-01-18 08:21 aiaustin Note Edited: 0029988 View Revisions
2016-01-18 08:25 aiaustin Note Added: 0029989
2016-01-18 08:25 aiaustin File Added: Glide-Goes-Thru-Solid-Surfaces.jpg
2016-01-18 08:26 aiaustin Note Edited: 0029988 View Revisions
2016-01-18 10:52 Robert Adams Note Added: 0029990
2016-01-18 11:04 aiaustin Note Added: 0029992
2016-01-18 11:04 aiaustin Note Edited: 0029992 View Revisions
2016-01-18 11:17 aiaustin Note Added: 0029993
2016-01-18 12:02 zadark Note Added: 0029994
2016-01-18 12:10 Robert Adams Note Added: 0029995
2016-01-18 13:00 zadark Note Added: 0029996
2016-01-18 13:12 aiaustin Note Added: 0029997
2016-01-18 13:12 aiaustin Note Edited: 0029997 View Revisions
2016-01-18 13:14 aiaustin Note Edited: 0029997 View Revisions
2016-01-18 13:24 aiaustin Note Added: 0029998
2016-01-18 13:24 aiaustin Note Edited: 0029997 View Revisions
2016-01-18 13:47 aiaustin Note Added: 0029999
2016-01-18 13:48 aiaustin Note Edited: 0029999 View Revisions
2016-01-18 13:52 aiaustin File Added: Avatar-Does-Not-Glide-Even-On-Steep-Normal-Terrain-Slope.jpg
2016-01-18 13:53 aiaustin Note Edited: 0029999 View Revisions
2016-01-18 19:00 tylexon Note Added: 0030003
2016-01-19 08:30 JoeRadik Note Added: 0030004
2016-01-19 11:39 JoeRadik Note Edited: 0030004 View Revisions
2016-01-20 05:57 aiaustin Note Added: 0030007
2016-01-20 05:59 aiaustin Note Edited: 0030007 View Revisions
2016-01-20 06:01 aiaustin Note Added: 0030008
2016-01-20 06:04 aiaustin Note Added: 0030009
2016-01-20 06:34 Robert Adams Note Added: 0030010
2016-01-20 07:06 aiaustin Note Added: 0030011
2016-01-20 07:16 JoeRadik Note Added: 0030012
2016-03-06 15:06 Robert Adams Note Added: 0030068
2016-03-08 01:33 JoeRadik Note Added: 0030077
2016-11-02 03:12 aiaustin Note Added: 0031222
2016-11-02 03:12 aiaustin Status assigned => resolved
2016-11-02 03:12 aiaustin Fixed in Version => 0.9.0
2016-11-02 03:12 aiaustin Resolution open => fixed
2016-11-02 03:12 aiaustin Status resolved => closed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker