POV-Ray : Newsgroups : povray.bugreports : sphere slicing problem : Re: sphere slicing problem Server Time
2 May 2024 06:26:47 EDT (-0400)
  Re: sphere slicing problem  
From: jr
Date: 3 Nov 2019 09:00:01
Message: <web.5dbedc9e401c5809feeb22ff0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/1/19 1:39 PM, William F Pokorny wrote:
> > On 11/1/19 10:16 AM, jr wrote:
> ...
> >>
> >> I now think that if, perhaps, there is a relatively simple and
> >> accurate way of
> >> calculating camera parameters for both camera types such that the
> >> object is seen
> >> in exactly the same size/position, perhaps one could merge the
> >> results.  any
> >> thought(s) welcome.
> >
> > Maybe...
> ...
>
> Woke up this morning with a thought.

:-)

> If you're willing to render each
> sample as three frames your idea might fly using two perspective cameras.
> While in general using whatever you are using set up wise for best
> results:
> Using a perspective camera down in the first frame of a sample; A
> perspective camera up in the second frame of a sample; In the last frame
> use the results of the of the first two sample frames for planar
> pigments which themselves would be used in a user defined pigment
> applied to a plane with no lights but an ambient 1 finish and an
> orthographic camera.
> In frame 3/3 of each sample in the scan the user defined pigment would
> be something like:
> #declare PigmentMaxUpDownPerspective = pigment {
>      user_defined {
>          function { max(FnUp(x,y,z).r,FnDown(x,y,z).r) },
>          function { max(FnUp(x,y,z).g,FnDown(x,y,z).g) },
>          function { max(FnUp(x,y,z).b,FnDown(x,y,z).b) },
>          ,
>      }
> }

while I can see/appreciate the concept, I'll need to think about how to approach
this.  I have never used more than one camera at a time, for instance.  and then
there's the .. function voodoo.  :-)  FnUp/FnDown are what?  the contents of the
slice wrapped somehow in a function?

> There is planar-position distortion due the perspective camera. You
> would want to keep the angle small(1) to limit this.

the opposite to what I've been doing so far.  I use(d) the angle and location to
fine tune the shape to fill the frame.

> Further for each
> sample the up / down cameras should be equal distance to the middle of
> each sample's slice. In other words, the camera positions should be
> based upon the middle of each sample slice.

another thing different.  until now I have used the lowest point, but will
incorporate this as a first change.

> Aside: A user defined perspective camera simultaneously up and down an
> option too - say alternating rows at twice the vertical height - could
> be rendered in one frame. You'd have to be willing to scale down
> vertically only with some post render program/process.

open to ideas.  more function voodoo, I bet.  :-)

> Bill P.
> (1) - Small perspective camera angles will tend to work against you in
> being more parallel - more like the orthographic - some balancing
> required. Small perspective camera angles also require the camera be
> further away. So, I'll also mention there are accuracy issues especially
> with higher order polynomial shapes when the camera rays start far away.
> The accuracy issue is improved if you use my updated solver branch, but
> still significantly present. The sphere is essentially order 2, so with
> it your OK accuracy wise even at large distances away for the camera.

while I've never compiled a patched version of POV-Ray, I'm willing to give it a
try (with a little hand-holding).


regards, jr.


Post a reply to this message

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