Sideband #51: POV-Ray Cameras

camerasI’ve been mentioning, and even writing about, POV-Ray for a while now. It and I go back quite a few years, and — as with may of my long-time hobbies — it’s something I’ll pick up and get really into for a while.  Then, after some period, which varies considerably, I’ll exhaust my interest, and back it goes onto the shelf (which is not the same as onto the back burner).

This is the fourth or fifth time I’ve picked it up, but the first time I’ve really gotten into it. It’s been fun and very productive (all this retirement free time is awesome). I make no claim for being any good at creating mind-blowing scenes (but I’m working on it). I do, however, have a couple process tricks that have made my life easier, and I thought I’d share them.

This first one is about managing camera positions.


Let’s say you’re designing a life-sized baseball park…
[click of these any for big]

I can’t speak for other POV-Ray users, but I tend to want to move my camera around any scene I’m working on.

I have an impression that, when creating those expertly done mind-blowing scenes, one picks the “right” camera angle and sticks with it.

(The length it takes to render a scene is certainly one good reason to have the one angle.)

Incidentally, a terminology point: the phrases “camera angle” and “camera position” are generally synonymous here. Both refer to the camera’s position, what it’s pointing at and its angle of view.

In some very specific contexts, “camera angle” could refer to just the view angle (the “zoom” of the “lens”). In particular, POV-Ray camera objects have an angle attribute, so I just wanted to be sure it’s clear that I’ll usually mean the general sense!)


…there are many places you need to be able to inspect.

I think there may be a slight difference in purpose or types of POV-Ray scenes.

The mind-blowing ones I’ll call “Showcase” types.

The end goal is that “photo” that astonishes.

I’m more drawn to the objects and spaces themselves. I love being able to create and move around in a three-dimensional space. That’s the big draw for me.

This “The Studio” movie I’ve been working on for three months now is the culmination of goals I’ve had since day one. Seeing an MP4 movie animating a 3D model is a huge thrill!

The bad news is that it’s looking like it take a couple of years to render all the frames at max quality, so I may never see a fully completed movie.


Multiple fixed cameras facilitate development, but also create a snapshot gallery!

Here’s an example of why.

I’ve been puttering with Python and blogging, so I’ve let the POV engine run its ass off.

It’s clocked seven days, eight hours (and five minutes) of rendering. (That’s 24-hour days, of course.) In that time, it’s generated (ta da): 260 frames!

A full week of rendering, and it’s done 260 frames.

Some of them averaged over an hour-and-a-half apiece. The minimum seemed to be around 25 minutes per frame.

Here’s the thing: the segment I’ve asked it to animate has 1600 frames. My math says that’s going to take [scribble, scribble, scribble] exactly “a whole shitload” of time!

[I wonder if it’s possible to buy processing time. The POV engine does come on a variety of different platforms.]

Back to the point: I like me a lot of camera positions.


You need a view (or several) from inside the dugout!

Even if it’s a single object, I like to be able to see it from different angles, and with a complex object, I often want various close up angles on interesting parts.

With a large scene I like lots of camera positions that let me see it from many angles.

What happens is that, over the course of the project, I end up with dozens, sometimes many dozens, of camera angles I want to remember and reuse.

I’ve tried a number of approaches to make this as flexible, powerful and painless as possible.

An obvious starting point was using comments to hide the cameras not being used (leaving only the one needed). That was a simple trick, but one with major flaws. The biggest is that there’s no way to queue all camera angles for rendering. Another is that it gets very tedious constantly commenting and uncommenting.


You need to see it from the stands, of course!

Taking it to the next level, I tried using declared variables and #ifdef statements.

That gets it down to merely setting a #declare somewhere exposing the desired camera.

This is less tedious, but you still can’t queue all the cameras. (Actually you can, using what I’m about to show you, but I think you’ll like the full technique even better.)

An alternative to #ifdef statements uses the #switch and #case statements. I used that technique for a long time before I figured out this next one.

(I used all the above techniques at some point or other. The one I’m about to describe is my keeper!)

I start by creating an array:

#declare CameraMax = 50;
#declare CameraSet = array[CameraMax];

And then I populate it with cameras:

#declare CameraSet[0] = camera {…}
#declare CameraSet[1] = camera {…}
#declare CameraSet[2] = camera {…}
#declare CameraSet[3] = camera {…}
#declare CameraSet[4] = camera {…}

To render any given camera, I set a variable, called CameraIndex, to the desired array index. Here’s how I arrange that:

#ifndef (CameraIndex)
#declare CameraIndex = 0;
camera {CameraSet[CameraIndex]}

This sets the default camera to the one in array slot zero — what we’ll call Camera #0 from now on (and likewise with the other cameras in the other array slots). I use Camera #0 as I develop a scene; it’s my “working” camera.

