I’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.
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!)
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.
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.
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.
Taking it to the next level, I tried using declared variables and
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
#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:
And then I populate it with cameras:
To render any given camera, I set a variable, called
CameraIndex, to the desired array index. Here’s how I arrange that:
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:
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:
(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.
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.
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):
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!