On 3-10-2018 15:17, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> 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?

Yes, 80. You know, I was just beating the bush and whistling a merry 
tune, waiting for anything (a miracle?) to happen ;-) Totally crap of 
course.

> 
> 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!

Indeed. I forgot about that one. See below for further thoughts.

> 
> 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.

One may wonder what we really need. I personally believe we do not need 
the rotation values resulting from the rx and rz calculations at all. We 
use this macro (1) primarily to get an accurate 3D position on a given 
surface; (2) possibly, we also need an orientation to the surface, thus 
we need the normal. With Point_At_Trans(Norm) we can then orient our 
object accurately on the surface.

> 
> 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.

I think: forget about this. No need for this.

-- 
Thomas

Post a reply to this message