On 1-10-2018 14:24, clipka wrote:
> Am 01.10.2018 um 08:52 schrieb Thomas de Groot:
> 
>> I must admit that I have major difficulties with vnormalize and vcross.
> 
> What's difficult aout `vnormalize`? It simply trims (or stretches) a
> vector to a length of 1 while keeping the direction. No magic there.
> 
> What `vcross` does is a bit more complex, I give you that; but normally
> it is simply used to compute a vector perpendicular to two others (with
> proper handedness; e.g. vcross(x,y) returs z), and is trimmed to unit
> size using vnormalize (unless the two input vectors are known to be
> perpendicular and of unit length).
> 


difficulty to understand the "why" of such use in most cases.

-- 
Thomas

Post a reply to this message

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

>
> I must admit that I have major difficulties with vnormalize and vcross.
> Somehow I achieve to understand vaxis_rotate more intuitively :-/ but
> the whole code is bursting my brains.
>
[snip]
> ...but I am confident that Kenneth can.

Uh, don't be so sure  :-P

I'm in the same boat as you-- it's vcross and vaxis_rotate that give me the
chills. *Someday*, with enough concentrated thinking, I'll have one of those
'Eureka' moments. Surely!! (?)

But I just discovered something in Norbert's core math code that is of interest
(in a small way): Until now, I've been thinking that the arrow-offset problem is
*somehow* related to his initial cam_z equation-- specifically the
tan(radians(cam_ang*0.5)  part-- because of the use of  tan  itself. (As an
angle approaches 90, tan(90) approaches infinity, which seems problematic. But
then again, his tan equation is working on only HALF the given angle-- so
tan(90) would never happen anyway.) 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.

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.

Post a reply to this message

On 2-10-2018 9:40, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>>
>> I must admit that I have major difficulties with vnormalize and vcross.
>> Somehow I achieve to understand vaxis_rotate more intuitively :-/ but
>> the whole code is bursting my brains.
>>
> [snip]
>> ...but I am confident that Kenneth can.
> 
> Uh, don't be so sure  :-P
> 
> I'm in the same boat as you-- it's vcross and vaxis_rotate that give me the
> chills. *Someday*, with enough concentrated thinking, I'll have one of those
> 'Eureka' moments. Surely!! (?)

Yeah... I have not too much problems with vaxis_rotate as I can 
understand and visualise the purpose of that in the macro. However, I 
scratch my head about the others.

> 
> But I just discovered something in Norbert's core math code that is of interest
> (in a small way): Until now, I've been thinking that the arrow-offset problem is
> *somehow* related to his initial cam_z equation-- specifically the
> tan(radians(cam_ang*0.5)  part-- because of the use of  tan  itself. (As an
> angle approaches 90, tan(90) approaches infinity, which seems problematic. But
> then again, his tan equation is working on only HALF the given angle-- so
> tan(90) would never happen anyway.) 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.
> 
> 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.
> 

I have been wondering also about those parameters. I had assumed that 
cam_dir was supposed to be the value for the direction parameter in the 
camera block. Putting cam_dir there does not do anything vital, so maybe 
it is some obsolete leftover from earlier versions? Puzzling, to say the 
least.

I agree with you about the radians. There seems to be no need for them 
but if cam_z is not used, I don't worry :-)

-- 
Thomas

Post a reply to this message

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

> I agree with you about the radians. There seems to be no need for them
> but if cam_z is not used, I don't worry :-)

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.

Post a reply to this message

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