|
 |
Thomas de Groot <tho### [at] degroot org> wrote:
> So, I manage to get the arrow on the rod by tweaking:
>
> #local dir_y = vaxis_rotate (lookat-cam_loc, vcross (cam_d, cam_up),
> (0.483-screen_y_position*0.01)*cam_ang/image_width*image_height);
> #local dir_xy = vaxis_rotate (dir_y, cam_up,
> (0.535-screen_x_position*0.01)*cam_mirror*cam_ang);
>
> replacing the 0.5 value by respectively 0.483 in dir_y and 0.535 in dir_xy.
>
> Of course, this is entirely by just dumb trial and error, and I highly
> doubt if it is significant. I wonder now if it holds for other scenes...
> tests to do...
>
Yeah, I've found that tweaking *something* (one of several different things
actually) can put the arrow where it's supposed to be. But I suspect that your
values would need to change, when using a different camera angle? My own 'tweak
tests' have shown that the code as-is has the ideal overall values in its
arrow-placement equations-- but only at the most extreme telephoto/zoom camera
angle. As that angle value climbs toward 90 (more and more wide-angle), the
arrow position just gets progressively worse... and my own value-compensation
tweaks have to get larger, to correct it. Very frustrating so far.
BTW, what CamAng did you use for this test? 80?
On a brighter note:
I've discovered a simple fix for ALL of the traced 'normal' problems that I've
been dealing with!
To wit: After spending WAY too much time trying to come up with workarounds, I
replaced Norbert's
rotate <rx,0,rz>
with
Point_At_Trans(Norm) // a macro
from "functions.inc"
That's it!
Well, not quite: Even though the ARROW'S 'normal' orientation now looks great
all the time, the found rotation (in the #debugged output and on-screen) is no
longer correct-- because rotate <rx,0,rz> no longer agrees with whatever
Point_At_Trans is doing behind-the-scenes.
I haven't yet found a way to get at Point_At_Tran's hidden inner values, to USE
for the rotation. Looking at its code (and at the other macros that it requires
in order to work), there's... a MATRIX. :-( I refuse to be beaten, though! Out
of desperation, I'm now *trying* to work out a way to turn a normal directly
into a set of rotations-- at least in two axes--that I can use to bypass
Point_At_Trans AND rotate <rx,0,rz> altogether.
Post a reply to this message
|
|
