[sldev] Request for help with modifying client camera behavior

[Kent Quirk (Q Linden)]

On Aug 27, 2008, at 2:18 AM, Tammy Nowotny wrote:
> Kent Quirk (Q Linden) wrote:
>> Hi, Victor.
>>
>> Although I work at Linden Lab, I'm not able to give you much help  
>> on the details of the code you'll have to write, as I haven't  
>> looked at our camera code at all, nor am I an expert in LSL.
>>
>> But what I can do is give you some benefit from having done some  
>> work on camera cinematics in a game I worked on. We had the need  
>> for an intelligent camera that could track between waypoints, and  
>> we also needed a repeatable camera that we could fine-tune the  
>> motion track for.
>>
>> I (and others) spent a fair amount of time playing around with the  
>> system until we got the sorts of results we wanted. What I can  
>> remember (it's been 8 years now) were:
>>
>
> Q for Q: do you have any thoughts on the problems with the erratic  
> camera movements in 1.20 ?  (It sounds like the frame was much  
> predictable in that game you worked on 8 years ago.)

Well, it seems to me that the "erratic" camera movement is due more to  
artifacts in the mouse picking code than to any issues relative to  
smoothing.  At least I assume that's what you're talking about (when  
you use alt+click to rotate the camera around an object and end up  
looking at the sun or something).

But it's also true that frame rate matters a lot if you want smooth  
motion. The system I described is reasonably tolerant of varying frame  
rate, provided that you take the delta T into account each frame --  
but it's piecewise linear, so if the frame rate is low you'll see the  
transitions in velocity. You could move to a time-based system,  
calculate frames on a fixed timestep, and then interpolate between  
those frames to get the actual camera motion based on the real  
framerate. That would give you predictable behavior.

	Q