 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28-9-2018 21:28, Kenneth wrote:
> Thomas de Groot <tho### [at] degroot org> wrote:
>
>>
>> My bad, as I misplaced the rod by one square :-/
>>
>
> Ha! Tt is always a relief when a so-called 'problem' has a simple solution :-P
Yes indeed.
>
> At some point, I hope to find a good solution to the arrow-offset problem
> itself.
>
I am twisting my brains in every direction to understand this. Beyond my
abilities I am afraid.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 29-9-2018 8:31, Thomas de Groot wrote:
> On 28-9-2018 21:28, Kenneth wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>
>>>
>>> My bad, as I misplaced the rod by one square :-/
>>>
>>
>> Ha! Tt is always a relief when a so-called 'problem' has a simple
>> solution :-P
>
> Yes indeed.
>
>>
>> At some point, I hope to find a good solution to the arrow-offset problem
>> itself.
>>
>
> I am twisting my brains in every direction to understand this. Beyond my
> abilities I am afraid.
>
...looking more closely at the macro code, I wonder if something is
missing to the dir_xy parameter, or to the dir_y parameter more
probably, as this last one controls the eventual z-location...
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
>
> ...looking more closely at the macro code, I wonder if something is
> missing to the dir_xy parameter, or to the dir_y parameter more
> probably, as this last one controls the eventual z-location...
>
I agree.
There is a small multiplier value in both equations -- .01 -- that *seems* to
relate to screen percentages (just my guess). I.e., 1-percent. Changing those
even slightly (to .011 for example) shifts the resulting arrow location.
Currently, the values are constants, but I wonder if they need to dynamically
change as the camera angle changes?
I have to admit that some of Norbert's math trickery is beyond me. At the same
time, his code is an instructive lesson in how to use POV-Ray's built-in math
constructs and keywords, and what effects they have. Hopefully, I will learn
some new things-- given enough time!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have actually had a little bit of time to look at this code in more detail and
shift it over to my camera view frustum scene --- whereupon it doesn't see the
SURFACE unless the plane is included, and then that's the only thing it sees...
But I do agree, after back-tracking through the code, that dir_xy, which is used
in the trace () call has a high probability of being the culprit.
Having said that, the whole manner in which this macro works with vaxis_rotate
is a bit hard to follow, and it may be easier to start from first principles.
I think that if you look at the screen.inc code, you'll see that all you're
doing is using normalized coordinates in screen space.
If you just extend that vector, you "reach out" into the scene past z=1.
(assuming a default camera)
This ought to be a matter of the same simple trig, with no hard-to-follow (and
verify by hand) rotating vectors around axes.
So more than half the work is already done.
{Just erase all the stuff about object dimensions and offsets, etc. since we're
only working with a single point.}
I propose a new format for the scene - have three independent code blocks,
chosen with a switch/case/break/end block.
0. The current Norbert Kern / Kenneth Walker code
1. a method which is a simple extension of screen.inc object placement
2. a method which uses a matrix
In this way they can be wrapped in a loop and executed sequentially in the same
scene run, to compare the results of the different methods of calculation.
I'm suggesting this because working it out by method 1 ought to help unravel
what's going on with method 0, and method 2 will just be points for style :)
I have to do a bunch of IRL stuff today - but hopefully I will be able to return
to this in the near future and have some code snippets of my own to offer.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30-9-2018 15:33, Bald Eagle wrote:
> I have actually had a little bit of time to look at this code in more detail and
> shift it over to my camera view frustum scene --- whereupon it doesn't see the
> SURFACE unless the plane is included, and then that's the only thing it sees...
???
>
> But I do agree, after back-tracking through the code, that dir_xy, which is used
> in the trace () call has a high probability of being the culprit.
>
> Having said that, the whole manner in which this macro works with vaxis_rotate
> is a bit hard to follow, and it may be easier to start from first principles.
>
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.
>
> I think that if you look at the screen.inc code, you'll see that all you're
> doing is using normalized coordinates in screen space.
> If you just extend that vector, you "reach out" into the scene past z=1.
> (assuming a default camera)
> This ought to be a matter of the same simple trig, with no hard-to-follow (and
> verify by hand) rotating vectors around axes.
> So more than half the work is already done.
> {Just erase all the stuff about object dimensions and offsets, etc. since we're
> only working with a single point.}
This is a highly interesting suggestion! I don't know if I can manage it
but I am confident that Kenneth can. However, I am going to get my hands
dirty nonetheless.
>
> I propose a new format for the scene - have three independent code blocks,
> chosen with a switch/case/break/end block.
>
> 0. The current Norbert Kern / Kenneth Walker code
> 1. a method which is a simple extension of screen.inc object placement
> 2. a method which uses a matrix
>
> In this way they can be wrapped in a loop and executed sequentially in the same
> scene run, to compare the results of the different methods of calculation.
>
Excellent suggestion.
> I'm suggesting this because working it out by method 1 ought to help unravel
> what's going on with method 0, and method 2 will just be points for style :)
>
> I have to do a bunch of IRL stuff today - but hopefully I will be able to return
> to this in the near future and have some code snippets of my own to offer.
>
Thanks again!
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
