Re: Smoothly rotating to another angle on pano nodes

[Christian W. <cwa...@gm...>]

James C. Wilson wrote:
> Yesterday I realized most of those problems, and fixed them. The new 
> code runs very well, but oddly enough, doesn't return to exactly the 
> defined target location, missing by about 1.5 degrees x, and 0.2 degrees y.

I don't know if that's the whole cause of your deviation, but when you 
add up a lot of little steps like this you can accumulate a lot of 
rounding error. Keep in mind that floating-point numbers such as the 
ones used by Lua have limited precision, and some (most) real numbers 
cannot be represented exactly as floating-point numbers (even if they 
can be represented exactly as decimal numbers, e.g. 0.1). Also, what you 
get back from pipmak.getviewdirection() is not equal in general to what 
you put into pipmak.setviewdirection(), because Pipmak internally stores 
them as single-precision floating-point numbers (corresponding to about 
9 decimal digits), while Lua uses double-precision numbers (about 18 
decimal digits).

You shouldn't stop your loop when a certain number of iteration is 
reached, but when the target angles are reached. And you can't count on 
them being reached exactly, you need to stop once you're close enough 
(e.g. less than half a step off) and then snap to the correct target value.

More comments:

- Why are you putting the parameters into global variables instead of 
passing them to the autoPan function as arguments? You could also put 
the intermediate results (autoPan_funcCount etc.) into local variables 
of the autoPan function, they are visible from the inner function (see 
<http://www.lua.org/manual/5.0/manual.html#visibility>). You should only 
use global variables when you have to, since they make your code less 
encapsulated and harder to maintain - for example, if somewhere else you 
later happen to use the same global variable name for a different 
purpose, that can cause hard to find bugs. (Plus, in Lua, they are less 
efficient than local variables).

> autoPan_rate = 0.025   --the framrate of the rotation, e.g. how many 
> times it runs per second.
- No. That's not the rate, that's the inverse of the rate, how many 
seconds each iteration takes.

- Your timer never stops if autoPan_iterCount happens not to be a whole 
number (autoPan_time isn't a whole multiple of autoPan_rate).


  -Christian