On 4-10-2018 9:18, Thomas de Groot wrote:
> 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:
>>>

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

After testing, I think you will get more reliable results using 
Reorient_Trans(y,Norm) instead. Otherwise the arrow text has a tendency 
to rotate around the original y axis.

Btw, not in functions.inc but in transforms.inc ;-)



-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> After testing, I think you will get more reliable results using
> Reorient_Trans(y,Norm) instead. Otherwise the arrow text has a tendency
> to rotate around the original y axis.

You're right!

Reorient_Trans(y,Norm)

MUCH better. I had never noticed the difference before. (Point_At_Trans had
always been my 'go-to' macro for this kind of thing; I assumed that they both
operated the same way.) Thanks!
>
> Btw, not in functions.inc but in transforms.inc ;-)

OOPS.  Correct again.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> After testing, I think you will get more reliable results using
> Reorient_Trans(y,Norm) instead. Otherwise the arrow text has a tendency
> to rotate around the original y axis.
>

[off-topic]
That little suggestion of yours has actually cleared up a long-standing mystery
for me. Having assumed that Point_At_Trans and Reorient_Trans produced the same
results, I had always used the former, for normals found on the surface of a
sphere (it just seemed easier)-- with the result being that my placed object
there rotated 90-degrees every now and then, relative to the surface's own
normal-- specifically, when the traced point crossed the border of
triangular-shaped 'quadrants' on the sphere surface. (It also occurs on the dips
and undulations of a height_field.)

I thought that this was due to a natural ambiguity of the found normal. But
Reorient_Trans doesn't perform that un-wanted rotation, as I see now. Excellent!

Post a reply to this message

On 4-10-2018 19:00, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>>
>> After testing, I think you will get more reliable results using
>> Reorient_Trans(y,Norm) instead. Otherwise the arrow text has a tendency
>> to rotate around the original y axis.
>>
> 
> [off-topic]
> That little suggestion of yours has actually cleared up a long-standing mystery
> for me. Having assumed that Point_At_Trans and Reorient_Trans produced the same
> results, I had always used the former, for normals found on the surface of a
> sphere (it just seemed easier)-- with the result being that my placed object
> there rotated 90-degrees every now and then, relative to the surface's own
> normal-- specifically, when the traced point crossed the border of
> triangular-shaped 'quadrants' on the sphere surface. (It also occurs on the dips
> and undulations of a height_field.)
> 
> I thought that this was due to a natural ambiguity of the found normal. But
> Reorient_Trans doesn't perform that un-wanted rotation, as I see now. Excellent!
> 
> 

Thanks for this little insight into working processes. From my side, I 
have always used Reorient_Trans instead of Point_At_Trans, probably for 
the reasons you mention, through the advice of somebody else, like 
usually happily happens in these ng's. The descriptions in the docs are 
the shortest possible, but it tells nonetheless the difference in 
concept from which one can understand the behaviour, with a bit of luck. 
;-)

Maybe this is a little bit clearer:
http://www.f-lohmueller.de/pov_tut/trans/trans_470e.htm

-- 
Thomas

Post a reply to this message