Hi - Yes, I updated that repository with my first attempt at improving the viewer prediction code. The changes are:
* Configurable settings for tapering off viewer-side motion prediction * Limit predicted motion at region edges based on adjacent regions * Bug fixes around region crossing timers and object positions I just spent some time looking into the server code, however, and see that the viewer needs more refinement. The server expects the viewer motion prediction code to follow the velocity and acceleration it sent to the viewer, so my new taper-off code should not kick in unless the simulator stops sending updates (which would indicate a bad lag event, rather than no updates due to constant motion). Some of my changes should help, however. The viewer will check the edge of the region, and if there is no neighbor region, stops the object motion. Normally the simulator will send down another update quickly as the object bounces off the edge, but this prevents the sail-into-the-sunset effect when the simulator lags badly. Predicted object motion is also pinned to the allowable underground distance and top of the region. I did some experiments with region crossings and attempts to predict some lag but didn't find a solution that worked well. As AnnMarie mentioned, vehicle crossings seem to be the worst and I'll be looking into that next. The viewer can probably be more intelligent on how it predicts region crossings, perhaps allowing for a bit of lag with normal objects and possibly accounting for the re-seating of AVs on vehicles, but I haven't worked out the details yet. - Simon Linden On Tue, Oct 12, 2010 at 2:06 PM, Kelly Linden <ke...@lindenlab.com> wrote: > If anyone is interested his code is here: > http://bitbucket.org/simon_linden/viewer-dev > > cc'ing the opensource-dev list as this seems appropriate for that list at > this point. > > - Kelly > > On Tue, Oct 12, 2010 at 8:27 AM, Kelly Linden <ke...@lindenlab.com> wrote: > >> Actually one of my coworkers has been working on some features along these >> lines. The two parts I'm aware of prevent flying into the horizon if there >> is no neighbor sim and some attenuation of movement if it has been too long >> since getting an update from the sim. He was also working on some region >> crossing specific bits to try and improve the prediction logic and reduce >> rubber banding, however he was getting mixed results on that front. >> >> I've forwarded him your email just so he has another data point, and I'll >> see if I can't find his repo to share should anyone want to give his patches >> a try. >> >> - Kelly >> >> On Tue, Oct 12, 2010 at 7:35 AM, annma...@slfbi.com >> <annma...@slfbi.com>wrote: >> >>> Border crossing rubber-banding, especially when riding a vehicle, can >>> vary from zero to annoying to purgatory to re-boot depending on the >>> severity. >>> My current SLURL is sim Sunell, <60902, 26106???, -136289?????> which >>> puts me at least 13 billion meters below ground on my way to SL hell. >>> It will require a re-log to recover. >>> >>> DUH. The client side viewer would not have to be very smart to figure >>> out something was wrong and discontinue stretching a rubber band that is >>> obviously broken. >>> >>> Why cannot the viewer and server have a simple uplink command that says >>> "I'm totally lost, please put me back at the last known vector"? It >>> could even have a popup to explain you have been restored to an earlier >>> valid location. >>> >>
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