When I stumble on camera angles I like enough to keep, I put them in one of the array slots.

Note that you can set CameraIndex in the POV code or in an INI file  using the Declare statement. (I’ll come back to that in a moment!)

The key to the working camera are these lines, placed in a convenient location:

#declare cam_pov = <+180, +5, 0>;
#declare cam_loc = cam_pov + <+10, +1, -25>;
#declare cam_ang = 60;

The camera in array slot zero (Camera #0) uses those three cam_ variables in its definition. This gives me a camera to move about easily.

The actual definition of Camera #0 looks like this:

#declare CameraSet[0] = camera {angle cam_ang location cam_loc look_at cam_pov}

(I didn’t show the full definition above due to the line wrapping.)

There is a consideration that might cause you to implement this slightly differently.

If you render the file without declaring which camera to use, the default is Camera #0. Since that’s the working camera, this means the file’s default image will always be whatever you last set Camera #0 to be.


Getting far back from the 300 Posts Trophy ruins the effect!

You might like having the default image be something specific, the “showplace” angle that really shows off the scene, for example.

Do this by simply setting the default CameraIndex to your desired camera position.

Alternately, you can rig this so the working camera is a different camera than zero.

Either way, you’ll now need to pick your working camera explicitly, but when you render your POV file by itself, it’ll render the preferred image.

A big goal is being able to queue all cameras for mass rendering, and we’ll do that through POV INI (initialization) files. These INI files also let us render any camera easily.

You could design your entire scene in INC files (or even POV) files, #include those in a series of “camera” POV files, each with just a separate camera set up. Then you just render the POV files you want.

For all I know, that’s how some do it, and I can’t see anything wrong with the technique.


Getting up close, but looking “off stage” also not good!

I went with a set of INI files.

I like being able to manage my camera positions in one place, for one thing (in the cameras array).

Also, as you’ll see, the ‘large collection of files’ thing becomes trivial using this technique. (In fact, I have a Python script that spits out as many as I need.)

I start by creating CAM.INI, which first (at the top) contains all my default settings and any Declare statements necessary to my project. Then I create sections for each of my camera positions (lots of copy/paste).

It might end up looking something like this:




Now I already have one way of rendering any camera at will. I set POV to use this initialization file, and I set it up as “CAM[cam-22].INI” (for example, to render Camera #22).

Notice that under the individual camera sections you can tweak settings to configure a render for a specific camera.  I often have Camera #0 set to use lower quality render settings to speed up development time.

The final step is that you create as many “launch” INI files as you have cameras or sections in CAM.INI.  These launch files only need one line (the only part that varies is the part inside the brackets):

;; INI launch file for Camera 22″


I tuck CAM.INI and all the launch INI files away in a sub-folder (which I call “cam”) off my project folder. This keeps my project folder uncluttered.  I may have 60+ launch files, plus CAM.INI, in the cam folder, so it’s nice to have them out of the way.

To Queue them all, just add’m to the Queue. To work on one, just use the appropriate INI file.  I’ve been converting all my projects over to this technique. It works great for me!

About Wyrd Smythe

The canonical fool on the hill watching the sunset and the rotation of the planet and thinking what he imagines are large thoughts. View all posts by Wyrd Smythe

3 responses to “Sideband #51: POV-Ray Cameras

  • bronxboy55

    I knew you were smarter than me, but man. If I ever figure out what a movie is, I’m hiring you to do the camera angles.

    • Wyrd Smythe

      Heh, deal! I always wanted to be discovered and hired by Hollywood (you are Hollywood, right?).

      All seriousness aside, it’s a nice thing you say, Amigo, but there’s a funny reality there. To me the smart ones are the ones who can turn to their loved one at some point today and have an idle discussion about tonight’s dinner or what TV show it might be fun to watch. They’ve all mastered something that’s eluded me all my life (despite pursing it all my life).

      What I have… sometimes seems like some sort of weird consolation prize from the universe. “Here. Your life is going to be mostly outside the human race, and very few will ever really take to you,.. BUT at least you’ll always be able to find work, and you’ll always find amusement inside your own head. Enjoy!”

      The ‘always able to find work’ part was pretty nice (even if there were some threatening times, in fact no threats ever came to pass in that area), but there are lots of times when I would have traded it all for a more normal life.

      I get the feeling some gypsy way back in my earliest days must have flung at me the curse, “May you live in interesting times.” Turned out to be a powerful and accurate curse!

  • 2023: Now What? | Logos con carne

    […] a good start on) the model of my own place (interior only), but I doubt I’ll ever finish that baseball park or theatre building. Or improve my […]

And what do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: