See my latest post in p.t.general. The yellow rod is situated about -200 
pov units from the trace arrow.

-- 
Thomas

Post a reply to this message

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

Preview of image 'islaytest.png'

Thomas de Groot <tho### [at] degrootorg> wrote:
> See my latest post in p.t.general. The yellow rod is situated about -200
> pov units from the trace arrow.
>

I got side-tracked by a surprising and different problem, concerning your test
image. I rendered the same view (as close as I could get-- using CamAng of 80),
and found that you and I are indeed getting different results(!) I have no idea
what the reason might be. My 2nd 'blended' image shows that we are at least
rendering the same view, and with the yellow rod in the same place. Why our red
arrows don't match is a mystery! Very strange. (Unless we are somehow using
different methodologies?? I doubt that, though.)

For the yellow rod in the position it's currently in, did you get the same
screen_x_position and screen_y_position values that I did (or nearly so)?

This is a mystery that we definitely need to solve ;-)

Post a reply to this message

Attachments:
Download 'islaytest_1_kw.jpg' (388 KB)

Preview of image 'islaytest_1_kw.jpg'

On 28-9-2018 11:51, Kenneth wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> See my latest post in p.t.general. The yellow rod is situated about -200
>> pov units from the trace arrow.
>>
> 
> I got side-tracked by a surprising and different problem, concerning your test
> image. I rendered the same view (as close as I could get-- using CamAng of 80),
> and found that you and I are indeed getting different results(!) I have no idea
> what the reason might be. My 2nd 'blended' image shows that we are at least
> rendering the same view, and with the yellow rod in the same place. Why our red
> arrows don't match is a mystery! Very strange. (Unless we are somehow using
> different methodologies?? I doubt that, though.)
> 
> For the yellow rod in the position it's currently in, did you get the same
> screen_x_position and screen_y_position values that I did (or nearly so)?
> 
> This is a mystery that we definitely need to solve ;-)
> 
> 

My bad, as I misplaced the rod by one square :-/

The yellow rod is placed at: <202, 884> (screen percent) ==> <-2479.693, 
-265.968, -1757.000> (forget the Y which is not relevant here)

At <202, 884> percent, I get an arrow position of: <-2479.693, -265.968, 
-1627.254>

I have a hunch that you will get about the same. Forget about the 200 
pov units. It is less and not so 'rounded' as I thought (about 130 instead).

-- 
Thomas

Post a reply to this message

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

At some point, I hope to find a good solution to the arrow-offset problem
itself.

Post a reply to this message

Attachments:
Download 'islaytest_2_kw.jpg' (199 KB)

Preview of image 'islaytest_2_kw.jpg'

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.

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