|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 20/Jan/07 09:09 PM
I'm gonna take a wild guess here and say that you probably accidentally turned off Velocity Interpolation. Look at Client -> Network -> Velocity Interpolate Objects, which should be checked. Maybe the bug that makes the menus pop up when we type caused you to accidentally turn this off?
I'm having the same problem, and the setting you mention IS checked!
I have this issue too – my test boat (a very basic standard issue vehicle) jolts from location to location when moving forwards, but is stationary between jerks. Oddly, interpolation IS performed... but only when the boat is turning! Looks like a client issue perhaps?
Can you try the First Look viewer, and see if that fixes the problem for you?
I have had the same issue in First Look and the normal viewers. Someone commented on the blog that they are having it as well. I do have interpolation checked.
The problem is more prevalent at low speed. Yep, I have had this problem since 17 Jan. I have interpolation checked, but for certain vehicles this only seems to be happening whilst the vehicle is turning. When I move in a straight line, the vehicle starts jumping across the screen in increasingly larger jumps as my speed increases. Strangely enough, it doesnt seem to affect all vehicles.
For me, this is most noticable in the following vehicles (practically making them unusable): Damania Roadster (Creator: Damanios Thetan) For me, the following vehicles DO NOT have this problem, and are as smooth as anything: Mehve (Creator: Chage McCoy) I just want to note that this seems unrelated to the 'freeze' bug, as whilst the vehicle is jumping across the screen, I can still smoothly alt-rotate and zoom the scene, type in the chat window, and access the rest of the GUI. Vehicles are unlikely to exhibit this problem in mouselook, probably since changing the angle of the vehicle prevents the stuttering and there will always be at least a tiny change in angle unless the reticle is perfectly centered.
Of course, if your vehicle cannot be controlled by mouselook, you're still out of luck. This doesn't just affect vehicles. Two days before that update, we had installed some surfable waves at Dogfight Atoll, the waves being physical objects that would glide smoothly across the surface of the lagoon. They looked really nice until that update, after which, the waves would stand still for a second, then instantly jump 10m, stand still, jump, etc. At first I thought it was the waves, but then I noticed the airship I was testing at the same time was also acting jerky, and it wasn't my framerate, the animated textures on the ship would continue to smoothly animate while the airship stood still, jumped, stood still, jumped, etc.
I have noticed, as someone else pointed out, the effect seems to go away if the object is not moving in a straight line. Further observations:
1) For me, this is still happening in the First Look Viewer. Yes, adding angular momentum to the vehicle causes the jerkiness to abate.
For example, my HV-02 hover vehicle is perfectly smooth, as it replies upon llApplyRotationalImpulse (instead of the angular motor). But my flying vehicle, which has a dual hover/flying mode (hover = keyboard only, flying = mouselook), exhibits the jerkiness when in hover mode. When I added a few llApplyRotationalImpulses to simulate banking, the jerkiness is not as bad. There is still jerkiness, but it only seems to occur between control event ticks (as that is when the llARI calls are invoked.) My guess is the interpolation updates are not being sent unless there is sufficient angular difference between simulator physics frames. Anyway, hope this helps! I've also noticed that vehicles are stuttering lately.
There's obviously big changes underway and Linden Lab are busy operating on Second Life, in an effort to make it more scalable. So let's all pray that Second Life doesn't end up like the Michael Jackson of the software world.
I take back what I said at first, this is definitely not an issue with Velocity Interpolation. A good place to see this problem is in Suffugium, where I've got physical objects flitting about. These objects don't use llMoveToTarget(). You can see them jerk about now, where their movement used to be steady. You can also see this problem in the IBM CODESTATION sim's maze. Watch a bug or a robot, and you'll see that one out of every three moves or so is jerky.
This is a huge problem, and greatly impacts the aesthetic appeal of my ambient physical objects. I have noticed that the motion of physical objects is identical regardless of how you set Client > Network > Velocity Interpolate Objects. The check mark does nothing, everything looks the same no matter how it's set. So, perhaps that is related to the problem – somehow this feature got disabled with that update, so it no longer matters how to check it in the menu, it's always off either way you set it.
It makes me laugh – I'm currently working on a 200 prim non-physical vehicle, and it's a joy to fly, because it's way way smoother than physical vehicles now. Poking around inside llviewerobject.cpp would seem to indicate that someone may have chopped the accel data from the update packets to save bandwidth.
Code: // CRO - don't velocity interp linked objects! // *TODO: should also wrap linear accel/velocity in check if (!(accel.isExactlyZero() && vel.isExactlyZero())) { LLVector3 pos = (vel + (0.5f * (dt-HAVOK_TIMESTEP)) * accel) * dt; // region local setPositionRegion(pos + getPositionRegion()); setVelocity(vel + accel*dt); // for objects that are spinning but not translating, make sure to flag them as having moved setChanged(MOVED | SILHOUETTE); } mLastInterpUpdateSecs = time; // [[update flags blah blah blah]] Okay, it's probably either mDead, mStatic, or the result of getAcceleration() that has the problem. It can't be mDead, or it'd vanish... Code: else { mStatic = FALSE; }mStatic looks ok, as far as I can tell that's the only place it gets set. That leaves some other cause of incorrect dt or wrong accel... It's not crappy ping interpolation, since I have that turned off, and anyway, if dt WAS wrong, angular updates would also be screwed... hmmm... Code: } Looks like applyAngularVelocity does cut out a low enough omega, but that shouldn't affect linear interpolation. :. Therefore by a process of elimination, it looks like getAcceleration isn't giving the correct value. I'd have to track down getAcceleration through other sections of the program to be sure, but I bet it's because someone chopped the accel data from the update packets to save bandwidth. I'm not a coder but I am a sponsor of sailboat racing. Virtually all my companies advertising budget goes into sponsoring sailboat racing and sailors in Second Life.
Obviously this issue is of great importance to me. When I promote my website I expect to see great competition and a great show. Hopping boats is not amusing. Currently we have plans for a second regatta but if this isn't fixed, I'm not so sure it is a cost effective way to spend my money. Thank you very much for looking into it. Seeker Gray If you want to see an example of this bug, go to the Abbotts runway and watch the planes take off. They appear to stop completely, sometimes for several seconds.
I can't emphasize enough how important it is to fix this bug. It's maddening. And my experiments did suggest the remove of acceleration data unless there was angular/rotational change as well, so in support of Mat Warf's analysis above.
BTW, this hurts not only vehicles, but anything using physics like machinima camera scripts and elevators. Another way to see it is to go to Yongnam, north-east corner, go up the store tower and fetch one of the free airships - try to fly that up. Around cloud level it starts to go completely jerky upwards. It uses buoyancy to go up, so it should be smooth, as it is not triggered by any scripts but only physics. And yes, it's driving me crazy - made my airships completely non-rideable, because it's just no fun to jerk along.
This bug is still present in the beta preview (1.13.4 (3)).
If anyone's wondered why they haven't seen me in a vehicle lately... this is why. Just wanted to let you guys know after reading existing knowledge and experiencing it annoying the heck out of me, I'm going to check with dev expertise for further actioning. This is on my manual watchlist (a bookmark, since public JIRA doesn't yet have the auto-Watch feature yet).
A lot of comments and the votes have rocketed this up, too; I'm also going to check with Rob re: being able to sort by # of votes in public JIRA so it'll help us see this stands in the big picture of current issues. BTW, I discovered how to manually sort by # of votes. You have to manually add the "Votes" column.
Out of all the issues we currently have, this one is by far the leader, with 64 votes at this time of writing. The next-nearest has 4 votes. And... great, Rob just added the Votes column to global view, so you should now see it right off the bat.
 Good news, Torley
