POV-Ray : Newsgroups : povray.binaries.images : "Position Finder" results : Re: "Position Finder" results Server Time
20 Apr 2024 08:52:47 EDT (-0400)
  Re: "Position Finder" results  
From: Thomas de Groot
Date: 1 Oct 2018 02:52:40
Message: <5bb1c438$1@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.