Am 02.10.2018 um 09:40 schrieb Kenneth:

> HOWEVER... I've been experimenting with the cam_z equation itself-- and found
> that no matter what I do to it, it has no effect on the arrow position, or on
> anything else in the scene(!). I even commented-out the equation, and
> substituted some wildly-different integer values just for kicks... again with no
> effect. I EVENTUALLY realized that cam_z is actually used only once, in cam_dir.
> And cam_dir isn't used at all!
> 
> I have no excuse for not seeing this until now. :-(
> 
> So, cam_z and cam_dir can be erased from the code, to make it a bit simpler to
> examine.

Or, maybe that's actually the problem?

A macro that tries to probe where a particular pixel's ray hits the
scene must know - and process - /something/ about the camera opening angle.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Or, maybe that's actually the problem?

He's just not seeing it embedded in
transform{TEXT_OBJECT_TRANSFORM}

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> > Or, maybe that's actually the problem?
>
> He's just not seeing it embedded in
> transform{TEXT_OBJECT_TRANSFORM}



So, I've just been dabbling with this in the odd 5-10 minute blocks of free time
that I have, and trying to see what I did with modeling the camera's view
frustum.

Let's suppose we're using the default camera, with the camera at the origin, the
"canvas"/image plane at z=1, right x, up y, sky, y, direction z, look_at z

If you're going to select pixels, then you want to translate those values so
that you get the +/- 0.5 range for x and y, with the center being <0,0>

Just divide the pixel value by the width and subtract 0.5 to give a range of
-0.5 to 0.5

Do the same for y and height, and flip the sign

Then to project that point "out" into the 3D scene, you just multiply all those
values by the z value (returned by trace() )
Because similar triangles.


This is not the hard part - the hard part is doing this when the basis vectors
are different - when the camera and look_at values, etc aren't axis-aligned.


So for envisioning what to do:
1. Take the scene's camera values and rotate everything so that it's in the
"default" frame.   (more to do if there's shear, etc.)
2. Do the simple math.
3. Rotate everything back by doing exactly the opposite of what you did in step
1.


And this is where I think the transform matrix approach will really shine.

I just need enough uninterrupted round-tuits to get oriented and forge far
enough ahead.

[highly] Suggested reading:
http://www.scratchapixel.com/lessons/3d-basic-rendering/computing-pixel-coordinates-of-3d-point/mathematics-computing-2
d-coordinates-of-3d-points

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

[Kenneth wrote:}
> > > So, cam_z and cam_dir can be erased from the code, to make it a bit
> > > simpler to examine.

[Clipka wrote:]
> > Or, maybe that's actually the problem?
> >
> > A macro that tries to probe where a particular pixel's ray hits the
> > scene must know - and process - /something/ about the camera opening angle.
>
> He's just not seeing it embedded in
> transform{TEXT_OBJECT_TRANSFORM}

Do you mean that Clipka's observation is already 'included' in that TEXT OBJECT
matrix in some way? Although I surely don't grasp that, it's quite interesting.
And the matrix is used ONLY for the text objects, not for the arrow placement
(unless all the ingredients in the matrix are also used in another form for the
arrow?) Sorry if I'm not making clear sense; the whole concept is quite fuzzy to
me at the moment.

BTW, apologies for not yet commenting on your code analysis; I'm slowly
digesting it all ;-)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> > BTW, it's not clear to me why he specified radians rather than degrees, as
> > a camera angle is specified in degrees(?), or something similar.
> > >
>
>
> The angle IS in degrees, but tan () acts on radians.
> That's why it needs to get converted to radians first, before performing the
> tan() function.

Oh, of course; thanks. The 'radians' keyword (or alternately 'degrees') is a
CONVERTER.

I forgot :-[

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> Do you mean that Clipka's observation is already 'included' in that TEXT OBJECT
> matrix in some way? Although I surely don't grasp that, it's quite interesting.

That was my initial thought, based on the briefest of glances.

> And the matrix is used ONLY for the text objects, not for the arrow placement
> (unless all the ingredients in the matrix are also used in another form for the
> arrow?) Sorry if I'm not making clear sense; the whole concept is quite fuzzy to
> me at the moment.

After scrutinizing the code more closely, the unions and indentations had me
confused, and perhaps you're right about that.

> BTW, apologies for not yet commenting on your code analysis; I'm slowly
> digesting it all ;-)

Take your time - and check your email.  ;)

Post a reply to this message

On 2-10-2018 21:08, Kenneth wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> BTW, it's not clear to me why he specified radians rather than degrees, as
>>> a camera angle is specified in degrees(?), or something similar.
>>>>
>>
>>
>> The angle IS in degrees, but tan () acts on radians.
>> That's why it needs to get converted to radians first, before performing the
>> tan() function.
> 
> Oh, of course; thanks. The 'radians' keyword (or alternately 'degrees') is a
> CONVERTER.
> 
> I forgot :-[
> 

I have never known ;-)

-- 
Thomas

Post a reply to this message

On 2-10-2018 21:10, Bald Eagle wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> 
>> Do you mean that Clipka's observation is already 'included' in that TEXT OBJECT
>> matrix in some way? Although I surely don't grasp that, it's quite interesting.
> 
> That was my initial thought, based on the briefest of glances.
> 
>> And the matrix is used ONLY for the text objects, not for the arrow placement
>> (unless all the ingredients in the matrix are also used in another form for the
>> arrow?) Sorry if I'm not making clear sense; the whole concept is quite fuzzy to
>> me at the moment.
> 
> After scrutinizing the code more closely, the unions and indentations had me
> confused, and perhaps you're right about that.
> 
>> BTW, apologies for not yet commenting on your code analysis; I'm slowly
>> digesting it all ;-)
> 
> Take your time - and check your email.  ;)
> 

This all is way beyond my skills I humbly admit. Just a little addendum 
though if I may: the matrix is not part of the original position finder 
by Norbert. It was conceived (and rightly so!) by Kenneth, as an 
improvement to the original.

-- 
Thomas

Post a reply to this message

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

-- 
Thomas

Post a reply to this message

Attachments:
Download 'islaytest.png' (360 KB)

Preview of image 'islaytest.png'

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?

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