Hello again.

I have a question regarding the calculation of pixel rates. My understanding is
that my clock values are equal divisions of my final frame value, so with that
in mind if I have a 720 or 1920 pixel wide image rendering and I want to move
my object one pixel/frame, then all I would need to do is make my final frame
equal to the pixel width and use my clock value as my one pixel/frame motion
value.
                 translate <clock,0,0>
BUT, what if I am not exactly <0,0,0> in my camera position, and view? How can I
calculate how much my clock is moving an object? Are there any other ways to do
this?

Post a reply to this message

"RC" <nomail@nomail> wrote:
> My understanding is
> that my clock values are equal divisions of my final frame value,

Yes, that is right.

> so with that
> in mind if I have a 720 or 1920 pixel wide image rendering and I want to move
> my object one pixel/frame, then all I would need to do is make my final frame
> equal to the pixel width and use my clock value as my one pixel/frame motion
> value.
>                  translate <clock,0,0>

Actually this is the wrong math already. It only holds true if your camera
happens to be 1.0 POV units away from the object's trajectory with an opening
angle of 90 degrees - or a suitable other distance if the opening angle is
different.

> BUT, what if I am not exactly <0,0,0> in my camera position, and view? How can I
> calculate how much my clock is moving an object? Are there any other ways to do
> this?

Simple advice: Try to get away from pixel-based thinking. It's almost never the
natural units to work with in POV, and it's incompatible with changes of the
image resolution.

As for the math: With the most common camera settings

  camera {
    perspective
    location  MyCameraLocation
    right     x*image_width/image_height
    up        y
    direction z
    look_at   MyObjectLocation
    angle     MyCameraAngle
  }

you can convert from POV units and vice versa using the following formulae (see
diagram in section 3.3.1.1 "Placing the Camera" of POV's online help):

  (1) tan(MyCameraAngle/2) * unitDistance = 0.5
  or  unitDistance = 0.5 / tan(MyCameraAngle/2)

  (2) pixels / image_width = size / (distance/unitDistance)
  or  pixels = image_width * size / (distance/unitDistance)
  or  size = (pixels/image_width) * (distance/unitDistance)

Formula (1) describes the distance at which 1 POV unit will appear to be equal
to the image width, while (2) describes the relation between size in pixels and
size in POV units.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "RC" <nomail@nomail> wrote:
> > My understanding is
> > that my clock values are equal divisions of my final frame value,
>
> Yes, that is right.
>
> > so with that
> > in mind if I have a 720 or 1920 pixel wide image rendering and I want to move
> > my object one pixel/frame, then all I would need to do is make my final frame
> > equal to the pixel width and use my clock value as my one pixel/frame motion
> > value.
> >                  translate <clock,0,0>
>
> Actually this is the wrong math already. It only holds true if your camera
> happens to be 1.0 POV units away from the object's trajectory with an opening
> angle of 90 degrees - or a suitable other distance if the opening angle is
> different.
>
> > BUT, what if I am not exactly <0,0,0> in my camera position, and view? How can I
> > calculate how much my clock is moving an object? Are there any other ways to do
> > this?
>
> Simple advice: Try to get away from pixel-based thinking. It's almost never the
> natural units to work with in POV, and it's incompatible with changes of the
> image resolution.
>
> As for the math: With the most common camera settings
>
>   camera {
>     perspective
>     location  MyCameraLocation
>     right     x*image_width/image_height
>     up        y
>     direction z
>     look_at   MyObjectLocation
>     angle     MyCameraAngle
>   }
>
> you can convert from POV units and vice versa using the following formulae (see
> diagram in section 3.3.1.1 "Placing the Camera" of POV's online help):
>
>   (1) tan(MyCameraAngle/2) * unitDistance = 0.5
>   or  unitDistance = 0.5 / tan(MyCameraAngle/2)
>
>   (2) pixels / image_width = size / (distance/unitDistance)
>   or  pixels = image_width * size / (distance/unitDistance)
>   or  size = (pixels/image_width) * (distance/unitDistance)
>
> Formula (1) describes the distance at which 1 POV unit will appear to be equal
> to the image width, while (2) describes the relation between size in pixels and
> size in POV units.

This is helpful thanks. I hate to admit it but so far to get this to work, I've
made marks with a dry erase marker on my LCDs to determine how far my objects
are moving between frames in front of a grid pattern. Ya, not so accurate...

Post a reply to this message

On Thu, 26 Feb 2009 16:22:52 EST, "RC" <nomail@nomail> wrote:

>
>This is helpful thanks. I hate to admit it but so far to get this to work, I've
>made marks with a dry erase marker on my LCDs to determine how far my objects
>are moving between frames in front of a grid pattern. Ya, not so accurate...

Christoph is right but you might consider using an orthographic camera if it
suits you annimation. See the help 3.3.1.2.2  Orthographic projection. 
-- 

Regards
     Stephen

Post a reply to this message

On Thu, 26 Feb 2009 21:49:30 +0000, Stephen <mcavoysAT@aolDOTcom> wrote:

>
>Christoph is right but you might consider using an orthographic camera if it
>suits you annimation. See the help 3.3.1.2.2  Orthographic projection. 

Oh! It might be an idea to use frame_number instead of the clock variable. I
find that it is easier in animations. You can do arithmetic with the variables
initial_frame and final_frame as well. See 3.2.1.3.5  Built-in Constants
-- 

Regards
     Stephen

Post a reply to this message

"RC" <nomail@nomail> wrote:
> This is helpful thanks. I hate to admit it but so far to get this to work, I've
> made marks with a dry erase marker on my LCDs to determine how far my objects
> are moving between frames in front of a grid pattern. Ya, not so accurate...

.... but definitely inventive :)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "RC" <nomail@nomail> wrote:
> > This is helpful thanks. I hate to admit it but so far to get this to work, I've
> > made marks with a dry erase marker on my LCDs to determine how far my objects
> > are moving between frames in front of a grid pattern. Ya, not so accurate...
>
> .... but definitely inventive :)

Ok, I think I got this working, but my object looks slightly squashed.
camera {
  location  <0, 0, -10>
  direction z
  up y
  right  x*image_width/image_height
  look_at   <0.0, 0.0,  0.0>
}
The render window looks right, but the output looks stretched?

Post a reply to this message

"RC" <nomail@nomail> wrote:
> "clipka" <nomail@nomail> wrote:
> > "RC" <nomail@nomail> wrote:
> > > This is helpful thanks. I hate to admit it but so far to get this to work, I've
> > > made marks with a dry erase marker on my LCDs to determine how far my objects
> > > are moving between frames in front of a grid pattern. Ya, not so accurate...
> >
> > .... but definitely inventive :)
>
> Ok, I think I got this working, but my object looks slightly squashed.
> camera {
>   location  <0, 0, -10>
>   direction z
>   up y
>   right  x*image_width/image_height
>   look_at   <0.0, 0.0,  0.0>
> }
> The render window looks right, but the output looks stretched?

Wow, ignore that last comment. Its always good to have your display set to 1:1.
Time for the weekend...

Post a reply to this message