Yes, this is an issue that rouses the passions of dedicated and committed residents who have had a fleeting glimpse of SL's potential. Please do right by us and light a fire under whoever's butt is looking into this. I'm not a coder and I don't understand all the code jargon, but I am an avid sailing fan... this issue is making it very difficult for me to join in the racing. I'm really looking forward to the fix!
I am glad someone at LL is finally looking at this. Perhaps while it is being investigated, someone can look into why it was left to sit for so long. To be perfectly honest, LL has a well-established pattern of breaking existing features (even if the breakage was reported in a beta cycle) and then ignoring them for weeks or even months.
It would be nice to see a change in direction here. If one of the software vendors you rely on were to push a new release (of, say, MySQL) that broke something you relied on, I'm sure you would either immediately go back to an older version or work with them to get it fixed pronto. We would very much appreciate it if you would show us the same diligence, and not deliberately release new versions when you know they break things that we rely on. By the same token, when something of this magnitude is reported, it should not sit for nearly a month and a half, still show as Unassigned, and have no visible progress. The message that sends us is not encouraging. I am sorry if my post sounds negative, but this is not the kind of issue that gets resolved when everyone is a "yes-man." This bug is just the latest reflection of a more fundamental issue. Thanks for your time. ^ Elevated to critical to match internal priority – I apologize this has taken so long and I agree with a number of the above comments about expediency. In this specific case, it was the # of votes on Public JIRA (after that had been opened up) which helped get attention and let me communicate how important it is to many of you; with many issues, it becomes difficult to prioritize them when we get "false "flags" (issues that someone proclaims are far more devastating than they actually are), so lest I be buzzword-laden, this will be a new test of the "wisdom of the crowds", you helping us do our jobs better through this public issue tracker.
I've let additional developers know about this too; also, sometimes there's internal progress made on issues that aren't publicly shared; it depends sometimes if a developer wants to be visibly credited (e.g., we've had times in the past where an issue here was fixed, yet was shown as Resolved and Unassigned). I will focus here and check this page daily. You know, it occurs to me it's not just acceleration data that's missing, the velocity data is too! It's not moving at any velocity at all between frames... if it was merely acceleration data missing, you'd get rubber-banded on updates, but at least you'd be moving continually.
Torley, thanks very much for the response!
OK, sorry if this goes on a bit, but I'm going to post a few videos demonstrating how damaging to vehicles this bug is, and also to provide a record of what is happening if people are having difficulty reproducing it. I'm not sure about uploading all this lot to JIRA, as it's about 10 megs worth of stuff, so I'll just do it as links. Torley, if you think adding these vids direct to the bug report is a good idea, then please go ahead.... First off, Cubey Terra's Terra Balloon 3.1: http://www.elencher.com/vwr-86/TerraBalloon.wmv This used to be a totally smooth ride, now it hops across the screen in irritating leaps. Note how the leaps get progressivly larger. The leaps reset to smaller jumps if you change the direction of the balloon. Really, it totally spoils the experience, especially if you like balooning and sightseeing in mouselook. Secondly, a couple of videos of the Kanker Greenacre's Flying Tako: http://www.elencher.com/vwr-86/Tako.wmv In the first video, note how smoothly the scene is rendered as I rotate the camera - but my Tako is hopping across the screen. Completely spoils the experience, takes all the finesse and fun out of it, and it looks stupid. The second vid shows how ridiculous the SLRR ferry looks now - towards the end, it makes one huge leap across nearly a half of the Sandra sim!!! Finally, Gaius Goodliffe's Lakehurst SSA-1901: http://www.elencher.com/vwr-86/Lakehurst.wmv Previously, vehicle irritations used to be limited to the odd rubberband, and dodgy sim crossings, but on the whole, I think vehicles used to work pretty well. Now, we have this consistant bug which has pretty much taken all of the fun out of almost all the vehicles I own. All of the above vehicles are fabulous creations, and I am glad to have them in my inventory. Their creators have put all this time and effort into getting them just right, and they are now reduced to these shambling kangeroo hopping things!!! Hi Torley, thanks for your response. I think the general feeling among residents is that if LL breaks something, and there is no reasonable workaround, there is no question as to whether fixing it needs to be a top priority. LL should assume that we will derive maximum benefit from this particular kind of bug (i.e. broken existing functionality/no workaround) being fixed ASAP. The voting system is a good step in this direction. It isn't 100%, but it's a start.
Here's where we stand on this: tentatively, we hope to have some progress we can share on this aggravating issue by next week. I don't want to say anything premature, but the Studio Blacklight dev team – which recently formed out of the recognized need – is focusing on Resident pain points, and we've committed to working on this. I help communicate your feedback from this, and many other sources.
(You may have seen the Blacklight name @ http://secondlife.com/support/known-issues.php @Cybrid: Thank-you for the videos. It helps, I really like video bug repros myself. It makes it much more clear at a glance at describing in text. @Huns: I feel the same way. It's particularly frustrating when there are unplanned fires to fight and not enough resources, but it's an ongoing challenge. I hope we'll be able to visibly demonstrate that Resident usage of JIRA is helping us prioritize important issues over the long-term, using this as a specific initial example. Assigned to Aura, who's already started work on this. Please continue to post feedback here.
I've noticed that this seems to be related to camera distance from the vehicle; zoom in, and you'll see several hops per second... zoom all the way out and you'll see a hop every few seconds.
I'm guessing that updates are sent on a proximity-to-camera basis (a sensible way to do things), but the lack of interpolation makes things far away look paticularly bad. ( http://www.elencher.com/vwr-86/Lakehurst.wmv I'm not sure that helps much, but there you go. Huns, I want to let you know that I really appreciated your comment up there (https://jira.secondlife.com/browse/VWR-86#action_10653
 ). It's a good example of how an SL Resident can criticize LL while still respecting them as people. You got your point across well without berating LL employees, and I think that'll get you heard a whole lot more than the standard LL bitchfest does. ^ IMHO I agree, and that's the type of criticism we need more of. It puts the seriousness and pain in perspective in a time where frankly, we have so much incoming feedback that it's more important than ever; we need to be able to focus on the issues at hand without wasted time. I'm happy to see Public JIRA grow with that discussion.
Aura and Andrew are continuing to work on this issue. The resolution for this issue is now awaiting Quality Assurance testing. I'll keep you guys posted.
This bug appears to be fixed in the latest beta (Aditi). Looking forward to the next update!
^ what Cubey said. It's fixed on Aditi!
Some 'before and after' vids (also demonstrating how much fun vehicles can be in SL!): Terra Balloon: http://www.elencher.com/vwr-86/Aditi/TerraBalloon.wmv Flying Tako (Wee Tiny this time, cos there's not much open water on Aditi): http://www.elencher.com/vwr-86/Aditi/WeeTinyTako.wmv And finally the Lakehurst: http://www.elencher.com/vwr-86/Aditi/Lakehurst.wmv Looking good! Well done Torley and Aura, fingers crossed for a smooth rollout onto the main grid! Gosh you guys are fast!
OK... good news here, Aura, Don, and Andrew got their hands on this one, and it just underwent QAing. Thanks for your observations, I'm marking it as fixed. Thanks everyone who voted too, this is the very first big-vote issue we've got on Public JIRA, and I hope it'll set the tone for future progress. w00t! I have never looked forward to an update as much as this one. Thanks for getting this fixed, Aura, Don, Andrew, and of course Torley! We love you, guys! ahem Err, you know what I mean.
 @Gaius: Thanks for the encouragement!
Unfortunately, we've found a new repro that results in jerky movement; Dan Linden mentioned this:
Observed results: As the tube's velocity approaches zero it begins to stutter/jerk Expected results: Smooth motion all the way to zero velocity so I'm reopening it until this is also resolved. This issue was not resolved on the main grid with today's release, or really alleviated in any way that I can see. Maybe this is because I need to wait for a new client release, or maybe it's because of what Torley just wrote. Either way, this is definitely still a huge issue.
Torley's description of the Ben Linden innertube may not be the only symptom of this re-opened problem. Using 1st look viewer v...59036 on the main grid this evening, my sailboat (Flying Tako 3.2 Dinghy, Creator: Kanker Greenacre) no longer jerks obviously, but, when in motion, it now bobs regularly at about the same rate that it used to jerk. It seems to lose buoyancy and ballistically drop, then bounce back to the right altitude, over and over. I'd like to suggest that checking the buoyancy of moving, boat-type vehicles be included in the testing regimen, if it is not already.
They're not losing their buoyancy, Vin. What's happening is that the sim isn't sending updates frequently enough to the client, so the client's interpolation is kicking in. Since objects that float actually bob up and down a bit, if the client gets no update from the server, the object will just continue to move downward at the (slow) velocity it was already moving at. This can also cause cars to appear to repeatedly fall through the road as they travel.
Agreed, Lex.
My Lakehurst does EXACTLY this in the video above! Watch what happends when I crank it up to 100% throttle, after rounding the building. You can see it start to bob. (link again: http://www.elencher.com/vwr-86/Aditi/Lakehurst.wmv Also, my Wee Tiny Tako does it once as it comes out from under the bridge (link again: http://www.elencher.com/vwr-86/Aditi/WeeTinyTako.wmv And on the subject of the low speed stutter / jerk: The Caledon Trolleys are also exhibiting this! (As they move at a stately pace more befitting Ladies and Gentlemen of quality and refinement!
) ^ Thanks, a new fix for this has been checked into internal maintenance... I believe it'll be undergoing QAing again soon, so I'll check back and update with what we find.
I'm not much of a vehicle user, so this doesn;t affect me personally. But I can see it affects lots of other people, so I'm voting for it.
/me supports Linden Labs. Even though you guys broke WarpPos, you fixed the clothes change unseating bug, which has made me happy. Nice to see torle posting lots in all different problems. Let's hope you guys can keep up this level of communication as Jira becomes more significant. I'm of to vote on every issue that matters. WarKirby @WarKirby: You're welcome, and good news is the "WarpPos" issue is already re-fixed internally and will be available in the next patch; it's
Re-resolving this one, as it's recently gone through Quality Assurance again, and fixed in build 1.13.4.6. Please check Beta Test Grid and let us know what you find. Looking good to me so far (on ADITI), a definite improvement over the last fix.
One thing I spotted was that in a cruising Tako (ie on straight course, as fast as it's going to get under the current conditions) seems to waver slightly, heeling/bobbing ever so slightly once per second, like a heartbeat. I can't record a video here, sorry. It's a very minor effect though, probably some interaction with the angular motor and the vertical attractor. Thanks for your email, Mat.
It tentatively looks like this will be fixed in a future 1.14.1 update which includes a number of server-side fixes. This is different from the release of the First Look Viewer this Wed., Mar. 28. I don't have a more exact time at this point, but it sure will be nice to see this fixed on the Live Grid soon – as always, keep checking http://blog.secondlife.com As of the current 1.14.1 Beta this is NOT fixed.
It may be a bit better, but still is quite bad for small light vehicle objects (< 1M), not sure about bigger ones. The jumps are smaller and more frequent, but it is a very long way from smooth. Non-physical motion is much smoother and before the release that broke this, the same objects moved very smoothly. Hi, this issue is not fixed yet on the main grid (as I can observe right now with Ben Linden's innert00bs) and there are reports that it is not fixed on the beta grid either. Until it is really fixed, for real, on the main grid, I'm going to suggest that it remain open.
Sucks to hear this isn't fixed yet, I've asked for dev expertise – will followup with further info.
Unfortunately, no ETA right now when this can be worked on again; I'm keeping my eye on this and will update if that changes.
For those who have a lot of experience with this, are you still seeing it on vehicles at higher velocities (as opposed to vehicles that are nearly stopped)?
I have seen it in vehicles that are BOTH A) moving slowly AND B) floating on water. Ben Linden's innert00b is a great example of this.
I have seen this happening more and more, mostly on automated vehicles. Think the last time I saw this happening was the short stretch of the SLRR south of the ANWR water bridge, and (I think) the tram system west of Ahern.
If I get the time, I'll see if I can catch it happening and post a video repro this weekend.... I think Torley is asking if it's happening on fast vehicles.
Ben's t00b and the SLRR might not be good examples.. I've been doing some testing on this and from what I see, in a straight linear velocity, anything below about .5 m/sec is jerky but rapidly smooths out at and above .5 m per sec. It's hard to really see, but it appears that adding some angular velocity helps the jerkyness, that is you can set the linear motor a little slower if you have some angular velocity and still see smooth motion, but I'm not sure about this.
There seems to be a related effect which is that if the vehicle buoyancy is carefully tuned to be exactly neutral - about .794 in my case of a .5 x .25 x .25 wooden block, the vehicle will stop moving completely and freeze even though the linear motor is running. This seems to be related to speed too. Faster speeds seem to freeze less and if you have an angular motor running that also seems to lessen freezing. Setting the vehicle buoyancy to below .78 or above .82 eliminates this effect Unlike the jerkyness however, this really stops the motion, using llGetVel will report 0 velocity and the position stops moving. I've been playing with non-vehicle physical movement using llApplyImpulse to get similar slow speeds. The test just applies an impulse in the X direction, waits a few seconds (depending on the speed), then applies an impulse to get the same speed but in the opposite direction.
What happens is that it works intemittantly, running for a few cycles back and forth, then the object stops (llGetVel = <0, 0, 0>). Sometimes it will restart after one or two dirction reverses, but it's not clear what the parameters are for starting and stopping. It does appear that slower speeds (< 1 m/sec) and shorter distances between reverses (< 5m) lead to more stopping. It also appears to behave this way in spurts, often if I reset the script, it will then run for quite awhile OK, but it's random. It usually freezes right when the direction reverses, but not always. .2 m/sec for 1 m will fail almost every time. 2 m/sec for 10m runs almost reliably, 2m/sec for 2 m is pretty good, but halts occasionall (1 out of 20 maybe) 1 m/sec. for 2 m is pretty bad, halts about half the time. These are all representative numbers, the actual tests are very random, sometimes they run no problems, sometimes the same test fails almost all the time. This is all on a private sim with very little other stuff on it, default .5x.5.x.5 wooden cube. I'm wondering ithe base of this JIRA bug is that there's something messed up in the physics engine and the vehicle code isn't checking to make sure that when it commands a velocity, it actually happens. In looking at this some more, I think the freezing at low speed and the buoyancy freezing are separate issues since they actually stop the motion. It appears that the vehicle movement jerkiness is a rendering problem, the object continues to move, llGetVel != <0,0,0> whereas with the two freezing conditions, llGetVel == <0,0,0>. I'm opening two new bugs for these.
Since this was reopened and still a problem in some cases, we'd like to get some more dev time on it. It hasn't been decided yet whether we'd fix this on its own or as a conducive part of the larger Havok 4 work (as mentioned in http://blog.secondlife.com/2007/05/02/cory-linden-town-hall/
) because it's a physics bug. Suggesting that physics bugs won't be addressed, even ones like this which was introduced several months ago and are not inherent in the physics engine since it used to work, is pretty discouraging for those of us attempting to build content. Beyond the question of when Havok 4 might actually be available in SL, the fact that this is something that used to work in the existing physics engine leads to the question of why it would be expected to work in a new physics engine? I'd like to suggest that deliberately leaving major parts of SL broken for months or years isn't a good decision if you want people to make any kind of serious commitment to SL development.
I am not technical, as many will attest, and have only recently taken up sailing [ how much dancing can you really do ] hehe. While sailing along, on a close beat, I looked to see my skipper and I violently oochng the boat upwind. In unison!, and we weren't really trying to do that. She almost fell off the transom. Plus this is a violation of rule 42 as well ! I asked my skipper if this was a bug in the software, and she said yes, this was part of it. She also told me that there was an issue raised. So here I am.
Sailors are decent folk and deserve an even playing field. With Torley Linden on board it would appear that we would get back to even racing soon on the waters of SL. Thanks to Kanker for the great boat and the Linden team for their unending work towards this huge bank of computers. Sail ON! -Tory Micheline @Ralph: It's definitely frustrating and I abhor seeing previously-working functionality get broken and not get fixed for long stretches (I have others I can name). I'll be updating this with any changes in status.
@Tory: Thanks for the colorful encouragement. I believe this has been fixed as of the current production version. At least the problems I was having with jerky vehicle motion have been fixed, although I can't speak for other people.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Critical
Jerky movement since update 1.13.2 on the 17th Jan 2007
