لطفا منتظر باشید ...
Creating the Ray-Traced Die
To create the ray-traced die, I used the Moray modeler to create the die “scene.” The scene consists of a cube, the pips (the little white dots that make up the die’s numbers), one light source, and one camera. I also grouped all of the pips for a given die side into a group in the modeler so that I could move each “pip set” as a group. Figure B-1 shows a wireframe shot of the die in Moray.
Figure B-1: The die in the Moray modeler
Understanding Materials
Each surface in a POV-RAY scene is described with one or more materials. The material is what gives each object its color, reflectiveness, and other properties. The die required two materials—the red, semitransparent body of the die and abright white for the pips. After creating these materials in Moray and exporting them, their description in the POV-RAY language looks like Listing B-1.Listing B.1: POV-RAY Pip Definition
#declare Pips =
material // Pips
{
texture
{
pigment
{
color rgb <1.0, 1.0, 1.0>
}
finish
{
ambient 0.258967
brilliance 2.406
}
}
}
The syntax of the POV-RAY language is somewhat like C or a C-language variant, with curly braces surrounding all of the blocks. The #declare specification indicates that this material is being defined but not yet used anywhere.The material Pips is pure white, with ambient and brilliance values that make the white stand out quite a bit, even when a given side of the die is in shadow. I can’t tell you I was smart enough to know how to make the renderer work this way beforehand—I use a pure trial-and-error approach until my scene looks the way I want it to look. The material for the die body isn’t declared because it’s used in only one place, so its description lies within the die body object itself, as you’ll see next.
Setting the Camera and Light Source
When defining a scene in POV-RAY, you need at least one camera and one light source (a scene can technically have zero light sources, but then there would be no rays of light for the renderer to trace).
Listing B-2 shows the code that declares the camera and a single light source.Listing B.2: POV_RAY Camera and Light Source Declaration
camera { // Camera StdCam
location < -3.000, 3.000, 4.000>
sky < 0.00000, 0.00000, 1.00000>
up < 0.0, 0.0, 1.0>
right < 1.00000, 0.0, 0.0>
angle 39.60000
look_at < 0.000, 0.000, 0.000>
}
light_source { // Light001
<0.0, 0.0, 0.0>
color rgb <1.000, 1.000, 1.000>
translate <-18.754392, -0.401769, 61.307308>
}
The components of the camera declare its location in three-dimensional coordinate space (coordinate <-3, 3, 4> in this case), the orientation of the coordinate system used (which way is up), and where the camera is looking (at <0, 0, 0>).The light source is a point light off to one side and high above the scene. Note that the floating-point values within the translate clause are seemingly “random” because I was manipulating the location of the light visually by dragging it around within the Moray program. You also have the option of typing these values directly if you want more “rounded off” numbers.
Creating the Die Body
The body of the die is a simple cube, having a 1-unit size. You declare cubes in POV-RAY using the following box statement:
#declare Body =
box { <-1, -1, -1>, <1, 1, 1>
texture {
pigment { color rgbf <0.75, 0.0004, 0.0, 0.4> }
finish {
//phong 0.2
//phong_size 10
ambient 0.2
diffuse 0.8
}
}
}
Note that the material is built right into the definition of the box statement instead of using the #declare statement first and then using that material later. Each method is identical—the #declare statement makes it easy to reuse a material in multiple places and to have that material in a single place in case you want to play around with it.Note how I’ve commented out the phong and phong_size declarations. I did this after I was done designing the object in Moray. Moray is great for creating the initial layout of a scene, but it doesn’t allow you to use the full capabilities of the POV-RAY language. Because of this, I usually get the layout of the scene pretty close to perfect, do a final export, and then tweak the final script by hand. This final tweaking is necessary in the end to get the animation working. The only thing to keep in mind is that Moray can’t import these exported POV language files, you’ll have to repeat any changes you make to the POV-RAY code if you decide to go back into Moray to change something and then reexport it.
Creating the Pips
The location of the pips was another thing I wanted to tweak outside of Moray. The position of each pip (which is in reality a little cone embedded in the die body) had to be perfect or it would stick slightly out of the die body or lie too far within it, which would obscure the bright white color. To do this, I set up two variables in the script and then altered them by hand. The script in Listing B-3 shows these declared variables and two “pip groups.”Listing B.3: The Pips (Gladys Knight Not Included)
#declare PIPX=0.475;
#declare PIPZ=0.801;
#declare Twos = union {
cone { // Cone020
<0,0,0>, 0.0, <0,0,1>, 1.0
material {
Pips
}
scale 0.2
rotate <-180.0, -270.0, -180.0>
translate <0.0, -PIPX, PIPX>
}
cone { // Cone021
<0,0,0>, 0.0, <0,0,1>, 1.0
material {
Pips
}
scale 0.2
rotate <-180.0, 90.0, -180.0>
translate <0.0, PIPX, -PIPX>
}
translate PIPZ*x
}
#declare Threes = union {
cone { // Cone011
<0,0,0>, 0.0, <0,0,1>, 1.0
material {
Pips
}
scale 0.2
rotate -90.0*x
translate <PIPX, 0.0, -PIPX>
}
cone { // Cone010
<0,0,0>, 0.0, <0,0,1>, 1.0
material {
Pips
}
scale 0.2
rotate -90.0*x
}
cone { // Cone009
<0,0,0>, 0.0, <0,0,1>, 1.0
material {
Pips
}
scale 0.2
rotate -90.0*x
translate <-PIPX, 0.0, PIPX>
}
translate PIPZ*y
}
This excerpt shows the definition of two sides of the die—the two side and the three side. Each face is defined with a union structure, which is the POV-RAY equivalent of a “group” in Moray. By grouping pips together, you can move them as a unit.Each individual pip is a cone scaled down to 0.2 and rotated in some direction so that the flat side faces outward (the flat side is the side that shows up on the surface of the die). The PIPX variable specifies how far the pips are from the center of a face. Making this number smaller “bunches” the pips closer together on a face. The variable PIPZ moves the pips closer or farther away from the center of the cube. Making this number smaller places the pips inside the cube; making it larger extends the pips outside the boundary of the die body.By setting up these variables and then using them in the declaration of each pip, I was able to change their values in a single place and then rerender the die to see how it looked. I repeated this, oh, about a zillion times until the die looked the way I wanted it to look.Once again, note that all of the pip groups start with the keyword #declare. This means that a construct is being defined, but that construct isn’t being placed in the world yet. This is somewhat analogous to defining a class in Visual Basic .NET. A recipe for something is being declared, but the something isn’t being called into being yet. That happens next.
Declaring the Die Object
With all the components declared, it’s finally time to bring them into the scene. Listing B-4 is the declaration of the Die object.Listing B.4: Declaring the Die Object
union { // Die
object { Twos }
object { Fives }
object { Sixes }
object { Threes }
object { Fours }
cone { // PipOne
<0,0,0>, 0.0, <0,0,1>, 1.0
material {
Pips
}
scale 0.2
translate PIPZ*z
}
object {Body}
rotate <0,-clock*10-90,-clock*10>
}
The Die object is a union of the five declared “pip groups,” one additional pip that represents the one face (no sense putting a single pip in its own group), an instance of the Body object (the box), and one additional specifier to rotate the whole thing by some amount. The amount rotated depends on the special variable clock, which is actually passed into the script like a parameter from the renderer.
Rendering and Animating the Picture
By default, POV-RAY will render a single picture representing the scene described in the POV file, but my goal is to render 36 frames of the die as it rotates around. You can control animated frames, as well as a number of other rendering options, by editing values in an INI file. The following fragment shows a piece of the INI file used to render the dice animation frames:
Initial_Clock = 0
Final_Clock = 35
Width = 160
Height = 160
Input_File_Name = dice.pov
The values in this INI file give the name of the input POV file, the size of the output bitmap, and the number of frames to render. Other options within this file can control the type of output file (TIF vs. BMP vs. GIF), the type and amount of anti-aliasing to use, and whether to display the rendering as it happens within the POV-RAY program (turning off the preview will make complex scenes render faster).The Initial_Clock and Final_Clock values tell the renderer how many times to render the scene and what value to pass into the clock variable for each pass. Looking back at the definition of the die, you can see that the die object rotates along various axes by an amount of 10 degrees multiplied by the amount of the clock value. Because the clock value will loop from 0 to 35, the die will rotate from 0 degrees to 350 degrees in 36 frames. When these frames are displayed together, the die will appear to rotate through an entire 360-degree cycle.
