Pov Ray Tutorial 5h573o

color color area_light <side-1>, <side-2>, len-1, len-2 [adaptive adaptive value] [jitter] /* specifications for spotlight, if desired */ } Adaptive and jitter are both optional, and are covered in their own sections. side-1 and side-2 are <x, y, z> vectors describing the orientation of the sides. Since area lights are rectangular, these vectors should be perpendicular. Your light will not end up like you intended if they are at some weird angle. The lengths of these vectors correspond the lengths of the sides. len-1 and len-2 are the number of lights along the corresponding dimensions of the light. For example light_source { <0, 0, 0> color White area_light <2, 0, 0>, <0, 0, 2>, 6, 6 } This defines an area light centered at <0, 0, 0> in the x-z plane. The light is two units on a side and contains 36 point sources. The intensity of the light is divided evenly between the 36 points. Interesting shadow effects can be created with linear lights. A linear light is an area light that only has one light along one of its dimensions. This can be used to simulate fluorescent light bars. Here's a sample image using an area light instead of a point source. Note how the shadows get softer http://library.thinkquest.org/3285/language/light.html (2 of 8) [9/12/2001 3:17:36 PM]

The Online POV-Ray Tutorial: Lights

towards the top of the image.

For more information on declaring light sources, see the light source section.

Falloff The falloff keyword only applies to spotlights. The float parameter for falloff controls the angle at which the lighting from the spotlight goes to zero. This parameter should always be larger than the radius value and smaller than 180. Setting this to the same value as the radius of the hot spot gives the spotlight a hard (and rather unrealistic looking) edge. The larger the falloff value, the softer the edge. The tightness parameter can control exactly how the light falls off between the radius value and the falloff value. As with the radius keyword, the parameter for this keyword is the angle (in degrees) between the center of the hotspot and the edge of the lit area. The following images give examples of the falloff keyword. All three images use "radius 1.5". The first uses "falloff 1.5" (note the hard edge on the light), the second uses "falloff 2", and the third uses "falloff 3".

The falloff radius for a spotlight needs to be specified. For more information about declaring lights, see the light source section.

Jitter The jitter keyword only applies to area lights. This keyword is just a toggle, it takes no parameter. If you use jitter in an arealight, for each ray traced, the individual point sources in the light are moved a small http://library.thinkquest.org/3285/language/light.html (3 of 8) [9/12/2001 3:17:36 PM]


random amount. This creates smooth shadows that don't have bands of different intensity. This feature can be used to create nice, smooth shadows without gargantuan area light that take years to render. However, jitter is one of the few completely random features of POV-Ray (like crand) and will not be the same in two traces of the same scene. For this reason, using jitter in animations is probably a bad idea.

Light Source The light_source declaration allows you to declare various types of lights for your scenes. Light sources are what give your objects three dimensionality. It's possible to "light" a scene completely with ambient lighting, but this produces objects which look unexciting and rather two dimensional. Well placed light sources, in combination with good surface finishes well make your objects appear extremely lifelike. Four types of light sources can be defined. The most basic is the point source. This is a geometric point from which light rays eminate. Its only properties are its color and its position. The second type of light is a spotlight. Spotlights are basically point sources which only cast their light in certain directions. The third type of light is an area light. These lights are no longer simgle points, but rather arrays of lights which can be used to make more realistic shadows. The fourth type is a spot area light. This is just a directional area light. But anyway, here's the general form for a light source. light_source { /* these two are required */ color color-spec /* optional area light specifiers */ area_light <side-1>, <side-2>, len-1, len-2 adaptive adapt level jitter /* optional spotlight specifiers */ spotlight point_at radius hotspot radius falloff falloff radius tightness tightness /* misc. optional specifiers */ looks_like { object { obj } } } The two required components of a light source are its location and its color. All light sources must have http://library.thinkquest.org/3285/language/light.html (4 of 8) [9/12/2001 3:17:36 PM]


these defined. The location is a standard three component <x, y, z> vector. The color parameter is used to define the color of the light source (go figure). The usage of color is covered elsewhere. The spotlight specifiers are used to turn the light into a spotlight. Spotlights can be used to emphasize parts of a scene, or just to light things selectively. The area light specifiers change the light from a zero dimensional object into a one or two dimensional object. They can be used to create objects that have soft-edged shadows, instead of the hard, well defined edges produced by point lights. They can be used in conjunction with spotlights to confine the soft shadow calculations to a certain area of the scene. The looks_like parameter is just sort of weird. It can be used to assign a "shape" to the light. THe object specified is automatically translated to the location of the light source and has the no shadow keyword set. The source for the various sample scenes shown in this section will give numerous examples of the different types of light sources.

Looks Like The looks_like parameter can be used to assign a shape to a light source. Normally, individual light sources are just invisible points which radiate light. This applies to area lights, too, as they are just collections of points sources. Any object may put in the looks_like field. Note that the object will be automatically translated to the location of the light source. Also, the object is automatically set to not cast a shadow (see no_shadow). If this were not done, the light source object would not let any of the light that was on the inside out. This would be bad. If you want the associated object to cast a shadow, you can include the light source in a union. Here's an example of "looks_like". light_source { <50, 50, -50> color White looks_like { sphere { <0, 0, 0>, 0.5 pigment { color rgb <0.8, 0.8, 1> } } } } Note how the sphere is created at the origin. Again, this is because it will be automatically translated to the light_source's location. Declaring the sphere's center to be at <50, 50, -50> would result in the sphere being moved again (and ending up at <100, 100, -100>). For more information on declaring light sources, see the light source section.

http://library.thinkquest.org/3285/language/light.html (5 of 8) [9/12/2001 3:17:36 PM]


Point At The point_at keyword is a required specifier for spotlights. It declares the point at which you wish the light source to point (it's similar to look_at for cameras). This parameter is used to orient the light; all in all, it's pretty intuitive. Enjoy some sample images. The first pointed at <0, 0, 0>, the second at <0, 10, 0>.

For information on declaring light sources, see the light source section.

Radius Radius is used to specify the size of the central highlight in a spotlight. It must be specified for all spotlights. The best way to think of a spotlight is as a cone of light originating from the light source. The parameter for radius is a float specifying the angle (in degrees) between the central axis of the cone, and the edge of the cone which defines the hot spot. This is similar to the parameter for falloff. The value for radius should always be less than the value for falloff. Here are some sample images for varying radii. The first has a radius of 0.75, the second 1.5, and the third 2.5.




Spotlight Spotlights allow you to specify directed lights. The default type of light source is a point that radiates light in all directions. A spotlight is a point that radiates light only in specified directions. You can turn any light into a spotlight by specifying the keyword "spotlight" in its declaration. Anyway, the following is the general syntax for a spotlight. light_source { radius radius falloff falloff radius [tightness tightness] } All of the above parameters have to be specified except for tightness, which is optional. A spotlight basically can be considered to be two coaxial cones of light. The inner cone is fully lit by the point source at the location. Its angular radius is specified by the "radius" keyword. The outer cone is the region in which light falls off from fully lit (at the radius angle) to unlit (at the angle specified for "falloff"). The tightness keyword can be used to control how the light falls off in the angles between radius and falloff radius. Although the POV-Ray authors say that your radius may be up to 180, in my experience, POV-Ray won't render any light beyond the 90-degree mark. Anyway, here's an example of a spotlight.

Note how only the regions around the "point_at" point are lit. The region is elliptical because the light is not shining straight down at the "point_at" point. For more information on declaring light sources, see the light source section.



Tightness Tightness is an optional modifier for spotlights. It controls how the light falls off the zero at the edge of the falloff radius. It also controls (to a much lesser extent) the falling off of light in the central hot spot. The default tightness is 10. Values can range to nearly zero (but zero itself is bad) for a very soft-edged spotlight, and up to 100 for a very tight edged spotlight. Here are some variations on tightness, rendered with "tightness 1", "tightness 10", and "tightness 100" respectively.


Reference Index

Top of Document

Beginning of the Tutorial

The Online POV-Ray Tutorial © 1996 The Online POV-Ray Tutorial ThinkQuest Team


http://library.thinkquest.org/3285/language/src/light.pov

#default { texture { finish { ambient 0 diffuse 1 } } } #declare sqrt2_2 = 0.707 #declare Light = light_source { <100, 100, -200> color rgb <1, 1, 1> } union { torus { 5, 0.5 rotate <90, 0, 0> } cylinder { <0, 0, 0>, <0, 10, 0>, 0.5 } pigment { color rgb <0.5, 0.5, 1> } } plane { y, 0 pigment { checker color rgb <0.75, 0, 0.75> color rgb <0.5, 0, 0.5> scale 3 } } light_source { Light } camera { location <-2, 16, -8> look_at <0, 5, 0> }

http://library.thinkquest.org/3285/language/src/light.pov [9/12/2001 3:17:40 PM]

http://library.thinkquest.org/3285/language/src/light1.pov

#default { texture { finish { ambient 0 diffuse 1 } } } #declare sqrt2_2 = 0.707 #declare Light = light_source { <100, 100, -200> color rgb <1, 1, 1> area_light <0, 30, 0>, <30*sqrt2_2, 0, 30*sqrt2_2>, 8, 8 adaptive 2 jitter } union { torus { 5, 0.5 rotate <90, 0, 0> } cylinder { <0, 0, 0>, <0, 10, 0>, 0.5 } pigment { color rgb <0.5, 0.5, 1> } } plane { y, 0 pigment { checker color rgb <0.75, 0, 0.75> color rgb <0.5, 0, 0.5> scale 3 } } light_source { Light } camera { location <-2, 16, -8> look_at <0, 5, 0> }

http://library.thinkquest.org/3285/language/src/light1.pov [9/12/2001 3:17:41 PM]


#default { texture { finish { ambient 0 diffuse 1 } } } #declare sqrt2_2 = 0.707 #declare Light = light_source { <100, 100, -200> color rgb <1, 1, 1> spotlight point_at <0, 0, 0> radius 1.5 falloff 1.5 } union { torus { 5, 0.5 rotate <90, 0, 0> } cylinder { <0, 0, 0>, <0, 10, 0>, 0.5 } pigment { color rgb <0.5, 0.5, 1> } } plane { y, 0 pigment { checker color rgb <0.75, 0, 0.75> color rgb <0.5, 0, 0.5> scale 3 } } light_source { Light } camera { location <-2, 16, -8> look_at <0, 5, 0> }



#default { texture { finish { ambient 0 diffuse 1 } } } #declare sqrt2_2 = 0.707 #declare Light = light_source { <100, 100, -200> color rgb <1, 1, 1> spotlight point_at <0, 0, 0> radius 1.5 falloff 2 } union { torus { 5, 0.5 rotate <90, 0, 0> } cylinder { <0, 0, 0>, <0, 10, 0>, 0.5 } pigment { color rgb <0.5, 0.5, 1> } } plane { y, 0 pigment { checker color rgb <0.75, 0, 0.75> color rgb <0.5, 0, 0.5> scale 3 } } light_source { Light } camera { location <-2, 16, -8> look_at <0, 5, 0> }



#default { texture { finish { ambient 0 diffuse 1 } } } #declare sqrt2_2 = 0.707 #declare Light = light_source { <100, 100, -200> color rgb <1, 1, 1> spotlight point_at <0, 0, 0> radius 1.5 falloff 3 } union { torus { 5, 0.5 rotate <90, 0, 0> } cylinder { <0, 0, 0>, <0, 10, 0>, 0.5 } pigment { color rgb <0.5, 0.5, 1> } } plane { y, 0 pigment { checker color rgb <0.75, 0, 0.75> color rgb <0.5, 0, 0.5> scale 3 } } light_source { Light } camera { location <-2, 16, -8> look_at <0, 5, 0> }


The Online POV-Ray Tutorial: Finish Reference

The Online POV-Ray Tutorial Finish Reference The topics covered in this section are the following ● Ambient ●

Brilliance

●

Crand

●

Diffuse

●

Finish

●

Ior

●

Metallic

●

Phong

●

Phong Size

●

Reflection

●

Refraction

●

Roughness

●

Specular

Here's the basic test scene used to render the examples. For comparison, this one uses only the default finishes.

All images in this page are links to the scene file that generated them.

Ambient Them ambient finish controls how much of the color of a surface comes from ambient lighting. Its parameter is a float value in the range 0.0 to 1.0 (typically). Ambient light is light in a scene that comes from no specific source. It's used to adequately model light that bounces off of objects. This light cannot be efficiently modelled by raytracing due to the "backward" nature of tracing rays. POV-Ray cheats by http://library.thinkquest.org/3285/language/finish.html (1 of 9) [9/12/2001 3:18:47 PM]


instead just mixing in a little bit of white to every pigment. The ambient value of an object controls how much white is mixed in. The default value is 0.1. A value of 0.0 means that objects that are not directly lighted will be completely black. Low values mean that objects which are not directly lit will retain some of their color. Higher values can make an object appear to glow (although it will not actually emit any light). The images below show basically how ambient lighting works. The first is the default, the second is rendered with ambient 0.6.

For more information about declaring finishes, see the finish section.

Brilliance Brilliance modifies the behavior of diffuse lighting. Brilliance takes a float parameter which modifies how diffuse light bounces off an object. The default value is 1.0. The way diffuse lighting works is by calculating the angle between the surface and the incoming light ray. The flatter this angle is, the less the surface is illuminated. Higher brilliance values make the light illuminate less at flat angles. This can make the object appear more polished or metallic. Values that are less than one cause the light to illuminate more at low angles, giving the surface a somewhat softer and less smooth feel. The first image below was rendered with the default, the second with brillance 5, and the third with brilliance 0.2.


http://library.thinkquest.org/3285/language/finish.html (2 of 9) [9/12/2001 3:18:47 PM]


Crand Crand can be used to simulate very rough surfaces like concrete and sand which have grainy surfaces. Crand works by randomly darkening pixels of the object to create a grainy shadow effect. Crand takes a float parameter from 0.0 to 1.0. The default is 0.0. Usually you shouldn't need more than very low values (such as 0.1). Higher values result in your objects turning into random pixel messes. Crand has some interesting features which can make it somewhat intractable, though. First off, because it's applied to pixels and not to objects, it looks the same on large objects as on small. It also changes when you change the resolution of the image. Finally, crand is one of the few completely random features in POV-Ray, which means that you should not use crand in animations, unless you want your objects to look like static. Anyway, the first image is again the default, while the second has crand 0.1 thrown in.


Diffuse The diffuse lighting model is the main way objects are lit. By default most of the coloring of an object comes from diffuse lighting. Diffuse light is basically light that comes from a light source and diffuses in all directions. It illuminates objects by striking them directly. Any object which does not have a direct, unblocked line to a light source will not be lit by diffuse lighting and will have to be lit by other models (ambient, for example). Light that directly lights a surface does so as a function of the angle at which it hits the surface. A surface which has the light source directly overhead will appear brighter than a surface which is lit from a very low angle. This angle effect can be modified to some extent by the brilliance keyword. The diffuse keyword takes a float parameter which expresses how much of an object's color comes from direct (diffuse) lighting. The value can range from 0.0 (no light from light sources) to 1.0 (very well lit). The default value is 0.6. Here are a few sample images for your viewing (and understanding) pleasure. The first is the default, the second has diffuse 0.3, and the third has diffuse 0.9.



For more information on declaring finishes, see the finish section which, conveniently, is next.

Finish The finish statement is used to define how objects interact with light. Specifying a finish for an object allows you to make the object mirrored, appear polished, appear to glow, or any number of other things (if you're wondering, the above effects can be created through use of reflection, phong or specular, and ambient, respectively). But moving along, the general format for a finish declaration goes something like this finish { ambient ambient lighting brilliance brilliance crand crand amount diffuse diffuse lighting ior index of refraction metallic phong phong highlighting phong_size phong size reflection reflected light refraction refract toggle roughness roughness specular specular highlighting } All of the parameters for the finish specifiers are float values (except for metallic which takes no parameter). The individual sections have more specific information about each type of finish. But here are some general things to keep in mind. ● The sum of the values of ambient, diffuse, and reflection should be about 1.0. Much higher, and your colors will saturate and look flat. Much lower, and your colors will appear dark. ● Objects with reflection and refraction (actually, any object with a nonzero filter) will increase your rendering time. Reflection requires an extra ray to be traced to determine the reflected color, while with transparent objects, an extra ray must be traced to determine the color that is being filtered. http://library.thinkquest.org/3285/language/finish.html (4 of 9) [9/12/2001 3:18:47 PM]


You usually don't need both phong and specular highlights. ● The argument to refraction should be 1 or 0 only. Finishes can be declared like just about anything else. All the of the example finish images were rendered using delcared finishes. As finishes aren't based on absolute locations, transforming them doesn't make sense. ●

Ior This value controls the index of refraction for transparent objects which refract. See refraction.

Metallic The metallic keyword is a modifier for the phong and specular highlights. It basically means that the highlight on an object should be modified by the object's surface color, and not just determined solely from the color of the light source. Metallic takes no parameter; either it's there or it's not. This keyword will have no effect if there isn't either phong or specular highlighting on an object. See either of those topics for information on highlights. The following sample images will almost undoubtedly explain this better than I have. The first was rendered with phong highlighting without metallic, and the second is with metallic.

For more information on declaring finishes, see the finish section.

Phong The phong keyword creates a highlight on an object that is the color of the light source. This is done by comparing the angle you're looking at a surface to the angle at which the light is striking the surface. If these angles are opposite and approximately equal, the color of the light is mixed into the color of the object. This highlight is similar to the one created with specular. Typically, phong and specular highlights are not both used on the same object. Phong takes a float parameter which expresses how bright the highlight should be. A value of 1.0 (the max) causes a complete saturation of the light's color http://library.thinkquest.org/3285/language/finish.html (5 of 9) [9/12/2001 3:18:47 PM]


at the center of the highlight. Lesser values cause less complete saturations. The size of the highlight can be controlled with the phong_size parameter. These images will show exatly what phong highlights look like. Note that there is no highlight on the box because none of the faces are oriented to reflect the light into the camera. First image: no highlights, second image: phong 0.9

Note that this finish does not actually make the object relfective. For that, see the reflection keyword. If you're wondering, this lighting model was named for the person who devised it. For more information on declaring finishes, see the finish section.

Phong Size The phong_size parameter is a modifier for the phong finish. It takes a float parameter (greater than zero) which defines how large the phong highlight will be. Typical values range from 1 (pretty dull) to 250 (very shiny). The default is 40. Higher values make the highlight tighter, creating a surface which looks very polished. Low values spread the highlight out a lot and make the surface appear dull. The images below were rendered with "phong_size 40" (default), "phong_size 4", and "phong_size 180", respectively. All have "phong 0.9".

Note that the phong_size parameter is ignored if there isn't a phong finish. This parameter has a similar function to the roughness parameter for specular. For more information on declaring finishes, see the finish section.



Reflection The reflection finish gives an object a mirrored or partially mirrored surface. This object will then reflect other objects in the scene. This keyword takes a float parameter (between 0 and 1) which describes how much reflected color to mix in. A value of 0 turns off reflection for the object, a value of 1 gives the object a perfectly mirrored surface (almost). To get an absolutely perfect reflector, you also need to specify "ambient 0" and "diffuse 0" in your finish statement. This will turn off all other coloring for the object. Normally you don't need high reflection values on objects that aren't suppose to be mirrors. Even for surfaces that are glass, a reflection value of 0.1 is sufficient to make it look realistic. Another thing to keep in mind about reflecting objects is that they will take longer to render. For every ray that strikes a reflective object, another ray has to be traced to determine what the first surface reflects. This can really add up if you have a lot of reflective objects. If you start having problems with reflective surfaces being rendered as black, try modifying the max_trace_level. But anyway, here's an example of reflection. The first scene has no reflection, the second has reflection 0.3.

Note how even with this small amount of reflectance, the objects appear very reflective. Reflection tends to like quite nice with a some phong or specular thrown in. For more information on declaring finishes, see the finish section.

Refraction Refraction only has meaning on objects that have at least a little bit of transparency. Refraction is the bending of light rays as they into a more dense or less dense medium. As light does not go through opaque things, they don't refract. Without refraction, transparent objects look like colored air. The refraction keyword takes one of two parameters either 0 (disable refraction) or 1 (enable refraction). It is legal to specify in between values, but the POV-Ray authors strongly recommend against it. In their words, Values in between will darken the refracted light in ways that do not correspond to any physical property. Many POV-Ray scenes were created with intermediate refraction values before this "bug" was discovered so the "feature" has been maintained. A more appropriate way to reduce the brightness of refracted light is to change the "filter" value in the colors specified in the pigment statement. You should also be aware that specifying "refraction 1.0" does not make an object transparent. You need http://library.thinkquest.org/3285/language/finish.html (7 of 9) [9/12/2001 3:18:47 PM]


to use filter in your pigment to make an object transmit light. Now, specifying "refraction 1.0" alone does not change the way your object looks. It will still look amazingly like colored air. This is because the default ior (index of refraction) is the same as the surrounding empty space. The index of refraction describes how much light bends when it es into and out of an object. Ior values are positive, and typically greater than 1.0. Empty space is arbitrarily defined to have "ior 1.0" (the default in POV). You can change the ior of a refracting object with the "ior" keyword. Some examples of indices of refraction are "ior 1.000292" (air) "ior 1.33" (water), and "ior 1.5" (glass). For the following example images, the filter value of the objects was set to 1.0. The first image has no refraction, the second has "ior 1.5", and the third has "ior 2.0".


Roughness The roughness parameter controls the size of the highlight produced by the specular keyword. Typical values range from 1.0 (sand paper) to 0.0005 (polished glass). The default roughness is 0.05. High values give very a very soft, very large highlight. Small values give a very small, tight highlight. 0 is a very bad number for roughness. Roughness is to specular as phong_size is to phong. Here are some roughness examples. All use "specular 0.9". The first uses the default roughness, the second uses "roughness 0.75", the third "roughness 0.001".




Specular The specular finish is similar to phong, but this one is more accurate as far as physical laws are concerned. It produces a highlight on the object where the reflection of the light source would be if the object were reflective. This keyword takes a parameter between 0.0 and 1.0 which describes how much specular highlighting to use on an object. 0.0 (default) creates no highlight, while 1.0 creates a highlight which is completely saturated to the color of the light_source. The size of the highlight can be controlled (to some extent) with the roughness parameter. Here's what specular (0.9) looks like.

For more information on declaring finishes, see the finish section. Reference Index

Top of Document




http://library.thinkquest.org/3285/language/src/fin.pov

#declare Fin = finish { // just default } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/fin.pov [9/12/2001 3:18:51 PM]

http://library.thinkquest.org/3285/language/src/fin1.pov

#declare Fin = finish { ambient 0.6 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/fin1.pov [9/12/2001 3:18:53 PM]


#declare Fin = finish { brilliance 5 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { brilliance 0.2 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { crand 0.1 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { diffuse 0.3 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { diffuse 0.9 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }


The Online POV-Ray Tutorial: Language Stuff

The Online POV-Ray Tutorial POV-Ray Language Things This section covers POV-Ray directives, object transformations, and various miscellaneous features. These include ● Background ●

Clock

●

Comment

●

Declare

●

Default

●

Fog

●

Include

●

Max Intersections

●

Max Trace Level

●

Rotate

●

Scale

●

Transformations

●

Translate

●

Version

●

X, Y, and Z

Background The background statement allows you to change the background color of the image. Any rays which do not strike any objects are colored with the background color. This must be a solid color; fancy pigments and textures are not allowed. Also, Objects do not cast shadows on the background. All in all, the background will look positively flat, but it also requires no extra effort from the POV-Ray to change the background color. This effect sometimes be exactly what you need, other times it'll just make your scene look strange. The syntax for specifying the background is as follows. background { color color-spec } color-spec is any solid color, whether declared with a name or defined with rgb. Here are two example

http://library.thinkquest.org/3285/language/language.html (1 of 13) [9/12/2001 3:19:25 PM]


background statements. background { color Red } background { color rgb <0.3, 0.6, 0.7> } Note that you should only have one background statement in your scene file. If you want a textured background, try using a "sky sphere." This is a large sphere (radius of maybe 10000) on which you place a texture. Note that the texture will doubtless have to scaled up (by a factor oy maybe 5000. it depends on the texture). If you don't want objects to cast shadows on your sky sphere, include the following statements in the sky sphere's finish. finish { diffuse 0 ambient 0.7 } This will make your sphere look somewhat flat, too, but that may be the effect you want from your sky. As always, experiment with it until you get something you like.

Clock "clock" is a float whose value is controlled by the +K command-line parameter. You can use it to create simple animations with ease (although it won't help you with complex stuff). For example to make a simple animation of a sphere orbiting the origin, you might try this sphere { <5, 0, 0>, 1 rotate clock*y } Then you could render this scene with +K0, +K15, +K30, etc, to get your frames. This is much more convenient than modifying your scene file for each frame. The value of clock is 0 if no +K argument is given to POV-Ray.



Comment Comments are used to describe what you were thinking in English (or whatever language you speak). Commenting a scene makes it much easier to return in a week and modify it. Nothing's worse then having a scene that you can't do anything with because you can't figure out what you meant. Comments in POV-Ray follow the C++ syntax. By putting the characters "//" on a line, any characters after it (on that line) will be ignored. This kind of comment ends when the line does. You can also start a comment with "/*". Then, any and all characters will be ignored until POV-Ray sees a "*/" to end the comment. This kind of comment can stretch as many lines as it needs to; it won't end until a "*/" is read. Here are some examples of comments. /* following these line, there will be a sphere declaration just so you know */ sphere { <1000, 0, 0>, 10 pigment { color Red } rotate 45*y }

// rotate sphere into position

That code segment demonstrates both kinds of comments. Note that you can include //'s in /**/ comments without a problem. But including other /**/ comments inside a /**/ comment may or may not work. Take for example /* outer comment /* inner comment */ boogaboogabooga */ With this segment, the first */ encountered ends the comment. Thus the "boogaboogabooga" is (unsuccessfully) parsed by POV-Ray, which promptly generates an error. However, in some versions of POV-Ray, you are allowed to nest comments, so the previous example may not apply to you. Comments are also useful for when you're debugging a scene. If there's some object that's generating an error, but you don't know what it is, you can go through and comment out blocks of code. If the error goes away, you know that the code you just commented out was causing it.



#declare The declare directive is used to create object definitions without actually creating the objects. It can be used with floats and vectors to declare constants, or to declare pigments, finishes, textures, objects, or anything else in POV-Ray. Note that declare does not create a macro. To use, for example, a declared texture, you need to enclose the name in texture statement. Declares are incredibly useful for creating several duplicates of a very complex object. For example #declare Complex_Object = union { /* pages and pages of object code is omitted */ } object { Complex_Object } object { Complex_Object translate <5, 0, 0> } object { Complex_Object translate <-5, 0, 0> } Once an indentifier is declared, that identifier can be used anywhere in the scene after the declaration. You can also use declared things in other #declare statements. Note that declared names, as with everything else in POV-Ray are case sensitive. The POV-Ray authors recommend that your declared names should have some upper case letters in them to distiguish them from built in things, and to keep them from conflicting with reserved words. One thing to keep in mind about declared objects is that any texture statements inside the #declare will override any applied to the object outside the #declare. Take, for example, the following segment #declare Ack = 2 #declare Moo = 0.6 #declare Blue = color rgb <0, 0, 1> #declare Green = color rgb <0, 1, 0> #declare SomewhatBumpy = normal { bumps Moo } #declare Spheres = union { sphere { http://library.thinkquest.org/3285/language/language.html (4 of 13) [9/12/2001 3:19:25 PM]


<-1, 0, 0>, Ack pigment { color Green } } sphere { <1, 0, 0>, Ack } } object { Spheres pigment { color Blue } normal { SomewhatBumpy } } Note that #declares can be used to improve readability (as with Green and Blue) and to degrade readability (as with Ack and Moo). In some cases, it really does make more sense to just use the number. This will produce a smooth green sphere and a bumpy blue one. Note that the normal in the object statement won't apply to the green sphere, because the pigment carries an implied texture. This implied texture includes a normal statement which won't be overridden. The methods for declaring all the various types of things that you can declare (almost anything, as noted above) are covered in a great deal of depth in the POV-Ray documentation, so they won't be duplicated here.

#default The #default directive is used to modify the default texture for all the objects in a scene. For example, if you want to remove all the ambient lighting from everything in a scene, you could go to every object and add finish { ambient 0 } But this gets tedious for large scenes. Instead, you could just put the statement #default { finish { ambient 0 } } This tells POV-Ray to automatically include "ambient 0" in every object. You can also specify a default pigment (normally solid, flat black) or a default normal (normally flat). As another example, if you http://library.thinkquest.org/3285/language/language.html (5 of 13) [9/12/2001 3:19:25 PM]


wanted every object in a scene to be heavily dented and red (unless you specified otherwise in the object declaration), you could do #default { pigment { color rgb <1, 0, 0> } normal { dents 1.0 } } The #default directive is basically just a time saver. It saves you from having to type or block copy the same thing over and over and over and . . . well, you get the idea.

Fog The fog statement allows you to add fog of any color and density to your scene. POV-Ray models fog by calculating the distance to an intersection, and then mixing in the fog's color based on that distance (higher distance = more fog color). Computing fog is computationally cheap and can add a great deal of realism to a scene. The basic form for declaring fog is fog { color color-spec distance dist } color-spec is any solid color. Any filter component for the color will be ignored by POV-Ray. dist is a float specifying the distance at which the color will be 63% the fog color. The equation for calculating fog density is as below. depth is the distance to the intersection, and dist is the value specified above. fog density = 1 - exp(-depth / dist) The exp function raises e (2.718281828459...) to the power of its argument. So when depth and dist are the same, you get 1 - exp(-1) 1 - 0.3679 0.6321 which corresponds to 63% fog color. The other 37% of the color comes from the pigment of the object. Note that this function will never actually reach 100% fog color. However, at a depth of 3 * dist the color will be 95% fog. The value of the color being mixed with the fog at this point doesn't really matter. The value you specify for the fog distance should depend on the extent of your scene. To compare, here are two scenes, the first without fog, the second with some rather surreal bright blue fog thrown in.



#include The #include directive is used to include other scene files in the current one. The effect is exactly as if you had typed the contents of the file in at that location. The syntax is pretty simple, #include "filename" filename is the name of the file you want to include. The quotes are necessary. This is the best way to use the standard POV-Ray libraries. For example, there's an include, colors.inc, which contains a great many color declarations. To get access to them you just need to put #include "colors.inc" at the top of your file. Note that when you include a file with declares in it, the names which are declared are only accessible to things below the #include in your scene. The convention is to name files which are intended to be #included with the extension ".inc", but this is not required. Another thing you can do is easily group objects together. If, for example, you have a file with a large number of objects in it, and you want to group and use these objects as one in another scene, you could do union { #include "objects.inc" } It is legal for include files to include other files. POV-Ray will generate an error, though, if you go more than ten levels deep with nested includes. This shouldn't be a limitation. If it is, you need to rethink how you're putting your scene together.

#max_intersections The #max_intersections directive controls memory allocation for an internal data structure called "I-Stacks". These data structures are used to store information about object intersections while rendering



a scene. However, if you are rendering a particularly complex scene, these stacks can overflow, resulting in scene errors. If, in the POV-Ray status report (after the render) you see "I-Stack Overflows" listed with the statistics, you need to increase the value of this parameter. The default value is 64. Really, you just need to increase the value upward until all the "I-Stack Overflows" disappear. The POV-Ray authors recommend #max_intersections 200 if you start to have problems. Of course, you may need to go even higher if this doesn't fix your problem.

#max_trace_level The #max_trace_level directive controls how patient POV-Ray will be when rendering reflective or transmissive surfaces. The first ray sent out for each pixel is at trace level 0. If that intersects a reflective surface, another ray needs to be traced to determine what's being reflected. This new ray is at trace level 1. If that ray intersects another reflective surface, a third ray (now at trace level 2) needs to traced, and so on. The same holds with transmissive surfaces. Whenever a ray strikes a surface with a nonzero filter value, another ray needs to be traced to determine what color is being transmitted. The trace level goes up from there. The default #max_trace_level is 5. This means that if any ray running at trace level 5 intersects a reflective or transmissive surface, POV-Ray will give up and just return the color black. Thus, if you get reflective or transmissive surfaces which appear black when they shouldn't be, you probably need to up the max trace level. This is done by specifying, for example #max_trace_level 10 Note that there is no upper limit on the max trace level, but POV-Ray might crash if it runs out of memory while tracing reflective surfaces.

Rotate Rotate is a transformation which can be used to both change the orientation of a thing in space. This thing can be an object, a light, a camera, or a texture (or any component of a texture). The basic format for a rotation is rotate <x angle, y angle, z angle> The argument to rotate is a vector of rotation angles. Each of the components are floats which specify the angle (in degrees) to rotate around the corresponding axis. Any float value is valid for each of these, including zero. Note that when you rotate an object, you always rotate it around the axis. So anything which is not centered on the axis around which you are rotating will appear to orbit that axis. Note also that the http://library.thinkquest.org/3285/language/language.html (8 of 13) [9/12/2001 3:19:25 PM]


coordinate system in POV-Ray is left-handed. To determine which way is the positive direction around an axis, hold your left hand with the thumb sticking out in the positive direction of that axis. The direction your fingers curl when you close your hand is the direction of positive rotation. Also, the order of the rotations for a rotate statement is around x-axis, then around y-axis, then around z-axis. This makes a difference. For proof if this, see the three scenes below. The first shows a cone pointing in the +y direction. The second has the cone transformed by rotating first -90 degrees around the x-axis, then 90 degrees around the y-axis. The third has these two transformations reversed.

For more information about general transformations, see the transformations section.

Scale The scale transformation is used to change the size of objects. You can scale objects uniformly, or nonuniformly if you wish. You can also mirror-reverse objects. As with any other transformation, this can be used with any object, light, camera, or texture. The two general forms for a scale is scale scl scale <x-scl, y-scl, z-scl> The first form is for uniform scaling. It takes a float which specifies the factor by which to scale the object. The object is then scaled by that factor in all dimensions. The second form is for nonuniform scaling of objects. The parameter here is a three-coordinate vector specifying the scale factor in the x, y, and z directions respectively. Values greater than one for any of these values (uniform or nonuniform) will stretch the object, values less than one will squish the object, and negative values will reverse the object. Scaling on object by zero in any dimension is not legal. If you try, POV-Ray wil generate a warning and reset the offending component to 1. All scaling is with respect to the corresponding axis (nonuniform) or the origin (uniform). Thus the following object delcarations are the same. sphere { <0, 2, 0>, 1 scale 2 }



sphere { <0, 4, 0>, 2 } When you scale the first sphere, you not only double its radius, you also double the center's distance from the origin. This can generate problems when working with objects that are not at origin. If you have an object somewhere and you scale it and it disappears, it's most likely because it wasn't at the origin when it was scaled. That's just something to keep in mind. Another thing to keep in mind is the use of the x, y, and z vectors in a scale statement. This will often generate scale-by-zero warnings. Take, for example, the following object sphere { <0, 0, 0>, 4 scale 5*x } This will generate a warning, because the value of "x" is <1, 0, 0>. Hence, the value of 5*x is <5, 0, 0>. The zeros in that will annoy POV-Ray. For more information about transformations in general, see the transformations section. Conveniently, this is the next section.

Transformations The term "transformation" refers to rotatations, translations, and scales. Transformations can be applied to just about anything, including objects, lights, cameras, pigments, and normals. It doesn't make sense to transform finishes as the finish of an object doesn't depend on its absolute location in space (it does, however, depend on its location relative to other objects). Any number of transformations may be applied to an object (from here on I'll use the term "object" to refer to any of those things I listed above). The transformations will be applied to the object in the order they are listed. Note that any position and orientation of an object can be achieved with a scale, a rotation, and a translation (in that order). However, it's often easier to use somewhat more complex transformations to acheive certain effects. For example, the following two scenes look the same. However, the first was generated by specifying object locations explicitly, and the second by rotating them into those positions.



Both show cylinders at the corners of an equilateral triangle. However, the first one required some thought to position the cylinders, while the second one didn't (at least not as much). Also, in the second scene it's more obvious from the source exactly what's going on in the scene with those cylinders. The order of transformations does matter, particularly with translations. As an example, here's a simple scene. The first shows the object untransformed, the second shows it after a scale and a rotation, and the third after a rotation and a scale.

Note the rather striking differences in the second two scenes.

Objects, Textures, and Transformations When transforming an textured object, the behavior of the texture is fairly intuitive. Just that an object is modifed in the order that things appear in its declaration. The following two objects will not look the same. White_Marble is declared in "textures.inc". sphere { <0, 4, 0>, 1 rotate 90*z pigment { White_Marble } } sphere { <0, 4, 0> 1 pigment { White_Marble } rotate 90*z } This is because, in the first sphere, the object is rotated, and then the pigment is applied to the object's http://library.thinkquest.org/3285/language/language.html (11 of 13) [9/12/2001 3:19:25 PM]


surface. In the second, first the object is covered with the pigment, and then the object (and pigment) are rotated. To make the first sphere look like the second, you could add a "rotate 90*z" transformation to the pigment of the first sphere. This would transform the sphere, then transform the pigment the same way, and then apply the pigment to the sphere's surface. The same rules hold for all the other transformations. For a perhaps more basic description of transformations, see the Tutorial.

Translate Translate is a transformation which modifies the position of an object. You can use it to put any object anywhere in space. The basic form for translate is translate <x-dist, y-dist, z-dist> The argument is a three component vector specifying the distance to move the object in the x direction, y direction, and z direction, respectively. The components in the vectors are floats, and any value (positive, negative, or zero) is legal. The order in which the translations from one vector are applied doesn't matter, so you don't have to worry about explicitly specifying it.

Version and #version The #version directive is used for backwards compatibility with POV-Ray 1.0. Currently, the valid arguments for this directive are "1.0" and "2.0" (without the quotes). The default value is 2.0. This default can be changed with the +MV command-line parameter. Most of time you won't be using this directive, however, it can come in handy if you get some old POV-Ray code from somewhere. Along with the #version directive is the version variable. The value of this variable is either "1.0" or "2.0" and it corresponds to the version expected at this point in the file. The #version directive must appear outside of any and all other things (like object declarations, for example).

X, Y, and Z x, y, and z are built in vectors for convenience. Their values are <1, 0, 0>, <0, 1, 0>, and <0, 0, 1>, respectively. They're useful for specifying transformations, for example, the following pairs of statements are equivalent. translate <5, 0, 0> translate 5*x rotate <0, 80, 0> http://library.thinkquest.org/3285/language/language.html (12 of 13) [9/12/2001 3:19:25 PM]


rotate 80*y translate <4, 6, 0> translate 4*x + 6*y Reference Index

Top of Document

Main Page



The Online POV-Ray Tutorial: Pigment Reference

The Online POV-Ray Tutorial Pigment Reference Topics covered in this section ● Agate ●

Bozo

●

Checker

●

Color (Colour)

●

Color (Colour) Map

●

Frequency

●

Gradient

●

Granite

●

Hexagon

●

Image Map

●

Lambda

●

Leopard

●

Mandel

●

Marble

●

Octaves

●

Omega

●

Onion

●

Phase

●

Pigment

●

Quick Color (Colour)

●

Radial

●

Spotted

●

Turbulence

●

Wood

Note: all the sample images in this scene were rendered with the following color map (unless otherwise specified). color_map { [0.00 color [0.33 color [0.50 color [0.66 color

rgb rgb rgb rgb

<0.75, 0, 0>] <0.75, 0.75, 0>] <0, 0.75, 0>] <0, 0, 0.75>]

http://library.thinkquest.org/3285/language/pigment.html (1 of 16) [9/12/2001 3:21:07 PM]


[1.00 color rgb <0.75, 0, 0>] } This color map has very high contrast so the details of each pigment can be easily seen. Also, all the pigments were rendered without any turbulence (except for agate, which always is turbulent).

Agate The agate pigment is a very swirly, very turbulent pattern. It's similar to the marble pigment, except for its color look-up function and the fact that it is always very turbulent. The look-up function for the color map uses the colors from 0.0 to 1.0 and back down to 0.0 like marble, but instead of indexing the colors linearly it uses a sine wave. This results in the ends of the color map having more weight than the center. In general, the pigment looks something like this

Another thing to note about agate is the fact that the turbulence keyword has no effect on this pigment. Agate is always turbulent. The amount of turbulence can be controlled, to some extent, with the "agate_turb" keyword. This parameter takes a positive float value. For more information on declaring pigments, see the pigment section.

Bozo The bozo pigment is a very cool and very useful pattern. It basically creates a series of "splotches" on the object. Its color map indexing function uses the colors from 0 to 1 without reversing. The pigment basically works by asg random colors to integer points in space and interpolating the colors between those points. As a result, two points that are "close" tend to have colors that are fairly similar while points that are "distant" tend to have colors that are random with respect to each other. The notion of "close" and "distant" depends on the scaling of the pigment. The bozo pigment uses the same coloring function as spotted, but spotted is unaffected by turbulence. Here's what a bozo texture might look like . . .



For more information on declaring pigments, see the pigment section.

Checker The checker pigment creates cubes of color in space. The checker pigment doesn't color maps; you specify the two colors that are checkered. This differs from the standard pigment declaration, so here's the general template for using checker. pigment { checker color color-a color color-b } color-a and color-b are any two colors. The pigment creates a space filling pattern of colored unit cubes with the given colors. For example, the pigment pigment { checker color Red color Blue } would come out looking something like this

One thing to notice about the checker pigment is that it is automatically offset a little bit in each direction to prevent problems with coincident surfaces. This may produce undesirable color patterns as seen on the front face of the cube in the image. Like most other pigments, checker responds to the turbulence modifier. The pigment can be scaled nonuniformly to produce rectangular blocks of color as well. http://library.thinkquest.org/3285/language/pigment.html (3 of 16) [9/12/2001 3:21:07 PM]


Color The color pigment is used to assign monochromatic, flat colors to objects. It is also used in both the hexagon and checker pigments. The general form for this pigment is as follows: pigment { color color def } where color def is a color defined in one of the following ways color color color color

color name rgb rgbf red rval green gval blue bval filter fval

In the first style, color name is the name of a declared color. A great number of (very cool) prefined color names can be found in colors.inc. They can be accessed through the include directive. In the second style, an rgb color vector is specified for the color. The vector has three components, all floats between 0.0 and 1.0, where 0.0 represents no saturation of that color and 1.0 represents full saturation of that color. Here are a few examples color color color color

rgb rgb rgb rgb

<1, <0, <1, <0,

1, 1> 0, 0> 0.7, 0.7> 0.6, 0.9>

// // // //

white black pink greenish blue

The third color style is similar to the second style, except a filter value is specified to make the color partially transparent. color vec in this example is a four component vector, the first three components are the same as above, and fourth float, also between 0.0 and 1.0, specifying the amount of transparency. 1.0 is a surface that is fully transparent, less than 1.0 makes colors translucent, and 0.0 makes them opaque. Note that a color that filters es through colors in proportion to each color component. For example color rgbf <1, 1, 1, 1> color rgbf <1, 0, 0, 1> color rgbf <0.8, 0.8, 0.8, 0.4>

// perfectly transparent // like red cellophane // like frosted glass

Note that a declaration like "color rgbf <0, 0, 0, 1>" will produce a filter that is perfectly black (and hence perfectly opaque). Finally, the fourth method of specifying colors is a more verbose variation of color specification three. Each keyword (red, green, blue, and filter) is followed by a float (between 0 and 1) that specifies the corresponding component of that color. Note that these keywords may appear in any order and are all optional (except for the first one. One must be specified or POV-Ray will whine at you). Any components that are not specified will be assumed to be 0. These keywords can also be used to modify existing colors. Any components which have not been specified can be specified with these keywords. For example, these two declarations are the same



color Red filter 0.5 color rgbf <1, 0, 0, 0.5> For more examples of these kinds of color declarations see the standard POV-Ray file colors.inc. Here's a sample image that was rendered with the pigment pigment { color rgb <0.75, 0, 0> }

Note how the surface have no detail except for the sphere, which has a bit of shading. This is partially because of the flat pigment and partially because of the location of the light source.

Color Map Color maps are what give pigments life. The default color map is a blend of grays from black to white, and frankly, this is dull. Color maps give you the power to specify blends of color over the range of a pigment. The general format for declaring color maps is like this color_map { [0 color color spec [1 color color spec [2 color color spec /* there can be up to 20 }

0] 1] 2] colors in the map */

0 through n are floats in the range 0 to 1 that specify the location of a control point in the color map. For each control point, a color is specified. To get the color of a point in between control points, POV-Ray uses linear interpolation. Color maps must contain between 2 and 20 control points, but the value of each control point should be greater than or equal to the previous one. Here are some example color maps color_map { [0.0 color Red] [0.33 color Green] [0.67 color Blue] [1.0 color Red] }

// // // //

starts at red, then blends through green, blue, and back to red



color_map { [0.0 color [0.5 color [0.5 color [1.0 color }

// all colors from 0.0 to 0.5 are Yellow Yellow] Yellow] Blue] Blue]

color_map { [0.5 color Yellow] [0.5 color Blue] }

// then, at 0.5, there is a sharp change to blue // which is the color of the remainder of the map

// same as above, but harder to understand

color_map { // filters blend too [0.0 color Red] [0.5 color White filter 1] [1.0 color Blue] } Some things to keep in mind about color maps ● If the first control point is greater than 0, all the colors between zero and that control point will be that color ● Similarly, if the last control point is less than 1.0, all the colors between that control point and 1.0 will be that color ● If two colors are specified to have the same control point, there will be a sudden change between colors at that point. The color at that point will be the color that is specified latest ● If two control points have colors with different filter values, the filter values will be interpolated too, producing colors with intermediate transparency. There are a number of examples of color maps in the POV-Ray include file textures.inc.

Frequency The frequency modifier controls how many times the color map is used over the 0.0 to 1.0 range. The modifier takes a float which defines how the color map is stretched. Values greater than 1 compress the map, values less than 1 stretch it. Negative values will reverse it and (potentially) stretch it. 0 is a bad number. For example, the statement "frequency 2" will cause the color map to repeat twice over the range that would've repeated once. Here are two sample images. The first was rendered with the default "frequency 1", the second was rendered with "frequency 5", and the third was rendered with "frequency -1". All three images use the radial pigment pattern.



See pigment for information about the use of frequency.

Gradient The gradient pigment creats parallel planes of color. The orientation of those planes is controlled with gradient's parameter. The said parameter is an 3 component vector which descibes the normal of the planes of color (they all have the same normal as they are parallel). Note that the magnitude of the vector is unimportant, as long as it is nonzero. To control the width of the bands of color, use the frequency keyword. The gradient pigment is very similar to the marble pigment. The main difference is the color map look up functions. Gradient uses indexes the color map from 0 to 1 without reversing, while marble bounces back and forth from 0 to 1 and back to 0 again. This effect can be simulated with gradient with the proper color map and scaling. Another thing to note about the gradient pattern is that the color map reverses at 0. To get rid of this potentially undesirable boundary, you can translate the pigment along its normal vector until the boundary is off the object. Here are two sample gradient patterns, the first is rendered with "gradient x" and the second is rendered with "gradient <1, 1, 1>"

The first image shows the color map reversal at the origin, while the second was translated to remove this "feature." For more information about declaring pigments, see the pigment section.

Granite The granite pigment creates a sort of bozo-like pattern. Typically, you'll end up with pockets of color from one end of the color map surrounded by rivers of colors from the other end. With the proper color map it can look very convincingly like real granite. The sample color map used here doesn't really do it justice. For much, much, much better examples of the use of this pigment (with layered textures), see the include file stones.inc.



Granite uses the color map from 0 to 1, 0 to 1, etc, without reversing. Granite responds to turbulence, although it doesn't have any by default. For more information on declaring pigments, see the pigment section.

Hexagon The hexagon pigment is similar to the checker pigment. For this pigment, three colors are specified, and they are used to create a hexagonal pattern on the objects. The hexagon pattern is projected onto the x-z plane, and produces haxagonal "pillars" of color parallel to the y-axis. Rendered with the following pigment pigment { hexagon color rgb <0.75, 0, 0> color rgb <0, 0, 0.75> color rgb <0, 0.75, 0> scale 0.5 }

The pigment was scaled to give more detail about how the pigment works. For more information about declaring pigments, see the pigment section.

Image Map Image mapping a very powerful technique for producing specific color patterns on the surface of an object. It basically works by reading an image file and then projecting that image onto the object. The default mapping method is to project the image onto the x-y plane in such a way that it fits into the square (0, 0), (1, 1). The pixels of the original image are turned into infinitely long boxes that are parallel to the z-axis. Note that larger images http://library.thinkquest.org/3285/language/pigment.html (8 of 16) [9/12/2001 3:21:07 PM]


do not produce larger image maps, but rather image maps with better resolution. By default, the image map is repeated infinitely in the x and y directions. This can be changed with the once keyword. If you don't like the normal position of the image map, you can scale, rotate, and translate it to your heart's content. If you don't like the default projection style mapping, you can change it (to some extent) with the map_type modifier. But onward now, to the syntax for image maps image_map { type "filename" modifiers . . . } type is one of gif, tga, iff, or dump. This is followed by the filename (in quotes) which specifies the image file to be mapped. Here we have an example of an image being mapped onto a box. The first image is the image that was mapped, and the second is the resulting scene.

The modifiers following the file type are optional. They include the aforementioned once and map_type as well as a few others. One of these others is the interpolate keyword. Interpolation performs smoothing on the image as it is mapped. By default, POV-Ray takes the location of the ray intersection and assigns a pixel value to it. When the image map is scaled up a great deal or is of poor resolution initally, this can result in image maps that appear blocky or otherwise generally ugly. When interpolation is turned on, POV-Ray averages the values of surrounding pixels to determine intermediate values. This eliminates (for the most part) blockiness, but at the expense of tracing time. The interpolate keyword is followed by a number specifying the type of interpolation to be used. This number can be either 4 (for the Normalized Distance algorithm) or 2 (for the Bilinear algorithm). Normalized Distance is the faster algorithm, while Bilinear does a better job of picking intermediate colors. Here's an example of using the interpolate keyword pigment { image_map { gif "foobar.gif" interpolate 4 } } The last modifier accepted by image maps is filter values. By default, image maps are all opaque. The filter keyword can be used to change this. Filter can be used to modify specific colors, or to assign a filter value to the entire image map. Probably the best way to explain filter is through examples so here are a few



image_map { gif "zordo.gif" filter 0, 0.5 filter 2, 1.0 filter 7, 0.4 } image_map { gif "gurple.gif" filter all 0.8 } The first image map maps the image with the color specified by palette entry 0 (in the .GIF file) being 50% transparent. The color specified by palette entry 2 becomes 100% transparent. The color with palette entry 7 becomes 40% transparent (which should not be surprising at this point). See the section on color for an explanation of color filtering. Image maps also respond to turbulence, which can make for some very interesting effects. Image maps and color maps do not mix. For more information about declaring pigments, see the pigment section.

Lambda Lambda (besides being a greek letter) is a modifier for turbulence. The lambda parameter basically controls how random each step of turbulence is (see turbulence for a description). It takes a float parameter that must be greater than or equal to 1.0. Values of 1.0 produce very straight steps, while greater values produce steps with a greater randomness. The default lambda is 2. Note that specifying a lambda value only makes sense if you have turbulence.

Leopard The leopard pigment is similar to the bozo pigment, except for its regularness. The pigment is generated by basically setting the center of each unit cube in the space to the color at one end of the color map, and points on the edge of the cube to the color at the other end. The colors inside the cube are then blended between the two. Leopard uses the color map values from 0 to 1, 0 to 1 without reversing. Here's an example of a leopard pigment



The leopard pigment responds to turbulence, and it is said that very turbulent leopard pigments look like bozo pigments to some extent. For more information about declaring pigments, see the pigment section.

Mandel The mandel pigment creates a pattern that looks like the famous Mandelbrot set. Mandel one of the few pigments which take a parameter; that parameter is the number of iterations to compute when generating the pigment. The number of interations for each point to escape is used to color it according to the given color map. By default, the set is mapped onto the x-y plane in the standard range. As usual, the pigment can be scaled, rotated, and translated to fulfill your fondest Mandelbrot set dreams. Now we have an example of a mandel texture rendered with "mandel 50"

For more information on declaring textures, see the pigment section.

Marble The marble pigment is quite similar to the gradient x pigment, except for its color map look up function. Where gradient uses the colors from 0 to 1, 0 to 1 without reversing, the marble pigment blends from colors 0 to 1 in the range x=0 to x=0.5 and then back down to color 0 again in the range x=0.5 to x=1. Also, the marble pigment doesn't take a "normal" parameter; if you want the pattern to vary from the default y-z plane orientation, you'll need to rotate the pigment. By default, marble has no turbulence and is consequently rather boring. A turbulence value of 0.8 or 0.9, in combination with a good color map, can create very realistic looking stone textures. Here are two sample images of marble pigments, identical except for the turbulence. The first image has no turbulence, while the second has turbulence 0.8.




Octaves The octaves keyword is modifier for turbulence. It controls the number of steps taken by the turbulence function when it is generating turbulence. The parameter is the number of steps that should be taken by the turbulence function. It can range from 1 to 10. The default value is 6. As the length of each step decreases exponentially, an octaves value much higher than 6 won't change the scene much. It will change the rendering time, though, as the more steps there are to calculate, the longer POV-Ray will have to spend on each ray. Using a low number of octaves can produce a sort of wavy pattern on the surface. For a description of turbulence, see (naturally enough) turbulence. Note that specifying the number of octaves only makes sense if you have turbulence.

Omega Omega is yet another turbulence modifier. It controls the size of each step in the turbulence function. When generating turbulence, each step is omega times as long as the previous one. Normally omega values are between 0.0 and 1.0. The default value is 0.5, which means that each step is half as long as the previous. For a more in depth description of turbulence, see the turbulence section (go figure). Note that specifying an omega only makes sense if you have turbulence.

Onion The onion pigment creates concentric spheres of color centered at the origin. It uses the color map entries from 0 to 1, 0 to 1, without reversing. Here's a sample of the onion texture

Note that the sphere is entirely one color. This is because the pigment is centered at the enter of the sphere and so each point one the sphere lines up with the same color in the color map. For more information on declaring pigments, see the pigment section.

Phase The phase keyword is used to offset the color map It takes a float parameter between 0.0 and 1.0. The phase adjustment is always applied before any frequency adjustments, regardless of their order in the pigment



declaration. Note that adjusting the phase of a gradient pattern is the same as translating the pigment and adjusting the phase of a radial pigment is the same as rotating the pigment around the y-axis. By modifying the phase of a pigment you can create interesting effects in animations. For more information on the usage of phase, see pigment, which just happens to be the next section.

Pigment The pigment statement is how pigments (colors or patterns of colors) are assigned to objects. Pigments are what give the life to raytraced images. POV-Ray s a very wide array of pigment types, with an effectively infinite number of ways to al ter them to your needs. And if there still isn't something you want, you can also image mapping and even material mapping (image mapping with entire textures instead of just colors). Anyway, the general format for specifying a pigment is like this . . . pigment { // One of these is required pigment type color color /* OR */ image_map { /* image map specifications */ } // all the following are optional color_map { /* color map entries */ } frequency frequency lambda lambda val octaves number of octaves omega omega val phase phase quick_color color turbulence turbulence val or vec /* any transformations go here */ }

/* OR */

Any number of transformations (rotations, translations, and scales) may follow the pigment declaration, but must specified after the last pigment modifier. A pigment consists of three major parts, first the pigment type, then the color map, and finally the turbulence. The color map and the turbulence are optional. The first part, pigment type is one of the following: agate, bozo, checker, gradient, granite, hexagon, leopard, marble, mandel, onion, , or wood. See their individual sections for more specific information on each (as well as sample images). The second type of modifier is the color map. The specification of a color map is covered in some detail above. The two color map modifiers are frequency, which stretches or compresses the color map, and phase, which shifts the colors in the map.



The third part of the pigment is the turbulence specification. Turbulence is the "most optional" of the three parts. There are a number of pigments which will look fine without turbulence (such as bozo), and some which look rather lame without turbulence (such as marble) and even some which don't even respond to turbulence (such as spotted). Turbulence is basically used to mix up a pigment a little (or a lot). This can add life to a pigment. It can also make some pigments look weird. The modifiers lambda, octaves, and omega can be used to tweak the turbulence to achieve the exact effect you're looking for.

Quick Color Quick colors are used only when debugging scenes. The method for specifying quick colors is the same as for specifying normal colors. You can have a pigment and a quick color assigned to the same object. The only time POV-Ray uses quick colors is when you set the rendering quality to +Q5 or below. At +Q6 and above the normal pigment declaration is used. When rendering a +Q5 and below, any objects which are not already solid colors will be grayscaled. For example sphere { gradient x color_map { [0.0 color Red] [1.0 color Yellow] } turbulence 0.8 quick_color Aquamarine } will instruct POV-Ray to create a turbulent gradient pigment at +Q6 and above, and otherwise just color the sphere Aquamarine. You can use the quick_color modifier to distinguish two objects in a quick rendering. Note that giving an object a solid color pigment will automatically set the quick color to the same color. You can override this by explicitly specifying a quick color, though.

Radial The radial pigment takes the color map and wraps it clockwise around the y-axis, starting in the positive x direction. There's not much more to say about it, so here's a sample image which probably explains it better.

There are some more samples over with the frequency section. For more information on declaring pigments, see http://library.thinkquest.org/3285/language/pigment.html (14 of 16) [9/12/2001 3:21:08 PM]


the pigment section.

Spotted The spotted pigment is identical to the bozo pigment, except it doesn't respond to turbulence. See the bozo section for more information on it. The following image was rendered with the spotted pigment.


Turbulence Turbulence is used to mix up a pigment to some extent. The turbulence key word can take either a float or a three component vector as a parameter. For example turbulence 0.8 // stir up the pigment equally in all directions turbulence <0, 0.9, 0.3> // no turbulence in the x direction, a lot in // the y direction and a little in the z // direction turbulence x // major turbulence only in the x direction All of the numbers, whether individual floats or vector components, should be between 0.0 and 1.0 inclusive. High numbers mean lots of turbulence, low numbers mean only a little turbulence. Here's an example of what turbulence does. Both images use a marble pigment, but only the second was rendered with turbulence (turbulence 0.8, to be exact).

The way POV-Ray implements turbulence is quite interesting. In a normal pigment, POV-Ray simples determines the color of the pixel at each point on the surface of the object and colors the object with that. Turbulence works by taking a number of semi-random steps and using the color at the destination point. In essence, it constructs a pointer which says, "use that color over there." The "random" number generator used to http://library.thinkquest.org/3285/language/pigment.html (15 of 16) [9/12/2001 3:21:08 PM]


produce these steps is a function of original point. Hence, points that are near each other initially tend to end up with similar colors, while points that are distant tend to end up with random colors (with respect to each other). The "random" number generator is also deterministic, so rendering a scene file with turbulence will always result in the same image (good for creating animations). Here's a more in depth description of the turbulence function which will make its modifiers (lambda, octaves, and omega) make a little more sense. Turbulence works by first selecting a direction and moving so far that way. Then it picks a new direction and moves not-quite-as-far in that direction. Then it picks yet another direction and moves not-quite-not-quite-as-far in that direction. It uses a function called DNoise to generate these random steps. The overall magnitude of these steps is controlled by the parameter given to turbulence. Hence large amounts of turbulence create very large steps. The total number of steps taken is controlled by the octaves parameter. The default number of octaves is 6. This is a reasonable number and will do fine for most textures. Decreasing the number or octaves (to, say, 2) can create interesting effects. Increasing it will have only a marginal effect. This is because the length of each step falls off exponentially. The rate at which the step length falls off is determined by the omega value. Each subsequent step in the turbulence is omega times as long as the previous one. The default omega value is 0.5. Omegas are typically less than 1.0. High values or omega (0.8, 0.9, whatever) tend to make the turbulence more random, while low values (say, 0.1, 0.2) tend to smooth the pigment out a lot. The third modifier for turbulence is the lambda parameter. This controls the "randomness" of each step. Lambdas that are close to 1.0 cause each of the steps to be in approximately the same direction. Higher lambdas increase the randomness of the direction of each step. The default value is 2.0. Lambda should be greater than or equal to 1.0.

Wood The wood pigment creates concentric cylinders of color centered around the z-axis. To create pigments that acutally look like wood, stick with earth tones, rotate the pigment around the x-axis a few degrees, and add a small amount of turbulence. Here, looking very un-wood-like is a sample image.

For more information about declaring pigments, see the pigment section. Reference Index

Top of Document




http://library.thinkquest.org/3285/language/src/pig1.pov

#declare Pigm = pigment { agate color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/pig1.pov [9/12/2001 3:21:09 PM]


#declare Pigm = pigment { bozo color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { checker color rgb <1, 0.25, 0.25> color rgb <0.25, 0.25, 1> } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { color rgb <1, 0.25, 0.25> } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { radial color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { radial color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } frequency 5 } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { radial color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } frequency -1 } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { gradient x color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { gradient <1, 1, 1> color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } translate <10, 10, 10> } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }


The Online POV-Ray Tutorial: Texture

The Online POV-Ray Tutorial Texture The topics in this section are texture declarations which don't fit into any other category. ● Material Map ●

Texture

●

Tiles

Material Map Material maps are basically image maps, except you're wrapping patterns of textures around an object instead of patterns of solid colors. This kind of thing is useful for creating inlaid floors, for example. The basic syntax for a material map is like this texture { material_map { type "filename" /* modifiers */ texture { /* texture 0 */ } texture { /* texture 1 */ } /* as many textures as you need */ } /* any transformations */ } Here, type is one of gif, tga, iff, or dump. This specifies the type of image file being read. This is then followed by filename, in quotes. After the file, you specify any mapping modifiers (like once or map_type). Interpolation is ed for material maps, but it interpolates between textures, not between colors, and so will probably not have the desired effect. Anyway, for the indexed color type of image (gifs), the texture selected at a point is based on the palette index. For example, if a particular pixel is black, and the palette index of black is 4, then texture 4 will be used to color that point. Color 0 in the palette gets texture 0 in the list mapped onto it. Color 1 in the palette gets texture 1, and so on. If there are not enough textures in the list to assign a texture to a particular number, the indexing will wrap around back to the first texture. For example, if you list three textures, and have a Color 3 in your material map, it will get mapped back to texture 0. When material mapping rgb images, the value of the red byte for each pixel is used as the texture index. http://library.thinkquest.org/3285/language/texture.html (1 of 5) [9/12/2001 3:22:00 PM]


If you specify a material map, any and all texture declarations (pigment, finish, or normal) must appear in textures in the texture list. They cannot appear outside in the "main" texture declaration. For example, the following is illegal. texture { material_map { gif "inlaid.gif" texture { Text1 } texture { Text2 } texture { Text3 } texture { Text4 } } finish { ambient 0 } } If you want to do something like this, you must manually add the "ambient 0" to each texture statement in the list. Here's an example of a material map. The map is the first image, the rendered scene is the second.

Texture The texture statement is used to give an object a surface texture. Surface textures consist of a pigment, a finish, and a normal. Any of these can be left to the default. Usually finishes and normals are left until the fine-tuning stages of scene production, anyway. Any floating pigment, normal, or finish statement in an object is assumed to be enclosed in a texture block. For example, POV-Ray considers the following statements to be identical. In fact, if you use the first form, POV-Ray assumes you mean the second. sphere { <0, 0, 0>, 5 pigment { color Green } } sphere { <0, 0, 0>, 5

http://library.thinkquest.org/3285/language/texture.html (2 of 5) [9/12/2001 3:22:00 PM]


texture { pigment { color Green } } } Most of the different texture components are covered in their own sections. A very powerful technique in object texturing is that of layered textures. With layered textures, you cover an object with several overlapping textures. Presumably the upper textures have transparent parts to let the lower ones show through. This is down by specifying multiple textures for an object. It might look something like this. object { Something_To_Put_Layered_Textures_On texture { /* the first texture listed goes on the bottom */ Bottom_Layer } texture { /* a middle layer which is draped over the first */ Middle_Layer } texture { /* and finally, a top layer */ Top_Layer } } You may have as many textures in a layered texture declaration as you need. Layered textures allow you to vary the built in textures styles in an almost infinite number of ways. For a number of really awesome examples of layered textures, see the standard include file stones.inc. Here, layered textures are used to create some exceedingly realistic looking stone textures. As an example, here's a layered texture being constructed from the bottom up. This texture was sort of designed to look like a molten planet or a dying star, but it's up to your imagination. In the first image, there's just a base for the texture. Usually this isn't very complex as everything else will be on top of it, but you can do whatever you want. Here it's just a simple bozo.

Next some violent orange bands were added on top (using agate).



Finally, some random splotches of yellow were put on top (this was done with granite).

Although this particular texture may not be the best or most realistic texture, it's much more interesting than a standard one-layer texture.

Tiles Tiles are to textures what checker is to colors. The tiles texture uses two textures and creates alternating "blocks" of those textures. When used on a plane, this typically looks like squares of texture. With some creative rotation, you can do a lot more, too. Anyway, the general form for a tiled texture is like this texture { tiles { texture { Text1 } tile2 texture { Text2 } } } The keyword tile2 is a separator and must occur between the two texture declarations. Any transformations of the texture must appear either inside the individual textures (which are to be tiled) or outside the tiles block altogether. A tiled texture may be used as one of the textures in another tiled texture to create a double-tiled texture (but you'll have to scale the inner one down or it'll overlap exactly with the outer one). Anyway, here's an example of a tiled texture.



Here's a tiled texture with one of those aforementioned creative rotations.

Reference Index

Top of Document




The Online POV-Ray Tutorial: Modifiers

The Online POV-Ray Tutorial Modifiers The things in this file are used to modify the default behavior of certain objects. These modifiers include the following. ● Bounded By ●

Clipped By

●

Map Type

●

No Shadow

●

Once

●

Open

●

Sturm

Bounded By The only effect of bounding is to speed the rendering of a scene. Specifying a bounding object for another object tells POV-Ray the latter is entirely contained by the former. When rendering, POV-Ray first does any ray tests against the presumably simpler bounding object. If the ray does not intersect the bounding object, then POV-Ray assumes that it does not intersect the interior object either. POV-Ray then skips the potentially lengthy ray intersection tests with the interior object. If the ray does intersect the bounding object, POV-Ray then performs tests to see if the ray also intersects the interior object. Bounding objects do not affect the way the scene looks. Any object (except light sources) can be bounded, although bounding will show the most speed improvement when used with complex CSG or polynomial objects. Boxes and spheres make wonderful bounding objects as they are highly optimized, however, any object may be used to bound another. Note that POV-Ray has a limited ability to do automatic bounding. Most finite objects can be automatically bounded with a reasonable amount of efficiency. Unions can also be bounded fairly efficently. Things that cannot be automatically bounded are infinite objects, differences, intersections, or merges. Here's an example of the use of bounded_by. Really_Complex_Chair is presumed to be defined somewhere above this in the scene file. object { Really_Complex_Chair bounded_by { box {

http://library.thinkquest.org/3285/language/modifiers.html (1 of 6) [9/12/2001 3:22:26 PM]


<-4, 0, -4>, >4, 8, 4> } } } Objects should never extend outside their bounds. Doing so will have undefined results. Sometimes the object will render ok, sometimes parts that stick out will be trimmed away, sometimes things will just get weird. If you want to slice away part of an object, use clipped_by or CSG. If you have an object which you clipped, and want to use the same object to bound that you used to clip, you can do something like this . . . object { Some_Object_Or_Other clipped_by { sphere { <0, 2, 0>, 3 } } bounded_by { clipped_by } }

Clipped By The clipped_by statement allows you slice away parts of objects to reveal a hollow interior. It is similar to intersection except it leaves holes where parts of the object were clipped away. Any object (except light sources) can be clipped, and any object (except for light sources again) can be used to clip. For example, here is a cube that is clipped with a sphere.

Only the portions of the cube that are on the inside of the sphere are retained. The notions of "inside" and "outside" in the clipping object can be switched with the inverse keyword. Note that you can specify multiple objects to clip with in one clipped_by statement. The result will be that the object is clipped first with first object, then the result is clipped with the second, and the result of that is clipped with the third, etc. Here's an example of a cube with two clipping spheres.



If you've bounded an object with a second object, and want to use that same second object to clip the first, you can do something like this (presumably This_Is_An_Object is declared elsewhere) object { This_Is_An_Object bounded_by { cylinder { <0, 0, 0>, <0, 1, 0>, 0.5 } } clipped_by { bounded_by } }

Map Type The map_type keyword is only applicable to image maps, bump maps, and material maps. It is used to modify how the image is projected onto the surface in the mapping. The parameter for map_type is an integer which tells what kind of mapping to use. The default is "map_type 0". This is a planar mapping in which the image is projected along the z axis onto the x-y plane. The image is rescaled to fit into the unit square in the x-y plane. It also repeats infinitely in the x and y directions. Other mappings are as follows. map_type 0 The planar mapping as described above. map_type 1 A sperical mapping. The image is mapped Mercator-style around the origin. The right edge of the image ends up in the +x direction and is mapped clockwise around the y-axis. The top and bottom edges of the image are compressed down to points on the y-axis. The image shows a great deal of distortion around the poles of the mapping (the y-axis by default). Each pixel in the image is transformed into a three dimensional wedge shape which radiates from the origin. map_type 2 A cylindrical mapping. The image is mapped around the y-axis like wrapping paper. As with the spherical mapping, the right edge of the image ends up in the +x direction, and the image is mapped around the y-axis in a clockwise sense. The image is still rescaled in the y-direction to be one unit tall and repeats infinitely up the y-axis. Each pixel in the image is transformed into a http://library.thinkquest.org/3285/language/modifiers.html (3 of 6) [9/12/2001 3:22:26 PM]


pie-slice shape which radiates from the y-axis. map_type 5 A toroidal mapping. This type of mapping is the most difficult to describe. The image will fit around an untransformed torus (i.e. one that was created with the torus primitive and then left alone). Experiment with it. Map types 3 and 4 are reserved for future use. The following images show map types 0, 1, 2, and 5, respectively. Each map type is projected onto its corresponding shape. Note that for types 1, 2, and 5, the pigment was rotated to give a better view of what exactly was going on.

For example, if you wanted to make a globe, you might try something like this sphere { <0, 0, 0>, 4 pigment { image_map { gif "earth.gif" map_type 1 } } }



No Shadow The no_shadow keyword is applicable to any object (not light sources or cameras). When included in an object, that object will not cast a shadow on anything else. This is primarily useful for special effects, primarily those which simulate objects which "produce" light. Laser beams are a good example. The no_shadow keyword takes no parameter, it's either there, or it's not (in which case the object will cast a shadow like normal). The following images show the effect of no_shadow. The first image is normal, the second has a sphere with the no_shadow keyword.

Once The once keyword is only applicable to image maps, bump maps, and material maps. By default, the image which is mapped is repeated infinitely in the x and y directions (this varies with the map type). Adding the "once" keyword to a mapping specification will remove all the duplications of the image except the one in the (0, 0), (1, 1) unit square. With image maps, everywhere else becomes transparent; with bump maps, everywhere else becomes flat; with material maps, everywhere else becomes texture 0. The once keyword takes no parameter. If, for example, you wanted to create a single image stamped into a mirror you might try box { <-1, -1, -1>, <2, 2, 2> pigment { color rgb <1, 1, 1> } finish { reflection 1 ambient 0 diffuse 0 } normal { bump_map { gif "stamp.gif" once



} } }

Open THe open keyword controls the existence of endcaps on cylinders and cones. It is not legal anywhere else. This keyword takes no parameter. If it is specified, then cones and cylinders will be rendered as hollow tubes. Otherwise they will have the circular ends in place (default). Here are two sample scenes, the first without open and the second with.

Sturm Sturm is only applicable to blobs and polynomial objects (including tori). These objects require extremely accurate calculations to render. Normally they will look ok with POV-Ray's default root-solver. However, in certain cases they will render incorrectly. In these cases, you can specify the keyword "sturm" inside the object's declaration to tell POV-Ray to use its more accurate (but slower) Sturmian Root Solver. Another possible fix is to rotate, translate, or scale the object by a very small amount. Reference Index

Top of Document




The Online POV-Ray Tutorial: CSG Reference

The Online POV-Ray Tutorial CSG Reference CSG (Constructive Solid Geometry) is used to combine simple objects to form potentially very complex ones. CSG allows you to merge objects into one and carve away parts of objects with other objects. Any object (just about) can appear in a CSG object, including other CSG objects. There's no limit on the number of objects that can appear in a CSG object, but POV-Ray will complain a little if you don't have at least two objects in a CSG object. The following topics are covered in this section. ● Difference ●

Intersection

●

Inverse

●

Merge

●

Union

This small collect of objects will do nicely in assisting if our exaplanation of the wonders of CSG.

Difference A difference is used to take an object and carve shapes out of it. Specifying a difference is no different from specifying any other CSG object (see union) The first object specified is the object you're carving from, and all subsequent objects are used to carve away sections from the first object. Somewhat more specifically, any parts of the first object that are "inside" any of the other objects are trimmed away. Difference is the only CSG object in which the order of the objects is important. The concept of the "inside" and "outside" of an object can be altered with the inverse keyword. Here's what it looks line when group the cylinder and the box together in a difference statement.

http://library.thinkquest.org/3285/language/csg.html (1 of 6) [9/12/2001 3:22:40 PM]


First off, note that this is a different viewing angle from the initial sample scene. This is to make it more obvious what the difference did. Note that the scene is a cube with some interesting sections taken out of it. This is because the box object was the first one listed in the difference (see the source). Also notice how the different parts of the now scarred cube are different colors. When you do a difference operation, the surface is colored based on which object acutally "created" that surface. So the hole through the center of the box is green because it was made with the green cylinder. If you wanted the entire surface to be all one color, you could either change each individual texture to the same, or you could remove all the textures on the individual objects, and just put one inside the difference. See union for more detailed information on declaring CSG objects.

Intersection The intersection of two or more objects is composed of all the points that are inside all the objects. The order of the objects listed in the declaration is not important. You can think of intersection as (sort of) the opposite of a difference. Instead of carving away points that are inside the objects (like difference), intersection throws out regions that are outside of subsequent objects. POV-Ray's concept of "inside" and "outside" can be changed by adding the keyword inverse to an object. But anyway, here's what results if we group our unsuspecting test objects together in an intersection.

The result is a cylinder with sort of "squared off" ends. That volume corresponds to the space which is contained inside both of those objects. You can see which object was defining each boundary by the color of the result. Anywhere that is green is on the boundary of the cylinder and anything that is red is on the boundary of the box. ittedly, this particular thing isn't too useful, but intersection, along with its close relative, difference, is probably the most powerful CSG directive for creating new and interesting objects.



See union for more detailed information on declaring CSG objects.

Inverse The inverse keyword can be added to any finite, infinite, or CSG object. It basically reverses the regions that POV-Ray considers to be the inside and outside of the object. This only really matters in CSG differences and intersections. It can also be used in clipping objects. For an example of the use of inverse, check out these two images.

See the difference (no pun intended)? If you did, then there's something wrong. The only difference between between these two scenes is in the source. They render to the same image. One (the first) uses a difference, while the other (the second) uses an intersection. The reason they look the same is the second and third object in the second scene were inverted (don't just trust me, see for yourself). how difference and intersection work. Difference carves away insides, and intersection carves away outsides. But by flipping the insides and outsides in the intersection, it, too, is effectively carving away outsides. In fact, difference is implemented in POV-Ray as an intersection with the second through nth objects inverted. Here's an image which should make inverse more understandable. In this intersection, the box is inverted, so only regions outside the box and inside the cylinder remain.



Merge Merge is very similar to union. It basically serves the same purpose; it s a group of objects together into one for whatever purpose. Merge, however, differs from union in that any surfaces which are inside the object are removed. This doesn't matter in opaque objects, as internal surfaces aren't visible anyway. However, it is very important in objects that have transparency. In unions, internal surfaces of transparent objects will be visible, and this can cause unwanted artifacts. Using merge to these objects will solve these problems, though. Here's our sample scene again, substantially modified, but hopefully still recognizable. Actually, the objects are the same, except for their pigments. A finish was added to make the objects look like glass. The first image shows the objects unioned, the second shows them merged.

Note how in the first image, the outline of the cylinder is clearly visible inside the box. In the second, this object is gone. The combined objects are now acutally a single, continuous unit. One very important thing to keep in mind when creating merge objects is that coincident surfaces (surfaces which touch exactly at more than just a point or a line) will cause very strange errors in your object. Sections of the object will be randomly invisible, and things will be generally very twisted. For example, doing the following is bad. merge { cylinder { <0, 0, 0>, <0, 3, 0>, 3 } cone { <0, 3, 0>, 3, <0, 6, 0>, 0 } texture { SomeTexture } } Note how the top of the cylinder and the bottom of the cone are the same. This is bad. Note that this will not always render incorrectly. Sometimes it'll come out ok, and sometimes it won't. C programmers will understand when we say that "the results will be undefined." merge { cylinder {



<0, 0, 0>, <0, 3, 0>, 3 } cone { <0, 2.99, 0>, 3, <0, 6, 0>, 0 } texture { SomeTexture } } Now the two objects overlap a bit. This is just enough to fix the problem, and won't impact the appearance of the object appreciably. See union for more detailed information on declaring CSG objects.

Union Union is used to combine groups of objects together into one logical object. This object can then be textured and transformed as a whole, so you don't have to deal with a bunch of little objects. The basic form for a union (or any CSG) is as follows union { object { obj 1 } object { obj 2 } /* you can have as many objects as you wish */ object { obj n } /* here go any textures, rotations, translations, and scales. */ } Of course, if you want a difference, intersection, or merge, you should change the "union" above to the appropriate identifier. Any object, whether finite, infinite, or CSG, can be used in a union. There are restrictions on objects in the other types of CSG, though. Any object used in an intersection, merge, or difference must have a clearly defined inside. Objects like triangles don't have insides, and so can only be used in unions, not the others. You can use clipping to simulate these operations on flat objects, though. Unions are wonderful for creating coherent objects. For example, you can create an object with a great many components and group them all together into a union. After that, you can transform them by transforming the union instead of having to transform all the individual objects. You can also easily texture the objects as one. One thing to when texturing CSG objects, though, is that a texture for a specific object in a CSG will override any texture specified for the CSG object itself. Here is the sample scene with the objects ed together in a union.



Reference Index

Top of Document




http://library.thinkquest.org/3285/language/src/csg.pov

#include "colors.inc" box { <-1, -1, -1>, <1, 1, 1> pigment { color Red } } cylinder { <1.5, 1.5, -1.5>, <-1.5, -1.5, 1.5>, 0.5 pigment { color Green } } plane { y, -3 pigment { checker color White color Black } } plane { -z, -3 pigment { checker color White color Black } } light_source { <-400, 200, -300> color rgb <1, 1, 1> } camera { location <-2, 3, -4> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/csg.pov [9/12/2001 3:23:11 PM]

http://library.thinkquest.org/3285/language/src/csg1.pov

#include "colors.inc" difference { box { <-1, -1, -1>, <1, 1, 1> pigment { color Red } } cylinder { <1.5, 1.5, -1.5>, <-1.5, -1.5, 1.5>, 0.5 pigment { color Green } } } plane { y, -3 pigment { checker color White color Black } } plane { -z, -3 pigment { checker color White color Black } } light_source { <-400, 200, -300> color rgb <1, 1, 1> } camera { location <2, 3, -4> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/csg1.pov [9/12/2001 3:23:13 PM]


#include "colors.inc" intersection { box { <-1, -1, -1>, <1, 1, 1> pigment { color Red } } cylinder { <1.5, 1.5, -1.5>, <-1.5, -1.5, 1.5>, 0.5 pigment { color Green } } } plane { y, -3 pigment { checker color White color Black } } plane { -z, -3 pigment { checker color White color Black } } light_source { <-400, 200, -300> color rgb <1, 1, 1> } camera { location <-2, 3, -4> look_at <0, 0, 0> }



#include "colors.inc" intersection { box { <-1, -1, -1>, <1, 1, 1> pigment { color Red } } cylinder { <1.5, 1.5, -1.5>, <-1.5, -1.5, 1.5>, 0.5 inverse pigment { color Green } } } plane { y, -3 pigment { checker color White color Black } } plane { -z, -3 pigment { checker color White color Black } } light_source { <-400, 200, -300> color rgb <1, 1, 1> } camera { location <2, 3, -4> look_at <0, 0, 0> }



#include "colors.inc" intersection { box { <-1, -1, -1>, <1, 1, 1> inverse pigment { color Red } } cylinder { <1.5, 1.5, -1.5>, <-1.5, -1.5, 1.5>, 0.5 pigment { color Green } } } plane { y, -3 pigment { checker color White color Black } } plane { -z, -3 pigment { checker color White color Black } } light_source { <-400, 200, -300> color rgb <1, 1, 1> } camera { location <-2, 3, -4> look_at <0, 0, 0> }



#include "colors.inc" union { box { <-1, -1, -1>, <1, 1, 1> } cylinder { <1.5, 1.5, -1.5>, <-1.5, -1.5, 1.5>, 0.5 } pigment { color rgbf <1.0, 0.8, 0.8, 0.8> } finish { refraction 1 ior 1.5 } } plane { y, -3 pigment { checker color White color Black scale 3 } } plane { -z, -3 pigment { checker color White color Black scale 3} } light_source { <-400, 200, -300> color rgb <1, 1, 1> } camera { location <-2, 3, -4> look_at <0, 0, 0> }



#include "colors.inc" merge { box { <-1, -1, -1>, <1, 1, 1> } cylinder { <1.5, 1.5, -1.5>, <-1.5, -1.5, 1.5>, 0.5 } pigment { color rgbf <1.0, 0.8, 0.8, 0.8> } finish { refraction 1 ior 1.5 } } plane { y, -3 pigment { checker color White color Black scale 3 } } plane { -z, -3 pigment { checker color White color Black scale 3} } light_source { <-400, 200, -300> color rgb <1, 1, 1> } camera { location <-2, 3, -4> look_at <0, 0, 0> }


The Online POV-Ray Tutorial: Finite Objects

The Online POV-Ray Tutorial Finite Object Reference The following topics are covered in this section ● Bicubic Patch ●

Blob

●

Box

●

Cone

●

Cylinder

●

Height Field

●

Object

●

Smooth Triangle

●

Sphere

●

Torus

●

Triangle

Bicubic Patch This primitive creates Bezier style bicubic patch (sorry about the flurry of large words). A bicubic patch is a smooth surface defined by sixteen points, four of which specify the corners and are necessarily on the surface, and twelve others which are probably not on the surface, but are rather used to stretch it into the proper shape. Bicubic patches are really meant to be created by people. They're more the kind of thing that would be generated by a modeller of some sort. If you like pain you can create them yourself, though. POV-Ray renders bicubic patches as meshes of triangles. Here's the syntax for a bicubic patch: bicubic_patch { type type flatness flatness u_steps u_steps v_steps v_steps , , , , , , , , , , , , }

, , ,

The four parameters (type, flatness, u_steps, and v_steps) may appear in any order, but must appear

http://library.thinkquest.org/3285/language/fobject.html (1 of 13) [9/12/2001 3:24:08 PM]


before the control points are specified. type specfies how POV-Ray should store the patch in memory. If type is 0 then POV-Ray just stores the control points in memory. This is quite memory efficient, but also very slow. If type is 1, then POV-Ray will preprocess the patch and store the resulting object(s) in memory. This will cause the object to render much faster, but at the expense of memory. The u_steps and v_steps keywords specify the maximum number of subpatches to divide the patch into. u_steps and v_steps are floats and shouldn't have any fractional part. The maximum number of subpatches can be calculated with the expression max = 2 ^ u_steps * 2 ^ v_steps As a result, it's a bad idea to make u_steps or v_steps very large. The POV-Ray authors recommend that "u_steps 3" and "v_steps 3" will cause most patches to render well. They also suggest 5 as a maximum value for either parameter. The flatness keyword is used to determine if a subpatch needs to be divided into smaller ones. flatness is a float which should be between 0 and 1 inclusive. The lower this value is, the more subdivisions POV-Ray will make (up to the u_steps or v_steps). If this value is 0, POV-Ray will always divide the patch into the maximum number of subpatches. Note that the lower this value is, the slower the patch will render. As bicubic patches are made of triangles, they don't have a clearly defined inside, and so can't be used in CSG (except for union) or inside a clipped_by statement. Although it's not particularly useful, here's an example of a bicubic patch.

If you want to learn more about bicubic patches (how they are generated, how they work, how to create them, and all the mathematics behind them) a book that we recommend is Fundamentals of Interactive Computer Graphics J. D. Foley and A. Van Dam Addison-Wesley 1983 ISBN 0-201-14468-9 It covers a great deal of material with a good amount of depth, despite the "fundamentals" in the title. Note that when dealing with bicubic patches this book assumes a familiarity with matrices.



Blob Blobs are quite peculiar. The basically consist of a bunch of spheres which attract or repel each other to form a surface. They aren't really meant to be precise objects, but rather objects that give a sort of "organic" feel to a scene. Their syntax is as follows: blob { threshold threshold component strength1, component strength2, component strength3, component strength4, /* you can have as many }

radius1, radius2, radius3, radius4, components as you have memory and time */

Blobs basically work by creating fields around each of the components by adding the strength values from each components according to a specified function. Wherever this value is equal to the threshold, the surface is drawn. As described above, threshold tells where in space to draw the surface. It is a float which should be greater than zero. The strength of each component tells how strong the field around this component is. This can be positive or negative. A positive strength will cause the surface to stretch towards this component; a negative strength will repel the surface away from this component. The larger the value, the greater the effect this particular component will have. The radius of each component describes its field of effect. The blob equations are set up so that the field strength of each component is equal to strength at the center of the component and falls off to zero at a distance of radius from the center of that component. Each vector gives the <x, y, z> of the center point of that component. As blobs are difficult to visualize, here are a few examples. blob { threshold component component component pigment { }

0.25 1.5, 0.5, <0, 0, 0> 1, 0.5, <-0.5, 0.5, 0> 1, 0.5, <0.5, 0.5, 0> color Red }



blob { threshold component component component pigment { }

0.25 1.5, 0.5, <0, 0, 0> 1, 0.5, <-0.5, 0.5, 0> -1, 0.5, <0.5, 0.5, 0> color Red }

Blobs can be used in CSG, the inside of a blob is anywhere the field strength is greater than the threshold. Conversely, the outside is anywhere that field strength is less than the threshold. Note that components in different blob objects will not affect each other. If a blob renders improperly, the keyword sturm may be added into the declaration. This will cause POV-Ray to use a more accurate (but slower) root solver.

Box The box primitive creates a rectangular prism (fancy term for a box) with faces parallel to the coordinate planes. Its syntax is a follows: box { , } where and are vectors specifying the <x, y, z> of opposite corners of the box. The POV-Ray documentation states that all the elements of should be less than the corresponding elements of , but I have never had problems with this. Here's an example of a



box: box { <-1, -1, -1>, <1, 1, 1> pigment { color Green } } This creates a green cube two units on a side centered at the origin. Here are some sample boxes, both of which just happen to be cubes (not all boxes have to be cubes, though).

Boxes are highly optimized objects and thus make wonderful bounding volumes.

Cone The cone primitive creates a creates a cone with the given characteristics. It is similar to the cylinder, but two radii are specified instead of just one. Its syntax: cone { , radius-1, , radius-2 [open] } and are <x, y, z> vectors for the centers of the two ends of the cone. radius-1 and radius-2 specify the radius of the cone at and respectively. Both radius-1 and radius-2 can be positive, negative, or zero. If one radius is zero, the objects looks like a standard cone shape. If both radii are the same sign, the object looks like a cone with the tip cut off. If the radii are opposite signs, the object looks like two cones with their tips touching. An example cone: cone { <0, 0, 0>, 3, <0, 3, 0>, 0 pigment { color Blue } }



This will create a cone that is three units tall and six units in diameter at the base. The following scene contains some other examples of cones.

The keyword open may be included in the object definition to make POV-Ray render the cone without endcaps.

Cylinder The cylinder primitive creates a circular cylinder with the given characteristics. The syntax of the primitive is the following: cylinder { , , radius [open] } and are vectors specifying the <x, y, z> of the centers of the ends of the cylinder. radius specifies the radius of the cylinder. Note that the sides of the cylinder will always be perpendicular to the ends. An example cylinder declaration: cylinder { <0, 0, 0>, <0, 1, 0>, 0.5 pigment { color Yellow } } This will create a circular cylinder that has the same height as diameter. The following example scene contains three cylinders.



Including the keyword open will cause POV-Ray to render the cylinder without endcaps (as a tube).

Disc The disc primitive creates an infinitely thin circular disc with an optional hole in the center. The syntax for a disc: disc { , <normal>, radius [, hole radius] } is an <x, y, z> vector specifying the center of the disc. <normal> is a vector perpendicular to the plane of the disc. radius is a float which gives the radius of the disc. Optionally, the float hole radius may be specified which will create a circular hole of that radius in the center of the disc. If present, hole radius should be smaller than radius (otherwise, what's the point?). Here's an example use of a disc: disc { <0, 0, 0>, <0, 1, -1>, 2, 1.5 pigment { color Green } } sphere { <0, 0, 0>, 1 pigment { color Green } } This will create a sort of monochromatic version of Saturn. Here's how that would look.



Note that discs are two dimensional objects and so have no inside or outside. Consequently, they can't be used in CSG (except in union) or inside a clipped_by.

Height Field Height fields are an easy way to create mountains in your scenes. They basically work by reading an image file and then turning that image into a mesh of triangles. The height of each point in the mesh is determined by the value of the corresponding pixel in the image. The general form for specifying a height field is height_field { type "filename" [smooth] [water_level height] /* transformations */ } type specifies the type of the file being read, and is one of gif, pot, or tga. This is then followed by the name of the source image (in quotes). With just these declarations, you'll get a height field which fits into the unit box with vertices at <0, 0, 0> an <1, 1, 1>. The image is mapped onto the x-z plane with the value of the pixel determining the y value of the field. The lower-left corner of the image ends up at <0, 0, 0> and the upper-right ends up at <1, 0, 1>. The lowest possible value of the height field ends up at y=0, while the highest gets y=1. The image is always rescaled to fit into that unit box. Thus, larger images do not produce larger height fields, but rather ones with better resolution. Here's an example of a height field. The first image is the source for the height field (black=0, white=255). The second is the rendered height field.

For gifs, the height of a given pixel is based on its palette index. The color with palette entry 0 gets the lowest height in the height field, while the color with palette entry 255 gets the hightest height in the field. Thus with gifs, you can get 256 distinct height levels in the height field. Pot files work the same, except they upto 32,000 (or so) colors. As with resolution, this does not produce taller height fields, but rather ones with better vertical resolution. According to the POV-Ray authors, the PC program Fractint can produce pot files. Height mapping is done slightly differently with tga files. With tgas a sixteen bit number (so you get http://library.thinkquest.org/3285/language/fobject.html (8 of 13) [9/12/2001 3:24:08 PM]


65,536 height levels) is stored for each pixel using that pixel's red and green bytes. The most significant byte is stored in the red, the least significant in the green. Generating these kinds of height fields is pretty much beyond the scope of most paint programs, but it's pretty rare that you'll actually need 65,536 distinct height levels anyway. Fractal mountains tend to look fine with 256 divisions, unless you want to get a super-close-up view. Normally, POV-Ray generates height fields out of normal, flat triangles. This gives the height field a rough, jagged look. While this may be exactly the effect you're looking for with mountains, sometimes it is undesirable. You can include the optional keyword "smooth" in the height field. This will cause POV-Ray to use smooth triangles instead of flat ones for mesh. POV-Ray will automatically calculate surface normals to make the height field into a smooth, rolling surface, however, smooth height fields require much more memory to deal with than do normal height fields. Another keyword that you can include is "water_level". This keyword is used to cut off the bottom part of a height field. This is useful for mountains which you plan to partially submerge in water. Parts of the height field which are below the "water_level" will not be turned into triangles, making for a speedier render. The water_level keyword takes a float parameter between 0.0 and 1.0 which specifies where to slice. 0.0 corresponds to the lowest level in the field, 1.0 to the heighest. 0.5 would cut off the bottom half of the field. This slicing is applied before any transformations are applied, so you should never need a value greater than 1. Here, for example, is the same height field as above with "water_level 0.5" added in.

Object The object primitive is not typically used to create single objects. It is primarily used only to create objects that have been declared with a declare directive. In fact, an object primitive is implied around any primitive that creates an object. For example, sphere { <1, 1, 1>, 1.732 pigment { color Red } } Is the same as



object { sphere { <1, 1, 1>, 1.732 pigment { color Red } } } The object primitive is more commonly used in this sort of fashion #declare BlueSphere = sphere { <0, 0, 0>, 1 pigment { color Blue } } object { BlueSphere } object { BlueSphere scale 2 translate <0, 5, 5> } Of course, this is a very simple example. Any type of object, whether finite, infinite, or CSG, can appear in an object statement.

Smooth Triangle Smooth triangles are triangular patches with normal vectors specified for each of the vertices. These vectors are used to bend the triangle into a curved shape. Smooth triangles aren't really designed to be used extensively by people. They're more the type of thing a modeller would produce to approximate a smooth surface. Here's the syntax anyway: smooth_triangle { , <normal-1> , <normal-2> , <normal-3> } The three vertices specify the corners of the triangle. The corresponding normal vector is then used in shading the surface. Note that the normal vectors don't acutally cause the triangle to be deformed, they just alter the way POV-Ray shades it. This can be used to great effect when approximating smooth surfaces, as it would require a much larger number of flat triangles to acheive the same results. To create http://library.thinkquest.org/3285/language/fobject.html (10 of 13) [9/12/2001 3:24:08 PM]


a smooth smooth_triangle mesh, the normals for shared vertices in any triangles should be the same. Smooth triangles are perfectly two-dimensional so they have no inside or outside. They therefore cannot be used in CSG (other than in union) or inside a clipped_by statement.

Sphere The sphere primitive creates a sphere of a given radius and center. The syntax is the following: sphere { , radius } where is a vector specifying <x, y, z> of the center of the sphere and radius is a float specifying the sphere's radius. For example, sphere { <10, 10, 10>, 5 pigment { color Blue } } will create a blue sphere of radius 5 that is centered at <10, 10, 10>. This primitive can only create spheres, but you can use nonuniform scaling to create ellipsoidal objects. Anyway, here are some sample spheres.

Also, spheres are highly optimized objects in POV-Ray, and thus make spectacular bounding volumes.

Torus The torus primitive will create a torus (doughnut shape) at the origin. A torus is a quartic shape; this primitive is basically an easier way of creating this cool and useful shape. The torus syntax is as follows: torus { http://library.thinkquest.org/3285/language/fobject.html (11 of 13) [9/12/2001 3:24:08 PM]


major radius, minor radius } The major radius and minor radius are defined as shown below

This primitive always creates a torus with a major axis in the x-z plane. If you want one with a different orientation, you'll need to rotate it. The advantage to using this form over the quartic definition is that this form is known by POV-Ray to be finite, thus POV-Ray can optimize its rendering.

Triangle Triangles are the familiar three cornered polygons we all learned about in school. They are similar to smooth triangles, only they don't have normal information for the vertices. Here's the syntax for the triangle: triangle { , , } where each is an <x, y, z> vector specifying the locations of the three corners. Triangles are moderately useful to human beings, but they're much more useful to modelling programs. The object in the following scene is composed entirely of triangles. If you're interested, the object is known as an icosahedron.

As with the other two dimensional objects, triangles have no inside or outside and so can't be used in CSG, with the exception of union, and nor can they be used inside a clipped_by.



Reference Index

Top of Document




http://library.thinkquest.org/3285/language/src/fobj3.pov

bicubic_patch type 1 u_steps 3 v_steps 3 <0, 0, 0>, <0, 0, 1>, <0, 0, 2>, <0, 0, 3>,

{

<1, <1, <1, <1,

0, 0>, <2, 0, 0>, <3, 0, 0>, 6, 1>, <2, -6, 1>, <3, 0, 1>, -6, 2>, <2, 6, 2>, <3, 0, 2>, 0, 3>, <2, 0, 3>, <3, 0, 3>

pigment { color rgb <1, 0.4, 0.4> } } light_source { <-1.5, 5, 1.5> color rgb <1, 1, 1> } camera { location <2, 3, -3> look_at <1.5, 0, 1.5> }

http://library.thinkquest.org/3285/language/src/fobj3.pov [9/12/2001 3:24:10 PM]


box { <-3, -1, -1>, <-1, 1, 1> pigment { color rgb <1, 1, 0> } } box { <-1, -1, -1>, <1, 1, 1> pigment { color rgb <0, 1, 0> } rotate 45*y rotate -35.264*x translate <2, 0, 0> } light_source { <10, 50, -80> color rgb <1, 1, 1> } camera { location <0, 1.5, -6> look_at <0, 0, 0> }



cone { <0, 0, 0>, 0.5, <0, 1, 0>, 0 pigment { color rgb <0, 0.7, 0> } } cone { <-1, 0, 0>, 0.25, <-1, 0.5, 0>, 0.125 pigment { color rgb <0.7, 0.7, 0> } } cone { <1, 0, 0>, 0.25, <1, 1, 0>, 0.5 pigment { color rgb <0, 0.7, 0.7> } } light_source { <20, 10, -50> color rgb <1, 1, 1> } camera { location <0, 0.5, -2.5> look_at <0, 0.5, 0> }



cylinder { <-1, 0, 0>, <1, 0, 0>, 0.125 pigment { color rgb <1, 0, 0> } } cylinder { <0, -1, 0>, <0, 1, 0>, 0.125 pigment { color rgb <0, 1, 0> } } cylinder { <0, 0, -1>, <0, 0, 1>, 0.125 pigment { color rgb <0, 0, 1> } } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <0.5, 0.25, -3> look_at <0, 0, 0> }



disc { <0, 0, 0>, <0, 1, -1>, 2, 1.5 pigment { color rgb <0, 1, 0> } } sphere { <0, 0, 0>, 1 pigment { color rgb <0, 1, 0> } } light_source { <20, 10, -50> color rgb <1, 1, 1> } camera { location <0, 0, -4> look_at <0, 0, 0> }



height_field { gif "fract001.gif" pigment { color rgb <1, 1, 1> } translate <-0.5, -0.5, -0.5> } disc { <0, -0.75, 0>, y, 2 pigment { checker color rgb <0.1, 1, 0.1> color rgb <0.4, 1, 0.4> scale 1/4 } } light_source { <-1, 2, 0> color rgb <1, 1, 1> } camera { location <-1, 0.5, -1> look_at <0, 0, 0> }



height_field { gif "fract001.gif" water_level 0.5 pigment { color rgb <1, 1, 1> } translate <-0.5, -0.5, -0.5> } disc { <0, -0.75, 0>, y, 2 pigment { checker color rgb <0.1, 1, 0.1> color rgb <0.4, 1, 0.4> scale 1/4 } } light_source { <-1, 2, 0> color rgb <1, 1, 1> } camera { location <-1, 0.5, -1> look_at <0, 0, 0> }



sphere { <0, 0, 0>, 1 pigment { color rgb <1, 1, 0> } } sphere { <1, 1, 0>, 0.25 pigment { color rgb <0.2, 1, 0.2> } } sphere { <0.5, -.5, -1>, 0.3 pigment { color rgb <1, 0.6, 0> } } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <0, 0, -3> look_at <0, 0, 0> }



union { triangle { <0.0000, 0.0000, 1.0000>, <0.8660, 0.0000, 0.5000>, <0.2676, 0.8236, 0.5000> } triangle { <0.0000, 0.0000, 1.0000>, <0.2676, 0.8236, 0.5000>, <-0.7006, 0.5090, 0.5000> } triangle { <0.0000, 0.0000, 1.0000>, <-0.7006, 0.5090, 0.5000>, <-0.7006, -0.5090, 0.5000> } triangle { <0.0000, 0.0000, 1.0000>, <-0.7006, -0.5090, 0.5000>, <0.2676, -0.8236, 0.5000> } triangle { <0.0000, 0.0000, 1.0000>, <0.2676, -0.8236, 0.5000>, <0.8660, 0.0000, 0.5000> } triangle { <0.8660, 0.0000, 0.5000>, <0.2676, 0.8236, 0.5000>, <0.7006, 0.5090, -0.5000> } triangle { <0.2676, 0.8236, 0.5000>, <-0.7006, 0.5090, 0.5000>, <-0.2676, 0.8236, -0.5000> } triangle { <-0.7006, 0.5090, 0.5000>, <-0.7006, -0.5090, 0.5000>, <-0.8660, 0.0000, -0.5000> } triangle { <-0.7006, -0.5090, 0.5000>, <0.2676, -0.8236, 0.5000>, <-0.2676, -0.8236, -0.5000> } triangle { <0.2676, -0.8236, 0.5000>, <0.8660, 0.0000, 0.5000>, <0.7006, -0.5090, -0.5000> } triangle { <0.7006, 0.5090, -0.5000>, <-0.2676, 0.8236, -0.5000>, <0.2676, 0.8236, 0.5000> } triangle { <-0.2676, 0.8236, -0.5000>, <-0.8660, 0.0000, -0.5000>, <-0.7006, 0.5090, 0.5000> } triangle { <-0.8660, 0.0000, -0.5000>, <-0.2676, -0.8236, -0.5000>, <-0.7006, -0.5090, 0.5000> } triangle { <-0.2676, -0.8236, -0.5000>, <0.7006, -0.5090, -0.5000>, <0.2676, -0.8236, 0.5000> } triangle { <0.7006, -0.5090, -0.5000>, <0.7006, 0.5090, -0.5000>, <0.8660, 0.0000, 0.5000> } triangle { <0.0000, 0.0000, -1.0000>, <0.7006, 0.5090, -0.5000>, <-0.2676, 0.8236, -0.5000> } triangle { <0.0000, 0.0000, -1.0000>, <-0.2676, 0.8236, -0.5000>, <-0.8660, 0.0000, -0.5000> } triangle { <0.0000, 0.0000, -1.0000>, <-0.8660, 0.0000, -0.5000>, <-0.2676, -0.8236, -0.5000> } triangle { <0.0000, 0.0000, -1.0000>, <-0.2676, -0.8236, -0.5000>, <0.7006, -0.5090, -0.5000> } triangle { <0.0000, 0.0000, -1.0000>, <0.7006, -0.5090, -0.5000>, <0.7006, 0.5090, -0.5000> } pigment { color rgb <0, 1, 0> } } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <0.75, 0.75, -2.5> look_at <0, 0, 0> }


The Online POV-Ray Tutorial: POV-Ray Language Reference

The Online POV-Ray Tutorial POV-Ray Language Reference Welcome to the POV-Ray Language Reference. This document contains information on the syntax, usage and purpose of every POV-Ray keyword and feature. Select a topic from below: General POV-Ray Language and Scene Wide Modifiers POV-Ray directives, transformations and other miscellaneous features. Finite Objects Finite POV-Ray primitives (those containing well-defined bounds). Infinite Objects Infinite POV-Ray primitives (those including a component which may potentially extend to infinity) CSG (Constructive Solid Geometry) CSG object manipulations (union, merge, difference, etc.) Object Modifiers Directives used to modify the default behaviour of certain objects. Pigment Object surface color/pattern modifiers. Finish POV-Ray directives that modify the way light interacts with object surfaces. Normal POV-Ray directives that can quickly simulate common 3D attributes such as bumps. Texture Special surface color/patterns modifiers. Camera POV-Ray camera modifiers. Lights POV-Ray light source types and attributes. Top of Document


http://library.thinkquest.org/3285/language/index.html (1 of 2) [9/12/2001 3:24:29 PM]

The Online POV-Ray Tutorial: POV-Ray Language Reference


http://library.thinkquest.org/3285/language/index.html (2 of 2) [9/12/2001 3:24:29 PM]

The Online POV-Ray Tutorial: Infinite Objects

The Online POV-Ray Tutorial Infinite Object Reference The following topic are covered in this section ● Cubic ●

Plane

●

Poly

●

Quadric

●

Quartic

Cubic A cubic is a third order poly. This means that the sum of the exponents of the variables in each term is less than or equal to three. The following are examples of equations (some cubic, some not). x x^3 x^2 y z 3

y^3 + 3 y^2 - z

+ 3 x^2 y + 3 x y^2 + y^3 - 6 x^2 - x y^2 - y z^3

cubic cubic not cubic, in first term 2 + 2 > 3 cubic cubic (but rather pointless)

Note also that the exponents in each are non-negative integers. For a better definition of polynomials see poly or just about any algebra text. The syntax for a cubic is as follows: cubic { } a0 through a19 are all floats. They are the coefficients for the general cubic equation in three variables: a0 x^3 a6 x y a12 y^2 a18 z

+ + + +

a1 x^2 y a7 x z^2 a13 y z^2 a19 = 0

+ + +

a2 x^2 z a8 x z a14 y z

+ + +

a3 x^2 a9 x a15 y

+ + +

a4 x y^2 a10 y^3 a16 z^3

+ + +

a5 x y z a11 y^2 z a17 z^2

+ + +

The second equation above would be defined by cubic { <1, 3, 0, 0, 3, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0> } Cubics are useful shapes as they can be used to smoothly two curves together. See the section on tips and tricks for more information on this technique. Calculations for cubics (as well as any type of poly) must be very accurate or the surface will appear strangely deformed. If you have a cubic that dessn't seem to be rendering correctly, the keyword sturm may be added to the definition to tell POV to use its more accurate (but unfortunately slower) Sturmian root solver. Also, sometimes the problem can be fixed http://library.thinkquest.org/3285/language/iobject.html (1 of 5) [9/12/2001 3:24:34 PM]


by rotating, scaling, or translating the object by some small amount. Cubics (like all polys) can be used in CSG as they have a defined inside and outside. The inside is defined to be all points where the equation is less than zero. The outside is all points where the equation is greater than zero. Points where the equation equals zero are on the surface. Note that cubics are considered infinite objects by POV, so they will not be optimized with automatic bounds.

Plane The plane primitive creates an infinite, flat plane of any orientation and any location. The syntax of plane is as follows: plane { <normal>, offset } <normal> is an <x, y, z> vector that describes the plane by giving a normal to its surface. By default, the plane goes through the origin. This is changed with the offset value. It is a float that translates the plane along its normal vector. It may be positive, negative, or zero, and can be used to position the plane anywhere in space. Here are some examples of planes: plane { y, 3 } This plane is parallel to the x-z coordinate plane. It extents infinitely in both the x and z directions. plane { <1, 1, 1>, 0 } This plane is diagonal and goes through the origin. Planes are acutally a very simple (first order) poly. The primitive can also be represented by plane { , d } which would represent the equation a x

+

b y

+

c z

=

d

This is important because it defines the "inside" and "outside" of a plane for use in CSG. By this definition, the normal vector always points to the "outside" of the plane.

Poly The poly primitive can be used to define up to seventh order polynomials in three variables. Note that there are already primitives to define second, third, and fourth order polynomials (quadric, cubic, and quartic respectively). There is no

http://library.thinkquest.org/3285/language/iobject.html (2 of 5) [9/12/2001 3:24:34 PM]


difference between defining one of these with the poly primitive or with its specialized primitive. Very quickly, a polynomial is an expression that consists of But anyway, the general syntax for poly is like this: poly { order, } order is a float which defines the order of the polynomial. order should be an integer between 2 and 7 inclusive. a0 through an are the coefficients for the generic polynomial equation of order order. The number of coefficients in the equation m is defined by the equation m = (order + 1) * (order + 2) * (order + 3) / 6 Note that n = m - 1. This relationship can make defining seventh order polynomials by hand a real pain (they have 120 coefficients). The other concern when defining polys is the order of the coefficients. This is not well covered in the POV-Ray documentation, but after some experimentation the pattern was determined. The following pseudocode segment will print out the in order: for x : order -> 0 for y : order - x -> 0 for z : order - x - y -> 0 print "x^", x, " y^", y, " z^", z As an example of this, the generic fifth order equation (all 56 ) is a0 a6 a12 a17 a23 a28 a34 a40 a46 a53

x^5 + a1 x^4 y + a2 x^4 z + a3 x^4 + a4 x^3 y^2 + a5 x^3 y z + x^3 y + a7 x^3 z^2 + a8 x^3 z + a9 x^3 + a10 x^2 y^3 + a11 x^2 y^2 z + x^2 y^2 + a13 x^2 y z^2 + a14 x^2 y z + a15 x^2 y + a16 x^2 z^3 + x^2 z^2 + a18 x^2 z + a19 x^2 + a20 x y^4 + a21 x y^3 z + a22 x y^3 + x y^2 z^2 + a24 x y^2 z + a25 x y^2 + a26 x y z^3 + a27 x y z^2 + x y z + a29 x y + a30 x z^4 + a31 x z^3 + a32 x z^2 + a33 x z + x + a35 y^5 + a36 y^4 z + a37 y^4 + a38 y^3 z^2 + a39 y^3 z + y^3 + a41 y^2 z^3 + a42 y^2 z^2 + a43 y^2 z + a44 y^2 + a45 y z^4 + y z^3 + a47 y z^2 + a48 y z + a49 y + a50 z^5 + a51 z^4 + a52 z^3 + z^2 + a54 z + a55 = 0

Ugh. This is definitely not something that one would want to type by hand. The cumbersomeness (cumbersomity?) of high order polys is the main limitation on their usefulness. POV comes with a number of predefined poly shapes; they can be found in shapesq.inc. The POV-Ray authors also recommend The CRC Handbook of Mathematical Curves and Surfaces David von Seggern CRC Press 1990 as a good resource for finding cool surface equations. Another concern with high order polys is the extreme accuracy required to render them accurately. If you have a poly that seems to rendering incorrectly, you can include the keyword sturm in the object definition. This will tell POV to use its more accurate (but somewhat slower) Sturmian root solver. All polys can be used in CSG and clipped_by constructs. The inside of the poly is defined to be all points with values http://library.thinkquest.org/3285/language/iobject.html (3 of 5) [9/12/2001 3:24:34 PM]


(when plugged into the equation) is less than zero. Conversely, the outside is all points with values greater than zero. All points with values of zero are on the surface of the object. Note also that POV considers all polys of any order to be infinite objects (regardless of whether or not they actually are) and so it does not automatically bound them.

Quadric A quadric is a second order poly. It can be used to create simple shapes like cylinders, cones, spheres, and hyperboloids. Note that many of these shapes already have primitives associated with them. It is usually better to use the sphere primitive to create a sphere than to use a quadric statement, because POV has special optimizations for spheres that would not take effect with the quadric definition. Note also that quadrics and quartics are different (quartics are fourth order polys). The syntax for a quadric is as follows: quadric { , , , j } a through j are all floats and correspond to the following second order poly equation: ax^2 + by^2 + cz^2 + dxy + exz + fyz + gx + hy + iz + j = 0 Some examples of quadrics: quadric { <1, -1, -1>, <0, 0, 0>, <0, 0, 0>, 0 }

// an infinite cone opening in the x direction

quadric { <1, 1, 1>, <0, 0, 0>, <-6, -6, -6>, 18 }

// a sphere of radius 3 centered at <3, 3, 3>

quadric { <1, 0, 1>, <-2, 0, 0>, <0, 0, 0>, 0 }

// a rotated cone

Well, you get the idea. There are actually quite a large number of useful shapes that can be generated with quadrics. This http://library.thinkquest.org/3285/language/iobject.html (4 of 5) [9/12/2001 3:24:34 PM]


is nice because quadrics are easy to define and are fairly efficient to render. As with all polys, accuracy is a factor in rendering quadrics. Although quadric surfaces will rarely cause problems, if you have one that's rendering incorrectly, you can throw in the keyword sturm to tell POV to use its slow but accurate Sturmian root solver. Quadrics have a clearly defined inside and outside, and so can be used in CSG. They are considered to be infinite and so are not automatically bounded.

Quartic Quartics are fourth order poly objects. Note the two letter (but very important) difference between quartic and quadric. A common and useful example of a quartic shape is the torus (or doughnut) shape. For concerns of efficiency and ease of use, you should probably use the torus primitive to declare a torus. The POV-Ray documentation contains a discussion of the quartic primitive, so it won't be repeated here. The syntax for a quartic is as follows: quartic { } Each of a0 through a34 is a float. The correspondence of these numbers to in the generic quartic equation is covered with the discussion of poly. Reference Index

Top of Document



http://library.thinkquest.org/3285/language/iobject.html (5 of 5) [9/12/2001 3:24:34 PM]

The Online POV-Ray Tutorial: Tips and Tricks

The Online POV-Ray Tutorial Tips and Tricks We've provided a list of useful tips and tricks to help you in learning and using POV-Ray. We came up with most of these as a side-effect of frequent POV-Ray use on our part (when we really should have been doing other things, like homework), so they're worth looking at. Quick index: 1. Developing POV-Ray Scenes 2. Being Artistic

Developing POV-Ray Scenes ●

●

●

●

●

●

●

Develop a good coding style. (A coding style is the way you format the source code in the file -where you place the tabs and such). If you ever go back and work on a scene you made a month ago, this can be invaluable. We personally like the one we've used in the examples in this tutorial, but you should feel free to develop one you like... just be consistent! Be prepared to spend some time. Not even the fastest computers will be fast enough for you once you really get going. Ray-tracing is a slow process. Make yourself a cup of coffee, or go on a month's vacation (if it's a really complex scene), or, better yet, multitask! (Sorry, DOS s, you're stuck with waiting). Low-quality images generate faster; use them.You can save yourself some time when developing a scene by generating low-quality output (see the +Q switch and the +A switch documentation in the Command Line Reference. Generate high quality output for the final scene. Make small changes, and render frequently. Although this seems like it will take more time, you will have actually saved yourself time that would have otherwise been spent debugging scenes where many changes have been made. If you rotate the camera, add three more objects, and change the lighting all in one go, the chances of you getting lost are a lot greater than if you render a quick image in between each step. Experiment. This tutorial can't teach you everything. Experimenting with objects, textures, and everything else about POV-Ray is the best way to learn. It certainly can't hurt anything. And hey, if you make anything interesting, submit it to the Texture Library or the Object Library for others to see! Don't start out with a modeller. Only start using extra tools once you have a firm understanding of POV-Ray and have had plenty of experience just using the text editor -- otherwise, you won't learn some of the most important things and you'll be very stuck down the road. Zoom way back if you've lost an object. The best way to find "missing" objects (objects that you put in the source code but that aren't appearing on-screen) is to pull the camera far back. You may be able to find the objects. Another possibility is that the object has no texture. POV-Ray will usually give you a warning in this case, but sometimes it'll just go ahead and color the object

http://library.thinkquest.org/3285/tips.html (1 of 3) [9/12/2001 3:24:50 PM]


●

●

black. Be aware of the defaults. Sometimes default values for things can mess up a scene. For example, putting "reflection 1.0" in an object's finish statement will not make that object a perfect reflector. You also need to add "ambient 0.0" and "diffuse 0.0". You can use the default directive to change the default behavior of an object. Bound complex objects. POV-Ray is only able to do so much with automatic bounds. The automatic bounding algorithm won't even touch really complex objects (like intersections or polynomial objects). You can really speed up rendering by specifying a bounding object for these, if applicable. Of course, if you have an infinite cone (for example), it'll be difficult to find an object which contains it. By far the best objects for bounding are boxes and spheres. See bounded_by.

Being Artistic ●

●

●

●

●

●

●

Surrealism is easy. Because of the way ray-tracers work, scenes tend to come out looking a little surrealistic. Try maximizing this effect. Use it to your advantage. Try adding some fog. Just a little bit of fog can make your scene look a lot more three-dimensional, and it's not very computationally expensive. Try it. Use your light sources wisely. Lighting can make and break a scene -- especially if you're working with glass or mirror-like objects. Bad lighting can make your image seem flat and two-dimensional, too dark, too bright, or just plain boring. Experiment, and find just the right configuration for each scene you create. , if your light source color is <2,2,2>, it will be twice as bright (this trick can save you a lot of time). Avoid infinite ground planes. Planes which stretch or appear to stretch off to infinity will give your scene an empty feeling. Unless you can find a way to populate this space with something, your scene will feel unbalanced. Of course, we've broken this rule many times throughout the Tutorial... but only when we're not trying to be artistic. Really. How something appears is more important than how it is. A scene needs to look right. If something is mathematically correct but doesn't look like it, that doesn't help you much. This is art -- the ends justify the means! Concentrate on what can be seen. This is related to the above tip. Don't agonize about perfecting things the viewer is never going to be able to see. As stated above, things only need to look right. Use a sky sphere. In scenes where you're going to have a visible "sky", a sky sphere is very effective. This is a sphere of a very large radius (the edge is maybe 1000 times further than any object in the scene), which you can texture to give a sky-like appearance. To keep things from casting a shadow on the sky sphere, use only ambient lighting on the sphere; turn off all the diffuse lighting. If you just want a sky that's a single color, you can just use the background directive. Top of Document


Main Page




The Online POV-Ray Tutorial: Command Line Parameters

The Online POV-Ray Tutorial Command Line Parameter Reference This section covers the various command-line parameters which POV-Ray will accept. POV-Ray checks command line parameters in a non-case-sensitive fashion. This means, for example, that +a is the same as +A. Some options are toggles, some are specifiers. With the toggles, specifying a "+" before the letter turns the option on, while specifying a "-" before it will turn it off. Examples of toggles are A, J, and MB. With specifiers, a value for a parameter is specified. Here, either "+" or "-" can be used before the letter. The argument for the specifier follows the parameter without a space. "-Ifoo.pov" for example. Any command line parameter which is not preceded by a "+" or a "-" is assumed to be the name of a command file from which further options will be read. Valid command line parameters are listed below. A Controls anti-aliasing (edge smoothing) of the image B Controls the size of the output buffer C Used to continue a incomplete render of an image D Controls display of the image during rendering E or ER Sets the ending row for partial renders EC Sets the ending column for partial renders F Sets to format of the output image H Specifies the height of the image (in pixels) I Specifies the name of the scene file being rendered J

http://library.thinkquest.org/3285/language/cmdln.html (1 of 11) [9/12/2001 3:27:16 PM]


Controls jitter during anti-aliasing K Specifies a value for the clock variable L Specify a path to search for files in MB Controls POV-Ray's use of automatic bounding MS Controls the size of POV-Ray's internal symbol table MV Used to modify the default value of the version parameter O Specifies a filename to render the scene to P Controls whether POV-Ray waits for a keypress after rendering Q Controls the rendering quality R Controls the number of extra rays used for anti-aliasing S or SR Sets the starting row for partial renders SC Sets the starting column for partial renders V Controls the display of verbose statistics while rendering W Specifies the width of the output image (in pixels) X Controls whether or not POV-Ray can be interrupted once started (only available in certain versions)



A: anti-aliasing The "A" parameter is a toggle that controls anti-aliasing of the rendered image. "+A" turns on anti-aliasing, "-A" turns it off. The default is "-A". Anti-aliasing works by determining how different two adjacent pixels are, and if they are too different, POV-Ray shoots extra rays into the scene (it supersamples the pixel) and colors the pixel with the averaged value. Note that because anti-aliasing requires extra rays to be traced, it drastically increases the amount of time to render the scene. It's not uncommon for anti-aliasing to double or triple the rendering time of a scene. Thus, it's a good idea to only use this option for final images, or right before you go to bed for the night. The following scenes and zoom-ins should should make anti-aliasing more clear. The first has no anti-aliasing, the second was rendered with "+A -J".

The "distance" between two colors is determined by summing the absolute values of the differences of each color component (phew!). For example, if you have two colors <0.2, 0.6, 0.8> and <0.3, 0.3, 0.9>, the difference will be 0.5 (0.1 + 0.3 + 0.1). If the distance between two colors is greater than the threshold (0.3 by default), then the pixels will be anti-aliased. This threshold can be changed by specifying a float with the "+A". For example, "+A1.5" will only anti-alias if the distance between two colors is greater than 1.5. The maximum threshold is 3.0, which effectively turns off anti-aliasing. Setting the threshold to 0.0 will make POV-Ray anti-alias every pixel. The number of rays used to supersample a pixel can be controlled with the R parameter. You can introduce a random jitter into the supersampling rays with the J parameter.



B: buffer size The value of this parameter controls how many pixels POV-Ray should calculate between disk writes. By default, POV-Ray will write to the disk after every line is calculated. The POV-Ray authors recommend +B30 as a good value for speeding up small renders. Note that "-B" cannot be used to turn off the output buffer.

C: continue interrupted render This is a toggle which can be used to get POV-Ray to continue work on a partially completed render. This is useful for when you have a trace which is taking a particularly long time to render, and you need to do something else with the computer for a while. You can interrupt the trace (see the X parameter), do what you need to do, and then restart with "+C". The default value of this toggle is "-C" (start anew).

D: display image The D parameter controls whether or not POV-Ray displays the image as it renders it. The parameter for D is system dependent, and display-while-render is not ed across all platforms. There should be system specific documentation with POV-Ray that details this parameter for your particular system.

E: ending row The E and ER parameters are used to tell POV-Ray to stop tracing after a certain row. E and ER are functionally equivalent. If their parameter is an integer, it specifies the row number on which to stop. If it is a float, it specifies a fraction of the image to render. This is useful for debugging a scene when you are only interested in a part of it. For example, if your image is 256 pixels high (see the H parameter), "+E192" and "+E0.75" will have the same effect. This is useful in concert with some or all of S, SC, and EC to render a rectangular portion of an image.

EC: ending column The EC parameter is used set the ending column for a partial image render. If the value for the parameter is an integer, POV-Ray interprets it to be the absolute number of the stopping column. If the value is a number betweem 0.0 and 1.0, POV-Ray interprets it to be a fraction the image width. For example, if your image is 256 pixels wide, "-EC160" and "-EC0.625" have the same effect. This parameter can be used in concert with E, S, and SC to specify a rectangular region of the image to render.



F: output file type The F parameter is used to control the file output format. Three file output types are ed, Truevision Targas, Dumps, and raw data output. These can be specified using the "+FT", "+FD", and "+FR". Of these, the Targas are probably the most useful and widely ed. You can disable file output by specifying "-F". It's a good idea to have F or D enabled (or both), otherwise you'll just spend a lot of time doing nothing.

H: image height The H parameter is used to specify the height of the output image in pixels. If not specified, it will default to 100. This parameter can take any value between 1 and 32,767 (inclusive). For example, specifying "-H768" will render an image that is 768 pixels high. To avoid weird distortion effects, it's a good idea to have the ratio of H and W be the same as the ratio of the up and right vectors in the camera.

I: input file The I parameter is used to specify the file from which POV-Ray will read the scene description. By convention, input files have the extension ".pov", but this is not required. If no I parameter is specified, POV-Ray will try to read from "object.pov". If you wanted to render the file "shmoo.pov", you would specify "-Ishmoo.pov". As this parameter is not a toggle, both "+" and "-" work equally well in specifying it.

J: jitter The J toggle controls the use of jitter when anti-aliasing an image. When "+J" is specified (this is the default when +A is given), POV-Ray will randomly perturb the extra rays it uses to do the anti-aliasing. This serves to break up edges and prevent annoying moire patterns along anti-aliased edges. J can also take a parameter between 0.0 and 1.0 which controls how much jittering will be done. The default is 1.0. Values greater than 1.0 aren't recommended because they cause supersampling rays to be jittered outside the pixel. The first image below was anti-aliased without jittering, the second, with. Although it's difficult to tell the difference, you'll notice that the zoom-in on the second image is a bit different from the zoom-in of the first.



To set the jitter to something lower, you could try "+J0.5". "-J" will turn off pixel jittering.

K: clock The K parameter is used to specify a value for the clock variable. This is useful for creating simple animations, but won't help too much with more complex stuff. It takes any floating point number as a parameter. If not specified, the value of the clock variable will be zero. For example, to set the value of the clock variable to "3.14159", you would give the parameter "+K3.14159".

L: library paths The L parameter is used to specify search paths for the various features of POV-Ray. When searching for an external file, POV-Ray will first look in the current directory, and then any directories given with the L parameter. You can use this to specify up to ten different search directories. These search directories are used for including files, or for images used in height fields, image maps, bump maps, and material maps. For example, you had your include files in the subdirectory "include" and your image maps in a subdirectory "images", you could tell POV-Ray to search those two directories when appropriate by giving the parameters "-Linclude -Limages".



MB: control automatic bounding This parameter is used to control POV-Ray's use of things called bounding slabs. When a scene reaches a predetermined complexity (defined by the number of objects in the scene), POV-Ray will divide them up and group them with these bounding slabs. These are very efficient bounding objects, and can speed a render greatly. However, for scenes which aren't very complex, the overhead involved in computing the slabs outweights any benefits. The value of the MB parameter is used to set the object threshold for the use of bounding slabs. By default it is 25, and this is a good limit. If you wanted to turn the threshold up to 50, you would issue the parameter "+MB50". "-MB" will turn off the use of bounding slabs.

MS: control symbol table size This parameter is used to control the size of POV-Ray's internal symbol table. Space in this table is allocated for everything that is declared in a scene file. Note that the standard include files tend to have a great number of declared identifiers, and this can cause the symbol table to fill up more quickly than you would expect. The default symbol table will hold 1000 symbols. If you get a "Too many symbols" error message, you need to either decrease the number of declares in your scene, or increase the size of the symbol table (the latter being the easier of the two). To increase the size of the symbol table to 2000 symbols, give the parameter "-MS2000". "+MS2000" will work just as well.

MV: set version The MV parameter is used to tell POV-Ray what version scene files it's reading. Two values can be specified for this parameter, 1.0 and 2.0. The default is 2.0, which is the syntax covered in this tutorial. However, if you want to render a scene which uses v1.0 syntax, you can use this parameter to get POV-Ray to recognize it. Note that there have been some changes to the language which will not be fixed with this parameter. Inside the scene file you can change the version with the #version directive.

O: set output filename The O parameter is used to tell POV-Ray what file to output to when file output is enabled. If not specified, it will default to "-Odata.tga". If the file you specify already exists, it will be overwritten. If, for example, you wanted to send the output to "shmoo.tga", you would give the parameter "-Oshmoo.tga". "+Oshmoo.tga" will work just as well.



P: wait for keypress The P parameter is a toggle which tells POV-Ray whether or not to wait for a keypress after it's done rendering. The default value is "-P" (don't wait for keypress). "+P" is useful for pausing when you're displaying an image.

Q: set rendering quality The Q parameter is used to tell POV-Ray what quality you want to render the image at. The default value is 9 (highest) quality. Rendering lower quality images is useful for debugging a scene. Lower quality settings will disable mroe and more features, resulting a quicker and quicker and render. This parameter can take a value from 0 (low quality, quick render) to 9 (high quality, not-as-quick render). The following list summarizes the effects of the different quality settings. +Q0, +Q1 Use quick colors (or gray scale) to color objects. Ambient light only. No shadows, no shading, no reflections, no transmission, no refraction, and area lights are rendered as point lights. +Q2, +Q3 Enables diffuse lighting and shading of objects. +Q4 Enables shadow calculations. +Q5 Enables area lights. +Q6, +Q7 Stops using quick colors, and instead colors objects based on their assigned textures. +Q8, +Q9 Enables reflection and transparency calculations (including refraction). The following images are of the same scene, rendered at quality settings 1, 3, 5, 7, and 9, respectively.



R: number of supersampling rays The R parameter is used to control how many rays POV-Ray will supersample with when it is anti-aliasing. The default value is 3, which means that POV-Ray will use a 3x3 grid of rays. Giving the parameter "+R5" will tell POV-Ray to use a 5x5 grid. Normally, the default value is sufficient to make a scene look nice. You shouldn't need to use high values of R. Note that since the number of extra rays increases with the square of this number, setting it much beyond 5 or 6 is a bad idea unless you're going on vacation for a week. The following two images show the difference between "+R3" (default) and "+R5", respectively, when anti-aliasing. Although the two zoomed-in images don't look to different, the second normal size image has softer, better looking edges. These softer edges are even more apparent when the image is still in 24-bit color (as opposed to the 8-bits ed by .GIFs).



S: starting row The S or SR parameter is used to specify a starting row for a partial image render. If the value given for this parameter is an integer, POV-Ray assumes you're giving a line number, and will start rendering at the specified row. If the value is instead between 0.0 and 1.0, POV-Ray interprets it as a fraction of the image height. For example, if your image is 256 pixels high, then the arguments "-S64" and "-S0.25" will have the same effect. Note that "+S" will work just as well in both these cases. This parameter is useful in conjunction with E, SC, and EC for specifying a rectangular portion of the image to render.

SC: starting column The SC parameter is used to specify the starting column for partial image renders. If the value given for this parameter is an integer, it is assumed to be the absolute column number on which to begin. If it is a number betweem 0.0 and 1.0, it is interpreted to be a fraction of the total image width. For example, if your image is 256 pixels wide, then "-SC32" and "-SC0.125" are the same. This parameter is useful to use with S, E, and EC to render a rectangular portion of an image.

V: verbose The V parameter allows you to control the verbose reporting of statistics while rendering. This is only useful when you aren't displaying the image. "+V" gives a report of how much of the image has rendered, while "-V" turns that reporing off. The default value is "-V".

W: image width The W parameter is used to specify the width of the rendered image. If you don't specify a width, it will default to 100 pixels. The image width can be anywhere from 1 to 32,767 pixels. As an example, to set the width of the image to 1024 pixels, you would give "-W1024". "+W1024" will work just as well. To avoid weird image distortion, it's a good idea to make the ratio between the W and H values the same as the ratio between the right and up vectors in the camera.

X: allow interrupt In certain versions (the DOS version, for example) the "+X" option will allow you to halt the rendering by hitting a key. "-X" will make it so that the only way to stop the trace is to reboot the computer. "-X" is useful for when you're starting a long trace and you don't want anyone to accidently stop it. If you do



stop an trace (when in +X mode), you can restart it later with the C option.

Reference Index

Top of Document

Main Page



http://library.thinkquest.org/3285/language/src/cmdln2.pov

plane { y, -2 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } rotate y*10 } box { <-1, -1, -1>, <1, 1, 1> pigment { color rgb <0.5685, 0.7095, 0.7785> } rotate <0, 45, 0> rotate <55, 0, 0> } light_source { <-1, 4, -1> color rgb <1, 1, 1> } camera { location <1, 4, -1> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/cmdln2.pov [9/12/2001 3:27:18 PM]

The Online POV-Ray Tutorial: Camera

The Online POV-Ray Tutorial Camera The following topics are covered in this section. ● Camera ●

Direction

●

Location

●

Look At

●

Right

●

Sky

●

Up

The following predominantly blue scene will be used to demonstrate the effects of the various camera modifiers.

Camera The camera defines what you exactly you see when you render an image. The camera is probably the sinlge most important element of a scene. Without a camera, there is no image (although it may just be all black without a few other things). There can only be one camera per scene. The POV-Ray camera is a very simple type of camera. It is not a "lens" camera, and consequently everything in the scene is always in focus. All you usually need to worry about with a camera is where it is and where it's pointing. The default settings usually take care of the rest. The general form for declaring a camera is something like this camera { location sky <sky vector> up right http://library.thinkquest.org/3285/language/camera.html (1 of 6) [9/12/2001 3:28:11 PM]


direction look_at /* translations, rotations, and scales */ } When declaring a camera, components that appear should do so in this order. This is because some later components modify previous ones, and putting them in the wrong order may result in your camera not doing exactly what you expect. Actually, the only really important ordering is that "look_at" should appear after "direction" if they are both present. Location is pretty self evident; it tells POV-Ray where in space to locate the camera. It takes an <x, y, z> vector of the location. Sky is used to tell the camera which way is up. Modifying this value can be used to roll the camera around its central axis. Up, right, and direction are used to modify the field of view and aspect ratio of the image. Direction and look_at are used to point the camera at a specific point in the scene. Direction is more typically used with up and right to define field of view then to position the camera, though. Most of the time, you'll only need to use "location" and "look_at" to define your camera. The other specifiers can be used for fine tuning a scene and producing special effects. After the camera is declared, it can be transformed like any other object. Any transformation applied to object modify the location of the camera and (potentially) the direction it's pointing.

Direction The direction vector is primarily used in conjunction with up and right to define the field of view. It can also be used to implement a telephoto lens or, less commonly, to orient the camera (but this is more commonly done with look_at. The default value of direction is <0, 0, 1>. Increasing the magnitude of the direction vector "stretches" the viewing pyramid and creates a telephoto sort of effect. Decreasing the magnitude of the direction vector "compresses" the viewing pyramid and gives the effect of a wide-angle camera. Here are some sample images with different direction vectors. The first uses "direction <0, 0, 0.5>", the second "direction <0, 0, 1>", the third "direction <0, 0, 2>", and the fourth "direction <0, 0, 4>".

http://library.thinkquest.org/3285/language/camera.html (2 of 6) [9/12/2001 3:28:11 PM]


The direction vector should always be perpendicular to the up and right vectors. For more information on declaring cameras, see the camera section.

Location The location keyword tells POV-Ray where to position the camera. This parameter must always be specified. It takes an <x, y, z> vector which tells the location of the camera. Note that if you have specified an look_at point, moving the location will also rotate the camera (maybe), while if you instead specify a direction, changing the location will not modify the rotation of the camera. For more information on declaring cameras, see the camera section.

Look At The look_at parameter controls the orientation of the camera. It is by far the easiest way to get the camera to point at the thing you want it to point at. You can also specify a camera direction with the direction vector, but this becomes tedious when you're not looking directly along an axis. Also, when you specify a look_at point, you can move the camera around and modify the parameters to your heart's delight, and the POV-Ray will rotate the camera around so it still points at the same place. Note that if look_at is specified with direction, the look_at specifier should appear after the location specifier. This is because the direction vector resets the direction that camera points. Anyway, here's our sample scene with various look_at points.

One thing to keep in mind when using look_at is that the location and look_at points should never be set http://library.thinkquest.org/3285/language/camera.html (3 of 6) [9/12/2001 3:28:11 PM]


so that the camera is looking directly down (parallel to the y-axis). If you want an "overhead" view, either offset the camera some small amount in the x or z direction, or rotate the entire scene so it just appears like you're looking straight down (but are actually looking along, say, the z-axis). For more information on declaring cameras, see the camera section.

Right The right vector controls the width of the view. It is used in conjunction with the up vector to define the aspect ratio of the image. Aspect ratios are covered in more depth in the up section. The angular width of the viewing pyramid can be found with the following equation. The vertical bars mean the magnitude (length) of the named vector. width = 2 * atan(|right| / |direction|) This diagram may help make the relationship of the right and direction vectors more clear. This is a diagram of the viewing pyramid as it would look from above.

Increasing the magnitude of the right vector will make the viewing pyramid wider, and consequently make the image appear "squished" in the left-right direction. Conversely, decreasing the magnitude of the right vector will make the viewing pyramid thinner, and make the image appear "stretched" in the left-right direction. Making the value of the right vector negative will reverse the image left to right. A right vector with a magnitude of zero is bad. The first image below was rendered with "right <4/3, 0, 0>", the second with "right <1, 0, 0>", and the third also with "right <1, 0, 0>" but rendered at 120x120 instead of 160x120.



For more information on declaring cameras, see the camera section.

Sky The vector tells the camera which way is up. This is not to be confused with the up vector which defines the aspect ratio. The default sky vector is <0, 1, 0>. By modifiying this value, you can roll the camera around its central axis. The sky vector, if specified, must appear before the look_at point is specified. This vector has no effect if look_at is not specified. The first image below is rendered with "sky <2, 1, 0>", and the second with "sky <0, -1, 0>".

For more information on declaring cameras, see the camera section.

Up The up vector is used to define the height of the viewing pyramid and, in conjunction with the right vector, the aspect ratio of the image. The combination of the up and direction vectors defines the angular height of the viewing pyramid. This can be found with the following equation. The vertical bars mean to take the magnitude (length) of the named vector. height = 2 * atan(|up| / |direction|) This diagram may clarify the relationship between the up and direction vectors. This is a diagram of the viewing pyramid as it would look from the side.



The default value of the up vector is "up <0, 1, 0>". This, together with the value "right <4/3, 0, 0>" (also default) defines the aspect ratio of the rendered image to be (4/3) / (1) = 4/3. This is the standard aspect ratio for most computer screens. Resolutions like 800x600, 640x480, and 1024x768 all have 4/3 aspect ratios. 320x200 also has a 4/3 aspect ratio, even though it would seem like it should be 8/5. This is because this resolution does not use square pixels. To prevent your image from looking distorted, it's a good idea to make the camera's aspect ratio the same as the image's aspect ratio. Modifying the value of the up vector independently of the right and direction has the same stretch/squish effect as with the right vector, only this stretch/squish is in the vertical direction. Reference Index

Top of Document




http://library.thinkquest.org/3285/language/src/camera.pov

#declare Cam = camera { location <0, 2, -10> look_at <0, 2, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> } camera { Cam }

http://library.thinkquest.org/3285/language/src/camera.pov [9/12/2001 3:28:17 PM]

http://library.thinkquest.org/3285/language/src/camera1.pov

#declare Cam = camera { location <0, 2, -10> direction <0, 0, 0.5> look_at <0, 2, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> } camera { Cam }

http://library.thinkquest.org/3285/language/src/camera1.pov [9/12/2001 3:28:28 PM]


camera { location <0, 2, -10> direction <0, 0, 2> look_at <0, 2, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> }



camera { location <0, 2, -10> direction <0, 0, 4> look_at <0, 2, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> }



#declare Cam = camera { location <0, 2, -10> look_at <0, -4, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> } camera { Cam }



#declare Cam = camera { location <0, 2, -10> look_at <-4, 0, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> } camera { Cam }



#declare Cam = camera { location <0, 2, -10> look_at <4, 4, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> } camera { Cam }



#declare Cam = camera { location <0, 2, -10> right <1, 0, 0> look_at <0, 2, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> } camera { Cam }



#declare Cam = camera { location <0, 2, -10> sky <2, 1, 0> look_at <0, 2, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> } camera { Cam }



#declare Cam = camera { location <0, 2, -10> sky <0, -1, 0> look_at <0, 2, 0> } disc { <0, 0, 0>, y, 5 pigment { checker color rgb <0.3, 0.3, 1> color rgb <0, 0, 0.7> } } union { cylinder { <0, 0, 0>, <0, 4, 0>, 0.5 } cylinder { <-2, 0, -2>, <-2, 2, -2>, 0.5 } cylinder { <2, 0, -2>, <2, 2, -2>, 0.5 } cylinder { <-2, 0, 2>, <-2, 2, 2>, 0.5 } cylinder { <2, 0, 2>, <2, 2 2>, 0.5 } pigment { color rgb <0, 0, 1> } } light_source { <20, 50, -50> color rgb <1, 1, 1> } camera { Cam }


The Online POV-Ray Tutorial: Normal Reference

The Online POV-Ray Tutorial Normal Reference The following topics are covered in this section. ● Bump Map ●

Bumps

●

Dents

●

Normal

●

Ripples

●

Waves

●

Wrinkles

The following scene is used for examples of the different normal modifiers. Right now it contains a Featureless Red Sphere. Some phong was added to make the effects of the normal modifiers more apparent.

The "bumps 0" statement was added just to keep POV from complaining. It doesn't actually have any effect in this scene.

Bump Map Bump maps are sort of a cross between an image map and a height field. They allow you to map a set of normals around an object. The intensity of the pixel value at each point in the input file for the bump map determines the "height" of the corresponding point. This can be changed with the "use_index" keyword (see below). Here's the general syntax for a bump map. normal { bump_map { type "filename" [bump_size size]

http://library.thinkquest.org/3285/language/normal.html (1 of 6) [9/12/2001 3:30:25 PM]


[interpolate mode] [use_color] [use_index] [once] [map_type map mode] } } Any specifiers in square brackets ([]) are optional. type specifies the type of the file that is the source for the bump map. It should be gif, iff, tga, or dump. This is followed by the full name of the file (filename), in double quotes. This image will mapped onto the object. The image will be mapped onto the x-y plane and rescaled to fit into the range (0, 0), (1, 1). To chnage this default mapping mode, you can make use of the map_type keyword. Larger images do not produce larger bump maps, but rather bumps maps with better resolution. By default, the bump map is repeated infinitely in the x and y directions; this can be altered with the once keyword. The bump_size parameter is used to control the apparent depth of the bumps generated by the bump map. This can be any number you want, as long as you don't want 0. 0 is bad. Large numbers give you big depths, small numbers give you little wrinkles. Negative numbers make the highs into lows and the lows into highs. Normally (ha!), the relative height of each point on the mapped surface is determined by the intensity (gray scale value) of the corresponding pixel. This creates a surface which looks like it has the image embossed into it. If you would rather have the bump map height based on the palette index of the corresponding color (as with height fields) you can include the optional keyword "use_index". The "use_color" keyword may be included to specifically state that a bump map uses the default behavior. It will not usually have any effect. Interpolation is good for smoothing out jagged or low resolution bump maps. By default, POV-Ray takes each surface intersection and assigns it a pixel value in the bump map. With low resolution bump maps, the surface will look blocky. Interpolation smooths the bump map by averaging surrounding pixel values. The parameter for interpolation tells POV-Ray what kind of interpolation to use. This can be either 2 (Bilinear) or 4 (Normalized Distance). As is usual with such things, you can either get speed or quality. Bilinear interpolation is better, but Normalized Distance is faster. By default, no interpolation is used.

Bumps The bumps normal creates a random bumpy pattern on the object. In fact, it uses a similar pattern to the bozo pigment. The result is really pretty cool. The bumps normal takes a float parameter from 0.0 (Flat) to 1.0 (Mountainous) that describes the depth of the bumps. The following image was rendered with "bumps 1.0".



By default the bumps are pretty large (about 0.5 to 1.0 units across), so the normal was scaled down to make it fit. Note that this only changes the spacing of the bumps, it does not modify their apparent depth. For more information on declaring normals, see the normal section.

Dents The dents normal basically makes the object look like someone attacked it with a sledgehammer. The surface appears to have dents (naturally enough) beaten into it. Dents takes a float parameter from 0.0 (Brand New) to 1.0 (Survived a Hail Storm) which specifies the depth of the dents. Here's what happens if we take the Featureless Red Sphere and beat it up a bit with "dents 1.0".

The normal was scaled to get it to fit nicely onto the sphere. Note that scaling only changes the spacing of the dents, it does not modify their depths. For more information on declaring normals, see the normal section.

Normal The normal component of a texture allows you to create effects on the surface of an object. Since much of the way we perceive objects is based on how they reflect light, it is possible to trick the eye into thinking a surface is bumpy by just modify the surface normal vectors. This is what the "normal" modifier does. Say you wanted to create a lake with ripples moding across the surface. Trying to model such a thing mathematically (whether with height fields or csg) would be excrutiatingly painful. So POV-Ray gives you the ability to modify the way light reflects off of the surface. Although not 100%



realistic, it's "close enough" for most purposes. You should note, though, that specifying a normal modifier for an object does not actually change the location of the surface, it just makes it look different. But anyway, here's how to specify a normal modifier for an object (really it's quite simple). normal { type depth /* OR */ bump_map { /* bump map specifiers */ } /* modifiers go here */ /* any rotations, scales, and translations go here */ } Normals have three parts, the type, the modifiers, and then transformations. A normal can only have one type, and that is one of bumps, dents, ripples, waves, or wrinkles. They each take a depth parameter between 0.0 (Flat) and 1.0 (Violent). Each type is covered with an examples in its own section. One modifier that is ed for normals is turbulence. Turbulence is covered in depth in the pigment section and will not be covered again here. Turbulence can really create some wacky normals. As an example, here's a standard ripples normal and another with "turbulence 0.7". Note the ripples have been translated to put their center on the top of the sphere.

Only certain normal modifiers respond to the keywords "frequency" and "phase". These are the ripples and waves. The frequency keyword controls the density of the ripples or waves, while phase controls their location. Incrementing phase from 0.0 to 1.0 will bring the normal back to where it started from. Transformations that are applied to normals only modify the locations of the normal components, they do not change the depths of the normals. You can create some pretty wacky effects (in animations) by translating bumps or dents perpendicular to the surface of the object. Normals are fun to play with, and easy to specify. They should be added last, in the "fine tuning" section of scene production. They can turn an object that looks great into an object that looks absolutely spectacular.



Ripples The ripples normal creates evenly space, smooth ripples which originate from 10 random locations inside the box with corners <0, 0, 0>, <1, 1, 1>. All the waves have the same frequency, so the ripple effect is smooth at a significant distance from the center. Ripples takes the standard 0.0 to 1.0 parameter. Compare the look of ripples to that of waves. Here's how ripples look, scaled a bit and translated so they will appear on the surface of the previously Featureless Red Sphere.

The appearance of these ripples can be modified to some extent with the frequency and phase modifiers. For more information on declaring normals, see the normal section.

Waves Waves are similar to ripples, except instead of creating smooth, even ripples, it creates more rough and tumble waves. Theoretically these look more like deep ocean waves. The waves normal takes the standard 0.0 (Becalmed) to 1.0 (Tsunami) parameter. Here's what "waves 1.0" looks like (scaled to some extent to get it to look good).

The appearance of the waves can be modified to some extent with the frequency and phase modifiers. For more information on declaring normals, see the normal section.



Wrinkles Wrinkles is one of the neatest surface normals, but it is also one of the slowest to compute. This normal specifier basically makes the object look like it had been wadded up and then stretched back out again. It basically works repeatedly denting the surface with smaller and smaller dents. Here's how a wrinkled by otherwise Featureless Red Sphere might look.

For more information on declaring normals, see the normal section.

Reference Index

Top of Document




http://library.thinkquest.org/3285/language/src/norm.pov

#declare Norm = normal { bumps 0 /* no normal in this one */ } sphere { <0, 0, 0>, 1 pigment { color rgb <1, 0, 0> } finish { phong 0.8 } normal { Norm } } plane { y, -2 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } rotate y*30 } light_source { <200, 200, -200> color rgb <1, 1, 1> } camera { location <0, 4, -1> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/norm.pov [9/12/2001 3:30:26 PM]

http://library.thinkquest.org/3285/language/src/norm1.pov

#declare Norm = normal { bumps 1.0 scale 1/4 } sphere { <0, 0, 0>, 1 pigment { color rgb <1, 0, 0> } finish { phong 0.8 } normal { Norm } } plane { y, -2 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } rotate y*30 } light_source { <200, 200, -200> color rgb <1, 1, 1> } camera { location <0, 4, -1> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/norm1.pov [9/12/2001 3:30:36 PM]


#declare Norm = normal { dents 1.0 scale 1/4 } sphere { <0, 0, 0>, 1 pigment { color rgb <1, 0, 0> } finish { phong 0.8 } normal { Norm } } plane { y, -2 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } rotate y*30 } light_source { <200, 200, -200> color rgb <1, 1, 1> } camera { location <0, 4, -1> look_at <0, 0, 0> }



#declare Norm = normal { ripples 1.0 scale 1/4 translate <0, 1, 0> } sphere { <0, 0, 0>, 1 pigment { color rgb <1, 0, 0> } finish { phong 0.8 } normal { Norm } } plane { y, -2 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } rotate y*30 } light_source { <200, 200, -200> color rgb <1, 1, 1> } camera { location <0, 4, -1> look_at <0, 0, 0> }



#declare Norm = normal { ripples 1.0 turbulence 0.7 scale 1/4 translate <0, 1, 0> } sphere { <0, 0, 0>, 1 pigment { color rgb <1, 0, 0> } finish { phong 0.8 } normal { Norm } } plane { y, -2 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } rotate y*30 } light_source { <200, 200, -200> color rgb <1, 1, 1> } camera { location <0, 4, -1> look_at <0, 0, 0> }



#declare Norm = normal { waves 1.0 scale 1/4 translate <0, 1, 0> } sphere { <0, 0, 0>, 1 pigment { color rgb <1, 0, 0> } finish { phong 0.8 } normal { Norm } } plane { y, -2 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } rotate y*30 } light_source { <200, 200, -200> color rgb <1, 1, 1> } camera { location <0, 4, -1> look_at <0, 0, 0> }



#declare Norm = normal { wrinkles 1.0 scale 1/4 } sphere { <0, 0, 0>, 1 pigment { color rgb <1, 0, 0> } finish { phong 0.8 } normal { Norm } } plane { y, -2 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } rotate y*30 } light_source { <200, 200, -200> color rgb <1, 1, 1> } camera { location <0, 4, -1> look_at <0, 0, 0> }


The Online POV-Ray Tutorial: About

The Online POV-Ray Tutorial About The Online POV-Ray Tutorial ThinkQuest Team, creators of the Online POV-Ray Tutorial, is: ● Owen Aftreth, from Some High School, Anchorage, Alaska. (E-mail) (Home Page) (Picture) ●

Grant Emery, from Thomas Jefferson High School for Science and Technology, Alexandria, Va. (E-mail) (Home Page) (Picture)

●

William Morgan, from Thomas Jefferson High School for Science and Technology, Alexandria, VA (E-mail) (Home Page) (Picture)

Or, you can the team as a whole. Please read about the Tutorial's design. Top of Document

Main Page


http://library.thinkquest.org/3285/about.html [9/12/2001 3:30:51 PM]

http://library.thinkquest.org/3285/images/owen.gif

http://library.thinkquest.org/3285/images/owen.gif [9/12/2001 3:30:55 PM]

http://library.thinkquest.org/3285/images/grant.gif

http://library.thinkquest.org/3285/images/grant.gif [9/12/2001 3:31:36 PM]

http://library.thinkquest.org/3285/images/william.jpg

http://library.thinkquest.org/3285/images/william.jpg [9/12/2001 3:31:45 PM]

http://library.thinkquest.org/3285/language/src/cmdln1.pov

disc { <0, 0, 0>, y,7 pigment { checker color rgb <1, 1, 0> color rgb <1, 0.3, 0> quick_color rgb <1, 1, 0> } } sphere { <-1.5, 1.5, 0>, 1 pigment { color rgbf <0.8, 0.8, 0.8, 0.8> quick_color rgb <0, 1, 0> } finish { refraction 1 ior 1.5 phong 0.8 } } box { <-1, -1, -1>, <1, 1, 1> pigment { marble color_map { [0.0 color rgb <0, 0, 0>] [1.0 color rgb <1, 1, 1>] } turbulence 1 quick_color rgb <0, 1, 1> } finish { reflection 0.25 } rotate <0, 45, 0> rotate <-35.264, 0, 0> translate <1.5, 1.5, 0> } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <0, 2, -5> look_at <0, 2, 0> }

http://library.thinkquest.org/3285/language/src/cmdln1.pov [9/12/2001 3:31:47 PM]

The Online POV-Ray Tutorial: Texture Library

The Online POV-Ray Tutorial Texture Library This is a list of POV-Ray textures that you can include in any scenes you create yourself. Some are provided with the POV-Ray package, and some have been contributed by other s of the Tutorial. If you have a texture of your own that you would like to contribute to the library, please do so!

Author & -Contributed textures: ●

model:

●

T_DRFantasy: green-pink-violet veins, uses pigment_map->POV3.0 is highly recommended

●

Agate: Sort of a "Moss Agate" clear with green veining

●

Dying Star: A fiery maelstrom of reds and oranges. Top of Document

http://library.thinkquest.org/3285/gather/texture_lib.html [9/12/2001 3:31:50 PM]

Main Page

The Online POV-Ray Tutorial: Texture Library - Contribution

The Online POV-Ray Tutorial Texture Library - Contribution The texture title is required may be anything you wish; it would help if it were in some way meaningful for the texture you are contributing. The short description, while not required, would be helpful and, if entered, should be a terse description of the texture itself, perhaps describing a style or material that the texture resembles. (Doesn't resemble?) If your texture needs further explanation, please describe it in whatever detail you feel is necessary within the source itself, preferably as a POV-Ray comment. Thanks! Note: we check submissions frequently for "appropriateness". Please only POV-Ray source to this library. Anything deemed inappropriate will be removed from the library.

-Contribution Form for POV-Ray Textures Texture Title: Short Description: Texture Source:

It's probably most efficient to just cut-and-paste the source into this window, but feel free to just type it in if you want. Contribute this texture Reset submission form

Main Page

http://library.thinkquest.org/3285/Contribute_Texture.html [9/12/2001 3:31:51 PM]

The Online POV-Ray Tutorial: Texture -

The Online POV-Ray Tutorial POV-Ray Texture: model

Texture Library

http://library.thinkquest.org/3285/gather/textures/model.html [9/12/2001 3:31:55 PM]

Main Page


The Online POV-Ray Tutorial POV-Ray Texture: T_DRFantasy green-pink-violet veins, uses pigment_map->POV3.0 is highly recommended /* T_DRFantasy: Uses pigment_map{}: POV-Ray version 3.0 is recommended I don´t know any material that looks like this. If you like the texture or if you have any suggestions for the name of it, please e-mail me: [email protected] ... always interested in other textures!!! */ #declare T_DRFantasy = texture { pigment { bozo pigment_map { [ 0.0 marble color_map { [0.0 color rgb [1.0 color rgb } frequency 2.0 turbulence 1.0 ] [ 0.3 marble color_map { [0.0 color rgb [1.0 color rgb } frequency 2.0 turbulence 1.0 ] [ 1.0 marble color_map { [0.0 color rgb [1.0 color rgb } frequency 2.0 turbulence 1.0

<0.0, 0.0, 0.0>] <0.2, 0.0, 0.5>]

<0.0, 0.0, 0.0>] <0.0, 0.3, 0.2>]

<0.0, 0.0, 0.0>] <0.6, 0.1, 0.15>]

http://library.thinkquest.org/3285/gather/textures/TDRFantasy.html (1 of 2) [9/12/2001 3:32:06 PM]


] } turbulence 0.5 rotate <20, 59, 100> scale 0.1 } finish { ambient 0.05 diffuse 0.6 reflection 0.05 specular 0.4 roughness 0.4 metallic } }

Texture Library

Main Page

http://library.thinkquest.org/3285/gather/textures/TDRFantasy.html (2 of 2) [9/12/2001 3:32:06 PM]


The Online POV-Ray Tutorial POV-Ray Texture: Agate Sort of a "Moss Agate" clear with green veining #declare Agate_Map = color_map { [0.0, 0.8 color rgbft color rgbft [0.8, 1.0 color rgbft color rgbft }

<0.1, <0.0, <0.1, <0.0,

0.6, 0.3, 0.6, 0.2,

0.1,0,1> 0.0,.2,.25>] 0.1,.4,.75> 0.0,.6,0>]

#declare Agate = pigment { marble turbulence 1.8 color_map { Agate_Map } }

Texture Library

http://library.thinkquest.org/3285/gather/textures/Agate.html [9/12/2001 3:32:16 PM]

Main Page


The Online POV-Ray Tutorial POV-Ray Texture: Dying Star A fiery maelstrom of reds and oranges #declare DyingStar = texture { pigment { bozo color_map { [0.0 color rgb <0.3, 0, 0>] [1.0 color rgb <0.6, 0.2, 0>] } turbulence 0.3 scale 1/2 } } texture { pigment { agate color_map { [0.0 color rgbf <1, 1, 1, 1>] [0.5 color rgbf <1, 1, 1, 1>] [0.5 color rgbf <0.5, 0, 0, 1>] [0.75 color rgb <0.5, 0, 0>] [1.0 color rgb <1, 0.5, 0>] } turbulence 1.0 scale 1.5 } } texture { pigment { granite color_map { [0.0 color rgb <1, 1, 0>] [0.2 color rgbf <1, 1, 1, 1>] [1.0 color rgbf <1, 1, 1, 1>] } } }

http://library.thinkquest.org/3285/gather/textures/DyingStar.html (1 of 2) [9/12/2001 3:32:19 PM]


Texture Library

Main Page

http://library.thinkquest.org/3285/gather/textures/DyingStar.html (2 of 2) [9/12/2001 3:32:19 PM]

The Online POV-Ray Tutorial: Object Library

The Online POV-Ray Tutorial Object Library This is a list of POV-Ray objects that you can include in any scenes you create yourself. Some of them are provided in POV-Ray sample scenes, some are objects we have provided, and some are objects contributed by other s of the Tutorial. (Which is from where all the really good stuff is going to come!) If you have an object of your own that you would like to contribute to the library, please do so!

Author & -Contributed objects: ●

triangular pyramid:

●

●

Chain: This is an include file that creates a "Chain" object at the origin, stretching along the +z axis. You specify the texture, link length, link thickness, and number of links you want in your chain, and it does the rest! mesilla:

●

Eye: Source for the eyeball seen in the title image Top of Document

http://library.thinkquest.org/3285/gather/object_lib.html [9/12/2001 3:32:29 PM]

Main Page

The Online POV-Ray Tutorial: Object Library - Contribution

The Online POV-Ray Tutorial Object Library - Contribution The object title is required may be anything you wish; it would help if it were in some way meaningful for the object you are contributing. The short description, while not required, would be helpful and, if entered, should be a terse description of the object itself; if your object needs further explanation, please describe it in whatever detail you feel is necessary within the object source itself, preferably as a POV-Ray comment. Within your code, you need not define a camera or light sources for your object. If your object is either a union, intersection, or difference, however, you will need to enter the entire declaration, beginning with "#declare objectname = ..." Thanks! Note: we check submissions frequently for their "appropriateness". Please only POV-Ray source to the library. Anything deemed inappropriate will be removed from the library.

-Contribution Form for POV-Ray Objects Object Title: Short Description: Object Source:

It's probably most efficient to cut-and-paste the source into this window, but you can just type here if you want. Contribute this object Reset submission form

Main Page

http://library.thinkquest.org/3285/Contribute_Object.html [9/12/2001 3:32:30 PM]

ThinkQuest Library of Entries

ThinkQuest Participant ThinkQuest Library of Entries News See the ThinkQuest Junior 2001 Winners! Wed, 12-Sep-2001, 05:57:48 AM EST The ThinkQuest Library of Entries

Competitions My ThinkQuest Communities Calendar Library of Entries Featured Entries

Raza

The ThinkQuest Library of Entries is the collection of educational web sites designed by participants in the ThinkQuest Contests. Teachers and learners can explore a multitude of topics. These sites have been organized to help you find what you need with an easy to use Index of Categories or search by keyword below.

Browse or Search

Search The Library

Advanced Search

Search

Exact Match

Winners IC 2000 Winners

Featured Sites! This month's featured entries are: Summer Fun Sites! Check them out!

ThinkQuest

Any Match

ThinkQuest Junior

ScienceQuest Sites Policies Initiatives Help/ Resources Press Room About ThinkQuest About This WebSite Home

| Disclaimer | of Use © 1995-2001, ThinkQuest Inc. all rights reserved

http://www.thinkquest.org/library/ [9/12/2001 3:32:47 PM]

Tomorrow's Teachers

The Online POV-Ray Tutorial: Object -

The Online POV-Ray Tutorial POV-Ray Object: triangular pyramid

Object Library

Main Page

http://library.thinkquest.org/3285/gather/objects/triangularpyramid.html [9/12/2001 3:32:50 PM]


The Online POV-Ray Tutorial POV-Ray Object: Chain This is an include file that creates a "Chain" object at the origin, stretching along the +z axis. You specify the texture, link length, link thickness, and number of links you want in your chain, and it does the rest! // // // //

Chain Object Include File David J.V. Brown Questions/comments: [email protected] April 25, 1997

/* INSTRUCTIONS: In your .pov scene file, declare the following: ChainTex = [texture]; texture for the links of the chain. MajR = [FLOAT]; major radius of torus, corresponds to length of individual link. MinR = [FLOAT]; minor radius of torus, corresponds to thickness of a link. NLinks = [INT]; number of links you want the chain to contain. After those are declared, add this line: #include "chain.inc" An object called Chain will be declared starting at the origin with the first link in the xz plane and extending NLinks along +z.

You can then add

instances of the object and translate/rotate it however you like. */ // Main Declaration Section #declare Origin = <0,0,0> // Objects #declare WholeR = MajR + (2 * MinR) + 0.05 /* HalfBoxP1 = bottom near left point of box used to cut torus in half HalfBoxP2 = top far right point of box used to cut torius in half -- 0.05 is added length to ensure that cutting box extends past torus -*/ #declare HalfBoxP1 = Origin - (x*WholeR) - (y*MinR + 0.05) #declare HalfBoxP2 = Origin + (x*WholeR) + (y*MinR + 0.05) + (z*WholeR) #declare Ring = torus { MajR, MinR texture {ChainTex} } // Object used to cut torus in half before adding extenders to create a link.

http://library.thinkquest.org/3285/gather/objects/Chain.html (1 of 3) [9/12/2001 3:32:58 PM]


#declare HalfBox = box { HalfBoxP1, HalfBoxP2 texture {ChainTex} } /* Extender: the cylinder used to make the chain links oblong. Created at origin and extends along the +z axis, to be translated later. ExtTrans: the +/- x translation factor to line the extender up with the HalfRing. */ #declare ExtTrans = x * MajR #declare Extender = cylinder {Origin, MajR*z, MinR texture {ChainTex} } /* HalfRing: the original torus cut in half. HalfTrans: the +z translation to put the flipped HalfRing on to close the Link. Flip: flips the 1st HalfRing over about the x axis to line it up right. Note: Flip first, THEN translate, or it'll all get screwed up! */ #declare Flip = x*180 #declare HalfTrans = z*MajR-0.01 #declare HalfRing = difference { object { Ring } object { HalfBox } } // Definition of one completed chain link: #declare Link = merge { object {HalfRing} object {Extender translate ExtTrans+(-0.01*z)} object {Extender translate -ExtTrans+(-0.01*z)} object {HalfRing rotate Flip translate HalfTrans} } /* Now create a procedure to generate a chain of NLinks length. The chain will extend in the +z direction. */ #declare Chain = Link

// Initialize the Chain

#declare NLinks = NLinks - 1

// Correct for initializaton link

#declare Count = 1 #while (Count <= NLinks) #declare LinkTrans = z * ((3*MajR) - (MinR*2)) * Count #declare LinkRot = z * Count * 90 #declare Chain = union { http://library.thinkquest.org/3285/gather/objects/Chain.html (2 of 3) [9/12/2001 3:32:58 PM]


object{Chain} object {Link rotate LinkRot translate LinkTrans } } #declare Count = Count + 1 #end

Object Library

Main Page

http://library.thinkquest.org/3285/gather/objects/Chain.html (3 of 3) [9/12/2001 3:32:58 PM]


The Online POV-Ray Tutorial POV-Ray Object: mesilla /* X: -23, 23 Y: 0, 45.4 Z: -18, 16 (los tiradores sobresalen un poco mas) */ #declare Tabla = difference { superellipsoid {<.05, .05>} plane {y, 0.8} translate -0.8*y scale <23, 6, 16> } #declare Tirador = union { sphere {<0, 2.25, 0>, 1.25} cone {<0, 0, 0>, 1.25, <0, 2.25, 0>, 0} rotate -90*x scale .8 } #declare Cajon = difference { superellipsoid {<.05, .05>} plane {y, 0.8} translate -0.8*y scale <20, 6, 6> rotate -90*x } #declare Cajon = union { object {Cajon} object {Tirador translate <-12, 0, -1.2>} object {Tirador translate <12, 0, -1.2>} } #declare Pata = cone {<0, 0, 0>, 1.25, <0, -13, 0>, .35} #declare Mesilla = union { box {<-22, -15, -15>, <22, 15, -13.8> texture {T_Wood10 scale 10 rotate 89*y} } http://library.thinkquest.org/3285/gather/objects/mesilla.html (1 of 2) [9/12/2001 3:33:01 PM]


box {<-22, -15, 13.8>, <22, 15, 15> texture {T_Wood10 scale 10 rotate 89*y} } box {<-22, -15, -13.8>, <22, 15, 13.8> texture {T_Wood10 scale 10 translate <0, 20, 0>} } object {Tabla translate <0, 15, 0> texture {T_Wood10 scale 10 rotate 89*y} } object {Tabla rotate 180*z translate <0, -15, 0> texture {T_Wood10 scale 10 rotate 89*y} } object {Cajon translate <0, texture {T_Wood10 scale 10 } object {Cajon translate <0, texture {T_Wood10 scale 10 }

7, -15> rotate 89*y translate <0, 14, 0>} -7, -15> rotate 89*y translate <0, -20, 0>}

object {Tirador translate <-12, 7, -16.2> texture {T_Wood10} } object {Tirador translate <-12, 7, -16.2> texture {T_Wood10} } object {Pata translate <-18, -16.2, -11> texture {T_Wood10 scale 6 rotate 89*y} } object {Pata translate <-18, -16.2, 11> texture {T_Wood10 scale 6 rotate 89*y} } object {Pata translate <18, -16.2, -11> texture {T_Wood10 scale 6 rotate 89*y} } object {Pata translate <18, -16.2, 11> texture {T_Wood10 scale 6 rotate 89*y} } translate <0, 29.2, 0> }

Object Library

Main Page

http://library.thinkquest.org/3285/gather/objects/mesilla.html (2 of 2) [9/12/2001 3:33:01 PM]


The Online POV-Ray Tutorial POV-Ray Object: Eye Source for the eyeball seen in the title image #declare Eyeball = sphere { <0, 0, 0>, 1 texture { pigment { granite color_map { [0.0 color LightBlue] [0.5 color SteelBlue] [1.0 color LightBlue] } scale 1/3 turbulence 0.2 rotate <90, 0, 0> } } texture { pigment { wood color_map { [0.0 color Black] [0.225 color Black] [0.225 color Clear] [0.45 color Clear] [0.45 color White] [1.0 color White] } scale 2 } } }

Object Library

http://library.thinkquest.org/3285/gather/objects/Eye.html [9/12/2001 3:33:03 PM]

Main Page

The Online POV-Ray Tutorial: Color Tool

The Online POV-Ray Tutorial Color Tool To find the color you need, enter the values in the text field (from 0.0 to 1.0) or slide the scrollbars. The values in the text fields correspond to the components in a POV-Ray color vector. For example, if you have found a color you like with a red component of 0.5, a green component of 0.75, and a blue component of 0.0, the resulting POV-Ray color vector would be <0.5, 0.75, 0>. Note that the more colors your terminal can display, the more accurate the Color Tool will be. If your terminal cannot display many colors, you may not get an accurate reading. If the square on the left stays black, you need a better display. Main Page


http://library.thinkquest.org/3285/color_tool.html [9/12/2001 3:33:11 PM]

The Online POV-Ray Tutorial: Example Scenes

The Online POV-Ray Tutorial Example Scenes Here we have some example scenes and their source, so you can see how different things were done. All scenes here were rendered by the authors. Beware, some of the images are rather large.

The title image for the Tutorial. Rendered by Grant Emery. (Source)

A landscape inspired by The Martian Chronicles (Ray Bradbury). Rendered by William Morgan. (Source)

"The Last Outpost" by Grant Emery. (Source)

http://library.thinkquest.org/3285/scenes_lib.html (1 of 2) [9/12/2001 3:33:43 PM]

The Online POV-Ray Tutorial: Example Scenes

"On Display" by Grant Emery. (Source)

"Columns" by Grant Emery. (Source)

Top of Document

Main Page


http://library.thinkquest.org/3285/scenes_lib.html (2 of 2) [9/12/2001 3:33:43 PM]

http://library.thinkquest.org/3285/scenes/title.jpg

http://library.thinkquest.org/3285/scenes/title.jpg [9/12/2001 3:34:46 PM]

http://library.thinkquest.org/3285/scenes/title.pov

#include "colors.inc" #include "textures.inc" #include "stones.inc" /* the letters */ height_field { gif "c:\temp\titleimg.gif" water_level 0.01 texture { Stone13 finish { phong 0.2 } scale 1/4 } translate <-0.5, 0, -0.5> scale <358/191, 1/6, 1> rotate <-90, 0, 0> scale 1.2 rotate <7.5, 0, 2.5> } /* the floor */ disc { <0, -1.5, 0>, y, 4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> scale 1/2 } } #declare Eyeball = sphere { <0, 0, 0>, 1 texture { pigment { granite color_map { [0/2 color LightBlue] [1/2 color SteelBlue] [2/2 color LightBlue] } scale 1/3 turbulence 0.2 rotate <90, 0, 0> } } texture { pigment { wood color_map { [0.0 color Black] [0.225 color Black] [0.225 color Clear] [0.45 color Clear] [0.45 color White] [1.0 color White] } scale 2 } } }

http://library.thinkquest.org/3285/scenes/title.pov (1 of 3) [9/12/2001 3:34:47 PM]


object { Eyeball scale 1/3 rotate <45, -45, 0> translate <-0.7, -0.7, 0> } /* the reflective box in the upper right */ box { <-0.25, -0.25, -0.25>, <0.25, 0.25, 0.25> texture { Silver2 } rotate <0, 45, 0> rotate <-55, 0, 0> translate <0.9, 0.7, 0> } /* sky sphere with sunrise texture */ sphere { <0, 0, 0>, 10000 texture { pigment { radial color_map { [0.0 color rgb <1, 1, 1>] [0.5 color rgb <0.3, 0.6, 1>] [1.0 color rgb <1, 1, 1>] } frequency 12 rotate <90, 0, 0> } finish { diffuse 0 ambient 0.9 } } texture { pigment { wood color_map { [0.0 color rgb <1, 1, 1>] [0.1 color rgb <1, 1, 1>] [0.25 color rgbf <1, 1, 1, 1>] [1.0 color rgbf <1, 1, 1, 1>] } scale 20000 } finish { diffuse 0 ambient 0.9 } } } light_source { <50, 150, -500> color rgb <1.5, 1.5, 1.5> } camera { location <0, 0, -2> look_at <0, 0.01, -0.5>



}


http://library.thinkquest.org/3285/scenes/mars3.jpg

http://library.thinkquest.org/3285/scenes/mars3.jpg [9/12/2001 3:35:21 PM]

http://library.thinkquest.org/3285/scenes/mars.pov

#include "ruins.inc" #declare landsize = 200 #declare landheight = 100 #declare #declare #declare #declare

lightpos = <-250, 100, 50> moonpos = <-450, 200, 800> ruinspos = <0, -42,-75> camerapos = <10, -12, -130>

#declare #declare #declare #declare #declare

Brown = color rgb <.247, .165, .165> MarsRed = color rgb <.31, .185 .185> White = color rgb <1, 1, 1> Black = color rgb <0, 0, 0> Gray = color rgb <.5, .5, .5>

#declare MountainT = texture { pigment { bozo turbulence .25 color_map { [0, 1 color Brown color MarsRed ] } } normal { bumps 1 } finish { crand .05 } } #declare PlainsT = texture { MountainT normal { bumps 1 } normal { dents 1 } scale 1/5 } #declare SkyT = texture { pigment { granite turbulence 1 color_map { [0, .01 color White color White] [.01, .5 color Black color Black] [.5, .501 color Gray color Gray] [.501, 1.01 color Black color Black] } } finish { ambient 1 } } #declare MoonT = texture { pigment { color rgb <.3, .32, .3> } normal { dents .5 } normal { bumps .5 } } camera {

http://library.thinkquest.org/3285/scenes/mars.pov (1 of 3) [9/12/2001 3:35:22 PM]


location camerapos look_at camerapos * <0, 1, 0> } /*fog { color rgb <.05, .05, .05> distance 1000 }*/ light_source { lightpos color White } light_source { lightpos + <1, 0, 0> color White } light_source { lightpos - <1, 0, 0> color White } light_source { lightpos + <0, 1, 0> color White spotlight point_at moonpos - <20, 0, 0> radius 5 falloff 10 tightness 10 } /*light_source { lightpos - <0, 1, 0> color White spotlight point_at moonpos - <20, 0, 0> radius 5 falloff 10 tightness 10 }*/ // mountain range height_field { pot "marsmnt.pot" smooth water_level .08 scale translate <-landsize/2, -landheight/2, -landsize/2> texture { MountainT scale 10 } } // sky sphere { <0, 0, 0>, 1000 texture { SkyT scale 250 } no_shadow } // plains disc { <0, 0, 0>, <0, 1, 0>, 180 texture { PlainsT scale 10 } translate <0, -42, 0> } // moon sphere { moonpos, 100 texture { MoonT scale 10 } no_shadow }



// ruins object { Ruins scale .25 translate ruinspos } //light_source { camerapos + <0, 1, 0> color White } //light_source { camerapos - <0, 1, 0> color White }


http://library.thinkquest.org/3285/scenes/outpost.jpg

http://library.thinkquest.org/3285/scenes/outpost.jpg [9/12/2001 3:38:46 PM]

http://library.thinkquest.org/3285/scenes/outpost.pov

#declare #declare #declare #declare #declare #declare

mnt_size = 75 sea_level = mnt_size / 4 island_cen = <39, 0, 36> island_size = 25 island_top = island_cen + (sea_level + island_size/2 + 2) * y dish_cen = island_top + 10 * y

#declare mnt_txtr_1 = texture { pigment { gradient y color_map { [0.0 color rgbf <1, 1, 1, 1>] [0.3 color rgbf <1, 1, 1, 1>] [0.35 color rgbf <1, 1, 1, 0>] } turbulence 0.1 scale <0.25, 2, 0.25> } } #declare mnt_txtr_2 = texture { pigment { bozo color_map { [0.0 color rgb <0.0, 0.6, 0.4>] [1.0 color rgb <0.0, 0.8, 0.6>] } scale 0.01 } } #declare sky_col = color rgb <159/255, 127/255, 55/255> #declare sky_tex = texture { pigment { bozo color_map { [0.0 color sky_col] [0.75 color rgb <0, 0, 0>] [1.0 color rgb <0, 0, 0>] } } finish { ambient 0.8 } } height_field { gif "fract002.gif" // water_level 0.25 texture { mnt_txtr_2 } texture { mnt_txtr_1 } rotate <0, -90, 0> translate <1, 0, 0> scale <100, mnt_size, 100> } plane { // water y, sea_level pigment { color rgb <0.5, 0.5, 0.5> /*rgb <0.196078, 0.6, 0.8>*/ } normal { ripples 0.5 translate island_cen

http://library.thinkquest.org/3285/scenes/outpost.pov (1 of 5) [9/12/2001 3:38:48 PM]


} finish { reflection 1.0 } clipped_by { box { <0, 0, 0>, <100, 100, 100> } } bounded_by { clipped_by } } /*#include "claw.pov" object { claw_set scale 5 translate island_cen + island_top * y pigment { color rgb <0, 0.4, 0.7> } finish { specular 0.5 } } */ #include "fl_islan.pov" object { fl_island scale island_size translate island_top texture { mnt_txtr_2 } } cylinder { island_top, dish_cen, 0.5 pigment { color rgb <0.7, 0.7, 0.7> } finish { specular 0.5 } } #include "dish.pov" object { dish rotate <0, 180, -30> translate dish_cen pigment { color rgb <1, 1, 1> } } #declare build_base_txt = texture { pigment { color rgb <0, 0, 0> } finish { specular 0.8 } } #declare win_txt = texture { pigment { color rgb <1, 1, 1> } finish { reflection 0.5 } } #declare building = cylinder { <0, 0, 0>, <0, 1, 0>, 0.5 texture { material_map { gif "winmap.gif" map_type 2 texture { build_base_txt } texture { win_txt } }



} } union { object { building scale <6, 4, 6> } sphere { <0, 0, 0>, 0.5 texture { build_base_txt } scale <6, 2, 6> translate <0, 4, 0> } translate island_top } union { intersection { object { building scale <6, 4, 6> } plane { y, 2 } } sphere { <0, 0, 0>, 0.5 scale <6, 2, 6> translate <0, 2, 0> texture { build_base_txt } } translate <3, 0, 0> rotate 60*y translate island_top } union { intersection { object { building scale <6, 4, 6> } plane { y, 1 texture { build_base_txt } } } sphere { <0, 0, 0>, 0.5 scale <6, 2, 6> translate <0, 1, 0> texture { build_base_txt } } translate <3, 0, 0> rotate 120*y translate island_top }



/* the flag and flagpole */ #declare flag = object { cubic { <-0.500000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.500000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000> } clipped_by { box { <-1, -0.75, -1>, <1, 0.75, 1> } } } union { cylinder { <0, 0, 0>, <0, 6.2, 0>, 0.1 pigment { color rgb <0.9, 0.91, 0.98> } finish { specular 0.8 } } sphere { <0, 6.2, 0>, 0.2 pigment { color rgb <0.8, 0.498, 0.196> } finish { specular 0.8 } } object { flag pigment { hexagon color d_col color d_col_2 color d_col_2 rotate <90, 0, 0> scale 0.5 } translate <1, 5.25, 0> } rotate <0, 10, 0> translate <8, 0, 0> rotate <0, 50, 0> translate island_top } cone { // sky -- obsolete if fog is used, but looks cool anyway <3500, 0, 5500>, 0 <0, 0, 0>, 2500 open texture { sky_tex scale 200 } no_shadow } /*fog { color rgb <0.5, 0.5, 0.5> distance 60 } */ light_source { <-3000, 2500, -500> color rgb <1, 1, 1> } camera { location <15, 45, -5>



//

look_at <65, 30, 50> look_at <40, 35, 50>

}


http://library.thinkquest.org/3285/scenes/froo.jpg

http://library.thinkquest.org/3285/scenes/froo.jpg [9/12/2001 3:40:00 PM]

http://library.thinkquest.org/3285/scenes/froo.pov

#include "colors.inc" #include "textures.inc" #include "stones.inc" #default { finish { ambient 0.3 } } #declare groove = union sphere { <0, 3 + 5/22, 0>, } cylinder { <0, 3 + 5/22, 0>, } sphere { <0, 9 - 5/22, 0>, } }

{ 5/22 <0, 9 - 5/22, 0>, 5/22 5/22

#declare groove_bunch = union { object { groove translate <-2.5, 0, -2.5> } object { groove translate <-2.5 + 5/6, 0, -2.5> } object { groove translate <-2.5 + 2 * 5/6, 0, -2.5> } object { groove translate <-2.5 + 3 * 5/6, 0, -2.5> } object { groove translate <-2.5 + 4 * 5/6, 0, -2.5> } object { groove translate <-2.5 + 5 * 5/6, 0, -2.5> } } #declare pedestal_end_4 = difference { box { <-3.5, 0, -3.5>, <3.5, 2, 3.5> } cylinder { <-4, 2, -3.5>, <4, 2, -3.5>, 1 } plane { x - z, 0 } plane { -x - z, 0 } texture { Rosewood scale 2 rotate <0, 90, 0> } }

http://library.thinkquest.org/3285/scenes/froo.pov (1 of 11) [9/12/2001 3:40:04 PM]


#declare pedestal_end = union { object { pedestal_end_4 } object { pedestal_end_4 rotate <0, 90, 0> } object { pedestal_end_4 rotate <0, 180, 0> } object { pedestal_end_4 rotate <0, 270, 0> } bounded_by { box { <-3.5, 0, -3.5>, <3.5, 2, 3.5> } } } #declare pedestal = union { difference { object { pedestal_end rotate <180, 0, 0> translate <0, 12, 0> } box { <-2.5, 11, -2.5>, <2.5, 13, 2.5> } } difference { box { <-2.5, 2, -2.5>, <2.5, 10, 2.5> } object { groove_bunch } object { groove_bunch rotate <0, 90, 0> } object { groove_bunch rotate <0, 180, 0> } object { groove_bunch rotate <0, 270, 0> } texture { Rosewood rotate <90, 0, 0> scale 2 } } object { pedestal_end } bounded_by { box { <-3.5, 0, -3.5>, <3.5, 14, 3.5>



} } } #declare case = union { difference { box { <-2.5, 0, -2.5>, <2.5, 5, 2.5> } box { <-2.4, -1, -2.4>, <2.4, 4.9, 2.4> } } difference { box { <-2.5, 0, -2.5>, <2.5, 5, 2.5> } box { <-3, -1, -2.4>, <3, 4.9, 2.4> } box { <-2.4, -1, -3>, <2.4, 4.9, 3> } box { <-2.4, -1, -2.4>, <2.4, 6, 2.4> } pigment { color rgb <0, 0, 0.25> } } } union { object { pedestal } object { case pigment { color rgbf <1, 1, 1, 1> } finish { reflection 0.1 refraction 1 ior 1.5 // Glass } translate <0, 12, 0> } box { <-2.4, 11, -2.4>, <2.4, 12, 2.4> pigment { gradient y color_map { [0.00 color rgb <0.75, 0, 0>] [0.33 color rgb <0.75, 0.75, 0>] [0.50 color rgb <0, 0.75, 0>] [0.66 color rgb <0, 0, 0.75>] [1.00 color rgb <0.75, 0, 0>] } scale 3 turbulence 1.0 translate <3, 4, 2> // random location } /* image_map { gif "pedestal.gif"



interpolate 2 } rotate <90, 0, 0> translate <-0.5, 0, -0.5> scale 5 } */ finish { brilliance 0.3 } } translate <-2, 0, -2> } /*#include "tjsym.pov" object { tjsym scale 3.5/30 translate <-2, 14.5, -2> pigment { color Gray80 } } */ /*#include "dodeca.pov" object { dodeca scale 3.5/2 rotate <0, 0, 90> translate <-2, 14.5, -2> texture { Stone13 } } */ #include "icosa.pov" object { icosa scale 3.5/2 // rotate <90, 0, 0> translate <-2, 14.5, -2> texture { Stone9 } } plane { // the floor y, 0 texture { material_map { gif "matmap.gif" texture { // White Marble pigment { White_Marble } finish { reflection 0.1 } } texture { // Black Marble pigment { marble turbulence 1 color_map { [0.0, 0.8 color red 0.1 green 0.1 blue 0.1 color red 0.5 green 0.5 blue 0.5] [0.8, 1.01 color red 0.5 green 0.5 blue 0.5



color red 0.8 green 0.8 blue 0.8] } rotate <0, 90, 0> } finish { reflection 0.1 } } texture { // Gold pigment { color BrightGold } finish { ambient 0.2 diffuse 0.7 reflection 0.5 brilliance 6 phong 0.5 phong_size 80 metallic } } } scale 10 rotate <90, 0, 0> } } #declare wall_texture = texture { pigment { image_map { gif "wp_flor7.gif" interpolate 2 } scale 10 } } #declare wall = union { plane { -z, 0 texture { wall_texture } } intersection { plane { -z, 1 } plane { y, 1 } } quadric { <0, 1, 1>, <0, 0, 0>, <0, 0, 0>, -1 translate <0, 1, 0> } } object { wall pigment { color White } translate <0, 0, 30> }



object { wall pigment { color White } rotate <0, -90, 0> translate <-30, 0, 0> } #declare shelf_ = difference { union { box { <-0.25, 0, 0>, <0.25, -1, -4> } box { <-0.25, 0, 0>, <0.25, -4, -1> } box { <-0.25, -1, -1>, <0.25, -2, -2> } /* intersection { cubic { <0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.222222, -1.000000, 0.000000, 0.000000> rotate <90, 0, 0> translate <-4, -1, 0> inverse } plane { x, 0.25 } plane { -x, 0.25 } plane { y, -1 } plane { z, -1 } } */ cylinder { <-0.25, -1, -3>, <0.25, -1, -3>, 1 } cylinder { <-0.25, -3, -1>, <0.25, -3, -1>, 1 } } cylinder { <-0.5, 2, 2>, <0.5, 2, 2>, 1 } bounded_by { box { <-0.25, 0, 0>, <0.25, -4, -4> } } } #declare shelf_top = intersection { union { box { <-2.5, 0, 0>, <2.5, 1.5, -5> } cylinder { <-2.5, 0.75, -5>, <2.5, 0.75, -5>, 0.75



} cylinder { <-2.5, 0.75, 0>, <-2.5, 0.75, -5>, 0.75 } cylinder { <2.5, 0.75, 0>, <2.5, 0.75, -5>, 0.75 } sphere { <2.5, 0.75, -5>, 0.75 } sphere { <-2.5, 0.75, -5>, 0.75 } } plane { y, 0.5 } bounded_by { box { <-3.25, 0, 0>, <3.25, 0.5, -5.75> } } } #declare shelf = union { object { shelf_top texture { Rosewood scale 2 } } object { shelf_ translate <1.5, 0, 0> texture { Rosewood } } object { shelf_ translate <-1.5, 0, 0> texture { Rosewood } } } object { shelf translate <-10, 8, 30> } object { shelf translate <8, 8, 30> } #declare frame_4 = intersection { cylinder { <-5, -10, 0>, <-5, 10, 0>, 0.5 } plane { x + y, 0 } plane { -(-x + y), 0 } } #declare picture = union { object {



frame_4 } object { frame_4 rotate <0, 0, 90> } object { frame_4 rotate <0, 0, 180> } object { frame_4 rotate <0, 0, 270> } box { <-5, -5, 0>, <5, 5, -0.01> pigment { image_map { // gif "aliens.gif" tga "d:froo.tga" interpolate 2 } scale 10 translate <-5, -5, 0> } finish { ambient 0.5 } } scale <3/2, 1, 1> texture { Silver_Texture } } object { picture rotate <0, -90, 0> scale 4/5 translate <-30, 10, 10> } union { sphere { // the pot for the plant <0, 0, 0>, 2 clipped_by { box { <-2, -0.75, -2>, <2, 0.75, 2> } } texture { Copper_Texture normal { wrinkles 0.5 } } } plane { y, 0.5 pigment { color DarkBrown } clipped_by { sphere { <0, 0, 0>, 2 } } } translate <-10, 9.25, 27.5> }



#include "narftree.pov" object { narftree scale 0.02 translate <-10, 8.5, 27.5> } #include "narfcrys.pov" object { narfcrys scale 0.3 rotate <0, 30, 0> translate <8, 8.5, 26.5> } #declare lamp_fixture = union { cylinder { <0, -1, -2.5>, <0, 1, -2.5>, 0.75 open pigment { color Black } finish { Shiny } } cylinder { <0, -1, -2.5>, <0, -1.5, -2.5>, 0.75 open texture { Gold_Texture } } cylinder { <0, 1, -2.5>, <0, 1.5, -2.5>, 0.75 open texture { Gold_Texture } } union { cylinder { <0, 0, -2.5>, <0, 0, 0>, 0.25 clipped_by { cylinder { <0, -1, -2.5>, <0, 1, -2.5>, 0.75 inverse } } } cylinder { <0, 0, -0.5>, <0, 0, 0>, 0.3 } cylinder { <0, 0, -0.1>, <0, 0, 0>, 0.75 } pigment { color Black } finish { Shiny } } } object { lamp_fixture translate <8, 20, 30> } light_source { <8, 20, 27.5> color rgb <2, 2, 2> spotlight point_at <8, 10, 27.5> radius 22 falloff 26.56505



} object { lamp_fixture translate <-10, 20, 30> } light_source { <-10, 20, 27.5> color rgb <2, 2, 2> spotlight point_at <-10, 10, 27.5> radius 22 falloff 26.56505 } object { lamp_fixture rotate <0, -90, 0> translate <-30, 20, 10> } light_source { <-27.5, 20, 10> color rgb <1.5, 1.5, 1.5> spotlight point_at <-27.5, 10, 10> radius 22 falloff 26.56505 } // four spotlights centered at <-2, 30, -2> light_source { <6, 30, 6> color Gray60 spotlight point_at <-2, 12, -2> radius 13 falloff 22 } light_source { <-10, 30, -10> color Gray60 spotlight point_at <-2, 12, -2> radius 13 falloff 22 } light_source { <6, 30, -10> color Gray60 spotlight point_at <-2, 12, -2> radius 13 falloff 22 } light_source { <-10, 30, 6> color Gray60 spotlight point_at <-2, 12, -2> radius 13 falloff 22



} //light_source { <40, 40, -20> color rgb <1, 1, 1> } camera { // location <15, 15, -15> // look_at <0, 8, 0> location <10, 19, -18> look_at <0, 11, 0> // location <-10, 11, 20> // look_at <-10, 11, 30> // location <8, 15, 27.5> // look_at <7.9, 20, 27.5> }


// all-illuminating

http://library.thinkquest.org/3285/scenes/rcolumn2.jpg

http://library.thinkquest.org/3285/scenes/rcolumn2.jpg [9/12/2001 3:41:04 PM]

http://library.thinkquest.org/3285/scenes/rcolumns2.pov

#include "colors.inc" #include "textures.inc" #include "stones.inc" #declare Fluting = union { // use with difference to flute the column sphere { <0, 1, 0>,0.0625 } cylinder { <0, 1, 0>,<0, -1, 0>,0.0625 } sphere { <0, -1, 0>,0.0625 } } #declare Column = difference { // the column union { difference { // top of the column cylinder { <0, 2.5, 0>, <0, 2.75, 0>,0.625 } torus { 0.625, 0.125 translate <0, 2.5, 0> } } cylinder { // main cylinder of the column <0, 0.25, 0>, <0, 2.5, 0>,0.5 } difference { cylinder { <0, 0, 0>, <0, 0.25, 0>,0.625 } torus { 0.625, 0.125 translate <0, 0.25, 0> } } } union { // the vertical spaces in the main cylinder object { Fluting translate <0, 1.5, -0.5> } object { Fluting translate <0, 1.5, -0.5> rotate y * -30 } object { Fluting translate <0, 1.5, -0.5> rotate y * -60 } object { Fluting

http://library.thinkquest.org/3285/scenes/rcolumns2.pov (1 of 4) [9/12/2001 3:41:06 PM]


translate <0, 1.5, -0.5> rotate y * -90 } object { Fluting translate <0, 1.5, rotate y * -120 } object { Fluting translate <0, 1.5, rotate y * -150 } object { Fluting translate <0, 1.5, rotate y * -180 } object { Fluting translate <0, 1.5, rotate y * -210 } object { Fluting translate <0, 1.5, rotate y * -240 } object { Fluting translate <0, 1.5, rotate y * -270 } object { Fluting translate <0, 1.5, rotate y * -300 } object { Fluting translate <0, 1.5, rotate y * -330 }

-0.5>

-0.5>

-0.5>

-0.5>

-0.5>

-0.5>

-0.5>

-0.5>

} bounded_by { cylinder { <0, 0, 0>, <0, 2.75, 0>,0.625 } } } object { Column texture { White_Marble finish { phong 1.0 phong_size 90 } } } sphere {



<0, 3.5, 0>,0.5 texture { Stone21 } finish { reflection 0.3 } } object { Column translate <-2, 0, 0> texture { White_Marble finish { phong 1.0 phong_size 90 } } } box { <-0.25, -0.25, -0.25>, <0.25, 0.25, 0.25> rotate <45, 0, 35.2> translate <-2, 3.5, 0> texture { Stone9 } } object { Column translate <2, 0, 0> texture { White_Marble finish { phong 1.0 phong_size 90 } } } /*intersection { difference { cylinder { <0, 0, 0>, <0, 2, 0>,0.5 } torus { 0.5, 0.5 scale <1, 2, 1> translate <0, 1, 0> } } plane { y, 1 } bounded_by { cylinder { <0, 0, 0>, <0, 1, 0>, 0.5 } } translate <2, 3, 0> texture { Stone18 translate <1, 1.25, 1.25> finish { phong 1.0 phong_size 90 } } } */ union { sphere { <0, 0, 0>, 0.25 }



cone { <0, -0.083333, 0>, 0.235702 <0, -0.75, 0>, 0 } bounded_by { box { <-0.25, -0.75, -0.25>, <0.25, 0.25, 0.25> } } translate <2, 3.75, 0> texture { Stone18 finish { reflection 0.3 } } } // the floor and the walls union { plane { y, 0 texture { Sapphire_Agate } } plane { x - z, -3 } plane { -x - z, -3 } texture { Polished_Chrome // finish { phong 0 diffuse 0 metallic } } } camera { location <0, 3.5, -5> look_at <0, 2, 0> } light_source { <3, 6, -2> color rgb <1.25, 1.25, 1.25> spotlight point_at <0, 2, 0> radius 25 falloff 35 tightness 5 } light_source { <-3, 6, -2> color rgb <1.25, 1.25, 1.25> spotlight point_at <0, 2, 0> radius 25 falloff 35 tightness 5 }


The Online POV-Ray Tutorial: Object Library

The Online POV-Ray Tutorial POV-Ray Resources Links for Beginners ●

The comp.graphics.rendering.raytracing FAQ

●

A novices guide to getting started with POV-Ray

●

POV-Ray's pseudo-FTP site, where you can get the official binaries for many platforms, and countless other POV-Ray utilities/related programs

POV-Ray Related Files ●

POVAFX, an unofficial version of POV-Ray with simple atmospheric effects (MSDOS, Win95/NT) Breeze Designer, a freeware modeller for Win95/NT/32s

●

Texture Magic, an interactive texture editor for Win95/NT

●

POVLAB, another shareware modeller for POV-Ray (DOS only)

●

SCED, a constraint-based scene designer for Unix/XWindows

●

Other Online Resources ●

The Official POV-Ray Site

●

●

The Internet Raytracing Competition, a great place to see all manner of spectacular raytraced images. And most of them include the source! A great online texture library

●

The POV-Ray 2.0 documentation in HTML format

●

An online request form from The Tackle Box BBS for s to personally request any obscure or hard-to-find POV-Ray/raytracing related files from the SysOp of that BBS; draws from a base of over 7000 files in 200 different file areas

Main Page

http://library.thinkquest.org/3285/resource_lib.html [9/12/2001 3:41:12 PM]

The Online POV-Ray Tutorial: POV-Ray Update

The Online POV-Ray Tutorial POV-Ray Update During the creation of this Web page, POV-Ray 3.0 was released. POV-Ray 3.0 contains many exciting new features, including ground fog, focal blur, and iterative functions. Unfortunately, we were not able to document all of the additions in time. The Tutorial covers POV-Ray 2.2, and everything found in here will work with POV-Ray 3.0. We advise that s interested in the new features of POV-Ray 3.0 consult its documentation after having gone through the Path of Learning. Top of Document

Main Page


http://library.thinkquest.org/3285/update.html [9/12/2001 3:41:15 PM]

The Online POV-Ray Tutorial: Introduction to POV-Ray and Ray-tracing

The Online POV-Ray Tutorial Introduction to POV-Ray and Ray-tracing (Show Jump Points) (Hide Jump Points) In this section, you will learn what ray-tracing is, how it works, what POV-Ray is, and how POV-Ray relates to the rest of the ray-tracing world. This is a good section if you've never experimented with (or even heard of) ray-tracing before. Quick index: 1. What is ray-tracing? 2. How does ray-tracing work? 3. What is POV-Ray? 4. How do I set up POV-Ray?

What is ray-tracing? Ray-tracing is a method of creating visual art in which a description of an object or scene is mathematically converted into a picture. In more precise , ray-tracing is the process of mathematically generating near-photorealistic images from a given description of a scene via geometrical modeling of light rays. Ray-tracing can generate very beautiful and complex scenes, and can open exciting possibilities as a new method of creating visual art. One of the most important advantages of computer-based ray-tracing over more "orthodox" art forms is that it removes the need for technical skills (such as the ability to paint, draw, or sculpt) that may take years to master, and places the burden on the computer. This leaves the to be as creative as possible, without having to spend years learning difficult skills. In fact, you should be well on your way to creating some exciting pictures before you're far along this tutorial. Ray-tracing can require millions and even billions of complex mathematical calculations and, as such, is usually done by computer (and even then, is not a speedy process). Usually, in the computer-based ray-tracing procedure, a file containing the description of a scene (in that the ray-tracing software can understand, and usually in some human-readable format) is converted, by the computer, into an actual image of the scene. Later on in the tutorial you will learn how to use the POV-Ray software to create scenes of your own, with the help of your computer. Of course, ray-tracing is not a magical technique that makes all art easy. Certain types of scenes are difficult or impossible to create with ray-tracing software. In most cases, you will find that ray-tracing is good at generating mathematically simple objects, such as those composed of spheres, cones and cubes, and poor (slower or more difficult to describe) at generating more complex objects, like a human face. There are several ways of getting around these barriers, but ray-tracing, like all forms of art, does have certain inherent limitations. http://library.thinkquest.org/3285/tutorial/intro.html (1 of 4) [9/12/2001 3:41:25 PM]


Because ray-tracing is based on math, ray-traced scenes have some distinct characteristics. For example, in a simple ray-traced scene, all objects are in focus, and all shadows are crisp and well-defined; in fact, every object in the scene is mathematically perfect. (When was the last time you saw a mathematically perfect pear?) Because of this, images produced by ray-tracing tend to look slightly odd, or even surrealistic, a side-effect many artists can exploit to their benefit. It is, interestingly enough, considered a mark of a "true ray-tracing artist" to be able to create more realistic, "less perfect" scenes.

How does ray-tracing work? We won't go into all the gory details, but having a general understanding of what's going on behind the scenes (so to speak) can be helpful when you start ray-tracing your own images. Although there are several methods of ray-tracing, one of the most common (and the one the POV-Ray software package uses) works something like this: First, an internal model of the scene is generated, with your computer screen included as the receiving "eye" in the model. Then, the software traces imaginary light rays backwards from where their endpoint lies (a pixel on your computer screen) to their initial point (some light source in the scene). This step is repeated, pixel by pixel, until the entire image has been created. The reason the software traces the light rays backwards, instead of starting at the light source, is for efficiency's sake -- if a light ray doesn't end up on your screen, then you, as the , don't care about it (because you'll never see it). By tracing the light rays backwards, beginning at the computer screen, the software can assure that every light ray it calculates is one you care about, because it knows that it will end up on your screen. In their journey, the light rays can be reflected by mirrors, refracted by glass, or undergo various other contortions, all of which result in a single pixel of the final image. Because the ray-tracing software must trace one ray of light for each pixel in the output image, and because the light rays can undergo so many contortions, the process of ray-tracing can take a very long time, depending on the size and complexity of the image and the processing power of your computer. Unless you have an extraordinarily fast computer, you will most likely find yourself waiting around impatiently for your scene to finish rendering once you've begun to ray-trace in earnest.

What is POV-Ray? POV-Ray is a high-quality, freely available ray-tracing software package that is available for PC, Macintosh and UNIX platforms. Yes, that's right, it's free! If you're a programmer interested in POV-Ray, you can also pick up a copy of the source code without charge. POV-Ray is perhaps one of the most commonly used ray-tracing software to date, because of its relative ease of use, cheap price, and high quality. POV-Ray is no toy. Despite not generating any direct income from their POV-Ray software, the POV-Ray Team (the people responsible for POV-Ray) has managed to create a commercial-quality product and, in the true spirit of the Internet, distribute it widely and without charge. As a consequence, http://library.thinkquest.org/3285/tutorial/intro.html (2 of 4) [9/12/2001 3:41:25 PM]


POV-Ray is one of the most popular ray-tracing programs to date. We, the authors of the Tutorial, think that POV-Ray is one of the greatest things to come out of the Internet (gee, is it a little obvious?), which is why we decided to create this Web page. At any rate, POV-Ray is what is known as a "rendering engine". What this means is that POV-Ray will take a file as input and generate an output file, but does not have much in the way of interface. There are modellers available for POV-Ray that will do that kind of visualization for you, if you choose, but we recommend you only start using those tools once you have a firm grasp of the POV-Ray language. Otherwise, you'll get stuck down the road. Describing scenes to POV-Ray is fairly simple. You give POV-Ray a file containing a description of every object in the scene, written in the POV-Ray language (which you will learn later in the tutorial). Each object's description consists of: 1. What type of object you want (one of POV-Ray's simple objects or one you've created yourself); and 2. Various attributes of the object (its color, how it reflects light, etc). POV-Ray takes this file and generates a picture, which you can then view. The Path of Learning is not meant to cover every single detail of the POV-Ray language. Such a task would be tremendous (although the Language Reference has come very close). Instead the Path will guide you as you learn about each section, and, when appropriate, refer you to more complete sources of information. At the end of the Path, you should be well on your way to being a certified POV-Ray blackbelt.

How do I set up POV-Ray? The latest version of POV-Ray can always be found at ftp.povray.org. You will have to the correct version for your computer (there are versions available for most operating systems) and to set it up. Once you have POV-Ray, how you set it up is highly dependant on your operating system. We're not about to teach you how to use your own computer; if you can't set it up yourself, ask a local computer guru to help. As we mentioned above, POV-Ray doesn't have much of an interface; on most operating systems, you will give POV-Ray the name of your input file, the name of your output file, and a whole bunch of other options via the command line. You will also need some form of image viewer and/or converter in order to display the output files that POV-Ray creates; again, this is highly operating-system-dependant. POV-Ray also comes with documentation and example scenes; these make excellent references if you're stuck or need to know more. Ok, we're ready to start learning the real stuff now!

http://library.thinkquest.org/3285/tutorial/intro.html (3 of 4) [9/12/2001 3:41:25 PM]


Top of Document

Main Page

Step 2: POV-Ray Basics


http://library.thinkquest.org/3285/tutorial/intro.html (4 of 4) [9/12/2001 3:41:25 PM]

The Online POV-Ray Tutorial: The Path of Learning

Jump Points Main Page

The Online POV-Ray Tutorial Introduction to POV-Ray and Ray-tracing (Show Jump Points) (Hide Jump Points) In this section, you will learn what ray-tracing is, how it works, what POV-Ray is, and how POV-Ray relates to the rest of the ray-tracing world. This is a good section if you've never experimented with (or even heard of) ray-tracing before.

Introduction Basics Simple Scenes Advanced Conclusion

Quick index: 1. What is ray-tracing? 2. How does ray-tracing work? 3. What is POV-Ray? 4. How do I set up POV-Ray?

Language Reference Glossary / Index

Texture Library Object Library Scene Library Resource Library

Color Tool Normal Tool Finish Tool Note: this frame is resizeable

What is ray-tracing? Ray-tracing is a method of creating visual art in which a description of an object or scene is mathematically converted into a picture. In more precise , ray-tracing is the process of mathematically generating near-photorealistic images from a given description of a scene via geometrical modeling of light rays. Ray-tracing can generate very beautiful and complex scenes, and can open exciting possibilities as a new method of creating visual art. One of the most important advantages of computer-based ray-tracing over more "orthodox" art forms is that it removes the need for technical skills (such as the ability to paint, draw, or sculpt) that may take years to master, and places the burden on the computer. This leaves the to be as creative as possible, without having to spend years learning difficult skills. In fact, you should be well on your way to creating some exciting pictures before you're far along this tutorial. Ray-tracing can require millions and even billions of complex mathematical calculations and, as such, is usually done by computer (and even then, is not a speedy process). Usually, in the computer-based ray-tracing procedure, a file containing the description of a scene (in that the ray-tracing software can understand, and usually in some human-readable format) is converted, by the computer, into an actual image of the scene. Later on in the tutorial you will learn how to use the POV-Ray software to create scenes of your own, with the help of your computer. Of course, ray-tracing is not a magical technique that makes all art easy. Certain

http://library.thinkquest.org/3285/tutorial/intro_frames.html (1 of 4) [9/12/2001 3:41:54 PM]


types of scenes are difficult or impossible to create with ray-tracing software. In most cases, you will find that ray-tracing is good at generating mathematically simple objects, such as those composed of spheres, cones and cubes, and poor (slower or more difficult to describe) at generating more complex objects, like a human face. There are several ways of getting around these barriers, but ray-tracing, like all forms of art, does have certain inherent limitations. Because ray-tracing is based on math, ray-traced scenes have some distinct characteristics. For example, in a simple ray-traced scene, all objects are in focus, and all shadows are crisp and well-defined; in fact, every object in the scene is mathematically perfect. (When was the last time you saw a mathematically perfect pear?) Because of this, images produced by ray-tracing tend to look slightly odd, or even surrealistic, a side-effect many artists can exploit to their benefit. It is, interestingly enough, considered a mark of a "true ray-tracing artist" to be able to create more realistic, "less perfect" scenes.

How does ray-tracing work? We won't go into all the gory details, but having a general understanding of what's going on behind the scenes (so to speak) can be helpful when you start ray-tracing your own images. Although there are several methods of ray-tracing, one of the most common (and the one the POV-Ray software package uses) works something like this: First, an internal model of the scene is generated, with your computer screen included as the receiving "eye" in the model. Then, the software traces imaginary light rays backwards from where their endpoint lies (a pixel on your computer screen) to their initial point (some light source in the scene). This step is repeated, pixel by pixel, until the entire image has been created. The reason the software traces the light rays backwards, instead of starting at the light source, is for efficiency's sake -- if a light ray doesn't end up on your screen, then you, as the , don't care about it (because you'll never see it). By tracing the light rays backwards, beginning at the computer screen, the software can assure that every light ray it calculates is one you care about, because it knows that it will end up on your screen. In their journey, the light rays can be reflected by mirrors, refracted by glass, or undergo various other contortions, all of which result in a single pixel of the final image. Because the ray-tracing software must trace one ray of light for each pixel in the output image, and because the light rays can undergo so many contortions, the process of ray-tracing can take a very long time, depending on the size and complexity of the image and the processing power of your computer. Unless you have an extraordinarily fast computer, you will most likely find yourself waiting around impatiently for your scene to finish rendering once you've begun to ray-trace in earnest.



What is POV-Ray? POV-Ray is a high-quality, freely available ray-tracing software package that is available for PC, Macintosh and UNIX platforms. Yes, that's right, it's free! If you're a programmer interested in POV-Ray, you can also pick up a copy of the source code without charge. POV-Ray is perhaps one of the most commonly used ray-tracing software to date, because of its relative ease of use, cheap price, and high quality. POV-Ray is no toy. Despite not generating any direct income from their POV-Ray software, the POV-Ray Team (the people responsible for POV-Ray) has managed to create a commercial-quality product and, in the true spirit of the Internet, distribute it widely and without charge. As a consequence, POV-Ray is one of the most popular ray-tracing programs to date. We, the authors of the Tutorial, think that POV-Ray is one of the greatest things to come out of the Internet (gee, is it a little obvious?), which is why we decided to create this Web page. At any rate, POV-Ray is what is known as a "rendering engine". What this means is that POV-Ray will take a file as input and generate an output file, but does not have much in the way of interface. There are modellers available for POV-Ray that will do that kind of visualization for you, if you choose, but we recommend you only start using those tools once you have a firm grasp of the POV-Ray language. Otherwise, you'll get stuck down the road. Describing scenes to POV-Ray is fairly simple. You give POV-Ray a file containing a description of every object in the scene, written in the POV-Ray language (which you will learn later in the tutorial). Each object's description consists of: 1. What type of object you want (one of POV-Ray's simple objects or one you've created yourself); and 2. Various attributes of the object (its color, how it reflects light, etc). POV-Ray takes this file and generates a picture, which you can then view. The Path of Learning is not meant to cover every single detail of the POV-Ray language. Such a task would be tremendous (although the Language Reference has come very close). Instead the Path will guide you as you learn about each section, and, when appropriate, refer you to more complete sources of information. At the end of the Path, you should be well on your way to being a certified POV-Ray blackbelt.

How do I set up POV-Ray? The latest version of POV-Ray can always be found at ftp.povray.org. You will have to the correct version for your computer (there are versions available for most operating systems) and to set it up. http://library.thinkquest.org/3285/tutorial/intro_frames.html (3 of 4) [9/12/2001 3:41:54 PM]


Once you have POV-Ray, how you set it up is highly dependant on your operating system. We're not about to teach you how to use your own computer; if you can't set it up yourself, ask a local computer guru to help. As we mentioned above, POV-Ray doesn't have much of an interface; on most operating systems, you will give POV-Ray the name of your input file, the name of your output file, and a whole bunch of other options via the command line. You will also need some form of image viewer and/or converter in order to display the output files that POV-Ray creates; again, this is highly operating-system-dependant. POV-Ray also comes with documentation and example scenes; these make excellent references if you're stuck or need to know more. Ok, we're ready to start learning the real stuff now! Top of Document

Main Page




The Online POV-Ray Tutorial: POV-Ray Basics

The Online POV-Ray Tutorial

POV-Ray Basics (Show Jump Points) (Hide Jump Points) Before you can start creating scenes in POV-Ray, you need to know a few things: how to describe objects in three dimensions, some of POV-Ray's basic notation, and other stuff. This section will give you the background knowledge you'll need to get started. Quick reference: 1. POV-Ray's Coordinate System 2. Vectors in POV-Ray 3. How to describe color: RGB and RGBF Vectors 4. Normal Vectors 5. POV-Ray Source Code 6. Comments in POV-Ray Source Code 7. Including files

POV-Ray's Coordinate System The source code file, the file POV-Ray takes as input, is really one big list of descriptions of objects. The very first thing we need in order to describe objects is a way of telling POV-Ray where things go. Such a method is called a coordinate system. If you have taken elementary algebra, you will already have experience with a simple coordinate system: a two-dimensional (or 2D) Cartesian coordinate system. A quick graph of a 2D Cartesian plane looks something like this:

Any position on this graph can be specified by a set of coordinates, usually written in the form (x,y). The x coordinate corresponds to its position along the horizontal, or x, axis, and the y coordinate corresponds to its position along the vertical, or y axis. For example, (0,0) corresponds to the point in the middle of the graph, or the origin. The point (1,3) corresponds to the point on the graph one unit right from the origin, and three units up from the origin. Negative numbers can also be used: (-6,4) corresponds to the point 6 units left from the origin, and four units up. You get the idea. Now this is all well and good, but when we look at things other than our computer screen, we notice we can observe three dimensions, not two: in other words, we describe objects not just by how far to the http://library.thinkquest.org/3285/tutorial/basics.html (1 of 6) [9/12/2001 3:42:03 PM]


right (or left) and how high (or low) they are, but also how close they are in front (or in back) of you. In other words, to be able to describe a real scene to POV-Ray, we need, in addition to the x and y coordinates, a third coordinate. This coordinate is called (surprisingly enough) the z coordinate. The coordinate system that POV-Ray uses, then, is called a three-dimensional (or 3D) Cartesian coordinate system. A quick graph looks like this:

(You have to use your imagination somewhat: that third axis is not a diagonal but is perpendicular to your computer screen -- imagine it shooting out at your face). As you can see, it looks similar to the 2D graph, except that one additional axis has been added: the z axis. Because of the additional possible direction, points in this coordinate system must be described in the form (x,y,z). The point (0,0,0) corresponds to the origin, or center of the graph, and (1,-2,7) corresponds to the point one unit to the right of, two units below, and seven units behind the origin. If you have experience with mathematical 3D coordinate systems, you will notice that the axes are labelled slightly differently than the system most commonly used in mathematical . The axis we have drawn above is not fixed in POV-Ray -- the way the axis looks (in of which axes are which) really depends on where you place your camera in POV-Ray. We'll get to explaining the camera soon. For now, just understand that the labels on the axes may change, depending on how you position your camera. The 3D graph above represents a coordinate system that POV-Ray can use. Visualizing objects and scenes in three dimensions can be tricky. Often, a pad of paper and a pencil can be extremely valuable tools, especially in more complex scenes. Alternatively, you can take a look at the Resource Library for some graphical tools that may help.

Vectors in POV-Ray POV-Ray calls the number triples that define positions position vectors. The term vector refers to any group of numbers describing a certain thing -- there are color vectors and normal vectors, for example, in addition to position vectors. In POV-Ray, vectors are surrounded by angle brackets (that's < and >). For example, to specify the origin in that POV-Ray understands, we would say <0,0,0>. The magnitude of a vector can be thought of as the "length" of the vector. Imagine a line from the origin to the point in the coordinate system represented by your vector. The magnitude is the length of this line. (If you really care about the math, the magnitute can be computed as the square root of the sum of the squares of the elements of the vector -- but don't worry, you probably won't have to know that).

http://library.thinkquest.org/3285/tutorial/basics.html (2 of 6) [9/12/2001 3:42:03 PM]


An important thing to know about is a POV-Ray feature called vector promotion. Vector promotion is when a single number is substituted in place of a vector. The single number is then promoted to a vector, one with all elements equal to that number. For example, promoting the number 2 to a three-dimensional vector would result in the vector <2,2,2>. Vector promotion is done automatically for you by POV-Ray in most cases -- just put in a single number instead of a vector. This feature allows you to quickly specify similar vectors.

How to describe color: RGB and RGBF Vectors Much as any position within the scene can be specified by a three-element vector, so can any color. In describing a position, each coordinate in the vector corresponds to the position along a particular axis. In describing a color, each element of the vector corresponds to the amount of a primary color -- red, green and blue. Such a vector is called a RGB vector (for red green blue vector). In a position vector, the individual elements can be any real number at all (actually, this isn't quite true -there are upper and lower limits set by the hardware constraints of your computer). In a RGB vector, the numbers should be between 0.0 and 1.0. You can have values higher that 1.0, but they don't correspond to any physical property (what's greener than green?). A value of 1.0 means 100% of that color. For example, the color black, which is actually the absence of all color, is described by the color vector <0,0,0>. The color white, a complete combination of all three primary colors, is specified by the color vector <1,1,1>. Try experimenting with the Color Tool to find the color vectors for particular colors -- it will help you get a good "feel" for describing colors in of POV-Ray color vectors. In addition to RGB vectors, you can specify a color in POV-Ray with an RGBF vector. As you might guess, a RGBF vector is like a RGB vector, but with one extra element - the F, for filter. The filter value specifies how transparent the pigment is, ranging from 0.0 (not transparent at all) to 1.0 (100% transparent). RGB vectors have an implied filter value of 0.0 -- in other words, a color specified by a RGB vector will be perfectly opaque. A filter value of 1.0 means that all light will be let through, but the light will still be filtered. For example, the RGBF vector <1,0,0,1> acts like red cellophane -- 100% of light is ed through, but it is filtered by the red pigment. RGBF vectors can be a little confusing at first, but they aren't too difficult once you get the hang of it. These are the most commonly-used ways of specifying color. There are a few more ways to do it; if you want to read about them, look at the color section of the Language Reference.

Normal Vectors Occasionally you will be called upon to specify a normal vector in POV-Ray. Simply put, a normal vector is a vector parallel to a given plane in three dimensions. Imagine a flat sheet of paper. If you were to poke a pencil all the way through it so that the end of the pencil was touching the paper and the pencil was standing straight up (with respect to the paper), the pencil would represent the normal vector to the paper. In the picture below, the normal vector is in red and the plane is in blue.



Note that the magnitude of normal vectors is not important (as long as it is non-zero). This is because normal vectors are used to specify an orientation, not a distance. POV-Ray is kind enough to automatically define three normal vectors for you: x (corresponding to <1,0,0>), the normal vector for a plane lying along the y and z axes, y (corresponding to <0, 1, 0>), the normal vector for a plane lying along the x and z axes, and z (corresponding to <0, 0, 1>), the normal vector for a plane lying along the x and y axes. Any time you are asked for a normal vector (or any vector, really) you can substitute those letters.

POV-Ray Source Code Source code is the name for the text you give to POV-Ray. POV-Ray reads the source code file and outputs an image. There are two things you need to know about POV-Ray source code: 1. POV-Ray source code is case sensitive 2. POV-Ray ignores whitespace 3. Ordering is unimportant Case sensitive means that upper and lower-case letters are not treated as the same by POV-Ray. For example, to POV-Ray, sphere is not the same as Sphere and is not the same as SpHeRe. Whitespace is the common name for any characters you can't directly see on screen -- spaces, tab characters (the invisible characters put there when you press the Tab key), carriage returns and line feeds (the invisible characters put there when you hit the Enter key). Between any two words or symbols in your source code, POV-Ray doesn't care whether you put one space, two spaces, one hundred spaces, a new line, or any other whitespace. For example, the phrase: one two the phrase one and the phrase

two

one two



are all treated the same by POV-Ray. Ordering means the order in which you declare objects. POV-Ray does not care where in the file the objects are -- it makes no difference to the final scene. (VRML programmers will note that this is a very different approach than VRML's "virtual pen" concept). This does not hold entirely true for some attributes and CSG operations (both of which we will describe in detail later), but in the outer-most level in POV-Ray (the one in which you list the objects in your scene) it doesn't matter.

Comments in POV-Ray Source Code Comments are another useful part of POV-Ray source code. A comment is a portion of text that POV-Ray will ignore. It is used to add information to the source code, usually to make things clearer to the human reader. Comments can be enclosed in /* and */, or, for single-line comments, can be prefixed with a //. For example: // this is a single-line comment /* this is another comment. it can be as long as you want it to be */ C and C++ programmers will recognized this comment style. For a detailed description of comments, see the comments section of the Language Reference.

Including files Including files is a feature of many languages that makes re-using code easier. If you have, for example, many red objects in your scene, you will find it cumbersome (and not very readable) to type the correct RGB vector for red every time. POV-Ray comes to the rescue with a file full of pre-defined colors, which you can use and re-use in your source code. (POV-Ray also comes with files of textures and even objects; we'll get to those later). You can take advantage of these files by adding the string #include "filename" to the beginning of your file. For example, to use the pre-defined colors, you would add the string #include "colors.inc" to the beginning of your file. Technically, the statement does not have to occur at the beginning of the file, but the convention is such, and it makes for readability. The example statement above tells POV-Ray to look for the file called colors.inc and to read it before continuing to the rest of your file. colors.inc defines many colors, such as Red, that you can use in your file any time you need a color, in place of a RGB (or RGBF) vector. This makes your source file much easier to read. Later in the tutorial, you will learn how to define your own colors (and objects, and textures, and so on) and how to put them in your own text files. For now, know how to use the provided ones and be happy. Now that you've got that out of the way, you're ready to start creating your first scene... almost.



Top of Document

Main Page

Step 1: Introduction to POV-Ray and Ray-tracing

Step 3: Creating Simple Scenes




The Online POV-Ray Tutorial

Jump Points

POV-Ray Basics (Show Jump Points) (Hide Jump Points)

Main Page

Before you can start creating scenes in POV-Ray, you need to know a few things: how to describe objects in three dimensions, some of POV-Ray's basic notation, and other stuff. This section will give you the background knowledge you'll need to get started. Quick reference: 1. POV-Ray's Coordinate System


2. Vectors in POV-Ray 3. How to describe color: RGB and RGBF Vectors 4. Normal Vectors 5. POV-Ray Source Code 6. Comments in POV-Ray Source Code 7. Including files




POV-Ray's Coordinate System The source code file, the file POV-Ray takes as input, is really one big list of descriptions of objects. The very first thing we need in order to describe objects is a way of telling POV-Ray where things go. Such a method is called a coordinate system. If you have taken elementary algebra, you will already have experience with a simple coordinate system: a two-dimensional (or 2D) Cartesian coordinate system. A quick graph of a 2D Cartesian plane looks something like this:

Any position on this graph can be specified by a set of coordinates, usually written in the form (x,y). The x coordinate corresponds to its position along the horizontal, or x, axis, and the y coordinate corresponds to its position along the vertical, or y axis. For example, (0,0) corresponds to the point in the middle of the graph, or the origin. The point (1,3) corresponds to the point on the graph one unit right from the origin, and three units up from the origin. Negative numbers can also be used: (-6,4) corresponds to the point 6 units left from the origin, and four units up. You get the idea. Now this is all well and good, but when we look at things other than our computer screen, we notice we can observe three dimensions, not two: in other words, we describe objects not just by how far to the right (or left) and how high (or low) they are, but also how close they are in front (or in back) of you. In other words, to be able to describe a real scene to POV-Ray, we need, in addition to the x and y coordinates, a third coordinate. This

http://library.thinkquest.org/3285/tutorial/basics_frames.html (1 of 5) [9/12/2001 3:42:40 PM]


coordinate is called (surprisingly enough) the z coordinate. The coordinate system that POV-Ray uses, then, is called a three-dimensional (or 3D) Cartesian coordinate system. A quick graph looks like this:

(You have to use your imagination somewhat: that third axis is not a diagonal but is perpendicular to your computer screen -- imagine it shooting out at your face). As you can see, it looks similar to the 2D graph, except that one additional axis has been added: the z axis. Because of the additional possible direction, points in this coordinate system must be described in the form (x,y,z). The point (0,0,0) corresponds to the origin, or center of the graph, and (1,-2,7) corresponds to the point one unit to the right of, two units below, and seven units behind the origin. If you have experience with mathematical 3D coordinate systems, you will notice that the axes are labelled slightly differently than the system most commonly used in mathematical . The axis we have drawn above is not fixed in POV-Ray -- the way the axis looks (in of which axes are which) really depends on where you place your camera in POV-Ray. We'll get to explaining the camera soon. For now, just understand that the labels on the axes may change, depending on how you position your camera. The 3D graph above represents a coordinate system that POV-Ray can use. Visualizing objects and scenes in three dimensions can be tricky. Often, a pad of paper and a pencil can be extremely valuable tools, especially in more complex scenes. Alternatively, you can take a look at the Resource Library for some graphical tools that may help.

Vectors in POV-Ray POV-Ray calls the number triples that define positions position vectors. The term vector refers to any group of numbers describing a certain thing -- there are color vectors and normal vectors, for example, in addition to position vectors. In POV-Ray, vectors are surrounded by angle brackets (that's < and >). For example, to specify the origin in that POV-Ray understands, we would say <0,0,0>. The magnitude of a vector can be thought of as the "length" of the vector. Imagine a line from the origin to the point in the coordinate system represented by your vector. The magnitude is the length of this line. (If you really care about the math, the magnitute can be computed as the square root of the sum of the squares of the elements of the vector -- but don't worry, you probably won't have to know that). An important thing to know about is a POV-Ray feature called vector promotion. Vector promotion is when a single number is substituted in place of a vector. The single number is then promoted to a vector, one with all elements equal to that number. For example, promoting the number 2 to a three-dimensional vector would result in the vector <2,2,2>. Vector promotion is done automatically for you by POV-Ray in most cases -- just put in a http://library.thinkquest.org/3285/tutorial/basics_frames.html (2 of 5) [9/12/2001 3:42:40 PM]


single number instead of a vector. This feature allows you to quickly specify similar vectors.

How to describe color: RGB and RGBF Vectors Much as any position within the scene can be specified by a three-element vector, so can any color. In describing a position, each coordinate in the vector corresponds to the position along a particular axis. In describing a color, each element of the vector corresponds to the amount of a primary color -- red, green and blue. Such a vector is called a RGB vector (for red green blue vector). In a position vector, the individual elements can be any real number at all (actually, this isn't quite true -- there are upper and lower limits set by the hardware constraints of your computer). In a RGB vector, the numbers should be between 0.0 and 1.0. You can have values higher that 1.0, but they don't correspond to any physical property (what's greener than green?). A value of 1.0 means 100% of that color. For example, the color black, which is actually the absence of all color, is described by the color vector <0,0,0>. The color white, a complete combination of all three primary colors, is specified by the color vector <1,1,1>. Try experimenting with the Color Tool to find the color vectors for particular colors -- it will help you get a good "feel" for describing colors in of POV-Ray color vectors. In addition to RGB vectors, you can specify a color in POV-Ray with an RGBF vector. As you might guess, a RGBF vector is like a RGB vector, but with one extra element - the F, for filter. The filter value specifies how transparent the pigment is, ranging from 0.0 (not transparent at all) to 1.0 (100% transparent). RGB vectors have an implied filter value of 0.0 -- in other words, a color specified by a RGB vector will be perfectly opaque. A filter value of 1.0 means that all light will be let through, but the light will still be filtered. For example, the RGBF vector <1,0,0,1> acts like red cellophane -- 100% of light is ed through, but it is filtered by the red pigment. RGBF vectors can be a little confusing at first, but they aren't too difficult once you get the hang of it. These are the most commonly-used ways of specifying color. There are a few more ways to do it; if you want to read about them, look at the color section of the Language Reference.

Normal Vectors Occasionally you will be called upon to specify a normal vector in POV-Ray. Simply put, a normal vector is a vector parallel to a given plane in three dimensions. Imagine a flat sheet of paper. If you were to poke a pencil all the way through it so that the end of the pencil was touching the paper and the pencil was standing straight up (with respect to the paper), the pencil would represent the normal vector to the paper. In the picture below, the normal vector is in red and the plane is in blue.



Note that the magnitude of normal vectors is not important (as long as it is non-zero). This is because normal vectors are used to specify an orientation, not a distance. POV-Ray is kind enough to automatically define three normal vectors for you: x (corresponding to <1,0,0>), the normal vector for a plane lying along the y and z axes, y (corresponding to <0, 1, 0>), the normal vector for a plane lying along the x and z axes, and z (corresponding to <0, 0, 1>), the normal vector for a plane lying along the x and y axes. Any time you are asked for a normal vector (or any vector, really) you can substitute those letters.

POV-Ray Source Code Source code is the name for the text you give to POV-Ray. POV-Ray reads the source code file and outputs an image. There are two things you need to know about POV-Ray source code: 1. POV-Ray source code is case sensitive 2. POV-Ray ignores whitespace 3. Ordering is unimportant Case sensitive means that upper and lower-case letters are not treated as the same by POV-Ray. For example, to POV-Ray, sphere is not the same as Sphere and is not the same as SpHeRe. Whitespace is the common name for any characters you can't directly see on screen -- spaces, tab characters (the invisible characters put there when you press the Tab key), carriage returns and line feeds (the invisible characters put there when you hit the Enter key). Between any two words or symbols in your source code, POV-Ray doesn't care whether you put one space, two spaces, one hundred spaces, a new line, or any other whitespace. For example, the phrase: one two the phrase one and the phrase

two

one two are all treated the same by POV-Ray. Ordering means the order in which you declare objects. POV-Ray does not care where in the file the objects are -- it makes no difference to the final scene. (VRML programmers will note that this is a very different approach than VRML's "virtual pen" concept). This does not hold entirely true for some attributes and CSG operations (both of which we will describe in detail later), but in the outer-most level in POV-Ray (the one in which you list the objects in your scene) it doesn't matter.



Comments in POV-Ray Source Code Comments are another useful part of POV-Ray source code. A comment is a portion of text that POV-Ray will ignore. It is used to add information to the source code, usually to make things clearer to the human reader. Comments can be enclosed in /* and */, or, for single-line comments, can be prefixed with a //. For example: // this is a single-line comment /* this is another comment. it can be as long as you want it to be */ C and C++ programmers will recognized this comment style. For a detailed description of comments, see the comments section of the Language Reference.

Including files Including files is a feature of many languages that makes re-using code easier. If you have, for example, many red objects in your scene, you will find it cumbersome (and not very readable) to type the correct RGB vector for red every time. POV-Ray comes to the rescue with a file full of pre-defined colors, which you can use and re-use in your source code. (POV-Ray also comes with files of textures and even objects; we'll get to those later). You can take advantage of these files by adding the string #include "filename" to the beginning of your file. For example, to use the pre-defined colors, you would add the string #include "colors.inc" to the beginning of your file. Technically, the statement does not have to occur at the beginning of the file, but the convention is such, and it makes for readability. The example statement above tells POV-Ray to look for the file called colors.inc and to read it before continuing to the rest of your file. colors.inc defines many colors, such as Red, that you can use in your file any time you need a color, in place of a RGB (or RGBF) vector. This makes your source file much easier to read. Later in the tutorial, you will learn how to define your own colors (and objects, and textures, and so on) and how to put them in your own text files. For now, know how to use the provided ones and be happy. Now that you've got that out of the way, you're ready to start creating your first scene... almost.

Top of Document

Main Page

Step 1: Introduction to POV-Ray and Ray-tracing




The Online POV-Ray Tutorial: Creating Simple Scenes

The Online POV-Ray Tutorial Creating Simple Scenes (Show Jump Points) (Hide Jump Points) The POV-Ray language is fairly easy to use, once you understand it. In fact, if you have any experience with programming, you will find POV-Ray very easy -- there are no variables, conditionals, loops, or anything else that can make programming tricky. Basically, a POV-Ray source file (the file you make and give to POV-Ray) is just a list of objects and their descriptions. Of course, describing the scene you have in your mind to POV-Ray is the tricky part, because you have to speak POV-Ray's language. Quick index: 1. Creating simple objects 2. The Camera 3. Let there be light! (Light sources) 4. The first example scene 5. Transformations 6. Texture 7. Pigment 8. Finish 9. Normal 10. Including Textures

Creating simple objects The building blocks of all POV-Ray objects and scenes are called primitives. Primitives are objects that POV-Ray already knows about, and all you have to do is describe a few attributes. POV-Ray primitives are usually simple geometric shapes such as spheres, cubes, and cones. Describing primitives, in general, take this form in POV-Ray: Object_Name { Object_Parameters Some_Simple_Attribute Some_Other_Simple_Attribute Some_Complex_Attribute { Some_Attribute Some_Other_Attribute } http://library.thinkquest.org/3285/tutorial/simple.html (1 of 15) [9/12/2001 3:43:37 PM]


} This isn't very enlightening. Let's take a look at a short example: sphere { <0, 0, 0>, 5 pigment { color rgb <1, 0, 0> } } Deciphering what this does isn't too tricky. The code defines a sphere with its center at the origin (that's <0,0,0>, ?) and with a radius of 5 (in other words, the distance from the center of the sphere to any point on the edge of the sphere is exactly 5 units). The phrase pigment { color rgb <1,0,0> } simply means that the sphere's pigment (or color) attribute is described by the rgb vector <1,0,0>, which is the color red. You could have just as well used color Red, if you had #included the correct file. The pigment attribute, by the way, is a complex attribute, of which color is just one of the many attributes that can go inside it. There are two types of primitives in POV-Ray: finite primitives and infinite primitives. Finite primitives have well-defined limits. Examples of finite primitives include spheres, cones, torii, and blobs. Infinite primitives have components that can potentially stretch to infinity -- for example, a plane is both infinitely thin and infinitely wide. Examples of infinite objects include planes, quadrics and cubics. At any rate, describing primitives in POV-Ray is only a matter of knowing the syntax for the particular primitive you want to describe. You can find a complete syntax reference in the finite object and infinite object language references. By now, you're probably itching to make your first scene. Before you can do that, however, you need to learn about two things: the camera and light sources.

The Camera Before POV-Ray can generate the scene, it needs to know from where you are looking. If you imagine your computer screen as the camera taking a snapshot of the scene you're describing, you'll see POV-Ray needs to know a) where the camera is in the scene, and b) which direction it's pointing. Such data is given to POV-Ray through the camera object. As you might imagine, the camera object is a rather important one: in fact, POV-Ray requires that there be one and only one in each scene. There are many attributes that the camera object can have; of these, we will only concentrate on the two most useful: the location and the look_at attributes. A complete reference of all the camera attributes can be found in the Camera Reference. A simple camera in POV-Ray looks like this: camera { location <2,5,-10> http://library.thinkquest.org/3285/tutorial/simple.html (2 of 15) [9/12/2001 3:43:37 PM]


look_at <0,0,0> } This example defines a camera located at <2,5,-10> and pointing at the origin. This means that anything with a z coordinate less than -10 will definately be invisible -- it will be behind the camera! You can put the camera anywhere you want in the scene, including inside of objects (although you may not see very much), with one exception: you may not place the camera directly over the origin and have it looking straight down. For complex mathematical reasons, this will cause POV-Ray to generate an error. If you need that type of setup, position the camera a little to the left or the right -- your problem will be solved, and your scene will look (almost) exactly the same. Anyways, now that we have a way of receiving light, we need to have a way of providing light.

Let there be light! (Light sources) If you gave POV-Ray a file containing the camera definition above and the sphere definition before that, the output image would be a lovely blank picture. This would happen because you'd have no light in your scene. To add light (thereby enabling you to actually see something), you need to add a light source. There are a few different types of light sources in POV-Ray. We will concentrate here on the most simple (and useful): the point light source. A point light source can be thought of as an infinitely small object that emits light. Because they are infinitely small, point light sources cannot be directly seen (so you don't have to worry about them appearing in your scene). However, their effects can certainly be seen: your scene lights up! Point light sources as known as non-attenuating light sources: the emitted light does not get weaker with distance. This means that you can illuminate your entire scene with one point light source placed far away from the scene. You can have as many light sources as you want, but they are computationally expensive -- the more you have, the longer POV-Ray will take to trace your scene. An example of a simple point light source definition in POV-Ray looks like this: light_source { <0,10,-10> color rgb <1,1,1> } The first vector is a position vector specifying the location of the light source. The second vector specifies the color (and brightness) of the light. It is generally a good idea to use white or gray light, as using colored light can have side effects that are not immediately obvious (for example, green objects will not show up when exposed to pure red light). Complete information for light sources can be found in the lights section of the Language Reference. Anyways, now that we can add light, we're ready to construct our first full scene.

http://library.thinkquest.org/3285/tutorial/simple.html (3 of 15) [9/12/2001 3:43:37 PM]


The first example scene Putting together all we have learned to far, we get a complete POV-Ray source code file that looks like this: // This is a simple red sphere // first, the camera position camera { location <2,5,-10> look_at <0,0,0> } // now, some light light_source { <0,-10,0> color rgb <1,1,1> } // the sphere sphere { <0,0,0>, 5 pigment { color rgb <1,0,0> } } After running POV-Ray, the output image looks like this:

Finally! Your first image! Of course, this one is a little boring -- but don't worry, we'll get to some fun stuff soon. For now, experiment! It's the best way to learn. Try replacing the sphere with other objects and seeing what happens. The objects that you should easily be able to use are boxes, cones, cylinders, spheres, torii and planes.

Transformations So now we can create some simple objecs. But wait! Some of these objects can only be created around the origin (like the torus). What if we want to put them somewhere else? What if we want to move them around? POV-Ray provides answers to all these questions in the form of transformations. http://library.thinkquest.org/3285/tutorial/simple.html (4 of 15) [9/12/2001 3:43:37 PM]


Transformations, in ray-tracing , are attributes that change the position, size or orientation of objects (and of the various attributes of the objects). The most common types of transformations, and the ones that POV-Ray s, are translations, rotations and scalings. A translation is a transformation that moves an object relative to its current position. It is specified in POV-Ray by the phrase translate <x,y,z>. Translations are easy to visualize. Consider a cube sitting on the origin, like this:

Our camera is positioned so that the x axis increases to the right, the y axis increases upwards and the z axis increases towards us. A translation of <-1,4,2> results in the cube being moved left one unit, up four, and back two, like this:

A rotation is a transformation that changes the orientation of an object (the way that it's facing). Rotations are the most complex of the transformations. They are specified to POV-Ray by the string rotation <x,y,z>, where x, y, and z are the number of degrees (not radians) around the respective axis. Consider the original cube up above. A rotation of <0,0,45> rotates the cube 45 degrees around the z axis, leaving us with a cube looking like this:

A quick way to which way the objects are going to rotate is by usings the so-called "left hand rule." Hold out your left hand, fingers clenched and thumb out. Point your thumb in the positive direction of the axis you are rotating about (if you're rotating about more than one axis at a time, this won't help you -- unless you have more than one thumb!) The direction that your fingers curl is the direction an http://library.thinkquest.org/3285/tutorial/simple.html (5 of 15) [9/12/2001 3:43:37 PM]


object will rotate when the number of degrees is positive. (Negative degrees rotate the opposite direction). Another important thing to about rotations is that they are always with respect to the coordinate axes -- in other words, unless your object is located at the origin, it will orbit around the axis (or axes) you are rotating it about. For example, this is what would happen if we translated the cube first, and then rotated it:

To get around this, make sure you rotate your object when its centered at the origin, and then translate it. Your picture will end up like this:

Transformations are one of the few aspects of POV-Ray in which the order matters, simply because transformations are always made with respect to the object's current orientation. The last translation you need to know about is scaling. Simply enough, scaling changes the size of the object with respect to its current size. Scaling is specified in POV-Ray via the string scale <x,y,z>. The elements of the vector specify the how much to scale the shape with respect to the coordinate axis: a scale of 1.0 leaves the object the same, and a scale of 0.0 or less is invalid. Going back to our original cube, if we scaled the object with the string scale <1,4,1>, we would get a result like this:

Because of vector promotion (if you don't what that is, you can re-read about it), scaling can also take a single number rather than a vector. This causes the object to be scaled in every direction by http://library.thinkquest.org/3285/tutorial/simple.html (6 of 15) [9/12/2001 3:43:37 PM]


that number. For example, the phrase scale 2 is the same as the phrase scale <2,2,2>. Transformations are placed like any other attribute. For example: torus { 3, 11 pigment { color Yellow } scale <1.5,1,1> rotate <-45,0,0> translate <0,2,0> } This code makes a yellow torus, slightly widened around the x axis, rotated -45 degrees around the x axis and with its center at <0,2,0>, like this:

Note that torus objects are created around the origin, so you are in fact forced to use transformations to get them where you want... luckily for you, you now know how. And to quote G. I. Joe, knowing is half the battle.

Texture We it it -- we lied to you. The pigment attribute is actually a part of a bigger attribute called the texture attribute. Every time you used pigment, it should have really looked like this: texture { pigment { color Red } } The reason that POV-Ray is a little loose about the pigment attribute and lets you use it outside of texture is because pigment is so frequently used by itself that it becomes a pain to type out the whole texture statement. In fact, most parts of the texture { } block you can do the same thing with. Either way, they have the same effect. The texture attribute contains attributes describing the outward appearance of the object: pigment, finish and normal. The pigment attribute, as you know, describes the color of the object (although it's a lot more complicated than what we've shown you so far). The finish attribute describes how the object "interacts with light" -- highlighting, metallic luster, shinyness, reflectivity, etc. The normal attribute describes some three-dimensional features of objects, such as bumps, waves, and ripples. We'll cover these one by http://library.thinkquest.org/3285/tutorial/simple.html (7 of 15) [9/12/2001 3:43:37 PM]


one.

Pigment You've seen the use of the color attribute within the pigment attribute (for example, pigment { color Blue }). A more complete description that what we've given you so far can be found in the Color section of the Language Reference. A more flexibe attribute, however, is color_map. color_maps are used to do a wide variety of things. Basically, a color_map defines bands of color on a "map" ranging from 0.0 to 1.0 Let's look at a simple example: color_map { [0.0 color Red] [0.25 color Blue] [0.9 color Green] } This defines three bands of color: red from 0.0 to 0.25, blue from 0.25 to 0.9, and green from 0.9 to 1.0. The other commonly used format looks like this: color_map { [0.0 0.25 color Red] [0.25 0.9 color Blue] [0.9 1.0 color Green] } They both do the same thing; the second one just contains information about where you want the bands to stop as well as start. The next step is tell POV-Ray what to do with this. This is done by using of the many pigment types. A simple pigment type is called gradient. Gradient creates bands of color based on the color map. Using the source code from the first scene we created, and replacing the color Red with our color map and pigment type, we get this: sphere { <0,0,0>, 5 pigment { gradient <0, 1, 0> color_map { [0.0 color Red] [0.25 color Blue] [1.0 color Green] } scale 3 } }



This source code requires a bit of explaining. The vector following the gradient keyword is the normal vector to the orientation of the bands of color (you normal vectors, don't you? Or did you think we were wasting our time telling you stuff you didn't need to know? it it! You skipped over that section! Well, we're forgiving; you can go back and read about it again). The scale statement applies to the pigment, not to the object (look carefully at where it's placed -- inside the pigment { } block). Our sphere now looks like this:

A careful examination of this image yields some interesting facts. Starting from the top down, you can see a slight bit of green (the rest of it was cut off), which fades into the the large blue band, which in turn fades into the small red band. The red band is abruptly cut off and the cycle repeats itself again. However, the next time, the pattern has reversed! The red band is on the top. This is because gradient patterns reverse themselves at the origin. To get around this, you can translate the texture away from the origin (you can apply all transformations to textures, ?). More information on gradients can be found in the gradient section of the Language Reference. Ok, now let's try something else. Add the phrase turbulence 0.5 after the gradient statement. The resulting picture looks like this:

Whoah! The turbulence keyword, as you may have guessed, "mixes stuff up." With this color map, we get a freakish plasma-like sphere. Values for turbulence range from 0.0 to 1.0. A complete description can be found in the turbulence section of the Language Reference. There are many other pigment types than gradient. For example, there is a pigment type called marble. By itself, rather boring and un-marble-like. However, with a high turbulence, it can create some very realistic marble pigments. Here's some sample source code: sphere { <0,0,0>,5 pigment { http://library.thinkquest.org/3285/tutorial/simple.html (9 of 15) [9/12/2001 3:43:37 PM]


marble turbulence 1 // full turbulence color_map { [0.0 color Gray90] // 90% gray [0.8 color Gray60] // 60% gray [1.0 color Gray20] // 20% gray } } } This high-turbulence marble pigment generates some very nice-looking marble:

Not too shabby, huh? Other pigment types include wood, agate, bozo, and a host of others that can be found in the pigment section of the Language Reference. And although technically not pigment types per se, you may want to check out the checker and hexagon pigment patterns, as well as the image map pattern (which lets you map an external image to an object), all found in the same section as above. And , the best way to learn is to experiment!

Finish Finish describes how the objects interact with light: how much they reflect, how they shine, how metallic they are, etc. All finish attributes are enclosed in a finish { } block. Perhaps the most used of the finish attributes is the phong attribute. A phong is a highlight, or glare. It is specified, strangely enough, by the phong attribute, followed by a number between 0.0 and 1.0 that specifies how bright the phong is. There is also a phong_size that controlls how "tight" the phong is -- in other words, the higher this number, the smaller in size the phong is (this is a little misleading, yes). Here we have a green sphere with a phong highlight of 1.0: sphere { <0,0,0>, 5 pigment { color rgb <1,1,0> } finish { phong 0.8 } } When lit by two light sources, the sphere looks like this:



As you can see, the phong adds a nice bit of realistic "shine" whenever a light source directly hits part of the object. A more complete description of phong can be found in the phong section of the Language Reference. Another finish attribute that can produce stunning effects is the reflection keyword. This causes objects to reflect their surroundings to a certain degree. Reflection takes one number, ranging from 0.0 to 1.0, that specifies how reflective the object is. Let's take a look at a more complex scene with a reflective object. #include "colors.inc" camera { location <-2, 3, -10> look_at <0, 5, 0> } plane { // the floor y, 0 // along the x-z plane (y is the normal vector) pigment { checker color Black color White } // checkered pattern } sphere { <0, 5, 0>, 2 pigment { color White } finish { reflection 0.9 phong 1 } } light_source { <10, 10, -10> color White } light_source { <-10, 5, -15> color White } The image this produces is:



As you can see, this generates a yellowish mirrored sphere floating above an infinite checkerboard -- a variant of one of the standard ray-tracing scenes. A more in-depth description of reflectivity can be found in the reflection section of the Reference manual. The final attribute of the finish keyword we will describe here is the refraction keyword. Refraction is what happens when light rays ing through a translucent object get bent, causing a distortion of everything seen through the object. For example, if you look through a crystal ball, you will see a distorted view of whatever is behind it. The refraction keyword takes one value. This value should either be 0.0 or 1.0, for refraction off and on, respectively. Although you can specify values in between, it is not recommended as it does not correspond to any known physical property. How noticeably it refracts is controlled by the ior keyword (for index of refraction), which takes a number greater than 0. The default ior of "empty space" is defined as 1.0. So, if we wanted to create the crystal ball described above, we would use something like this: sphere { <0,5,0>,2 pigment { color rgbf <1,1,1,.8> } finish { reflection 0.1 refraction 1.0 ior 1.5 phong 1.0 } } your RGBF vectors? A filter value of 1.0 would mean this was an invisible sphere, certainly not what we want. Our filter value of 0.8 gives the sphere enough definition to be visible. The image generated looks like this:



Now we start seeing some of the true power of ray-tracing. The warped look of the checkboard pattern is due to the refraction, the bright hightlighting is due to a phong, and a bit of reflection makes this all the more realistic. Tinting the glass would be easy: just change the color of the sphere from <1,1,1> (or white) to whatever color you want it tinted. Modify the filter value to make the ball more and less translucent. It's fun! There are many other finish attributes that you can play with, including metallic, ambient, and crand. We've touched on a few; for a complete reference, read the finish section of the Language Reference. To get a good feel for most of the finish attributes, you can experiment with the Finish Tool.

Normal The normal attribute creates some simple 3D features on your objects: bumps, ripples, waves, and the like. It does not actually change the object; instead, it changes slightly the way light bounces off the object and essentailly fools the eye into believing the object is a little different than it really is. As such, the effects are not 100% true to real life, but they are much, much faster than actually describing the changes individually would be. Let's try a bumps example. Bumps are created with (oddly enough) the bumps keyword, followed by a single number, generally between 0.0 and 1.0, that specifies the relative size of the bumps. Here's some source code: cone { <0,-3,0>,1 <0,3,0>,0.1 texture { normal { bumps 1/2 scale 1/6 } pigment { color rgb <.5,.7,.2> } } } This creates a green cone with a slightly bumpy appearance, like this:

Not to difficult, eh? Imagine how difficult it would be to model all those bumps yourself. Now, here's a http://library.thinkquest.org/3285/tutorial/simple.html (13 of 15) [9/12/2001 3:43:37 PM]


fun one to try -- ripples: plane { y, -2 texture { pigment { color rgb <.1,.9,.9> } normal { ripples 0.5 } } } The number following the ripples keyword specifies, again, the relative size of the ripples. The image this produces is:

Pretty nifty! The ripples keyword and its close relative, the waves keyword, can take a few modifiers that give a little more control than we've shown you. A complete reference can be found in the ripples section of the Language Reference. More normal attributes, such a dents and wrinkles, can be found in the normal section of the same document. You can also experiment with the Normal Tool to get a feeling for the various attributes.

Including Textures Much like you learned how to include colors beforehand, you can also include textures. POV-Ray comes with a file full of some very good textures, called textures.inc. Including this is the same as before: #include "colors.inc" #include "textures.inc" Note that you must include colors.inc before you include textures.inc, because textures.inc uses colors from colors.inc. Using an included texture is easy. To make a sphere that uses the Jade textures, for example, you would say: sphere { <-2, 4, 6>, 5.6



texture { Jade } } Look through the file textures.inc for a list of the textures included. You can also look through colors.inc for a list of the colors in there. Well, if you've managed this far, you're in good shape. Keep it up! The next section gets in to the really fun stuff. Top of Document

Main Page


Step 4: Advanced POV-Ray Features




Jump Points

The Online POV-Ray Tutorial Creating Simple Scenes (Show Jump Points) (Hide Jump Points)

Main Page


The POV-Ray language is fairly easy to use, once you understand it. In fact, if you have any experience with programming, you will find POV-Ray very easy -- there are no variables, conditionals, loops, or anything else that can make programming tricky. Basically, a POV-Ray source file (the file you make and give to POV-Ray) is just a list of objects and their descriptions. Of course, describing the scene you have in your mind to POV-Ray is the tricky part, because you have to speak POV-Ray's language. Quick index: 1. Creating simple objects 2. The Camera 3. Let there be light! (Light sources) 4. The first example scene 5. Transformations


6. Texture 7. Pigment 8. Finish 9. Normal


10. Including Textures

Creating simple objects The building blocks of all POV-Ray objects and scenes are called primitives. Primitives are objects that POV-Ray already knows about, and all you have to do is describe a few attributes. POV-Ray primitives are usually simple geometric shapes such as spheres, cubes, and cones.


Describing primitives, in general, take this form in POV-Ray: Object_Name { Object_Parameters Some_Simple_Attribute Some_Other_Simple_Attribute Some_Complex_Attribute { Some_Attribute Some_Other_Attribute } } This isn't very enlightening. Let's take a look at a short example: sphere { <0, 0, 0>, 5 pigment {

http://library.thinkquest.org/3285/tutorial/simple_frames.html (1 of 13) [9/12/2001 3:44:25 PM]


color rgb <1, 0, 0> } } Deciphering what this does isn't too tricky. The code defines a sphere with its center at the origin (that's <0,0,0>, ?) and with a radius of 5 (in other words, the distance from the center of the sphere to any point on the edge of the sphere is exactly 5 units). The phrase pigment { color rgb <1,0,0> } simply means that the sphere's pigment (or color) attribute is described by the rgb vector <1,0,0>, which is the color red. You could have just as well used color Red, if you had #included the correct file. The pigment attribute, by the way, is a complex attribute, of which color is just one of the many attributes that can go inside it. There are two types of primitives in POV-Ray: finite primitives and infinite primitives. Finite primitives have well-defined limits. Examples of finite primitives include spheres, cones, torii, and blobs. Infinite primitives have components that can potentially stretch to infinity -- for example, a plane is both infinitely thin and infinitely wide. Examples of infinite objects include planes, quadrics and cubics. At any rate, describing primitives in POV-Ray is only a matter of knowing the syntax for the particular primitive you want to describe. You can find a complete syntax reference in the finite object and infinite object language references. By now, you're probably itching to make your first scene. Before you can do that, however, you need to learn about two things: the camera and light sources.

The Camera Before POV-Ray can generate the scene, it needs to know from where you are looking. If you imagine your computer screen as the camera taking a snapshot of the scene you're describing, you'll see POV-Ray needs to know a) where the camera is in the scene, and b) which direction it's pointing. Such data is given to POV-Ray through the camera object. As you might imagine, the camera object is a rather important one: in fact, POV-Ray requires that there be one and only one in each scene. There are many attributes that the camera object can have; of these, we will only concentrate on the two most useful: the location and the look_at attributes. A complete reference of all the camera attributes can be found in the Camera Reference. A simple camera in POV-Ray looks like this: camera { location <2,5,-10> look_at <0,0,0> } This example defines a camera located at <2,5,-10> and pointing at the origin. This means that anything with a z coordinate less than -10 will definately be invisible -- it will be behind the camera! You can put the camera anywhere you want in the scene, including inside of objects (although you may not see very much), with one exception: you may not place the camera directly over the origin and have it looking straight down. For complex mathematical reasons, this will cause POV-Ray to generate an error. If you need that type of setup, position the camera a little to the left or the right -- your problem will be solved, and your scene will look (almost) exactly the same. Anyways, now that we have a way of receiving light, we need to have a way of providing light.



Let there be light! (Light sources) If you gave POV-Ray a file containing the camera definition above and the sphere definition before that, the output image would be a lovely blank picture. This would happen because you'd have no light in your scene. To add light (thereby enabling you to actually see something), you need to add a light source. There are a few different types of light sources in POV-Ray. We will concentrate here on the most simple (and useful): the point light source. A point light source can be thought of as an infinitely small object that emits light. Because they are infinitely small, point light sources cannot be directly seen (so you don't have to worry about them appearing in your scene). However, their effects can certainly be seen: your scene lights up! Point light sources as known as non-attenuating light sources: the emitted light does not get weaker with distance. This means that you can illuminate your entire scene with one point light source placed far away from the scene. You can have as many light sources as you want, but they are computationally expensive -- the more you have, the longer POV-Ray will take to trace your scene. An example of a simple point light source definition in POV-Ray looks like this: light_source { <0,10,-10> color rgb <1,1,1> } The first vector is a position vector specifying the location of the light source. The second vector specifies the color (and brightness) of the light. It is generally a good idea to use white or gray light, as using colored light can have side effects that are not immediately obvious (for example, green objects will not show up when exposed to pure red light). Complete information for light sources can be found in the lights section of the Language Reference. Anyways, now that we can add light, we're ready to construct our first full scene.

The first example scene Putting together all we have learned to far, we get a complete POV-Ray source code file that looks like this: // This is a simple red sphere // first, the camera position camera { location <2,5,-10> look_at <0,0,0> } // now, some light light_source { <0,-10,0> color rgb <1,1,1> }



// the sphere sphere { <0,0,0>, 5 pigment { color rgb <1,0,0> } } After running POV-Ray, the output image looks like this:

Finally! Your first image! Of course, this one is a little boring -- but don't worry, we'll get to some fun stuff soon. For now, experiment! It's the best way to learn. Try replacing the sphere with other objects and seeing what happens. The objects that you should easily be able to use are boxes, cones, cylinders, spheres, torii and planes.

Transformations So now we can create some simple objecs. But wait! Some of these objects can only be created around the origin (like the torus). What if we want to put them somewhere else? What if we want to move them around? POV-Ray provides answers to all these questions in the form of transformations. Transformations, in ray-tracing , are attributes that change the position, size or orientation of objects (and of the various attributes of the objects). The most common types of transformations, and the ones that POV-Ray s, are translations, rotations and scalings. A translation is a transformation that moves an object relative to its current position. It is specified in POV-Ray by the phrase translate <x,y,z>. Translations are easy to visualize. Consider a cube sitting on the origin, like this:

Our camera is positioned so that the x axis increases to the right, the y axis increases upwards and the z axis increases towards us. A translation of <-1,4,2> results in the cube being moved left one unit, up four, and back two, like this:



A rotation is a transformation that changes the orientation of an object (the way that it's facing). Rotations are the most complex of the transformations. They are specified to POV-Ray by the string rotation <x,y,z>, where x, y, and z are the number of degrees (not radians) around the respective axis. Consider the original cube up above. A rotation of <0,0,45> rotates the cube 45 degrees around the z axis, leaving us with a cube looking like this:

A quick way to which way the objects are going to rotate is by usings the so-called "left hand rule." Hold out your left hand, fingers clenched and thumb out. Point your thumb in the positive direction of the axis you are rotating about (if you're rotating about more than one axis at a time, this won't help you -- unless you have more than one thumb!) The direction that your fingers curl is the direction an object will rotate when the number of degrees is positive. (Negative degrees rotate the opposite direction). Another important thing to about rotations is that they are always with respect to the coordinate axes -- in other words, unless your object is located at the origin, it will orbit around the axis (or axes) you are rotating it about. For example, this is what would happen if we translated the cube first, and then rotated it:

To get around this, make sure you rotate your object when its centered at the origin, and then translate it. Your picture will end up like this:

Transformations are one of the few aspects of POV-Ray in which the order matters, simply because transformations are always made with respect to the object's current orientation. The last translation you need to know about is scaling. Simply enough, scaling changes the size of the object with respect to its current size. Scaling is specified in POV-Ray via the string scale <x,y,z>. The elements of the vector specify the how much to scale the shape with respect to the coordinate axis: a scale of 1.0 leaves the object the same, and a scale of 0.0 or less is invalid. Going back to our original cube, if we scaled the object with the string scale <1,4,1>, we would get a result like this: http://library.thinkquest.org/3285/tutorial/simple_frames.html (5 of 13) [9/12/2001 3:44:25 PM]


Because of vector promotion (if you don't what that is, you can re-read about it), scaling can also take a single number rather than a vector. This causes the object to be scaled in every direction by that number. For example, the phrase scale 2 is the same as the phrase scale <2,2,2>. Transformations are placed like any other attribute. For example: torus { 3, 11 pigment { color Yellow } scale <1.5,1,1> rotate <-45,0,0> translate <0,2,0> } This code makes a yellow torus, slightly widened around the x axis, rotated -45 degrees around the x axis and with its center at <0,2,0>, like this:

Note that torus objects are created around the origin, so you are in fact forced to use transformations to get them where you want... luckily for you, you now know how. And to quote G. I. Joe, knowing is half the battle.

Texture We it it -- we lied to you. The pigment attribute is actually a part of a bigger attribute called the texture attribute. Every time you used pigment, it should have really looked like this: texture { pigment { color Red } } The reason that POV-Ray is a little loose about the pigment attribute and lets you use it outside of texture is because pigment is so frequently used by itself that it becomes a pain to type out the whole texture statement. In fact, most parts of the texture { } block you can do the same thing with. Either way, they have the same effect. The texture attribute contains attributes describing the outward appearance of the object: pigment, finish and normal. The pigment attribute, as you know, describes the color of the object (although http://library.thinkquest.org/3285/tutorial/simple_frames.html (6 of 13) [9/12/2001 3:44:25 PM]


it's a lot more complicated than what we've shown you so far). The finish attribute describes how the object "interacts with light" -- highlighting, metallic luster, shinyness, reflectivity, etc. The normal attribute describes some three-dimensional features of objects, such as bumps, waves, and ripples. We'll cover these one by one.

Pigment You've seen the use of the color attribute within the pigment attribute (for example, pigment { color Blue }). A more complete description that what we've given you so far can be found in the Color section of the Language Reference. A more flexibe attribute, however, is color_map. color_maps are used to do a wide variety of things. Basically, a color_map defines bands of color on a "map" ranging from 0.0 to 1.0 Let's look at a simple example: color_map { [0.0 color Red] [0.25 color Blue] [0.9 color Green] } This defines three bands of color: red from 0.0 to 0.25, blue from 0.25 to 0.9, and green from 0.9 to 1.0. The other commonly used format looks like this: color_map { [0.0 0.25 color Red] [0.25 0.9 color Blue] [0.9 1.0 color Green] } They both do the same thing; the second one just contains information about where you want the bands to stop as well as start. The next step is tell POV-Ray what to do with this. This is done by using of the many pigment types. A simple pigment type is called gradient. Gradient creates bands of color based on the color map. Using the source code from the first scene we created, and replacing the color Red with our color map and pigment type, we get this: sphere { <0,0,0>, 5 pigment { gradient <0, 1, 0> color_map { [0.0 color Red] [0.25 color Blue] [1.0 color Green] } scale 3 } } This source code requires a bit of explaining. The vector following the gradient keyword is the normal vector to the orientation of the bands of color (you normal vectors, don't you? Or did you think we were wasting our time telling you stuff you didn't need to know? it it! You skipped over that section! Well, we're forgiving; you can go back and read about it again). The scale statement applies to the pigment, not to the object (look carefully at where it's placed -http://library.thinkquest.org/3285/tutorial/simple_frames.html (7 of 13) [9/12/2001 3:44:25 PM]


inside the pigment { } block). Our sphere now looks like this:

A careful examination of this image yields some interesting facts. Starting from the top down, you can see a slight bit of green (the rest of it was cut off), which fades into the the large blue band, which in turn fades into the small red band. The red band is abruptly cut off and the cycle repeats itself again. However, the next time, the pattern has reversed! The red band is on the top. This is because gradient patterns reverse themselves at the origin. To get around this, you can translate the texture away from the origin (you can apply all transformations to textures, ?). More information on gradients can be found in the gradient section of the Language Reference. Ok, now let's try something else. Add the phrase turbulence 0.5 after the gradient statement. The resulting picture looks like this:

Whoah! The turbulence keyword, as you may have guessed, "mixes stuff up." With this color map, we get a freakish plasma-like sphere. Values for turbulence range from 0.0 to 1.0. A complete description can be found in the turbulence section of the Language Reference. There are many other pigment types than gradient. For example, there is a pigment type called marble. By itself, rather boring and un-marble-like. However, with a high turbulence, it can create some very realistic marble pigments. Here's some sample source code: sphere { <0,0,0>,5 pigment { marble turbulence 1 // full turbulence color_map { [0.0 color Gray90] // 90% gray [0.8 color Gray60] // 60% gray [1.0 color Gray20] // 20% gray } } } This high-turbulence marble pigment generates some very nice-looking marble:



Not too shabby, huh? Other pigment types include wood, agate, bozo, and a host of others that can be found in the pigment section of the Language Reference. And although technically not pigment types per se, you may want to check out the checker and hexagon pigment patterns, as well as the image map pattern (which lets you map an external image to an object), all found in the same section as above. And , the best way to learn is to experiment!

Finish Finish describes how the objects interact with light: how much they reflect, how they shine, how metallic they are, etc. All finish attributes are enclosed in a finish { } block. Perhaps the most used of the finish attributes is the phong attribute. A phong is a highlight, or glare. It is specified, strangely enough, by the phong attribute, followed by a number between 0.0 and 1.0 that specifies how bright the phong is. There is also a phong_size that controlls how "tight" the phong is -- in other words, the higher this number, the smaller in size the phong is (this is a little misleading, yes). Here we have a green sphere with a phong highlight of 1.0: sphere { <0,0,0>, 5 pigment { color rgb <1,1,0> } finish { phong 0.8 } } When lit by two light sources, the sphere looks like this:

As you can see, the phong adds a nice bit of realistic "shine" whenever a light source directly hits part of the object. A more complete description of phong can be found in the phong section of the Language Reference. Another finish attribute that can produce stunning effects is the reflection keyword. This causes objects to reflect their surroundings to a certain degree. Reflection takes one number, ranging from 0.0 to 1.0, that specifies how reflective the object is. Let's take a look at a more complex scene with a reflective object. #include "colors.inc"



camera { location <-2, 3, -10> look_at <0, 5, 0> } plane { // the floor y, 0 // along the x-z plane (y is the normal vector) pigment { checker color Black color White } // checkered pattern } sphere { <0, 5, 0>, 2 pigment { color White } finish { reflection 0.9 phong 1 } } light_source { <10, 10, -10> color White } light_source { <-10, 5, -15> color White } The image this produces is:

As you can see, this generates a yellowish mirrored sphere floating above an infinite checkerboard -- a variant of one of the standard ray-tracing scenes. A more in-depth description of reflectivity can be found in the reflection section of the Reference manual. The final attribute of the finish keyword we will describe here is the refraction keyword. Refraction is what happens when light rays ing through a translucent object get bent, causing a distortion of everything seen through the object. For example, if you look through a crystal ball, you will see a distorted view of whatever is behind it. The refraction keyword takes one value. This value should either be 0.0 or 1.0, for refraction off and on, respectively. Although you can specify values in between, it is not recommended as it does not correspond to any known physical property. How noticeably it refracts is controlled by the ior keyword (for index of refraction), which takes a number greater than 0. The default ior of "empty space" is defined as 1.0. So, if we wanted to create the crystal ball described above, we would use something like this: sphere { <0,5,0>,2 pigment { color rgbf <1,1,1,.8> } finish { reflection 0.1 refraction 1.0 http://library.thinkquest.org/3285/tutorial/simple_frames.html (10 of 13) [9/12/2001 3:44:25 PM]


ior 1.5 phong 1.0 } } your RGBF vectors? A filter value of 1.0 would mean this was an invisible sphere, certainly not what we want. Our filter value of 0.8 gives the sphere enough definition to be visible. The image generated looks like this:

Now we start seeing some of the true power of ray-tracing. The warped look of the checkboard pattern is due to the refraction, the bright hightlighting is due to a phong, and a bit of reflection makes this all the more realistic. Tinting the glass would be easy: just change the color of the sphere from <1,1,1> (or white) to whatever color you want it tinted. Modify the filter value to make the ball more and less translucent. It's fun! There are many other finish attributes that you can play with, including metallic, ambient, and crand. We've touched on a few; for a complete reference, read the finish section of the Language Reference. To get a good feel for most of the finish attributes, you can experiment with the Finish Tool.

Normal The normal attribute creates some simple 3D features on your objects: bumps, ripples, waves, and the like. It does not actually change the object; instead, it changes slightly the way light bounces off the object and essentailly fools the eye into believing the object is a little different than it really is. As such, the effects are not 100% true to real life, but they are much, much faster than actually describing the changes individually would be. Let's try a bumps example. Bumps are created with (oddly enough) the bumps keyword, followed by a single number, generally between 0.0 and 1.0, that specifies the relative size of the bumps. Here's some source code: cone { <0,-3,0>,1 <0,3,0>,0.1 texture { normal { bumps 1/2 scale 1/6 } pigment { color rgb <.5,.7,.2> } } } This creates a green cone with a slightly bumpy appearance, like this:



Not to difficult, eh? Imagine how difficult it would be to model all those bumps yourself. Now, here's a fun one to try -- ripples: plane { y, -2 texture { pigment { color rgb <.1,.9,.9> } normal { ripples 0.5 } } } The number following the ripples keyword specifies, again, the relative size of the ripples. The image this produces is:

Pretty nifty! The ripples keyword and its close relative, the waves keyword, can take a few modifiers that give a little more control than we've shown you. A complete reference can be found in the ripples section of the Language Reference. More normal attributes, such a dents and wrinkles, can be found in the normal section of the same document. You can also experiment with the Normal Tool to get a feeling for the various attributes.

Including Textures Much like you learned how to include colors beforehand, you can also include textures. POV-Ray comes with a file full of some very good textures, called textures.inc. Including this is the same as before: #include "colors.inc" #include "textures.inc" Note that you must include colors.inc before you include textures.inc, because textures.inc uses colors from colors.inc. Using an included texture is easy. To make a sphere that uses the Jade textures, for example, you would say:



sphere { <-2, 4, 6>, 5.6 texture { Jade } } Look through the file textures.inc for a list of the textures included. You can also look through colors.inc for a list of the colors in there. Well, if you've managed this far, you're in good shape. Keep it up! The next section gets in to the really fun stuff. Top of Document

Main Page





The Online POV-Ray Tutorial: Advanced POV-Ray Features

The Online POV-Ray Tutorial Advanced POV-Ray Features (Show Jump Points) (Hide Jump Points) If you've made it this far, you're in good shape! This section covers the features of POV-Ray that are most most complex, but also the most powerful. Once you complete this section, you'll be ready a certified ray-tracing master. Quick Index: 1. #declare 2. CSG 1. Union 2. Difference 3. Intersection 4. Merge 5. Inverse 3. Advanced Objects

#declare Up until now, creating large numbers of similar objects has been an excersize in cut-and-paste editor features. POV-Ray provides a very powerful, very flexible way to create many similar objects with a statement called #declare. #declare essentially creates a new type of object (or pigment, or texture, or almost anything) that you can use and re-use whenever you like. Take a look at the following code: #declare my_sphere = sphere { <0, 0, 0>, 5 finish { pigment rgbf <.5, .2, .4, .667> } } What this does, essentially, is declare a new type of object called "my_sphere" which you can now use later on in your source code, like this: object { my_sphere translate <-2, 0, 0> } The object statement tells POV-Ray to create an object of type "my_sphere." Theoretically, you can put object statements around every object you use (including primitives, like spheres) but POV-Ray only requires it for #declared objects.

http://library.thinkquest.org/3285/tutorial/advanced.html (1 of 9) [9/12/2001 3:45:14 PM]


Note that any attributes you place inside the object statement override those in the #declare statement -- in this example, our sphere is moved from its original location at <0,0,0> to <-2,0,0>. This hold true for pigments, finishes, etc. VRML programmers should take note that this #declare differs somewhat from VRML's DFN node. #declare does not create an instance of the object (which DFN does), only the definition. In other words, the above #declare statement would not add any objects to your scene on its own. You need to instantiate the objects (with the object keyword) to do that. Now, why would you want to use #declare? Say, for example, you're making a Greek temple. You would want many pillars in your object, so you would create a pillar object with #declare, like this: #declare pillar = cylinder { <0, -5, 0>, <0, 5, 0> texture { White_Marble } } Then, you would create however many of these you needed, translating to your heart's content. Say, however, that you decide the columns in your temple should be made out of red marble, not white. All you have to do is change the one #declare statement, and all the pillars change! If you had created those pillars without #declare, you'd have to change each one by hande -- a major hassle, especially if you had 40 pillars in your temple. So you can see one immediate benefit to #declare -- updating your scene becomes a lot easier. But wait, there's more! You can also use #declare to create your own colors and textures. In fact, the colors.inc and textures.inc files are basically long lists of #declared colors and textures, respectively. The syntax is intuitive: #declare blue_green_filter = rgbf <0, .5, .5, .5> #declare red_glass = texture { finish { refraction 1.0 reflection 0.1 ior 1.5 } pigment { color rgbf <1, .7, .7, .7> } } As you can most likely guess, these define a new color, called "blue_green_filter" and a new texture, called "red_glass". You would use these like this: sphere { <0, 0, 0>, 1 pigment { blue_green_filter } } cone { <-2, -4, 16>, 5 http://library.thinkquest.org/3285/tutorial/advanced.html (2 of 9) [9/12/2001 3:45:14 PM]


<0, -3, 1>, 1 texture { red_glass } } Not too difficult! You can use #declare to create custom finish, normal, and pigment statements... you can even use it with vectors and single numbers, like this: #declare PI = 3.1415926545338327950288 This will save you a bit of typing if you reference PI frequently in your scene file! (Please that you don't need to put an object statement around anything you #declare other than objects). C and C++ programmers should not be mislead by #delare's superficial similarity to the C/C++ pre-processor macro #define. Their behaviour is quite different. #define actually changes the source code before it gets compiled (why is why it's called a pre-processor macro). POV-Ray does not have a pre-processor, and so #declare, although misleadingly labeled, will not do source-code substitution. At any rate, you can get the complete syntax for object and #declare in the Language Reference. They are both powerful tools, and if you create anything other than very simple scenes, you will find them invaluable.

CSG CSG stands for Constructive Solid Geometry, a powerful technique in POV-Ray for creating new objects from combinations of other objects. So far, you have been limited to POV-Ray's primitives, which, while nice, aren't always what you need. POV-Ray lets you use the primitives in a much more constructive (har har) way with CSG: you can carve away parts of objects, you can stick objects together, and other exciting stuff. There are five operators in CSG: union, intersection, merge, difference, and inverse. The syntax of all the operators (except inverse) is very simple: it's the operator, followed by a list of two or more objects enclosed by braces, like this: CSG_operator { object_1 object_2 etc. } You actually don't have to put any objects at all between the braces, but it doesn't make sense to have less than two objects (, CSG creates new objects from combinations of other objects) and POV-Ray will warn you when you trace the file. The syntax for inverse is even easier: it's just the word "inverse." We'll go over these operators one by one, because they're all important. A complete reference can be found in the CSG Section of the Language Reference.

Union A union is the easiest CSG operator to understand. It simply takes a bunch of objects, and "sticks them together." It doesn't actually move the objects at all, but it creates a common bond between the objects, kind of like they've ed a special club for important primitives. (We'll politely ignore the similarities to certain political parties). The source code to a sample union looks like this:



union { sphere { <0, 1, 2>, 3 } box { <-77, 6, 5>, <2, 3, 55> } sphere { <-2, -3, -4>, 5 } } Now rendering the scene doesn't look any different whether you have the union keyword there or not. So why bother? Two reasons: first, you can assign attributes to the entire union of objects very easily: union { sphere { <0, 1, 2>, 3 } box { <-77, 6, 5>, <2, 3, 55> } sphere { <-2, -3, -4>, 5 } pigment { color Blue } // applies to the entire union } In this case, the attribute pigment { color Blue } is applied to every object in the union. As always, this works with any attribute you care to try: pigment, translations, normal, etc. The second, and perhaps even more useful reason for using unions, is when you combine CSG and the #declare keyword, like this: #define two_spheres = union { sphere { <0, 0, 0>, 3 } sphere { <-1, -5, -1>, 3 } } From now on, you can reference the object two_spheres (which is, amazingly enough, two separate spheres) just as you would any other #declared object: object { two_spheres pigment { color Pink } rotate <0, 180, 0> } Let's go through one more example, to make sure you understand -- this is a very important concept. Say you wanted to ray-trace a car. You'd create the wheels, then an axle, and then use union to stick them together. You could then re-use this wheel and axle combination however many times you wanted (depending on how many sets of wheels your car has). Your code might look something like this: #declare wheels_n_axle = union { object { // left wheel wheel // assuming we have already created a wheel object translate <-3, 0, 0> } object {

// axle



axle

// assuming we have already created an axle object

} object { // right wheel wheel // assuming we have already created a wheel object translate <3, 0, 0> } } #declare car = union { object { // front wheels and axle wheel_n_axle translate <0, 0, 5> } object { // rear wheels and axle wheels_n_axle translate <0, 0, -5> } // other car parts go here } Note that the order you place objects in a union is unimportant -- objects within a union don't really care about the other objects. This is different from the objects in a difference -- they are very caring, almost loving, objects, as you will see in the next section. A complete description of the union operator can be found in the CSG Section of the Language Reference. Difference A CSG difference is much like a mathematical difference -- it subtracts objects from one another. More specifically, it takes chunks out of the first object, each chunk being defined by the other objects in the difference statement. For example, say we wanted to make a wall that we would add a door to. The simplest way to do this is with a difference: #declare wall = difference { box { <0, 0, 0>, <10, 10, 1> } // 10x10x1 wall box { <2, 0, -1>, <6, 8, 2> } // minus a doorway texture { Wall_Texture } // assuming we have already created a Wall_Texture } The first cube serves as the wall, and the second cube describes what, exactly, we want to take out from the wall. The two objects without the difference statement look like this:



When we add the difference statement, we get:

Note that we made the doorway cube thicker than the wall. Why? This is because, occasionally, POV-Ray will get confused when you have two objects that overlay exactly the same space. So, we made the doorway cube a little thicker, avoiding a potentially weird image, and at no loss to anything else. One important thing to about differences is that all objects are subtracted from the first one. If, for example, we wanted to add a few window holes to the wall above, we could just add a few more cubes at the very end, and voila! Once again, any attributes placed at the end of the difference statement will apply to the entire object. A complete reference for the difference keyword is located in the CSG Section of the Language Reference. Intersection Much as a difference removes the insides of objects, a intersection removes the outsides of objects. The result of using the intersection operator is that the only thing remaining is the parts which all the objects within the operator had in common. Let's say that you want to make a single, colored, sugar-coated chocolate candy that won't melt in your hands (not nameing any names). Furthermore, it must be a mathematically perfect candy. The easiest way to do this in POV-Ray is with an intersection, like this: #include "colors.inc" camera { location <0, 0, -5> look_at <0, 0, 0> } light_source { <10, 10, -10> color White } intersection { http://library.thinkquest.org/3285/tutorial/advanced.html (6 of 9) [9/12/2001 3:45:14 PM]


sphere { <0, -1, 0>, 2 } sphere { <0, 1, 0>, 2 } pigment { color Yellow } } This code takes two spheres that overlap, like this:

Then, it uses the intersection operator to remove everything that isn't overlapping, leaving an a remarkably sweet-looking goody, like this:

Although intersections are a little more difficult to imagine than some of the other CSG operators, they can be a very powerful tool. You can find a complete reference in the intersection section of the Language Reference. Merge Merge is very similar to union. In fact, the only difference between the two is that, if the objects actually overlap, merge will make the interior a smooth, continuous unit. Now, obviously, this won't make a difference to you if your objects aren't opaque. But if you have transparent, overlapping objects in your scene, the original object boundaries will be shown if you use a union (or no CSG at all); to get around this, you muts use merge. A complete reference for the merge operator can be found in the CSG Section of the Language Reference. Inverse Inverse is not used very often, but there are times when it must be used. Inverse will take your object and reverse what POV-Ray considers to be its "inside" and "outside." This will make no difference to the way your object looks, but it makes a great deal of difference to the wayyour object acts when you use it in CSG. Consider the intersection of a sphere and a box. If the sphere is inverted (by placing the keyword invert in its definition), then POV-Ray will take the intersection of the box and an object defined as "the entire universe except this sphere." If you think about it for a while (probaby a long while), you'll realize that that's the same as a difference. In other



words, this: intersection { box { <0,0,0>,<1,1,1> } sphere { <1,1,1>, 1 inverse } } is the same as this: difference { box { <0,0,0>,<1,1,1> } sphere { <1,1,1>, 1 } } In fact, POV-Ray calculates differences using this same method. A complete reference to the inverse keyword can be found in the CSG Section of the Language Reference.

Advanced Objects There are times when POV-Ray's geometric primitives aren't going to be enough for you. Face it, if you want to ray-trace something as complex as a human being, even CSG won't help you. In this case, there are two options left to you: The first is to specify your object in mathematical . Obviously, this will only work if 1. Your object can be described by an n-dimensional polynomial in 3-space; 2. You know what the heck I'm talking about; and 3. You like pain What we're trying to say here is that we're not about to teach you the math necessary to specify these objects, and, furthermore, we recommend against it, unless you really know what you're doing. Of course, if you'd like to read about the objects involved (namely, quadrics, cubics, quadrics and polys), the go right ahead. And if you can use them, so much the better. But if you don't have the math behind it, then don't worry about it; you'll probably sleep better at night. We have found these objects to be of limited use. The second option you have is to use a modelling program. What a modelling program can do is generate extremely complex objects in POV-Ray by specifying them as a whole bunch of really simple objects, normally blobs, triangles, smooth triangles. or bicubic patches. These objects, much like the the mathematical ones above, are not generally meant for human consumption -- in other words, don't bother trying to create objects with these by hand, because unless you really know what you're doing, you'll probably just waste a lot of time. Instead, find a good modelling program (there are many free and shareware ones out there; try the Resource Library), create the complex object in there (usually the modelling programs will have a very nice, graphical interface) and run POV-Ray on the file it creates. You will save a lot of time and effort.



Top of Document

Main Page




Step 5: Conclusion


Jump Points

The Online POV-Ray Tutorial Advanced POV-Ray Features (Show Jump Points) (Hide Jump Points)

Main Page

If you've made it this far, you're in good shape! This section covers the features of POV-Ray that are most most complex, but also the most powerful. Once you complete this section, you'll be ready a certified ray-tracing master. Quick Index: 1. #declare


2. CSG 1. Union 2. Difference 3. Intersection 4. Merge 5. Inverse 3. Advanced Objects


#declare



Up until now, creating large numbers of similar objects has been an excersize in cut-and-paste editor features. POV-Ray provides a very powerful, very flexible way to create many similar objects with a statement called #declare. #declare essentially creates a new type of object (or pigment, or texture, or almost anything) that you can use and re-use whenever you like. Take a look at the following code: #declare my_sphere = sphere { <0, 0, 0>, 5 finish { pigment rgbf <.5, .2, .4, .667> } } What this does, essentially, is declare a new type of object called "my_sphere" which you can now use later on in your source code, like this: object { my_sphere translate <-2, 0, 0> } The object statement tells POV-Ray to create an object of type "my_sphere." Theoretically, you can put object statements around every object you use (including primitives, like spheres) but POV-Ray only requires it for #declared objects. Note that any attributes you place inside the object statement override those in the #declare statement -- in this example, our sphere is moved from its original location at <0,0,0> to <-2,0,0>. This hold true for pigments, finishes, etc. VRML programmers should take note that this #declare differs somewhat from VRML's DFN node. #declare does not create an instance of the object (which DFN does), only the definition. In other words, the above #declare statement would not add any objects to your scene on its own. You need to instantiate the objects (with the object keyword) to do that. Now, why would you want to use #declare? Say, for example, you're making a Greek temple. You would want many pillars in your object, so you would create a pillar object with #declare, like this:

http://library.thinkquest.org/3285/tutorial/advanced_frames.html (1 of 7) [9/12/2001 3:46:18 PM]


#declare pillar = cylinder { <0, -5, 0>, <0, 5, 0> texture { White_Marble } } Then, you would create however many of these you needed, translating to your heart's content. Say, however, that you decide the columns in your temple should be made out of red marble, not white. All you have to do is change the one #declare statement, and all the pillars change! If you had created those pillars without #declare, you'd have to change each one by hande -- a major hassle, especially if you had 40 pillars in your temple. So you can see one immediate benefit to #declare -- updating your scene becomes a lot easier. But wait, there's more! You can also use #declare to create your own colors and textures. In fact, the colors.inc and textures.inc files are basically long lists of #declared colors and textures, respectively. The syntax is intuitive: #declare blue_green_filter = rgbf <0, .5, .5, .5> #declare red_glass = texture { finish { refraction 1.0 reflection 0.1 ior 1.5 } pigment { color rgbf <1, .7, .7, .7> } } As you can most likely guess, these define a new color, called "blue_green_filter" and a new texture, called "red_glass". You would use these like this: sphere { <0, 0, 0>, 1 pigment { blue_green_filter } } cone { <-2, -4, 16>, 5 <0, -3, 1>, 1 texture { red_glass } } Not too difficult! You can use #declare to create custom finish, normal, and pigment statements... you can even use it with vectors and single numbers, like this: #declare PI = 3.1415926545338327950288 This will save you a bit of typing if you reference PI frequently in your scene file! (Please that you don't need to put an object statement around anything you #declare other than objects). C and C++ programmers should not be mislead by #delare's superficial similarity to the C/C++ pre-processor macro #define. Their behaviour is quite different. #define actually changes the source code before it gets compiled (why is why it's called a pre-processor macro). POV-Ray does not have a pre-processor, and so #declare, although misleadingly labeled, will not do source-code substitution. At any rate, you can get the complete syntax for object and #declare in the Language Reference. They are both powerful tools, and if you create anything other than very simple scenes, you will find them invaluable.



CSG CSG stands for Constructive Solid Geometry, a powerful technique in POV-Ray for creating new objects from combinations of other objects. So far, you have been limited to POV-Ray's primitives, which, while nice, aren't always what you need. POV-Ray lets you use the primitives in a much more constructive (har har) way with CSG: you can carve away parts of objects, you can stick objects together, and other exciting stuff. There are five operators in CSG: union, intersection, merge, difference, and inverse. The syntax of all the operators (except inverse) is very simple: it's the operator, followed by a list of two or more objects enclosed by braces, like this: CSG_operator { object_1 object_2 etc. } You actually don't have to put any objects at all between the braces, but it doesn't make sense to have less than two objects (, CSG creates new objects from combinations of other objects) and POV-Ray will warn you when you trace the file. The syntax for inverse is even easier: it's just the word "inverse." We'll go over these operators one by one, because they're all important. A complete reference can be found in the CSG Section of the Language Reference.

Union A union is the easiest CSG operator to understand. It simply takes a bunch of objects, and "sticks them together." It doesn't actually move the objects at all, but it creates a common bond between the objects, kind of like they've ed a special club for important primitives. (We'll politely ignore the similarities to certain political parties). The source code to a sample union looks like this: union { sphere { <0, 1, 2>, 3 } box { <-77, 6, 5>, <2, 3, 55> } sphere { <-2, -3, -4>, 5 } } Now rendering the scene doesn't look any different whether you have the union keyword there or not. So why bother? Two reasons: first, you can assign attributes to the entire union of objects very easily: union { sphere { <0, 1, 2>, 3 } box { <-77, 6, 5>, <2, 3, 55> } sphere { <-2, -3, -4>, 5 } pigment { color Blue } // applies to the entire union } In this case, the attribute pigment { color Blue } is applied to every object in the union. As always, this works with any attribute you care to try: pigment, translations, normal, etc. The second, and perhaps even more useful reason for using unions, is when you combine CSG and the #declare keyword, like this: #define two_spheres = union { sphere { <0, 0, 0>, 3 } sphere { <-1, -5, -1>, 3 } } From now on, you can reference the object two_spheres (which is, amazingly enough, two separate spheres) just as you would any other #declared object:



object { two_spheres pigment { color Pink } rotate <0, 180, 0> } Let's go through one more example, to make sure you understand -- this is a very important concept. Say you wanted to ray-trace a car. You'd create the wheels, then an axle, and then use union to stick them together. You could then re-use this wheel and axle combination however many times you wanted (depending on how many sets of wheels your car has). Your code might look something like this: #declare wheels_n_axle = union { object { // left wheel wheel // assuming we have already created a wheel object translate <-3, 0, 0> } object { axle }

// axle // assuming we have already created an axle object

object { // right wheel wheel // assuming we have already created a wheel object translate <3, 0, 0> } } #declare car = union { object { // front wheels and axle wheel_n_axle translate <0, 0, 5> } object { // rear wheels and axle wheels_n_axle translate <0, 0, -5> } // other car parts go here } Note that the order you place objects in a union is unimportant -- objects within a union don't really care about the other objects. This is different from the objects in a difference -- they are very caring, almost loving, objects, as you will see in the next section. A complete description of the union operator can be found in the CSG Section of the Language Reference. Difference A CSG difference is much like a mathematical difference -- it subtracts objects from one another. More specifically, it takes chunks out of the first object, each chunk being defined by the other objects in the difference statement. For example, say we wanted to make a wall that we would add a door to. The simplest way to do this is with a difference: #declare wall = difference { box { <0, 0, 0>, <10, 10, 1> } // 10x10x1 wall box { <2, 0, -1>, <6, 8, 2> } // minus a doorway texture { Wall_Texture } // assuming we have already created a Wall_Texture http://library.thinkquest.org/3285/tutorial/advanced_frames.html (4 of 7) [9/12/2001 3:46:18 PM]


} The first cube serves as the wall, and the second cube describes what, exactly, we want to take out from the wall. The two objects without the difference statement look like this:

When we add the difference statement, we get:

Note that we made the doorway cube thicker than the wall. Why? This is because, occasionally, POV-Ray will get confused when you have two objects that overlay exactly the same space. So, we made the doorway cube a little thicker, avoiding a potentially weird image, and at no loss to anything else. One important thing to about differences is that all objects are subtracted from the first one. If, for example, we wanted to add a few window holes to the wall above, we could just add a few more cubes at the very end, and voila! Once again, any attributes placed at the end of the difference statement will apply to the entire object. A complete reference for the difference keyword is located in the CSG Section of the Language Reference. Intersection Much as a difference removes the insides of objects, a intersection removes the outsides of objects. The result of using the intersection operator is that the only thing remaining is the parts which all the objects within the operator had in common. Let's say that you want to make a single, colored, sugar-coated chocolate candy that won't melt in your hands (not nameing any names). Furthermore, it must be a mathematically perfect candy. The easiest way to do this in POV-Ray is with an intersection, like this: #include "colors.inc" camera { location <0, 0, -5> look_at <0, 0, 0> } light_source { <10, 10, -10> color White } intersection { sphere { <0, -1, 0>, 2 } sphere { <0, 1, 0>, 2 } pigment { color Yellow } } This code takes two spheres that overlap, like this: http://library.thinkquest.org/3285/tutorial/advanced_frames.html (5 of 7) [9/12/2001 3:46:18 PM]


Then, it uses the intersection operator to remove everything that isn't overlapping, leaving an a remarkably sweet-looking goody, like this:

Although intersections are a little more difficult to imagine than some of the other CSG operators, they can be a very powerful tool. You can find a complete reference in the intersection section of the Language Reference. Merge Merge is very similar to union. In fact, the only difference between the two is that, if the objects actually overlap, merge will make the interior a smooth, continuous unit. Now, obviously, this won't make a difference to you if your objects aren't opaque. But if you have transparent, overlapping objects in your scene, the original object boundaries will be shown if you use a union (or no CSG at all); to get around this, you muts use merge. A complete reference for the merge operator can be found in the CSG Section of the Language Reference. Inverse Inverse is not used very often, but there are times when it must be used. Inverse will take your object and reverse what POV-Ray considers to be its "inside" and "outside." This will make no difference to the way your object looks, but it makes a great deal of difference to the wayyour object acts when you use it in CSG. Consider the intersection of a sphere and a box. If the sphere is inverted (by placing the keyword invert in its definition), then POV-Ray will take the intersection of the box and an object defined as "the entire universe except this sphere." If you think about it for a while (probaby a long while), you'll realize that that's the same as a difference. In other words, this: intersection { box { <0,0,0>,<1,1,1> } sphere { <1,1,1>, 1 inverse } } is the same as this: difference { box { <0,0,0>,<1,1,1> } sphere { <1,1,1>, 1 } } http://library.thinkquest.org/3285/tutorial/advanced_frames.html (6 of 7) [9/12/2001 3:46:18 PM]


In fact, POV-Ray calculates differences using this same method. A complete reference to the inverse keyword can be found in the CSG Section of the Language Reference.

Advanced Objects There are times when POV-Ray's geometric primitives aren't going to be enough for you. Face it, if you want to ray-trace something as complex as a human being, even CSG won't help you. In this case, there are two options left to you: The first is to specify your object in mathematical . Obviously, this will only work if 1. Your object can be described by an n-dimensional polynomial in 3-space; 2. You know what the heck I'm talking about; and 3. You like pain What we're trying to say here is that we're not about to teach you the math necessary to specify these objects, and, furthermore, we recommend against it, unless you really know what you're doing. Of course, if you'd like to read about the objects involved (namely, quadrics, cubics, quadrics and polys), the go right ahead. And if you can use them, so much the better. But if you don't have the math behind it, then don't worry about it; you'll probably sleep better at night. We have found these objects to be of limited use. The second option you have is to use a modelling program. What a modelling program can do is generate extremely complex objects in POV-Ray by specifying them as a whole bunch of really simple objects, normally blobs, triangles, smooth triangles. or bicubic patches. These objects, much like the the mathematical ones above, are not generally meant for human consumption -- in other words, don't bother trying to create objects with these by hand, because unless you really know what you're doing, you'll probably just waste a lot of time. Instead, find a good modelling program (there are many free and shareware ones out there; try the Resource Library), create the complex object in there (usually the modelling programs will have a very nice, graphical interface) and run POV-Ray on the file it creates. You will save a lot of time and effort. Top of Document

Main Page




Step 5: Conclusion

The Online POV-Ray Tutorial: Conclusion

The Online POV-Ray Tutorial Conclusion (Show Jump Points) (Hide Jump Points) Well, well, well. You've come far from the beginning of the Path of Learning. We'd just like to take a monute to congratulate you on your new found skills. Congratulations. You now know the POV-Ray language. Anything that can be done in POV-Ray is now within your grasp. However, this is just the beginning of your full journey through POV-Ray. This tutorial has helped as much as it can. Now all you need is experience. The main thing that distinguishes a good POV-Ray artist from an awesome POV-Ray artist is experience with ray tracing and possibly better hardware, but that's not as important. There are a great many ray tracing libraries on the internet and many of them include source. Check 'em out and see how the masters do things. Then you will be well on your way to becoming a POV-Ray master yourself. Top of Document

Main Page



http://library.thinkquest.org/3285/tutorial/conclusion.html [9/12/2001 3:46:29 PM]


Jump Points

The Online POV-Ray Tutorial Conclusion (Show Jump Points) (Hide Jump Points)

Main Page


Well, well, well. You've come far from the beginning of the Path of Learning. We'd just like to take a monute to congratulate you on your new found skills. Congratulations. You now know the POV-Ray language. Anything that can be done in POV-Ray is now within your grasp. However, this is just the beginning of your full journey through POV-Ray. This tutorial has helped as much as it can. Now all you need is experience. The main thing that distinguishes a good POV-Ray artist from an awesome POV-Ray artist is experience with ray tracing and possibly better hardware, but that's not as important. There are a great many ray tracing libraries on the internet and many of them include source. Check 'em out and see how the masters do things. Then you will be well on your way to becoming a POV-Ray master yourself. Top of Document

Main Page



The Online POV-Ray Tutorial © 1996 The Online POV-Ray Tutorial ThinkQuest Team Texture Library Object Library Scene Library Resource Library


http://library.thinkquest.org/3285/tutorial/conclusion_frames.html [9/12/2001 3:46:58 PM]

The Online POV-Ray Tutorial: Image: Difference Example #1

The Online POV-Ray Tutorial Image: Difference Example #1 A wall without a doorway. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/difference1.html [9/12/2001 3:47:02 PM]

http://library.thinkquest.org/3285/tutorial/images/difference1.gif

http://library.thinkquest.org/3285/tutorial/images/difference1.gif [9/12/2001 3:47:12 PM]

http://library.thinkquest.org/3285/tutorial/images/difference1_big.gif

http://library.thinkquest.org/3285/tutorial/images/difference1_big.gif [9/12/2001 3:48:26 PM]

The Online POV-Ray Tutorial: Image: Difference Example #2

The Online POV-Ray Tutorial Image: Difference Example #2 A wall with a doorway. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/difference2.html [9/12/2001 3:48:28 PM]

http://library.thinkquest.org/3285/tutorial/images/difference2.gif

http://library.thinkquest.org/3285/tutorial/images/difference2.gif [9/12/2001 3:48:30 PM]

http://library.thinkquest.org/3285/tutorial/images/difference2_big.gif

http://library.thinkquest.org/3285/tutorial/images/difference2_big.gif [9/12/2001 3:48:58 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/difference2.pov

#include "colors.inc" camera { location <-3, 10, 5> look_at <5, 5, 0> } plane { y, 0 pigment { checker color Black color White } } light_source { <-5, 10, 4> color White } light_source { <-3, 10, 5> color White } difference { box { <0, 0, 0>, <10, 10, 1> } box { <2, 0, -1>, <6, 8, 2> } pigment { color Red } }

http://library.thinkquest.org/3285/tutorial/examples/src/difference2.pov [9/12/2001 3:48:59 PM]

The Online POV-Ray Tutorial: Image: Intersection Example #1

The Online POV-Ray Tutorial Image: Intersection Example #1 Two big spheres stuck together. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/intersection1.html [9/12/2001 3:49:01 PM]

http://library.thinkquest.org/3285/tutorial/images/intersection1.gif

http://library.thinkquest.org/3285/tutorial/images/intersection1.gif [9/12/2001 3:49:11 PM]

http://library.thinkquest.org/3285/tutorial/images/intersection1_big.gif

http://library.thinkquest.org/3285/tutorial/images/intersection1_big.gif [9/12/2001 3:49:28 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/intersection1.pov

#include "colors.inc" camera { location <0, 0, -5> look_at <0, 0, 0> } light_source { <10, 10, -10> color White } sphere { <0, -1, 0>, 2 pigment { color Yellow } } sphere { <0, 1, 0>, 2 pigment { color Yellow } }

http://library.thinkquest.org/3285/tutorial/examples/src/intersection1.pov [9/12/2001 3:49:31 PM]

The Online POV-Ray Tutorial: Image: Intersection Example #2

The Online POV-Ray Tutorial Image: Intersection Example #2 The perfect bite-sized candy-coated chocolate treat. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/intersection2.html [9/12/2001 3:49:32 PM]

http://library.thinkquest.org/3285/tutorial/images/intersection2.gif

http://library.thinkquest.org/3285/tutorial/images/intersection2.gif [9/12/2001 3:49:34 PM]

http://library.thinkquest.org/3285/tutorial/images/intersection2_big.gif

http://library.thinkquest.org/3285/tutorial/images/intersection2_big.gif [9/12/2001 3:49:43 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/intersection2.pov

#include "colors.inc" camera { location <0, 0, -5> look_at <0, 0, 0> } light_source { <10, 10, -10> color White } intersection { sphere { <0, -1, 0>, 2 } sphere { <0, 1, 0>, 2 } pigment { color Yellow } }

http://library.thinkquest.org/3285/tutorial/examples/src/intersection2.pov [9/12/2001 3:49:47 PM]

The Online POV-Ray Tutorial: Image: Example Scene #1

The Online POV-Ray Tutorial Image: Example Scene #1 The first example scene. A red sphere. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/demo1.html [9/12/2001 3:49:53 PM]

http://library.thinkquest.org/3285/tutorial/images/demo1.gif

http://library.thinkquest.org/3285/tutorial/images/demo1.gif [9/12/2001 3:49:57 PM]

http://library.thinkquest.org/3285/tutorial/images/demo1_big.gif

http://library.thinkquest.org/3285/tutorial/images/demo1_big.gif [9/12/2001 3:50:27 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/demo1.pov

// A simple red sphere // first, the camera position camera { location <2,5,-10> look_at <0,0,0> } // now, some light light_source { <0,10,-10> color rgb <1,1,1> } // the sphere sphere { <0,0,0>, 5 pigment { color rgb <1,0,0> } }

http://library.thinkquest.org/3285/tutorial/examples/src/demo1.pov [9/12/2001 3:50:28 PM]

The Online POV-Ray Tutorial: Image: Transformation Example #1

The Online POV-Ray Tutorial Image: Transformation Example #1 Regular, un-transformed cube. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/transform1.html [9/12/2001 3:50:29 PM]

http://library.thinkquest.org/3285/tutorial/images/transform1.gif

http://library.thinkquest.org/3285/tutorial/images/transform1.gif [9/12/2001 3:50:31 PM]

http://library.thinkquest.org/3285/tutorial/images/transform1_big.gif

http://library.thinkquest.org/3285/tutorial/images/transform1_big.gif [9/12/2001 3:50:55 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/transform1.pov

// A plain blue box with x/y/z axes camera { location <5, 5, -10> look_at <0, 0, 0> } cylinder { <-50, 0, 0>, <50, 0, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, -50, 0>, <0, 50, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, 0, -50>, <0, 0, 50>, 0.1 pigment { color rgb <0, 1, 0> } } box { <-1, -1, -1>, <1, 1, 1> pigment { color rgb <0, 0, 1> } } light_source { <-10, 10, -10> color rgb <1, 1, 1> } light_source { <10, 10, -10> color rgb <1, 1, 1> }

http://library.thinkquest.org/3285/tutorial/examples/src/transform1.pov [9/12/2001 3:50:57 PM]


The Online POV-Ray Tutorial Image: Transformation Example #2 Translated cube. Original Image Large Image Source Code

Main Page








// A simple translated box with x/y/z axes. camera { location <5, 5, -10> look_at <0, 0, 0> } cylinder { <-50, 0, 0>, <50, 0, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, -50, 0>, <0, 50, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, 0, -50>, <0, 0, 50>, 0.1 pigment { color rgb <0, 1, 0> } } box { <-1, -1, -1>, <1, 1, 1> pigment { color rgb <0, 0, 1> } translate <-1, 4, 2> } light_source { <-10, 10, -10> color rgb <1, 1, 1> } light_source { <10, 10, -10> color rgb <1, 1, 1> }



The Online POV-Ray Tutorial Image: Transformation Example #3 Rotated cube. Original Image Large Image Source Code

Main Page








// A simple rotated box with x/y/z axes. camera { location <5, 5, -10> look_at <0, 0, 0> } cylinder { <-50, 0, 0>, <50, 0, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, -50, 0>, <0, 50, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, 0, -50>, <0, 0, 50>, 0.1 pigment { color rgb <0, 1, 0> } } box { <-1, -1, -1>, <1, 1, 1> pigment { color rgb <0, 0, 1> } rotate <0, 0, 45> } light_source { <-10, 10, -10> color rgb <1, 1, 1> } light_source { <10, 10, -10> color rgb <1, 1, 1> }



The Online POV-Ray Tutorial Image: Transformation Example #4 Translated, then rotated, cube. Original Image Large Image Source Code

Main Page








//A simple translated and rotated box with x/y/z axes camera { location <5, 5, -10> look_at <0, 0, 0> } cylinder { <-50, 0, 0>, <50, 0, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, -50, 0>, <0, 50, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, 0, -50>, <0, 0, 50>, 0.1 pigment { color rgb <0, 1, 0> } } box { <-1, -1, -1>, <1, 1, 1> pigment { color rgb <0, 0, 1> } translate <-1, 4, 2> rotate <0, 0, 45> } light_source { <-10, 10, -10> color rgb <1, 1, 1> } light_source { <10, 10, -10> color rgb <1, 1, 1> }



The Online POV-Ray Tutorial Image: Transformation Example #7 Rotated, then translated, sphere. Original Image Large Image Source Code

Main Page








// A rotated, then translated, cube, with x/y/z axes camera { location <5, 5, -10> look_at <0, 0, 0> } cylinder { <-50, 0, 0>, <50, 0, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, -50, 0>, <0, 50, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, 0, -50>, <0, 0, 50>, 0.1 pigment { color rgb <0, 1, 0> } } box { <-1, -1, -1>, <1, 1, 1> pigment { color rgb <0, 0, 1> } rotate <0, 0, 45> translate <-1, 4, 2> } light_source { <-10, 10, -10> color rgb <1, 1, 1> } light_source { <10, 10, -10> color rgb <1, 1, 1> }



The Online POV-Ray Tutorial Image: Transformation Example #5 Scaled cube. Original Image Large Image Source Code

Main Page








//A simple scaled box with x/y/z axes camera { location <5, 5, -10> look_at <0, 0, 0> } cylinder { <-50, 0, 0>, <50, 0, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, -50, 0>, <0, 50, 0>, 0.1 pigment { color rgb <0, 1, 0> } } cylinder { <0, 0, -50>, <0, 0, 50>, 0.1 pigment { color rgb <0, 1, 0> } } box { <-1, -1, -1>, <1, 1, 1> pigment { color rgb <0, 0, 1> } scale <1, 4, 1> } light_source { <-10, 10, -10> color rgb <1, 1, 1> } light_source { <10, 10, -10> color rgb <1, 1, 1> }



The Online POV-Ray Tutorial Image: Transformation Example #6 Scaled, translated and rotated torus. Original Image Large Image Source Code

Main Page








// A translated, scaled and rotated torus #include "colors.inc" torus { 3, 1 pigment { color Yellow } scale <1.5, 1, 1> rotate <-45, 0, 0> translate <0, 2, 0> } camera { location <5, 5, -10> look_at <0, 0, 0> } // x axis cylinder { <-50, 0, 0>, <50, 0, 0>, 0.1 pigment { color rgb <0, 1, 0> } } // y axis cylinder { <0, -50, 0>, <0, 50, 0>, 0.1 pigment { color rgb <0, 1, 0> } } //z axis cylinder { <0, 0, -50>, <0, 0, 50>, 0.1 pigment { color rgb <0, 1, 0> } } light_source { <-10, 10, -10> color rgb <1, 1, 1> } light_source { <10, 10, -10> color rgb <1, 1, 1> }


The Online POV-Ray Tutorial: Image: Pigment Example #1

The Online POV-Ray Tutorial Image: Pigment Example #1 A sphere with a gradient color map. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/pigment1.html [9/12/2001 3:55:39 PM]

http://library.thinkquest.org/3285/tutorial/images/pigment1.gif

http://library.thinkquest.org/3285/tutorial/images/pigment1.gif [9/12/2001 3:56:03 PM]

http://library.thinkquest.org/3285/tutorial/images/pigment1_big.gif

http://library.thinkquest.org/3285/tutorial/images/pigment1_big.gif [9/12/2001 3:56:41 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/pigment1.pov

// This is a sphere demonstrating the gradient pigment #include "colors.inc" // first, the camera position camera { location <2,5,-10> look_at <0,0,0> } // now, some light light_source { <0,10,-10> color White } light_source { <0,0,-10> color White } // the sphere sphere { <0,0,0>, 5 pigment { gradient <0, 1, 0> color_map { [0.0 color Red] [0.25 color Blue] [1.0 color Green] } scale 3 // make the pigment bigger } }

http://library.thinkquest.org/3285/tutorial/examples/src/pigment1.pov [9/12/2001 3:56:42 PM]

The Online POV-Ray Tutorial: Image: Pigment Example #2

The Online POV-Ray Tutorial Image: Pigment Example #2 A sphere with a gradient color map and some turbulence. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/pigment2.html [9/12/2001 3:56:44 PM]

http://library.thinkquest.org/3285/tutorial/images/pigment2.gif

http://library.thinkquest.org/3285/tutorial/images/pigment2.gif [9/12/2001 3:56:47 PM]

http://library.thinkquest.org/3285/tutorial/images/pigment2_big.gif

http://library.thinkquest.org/3285/tutorial/images/pigment2_big.gif [9/12/2001 3:58:05 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/pigment2.pov

// This is a sphere demonstrating the gradient pigment and turbulence #include "colors.inc" // first, the camera position camera { location <2,5,-10> look_at <0,0,0> } // now, some light light_source { <0,10,-10> color White } light_source { <0,0,-10> color White } // the sphere sphere { <0,0,0>, 5 pigment { gradient <0, 1, 0> turbulence 0.5 color_map { [0.0 color Red] [0.25 color Blue] [1.0 color Green] } scale 3 // make the pigment bigger translate <0, 10, 0> } }

http://library.thinkquest.org/3285/tutorial/examples/src/pigment2.pov [9/12/2001 3:58:09 PM]

The Online POV-Ray Tutorial: Image: Finish Example #1

The Online POV-Ray Tutorial Image: Finish Example #1 Sphere with phong highlights. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/finish1.html [9/12/2001 3:58:12 PM]

http://library.thinkquest.org/3285/tutorial/images/finish1.gif

http://library.thinkquest.org/3285/tutorial/images/finish1.gif [9/12/2001 3:58:20 PM]

http://library.thinkquest.org/3285/tutorial/images/finish1_big.gif

http://library.thinkquest.org/3285/tutorial/images/finish1_big.gif [9/12/2001 3:58:34 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/finish1.pov

// This is a simple red sphere with phong highlights // first, the camera position camera { location <2,5,-10> look_at <0,0,0> } // now, some light light_source { <-7,10,-10> color rgb <1,1,1> } light_source { <17, -10, 0> color rgb <1,1,1> } // the sphere sphere { <0,0,0>, 5 pigment { color rgb <0,1,0> } finish { phong 1 } }

http://library.thinkquest.org/3285/tutorial/examples/src/finish1.pov [9/12/2001 3:58:37 PM]


The Online POV-Ray Tutorial Image: Finish Example #2 Yellow mirrorish sphere floating above an infinite checkerboard. Original Image Large Image Source Code

Main Page








// A yellow mirrorish sphere above a checkerboard #include "colors.inc" camera { location <-2, 3, -10> look_at <0, 5, 0> } plane { // the floor y, 0 // along the x-z plane (y is the normal vector) pigment { checker color Black color White } // checkered pattern } sphere { <0, 5, 0>, 2 pigment { color Yellow } finish { reflection 0.9 phong 1 } } light_source { <10, 10, -10> color White } light_source { <-10, 5, -15> color White }



The Online POV-Ray Tutorial Image: Finish Example #3 A crystal ball. Original Image Large Image Source Code

Main Page








// A crystal ball #include "colors.inc" camera { location <-2, 5, -5> look_at <0, 5, 0> } plane { // the floor z, 10 // along the x-z plane (y is the normal vector) pigment { checker color Green color Yellow } // checkered pattern } sphere { <0, 5, 0>, 2 pigment { color rgbf <1, 1, 1, .8> } // transparent sphere finish { reflection 0.1 refraction 1.0 ior 1.5 phong 1 } } light_source { <10, 10, -10> color White }


The Online POV-Ray Tutorial: Finish Tool

The Online POV-Ray Tutorial Finish Exploration Tool This tool is designed to let you experiment with different values of different finishes. To experiment with a parameter, select an option from the menu below and press "Select". Viewing "collectively" will show you all the possible images you can view and allow you to select from them. Viewing "individually" will show you an image and allow you to vary the amount of the finish. The images we have here do not represent the only allowable values for these parameters, we just chose a range of values so you could get a feel for how the parameter changes the object. I want to experiment with highlights

and view the images individually

Select

Top of Document

Main Page


http://library.thinkquest.org/3285/cgi-bin/SelectFinish.cgi [9/12/2001 4:01:29 PM]

The Online POV-Ray Tutorial: Image: Normal Example #1

The Online POV-Ray Tutorial Image: Normal Example #1 A bumpy cone. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/normal1.html [9/12/2001 4:01:33 PM]

http://library.thinkquest.org/3285/tutorial/images/normal1.gif

http://library.thinkquest.org/3285/tutorial/images/normal1.gif [9/12/2001 4:01:41 PM]

http://library.thinkquest.org/3285/tutorial/images/normal1_big.gif

http://library.thinkquest.org/3285/tutorial/images/normal1_big.gif [9/12/2001 4:02:04 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/normal1.pov

// A bumpy cone // first, the camera position camera { location <2,2,-6> look_at <0,0,0> } // now, some light light_source { <3,2,-6> color rgb <2,2,2> } // the cone cone { <0, -3, 0>, 1 <0, 3, 0>, 0.1 texture { normal { bumps 0.5 // add some bumps scale 1/6 } pigment { color rgb <.5, .7, .2> } } }

http://library.thinkquest.org/3285/tutorial/examples/src/normal1.pov [9/12/2001 4:02:05 PM]

The Online POV-Ray Tutorial: Image: Normal Example #2

The Online POV-Ray Tutorial Image: Normal Example #2 A blue plane with ripples. Original Image Large Image Source Code

Main Page


http://library.thinkquest.org/3285/tutorial/examples/normal2.html [9/12/2001 4:02:06 PM]

http://library.thinkquest.org/3285/tutorial/images/normal2.gif

http://library.thinkquest.org/3285/tutorial/images/normal2.gif [9/12/2001 4:02:13 PM]

http://library.thinkquest.org/3285/tutorial/images/normal2_big.gif

http://library.thinkquest.org/3285/tutorial/images/normal2_big.gif [9/12/2001 4:05:12 PM]

http://library.thinkquest.org/3285/tutorial/examples/src/normal2.pov

// A plane with ripples // first, the camera position camera { location <-4,5,-6> look_at <0,0,0> } // now, some light light_source { <3,2,-6> color rgb <2,2,2> } plane { y, -2 texture { pigment { color rgb <.1, .9, .9> } normal { ripples 0.5 } } }

http://library.thinkquest.org/3285/tutorial/examples/src/normal2.pov [9/12/2001 4:05:13 PM]

The Online POV-Ray Tutorial: Normal Tool

The Online POV-Ray Tutorial Normal Exploration Tool This tool is designed to let you experiment with different values of different normals. To experiment with a parameter, select an option from the menu below and press "Select". Viewing "collectively" will show you all the possible images you can view and allow you to select from them. Viewing "individually" will show you an image and allow you to vary the amount of the normal modifier. The images we have here do not represent the only allowable values for these parameters, we just chose a range of values so you could get a feel for how the parameter changes the object. I want to experiment with bumps

and view the images individually Select

Top of Document

Main Page


http://library.thinkquest.org/3285/cgi-bin/SelectNormal.cgi [9/12/2001 4:05:15 PM]


#include "colors.inc" union { box { <-1, -1, -1>, <1, 1, 1> pigment { color Red } } cylinder { <1.5, 1.5, -1.5>, <-1.5, -1.5, 1.5>, 0.5 pigment { color Green } } } plane { y, -3 pigment { checker color White color Black } } plane { -z, -3 pigment { checker color White color Black } } light_source { <-400, 200, -300> color rgb <1, 1, 1> } camera { location <-2, 3, -4> look_at <0, 0, 0> }


http://library.thinkquest.org/3285/language/src/modifie1.pov

box { <-1, -1, -1>, <1, 1, 1> clipped_by { sphere { <-1, -1, 1>, 2.6 } } pigment { color rgb <1, 1, 0> } } light_source { <40, 40, -50> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/modifie1.pov [9/12/2001 4:06:23 PM]


box { <-1, -1, -1>, <1, 1, 1> clipped_by { sphere { <-1, -1, 1>, 2.6 } sphere { <1, 1, -1>, 2.6 } } pigment { color rgb <1, 1, 0> } } light_source { <40, 40, -50> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



box { <0, 0, 0>, <1, 1, 1> pigment { image_map { gif "../gfx/mmap.gif" } } } plane { -z, -10 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> rotate 45*z } } light_source { <50, 30, -50> color rgb <1, 1, 1> } camera { location <1.5, 1.5, -2> look_at <0.5, 0.5, 0.5> }



sphere { <0, 0, 0>, 0.5 pigment { image_map { gif "../gfx/mmap.gif" map_type 1 } rotate y*-90 } translate <0.5, 0.5, 0.5> } plane { -z, -10 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> rotate 45*z } } light_source { <50, 30, -50> color rgb <1, 1, 1> } camera { location <1.5, 1.5, -2> look_at <0.5, 0.5, 0.5> }



cylinder { <0, 0, 0>, <0, 1, 0>, 0.5 pigment { image_map { gif "../gfx/mmap.gif" map_type 2 } rotate y*-90 } translate <0.5, 0.5, 0.5> } plane { -z, -10 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> rotate 45*z } } light_source { <50, 30, -50> color rgb <1, 1, 1> } camera { location <1.5, 1.5, -2> look_at <0.5, 0.5, 0.5> }



torus { 0.75, 0.25 pigment { image_map { gif "../gfx/mmap.gif" map_type 5 } rotate y*-90 } translate <0.5, 0.5, 0.5> } plane { -z, -10 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> rotate 45*z } } light_source { <50, 30, -50> color rgb <1, 1, 1> } camera { location <1.5, 1.5, -2> look_at <0.5, 0.5, 0.5> }



sphere { <0, 0, 0>, 1 pigment { color rgb <1, 0, 0> } } disc { <0, -2, 0>, y, 4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } } light_source { <10, 50, -10> color rgb <1, 1, 1> } camera { location <0, 1, -4> look_at <0, -1, 0> }



sphere { <0, 0, 0>, 1 no_shadow pigment { color rgb <1, 0, 0> } } disc { <0, -2, 0>, y, 4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } } light_source { <10, 50, -10> color rgb <1, 1, 1> } camera { location <0, 1, -4> look_at <0, -1, 0> }



cylinder { <0, 0, -2>, <0, 0, 2>, 0.5 pigment { color rgb <1, 0, 0> } rotate <-6, 6, 0> } light_source { <0, 4, -20> color rgb <1, 1, 1> } camera { location <0, 0, -4> look_at <0, 0, 0> }



cylinder { <0, 0, -2>, <0, 0, 2>, 0.5 open pigment { color rgb <1, 0, 0> } rotate <-6, 6, 0> } light_source { <0, 4, -20> color rgb <1, 1, 1> } camera { location <0, 0, -4> look_at <0, 0, 0> }


http://library.thinkquest.org/3285/language/src/texture1.pov

box { <0, 0, 0>, <1, 0.99, 1> texture { material_map { gif "mmap.gif" texture { pigment { mandel 100 color_map { [0.00 color rgb <0.2, 0, 0.2>] [0.10 color rgb <1, 0, 1>] [0.60 color rgb <1, 1, 1>] [1.00 color rgb <1, 1, 1>] [1.00 color rgb <0, 0, 0>] } scale 1/4 rotate <0, 0, -45> translate <0.5, 0.5, 0> } } texture { pigment { mandel 100 color_map { [0.00 color rgb <0, 0.2, 0.2>] [0.10 color rgb <0, 1, 1>] [0.60 color rgb <1, 1, 1>] [1.00 color rgb <1, 1, 1>] [1.00 color rgb <0, 1, 1>] } scale 1/4 rotate <0, 0, -45> translate <0.5, 0.5, 0> } } texture { pigment { marble color_map { [0 color rgb <0, 0, 0>] [1 color rgb <1, 1, 1>] } turbulence 1.0 scale 1/6 } } texture { pigment { color rgb <1, 1, 1> } finish { reflection 0.8 diffuse 0.2 ambient 0 } normal { bumps 0.1 scale 1/2 } } } }

http://library.thinkquest.org/3285/language/src/texture1.pov (1 of 2) [9/12/2001 4:06:51 PM]


scale 4 } disc { <0, 0, 0>, y, 15 pigment { checker color rgb <0, 0, 0> color rgb <1, 1, 1> } rotate 30 * y } light_source { <50, 50, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <2, 2, 0> }

http://library.thinkquest.org/3285/language/src/texture1.pov (2 of 2) [9/12/2001 4:06:51 PM]


#default { finish { ambient 0 diffuse 1 } } sphere { <0, 0, 0>, 2 texture { pigment { bozo color_map { [0.0 color rgb <0.3, 0, 0>] [1.0 color rgb <0.6, 0.2, 0>] } turbulence 0.3 scale 1/2 } } } light_source { <50, 35, -50> color rgb <1, 1, 1> } camera { location <0, 0, -6> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/texture2.pov [9/12/2001 4:06:56 PM]


#default { finish { ambient 0 diffuse 1 } } sphere { <0, 0, 0>, 2 texture { pigment { bozo color_map { [0.0 color rgb <0.3, 0, 0>] [1.0 color rgb <0.6, 0.2, 0>] } turbulence 0.3 scale 1/2 } } texture { pigment { agate color_map { [0.0 color rgbf <1, 1, 1, 1>] [0.5 color rgbf <1, 1, 1, 1>] [0.5 color rgbf <0.5, 0, 0, 1>] [0.75 color rgb <0.5, 0, 0>] [1.0 color rgb <1, 0.5, 0>] } turbulence 1.0 scale 1.5 } } } light_source { <50, 35, -50> color rgb <1, 1, 1> } camera { location <0, 0, -6> look_at <0, 0, 0> }



#default { finish { ambient 0 diffuse 1 } } sphere { <0, 0, 0>, 2 texture { pigment { bozo color_map { [0.0 color rgb <0.3, 0, 0>] [1.0 color rgb <0.6, 0.2, 0>] } turbulence 0.3 scale 1/2 } } texture { pigment { agate color_map { [0.0 color rgbf <1, 1, 1, 1>] [0.5 color rgbf <1, 1, 1, 1>] [0.5 color rgbf <0.5, 0, 0, 1>] [0.75 color rgb <0.5, 0, 0>] [1.0 color rgb <1, 0.5, 0>] } turbulence 1.0 scale 1.5 } } texture { pigment { granite color_map { [0.0 color rgb <1, 1, 0>] [0.2 color rgbf <1, 1, 1, 1>] [1.0 color rgbf <1, 1, 1, 1>] } } } } light_source { <50, 35, -50> color rgb <1, 1, 1> } camera { location <0, 0, -6> look_at <0, 0, 0> }



plane { -z, 0 texture { tiles { texture { pigment { marble color_map { [0.0 color rgb <1, 1, 1>] [0.75 color rgb <0.75, 0.75, 0.75>] [1.0 color rgb <0, 0, 0>] } turbulence 0.8 } finish { phong 0.7 } } tile2 texture { pigment { marble color_map { [0.0 color rgb <0, 0, 0>] [0.75 color rgb <0.25, 0.25, 0.25>] [1.0 color rgb <1, 1, 1>] } turbulence 0.8 } finish { phong 0.7 } rotate <0, 0, 90> } } } } light_source { <5, 0, -6> color rgb <1, 1, 1> } camera { location <0, 0, -6> look_at <0, 0, 0> }



plane { y, 0 rotate <-55, -45, 0> translate <0, 1/2, 0> texture { tiles { texture { pigment { marble color_map { [0.0 color rgb <1, 1, 1>] [0.75 color rgb <0.75, 0.75, 0.75>] [1.0 color rgb <0, 0, 0>] } turbulence 0.8 } finish { phong 0.7 } } tile2 texture { pigment { marble color_map { [0.0 color rgb <0, 0, 0>] [0.75 color rgb <0.25, 0.25, 0.25>] [1.0 color rgb <1, 1, 1>] } turbulence 0.8 } finish { phong 0.7 } rotate <0, 0, 90> } } } scale 3 } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <6, 0, -6> look_at <0, 0, 0> }



#declare Pigm = pigment { granite color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { hexagon color rgb <1, 0.25, 0.25> color rgb <0.25, 0.25, 1> color rgb <0.25, 1, 0.25> scale 0.5 } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { leopard color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } scale 1/5 } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { mandel 50 color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { marble color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { marble color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } turbulence 0.8 } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { onion color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { spotted color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Pigm = pigment { wood color_map { [0.00 color rgb <1, 0.25, 0.25>] [0.33 color rgb <1, 1, 0.25>] [0.50 color rgb <0.25, 1, 0.25>] [0.66 color rgb <0.25, 0.25, 1>] [1.00 color rgb <1, 0.25, 0.25>] } } sphere { <1.5, 0, 0>, 1 pigment { Pigm translate <1.5, 0, 0> } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { Pigm translate <-1.5, 0, 0> } } light_source { <150, 200, -500> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }


http://library.thinkquest.org/3285/language/src/languag1.pov

plane { y, 0 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } } union { cone { <0, 0, 0>, 1 <0, 4, 0>, 0 } cone { <4, 0, 0>, 1 <4, 3, 0>, 0 } cone { <-4, 0, 0>, 1 <-4, 3, 0>, 0 } cone { <0, 0, 4>, 1 <0, 3, 4>, 0 } cone { <0, 0, -4>, 1 <0, 3, -4>, 0 } pigment { color rgb <1, 1, 0> } } light_source { <-100, 200, -500> color rgb <1, 1, 1> } camera { location <2, 7, -2> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/languag1.pov [9/12/2001 4:08:00 PM]


plane { y, 0 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } } union { cone { <0, 0, 0>, 1 <0, 4, 0>, 0 } cone { <4, 0, 0>, 1 <4, 3, 0>, 0 } cone { <-4, 0, 0>, 1 <-4, 3, 0>, 0 } cone { <0, 0, 4>, 1 <0, 3, 4>, 0 } cone { <0, 0, -4>, 1 <0, 3, -4>, 0 } pigment { color rgb <1, 1, 0> } } fog { color rgb <0, 0, 1> distance 12 } light_source { <-100, 200, -500> color rgb <1, 1, 1> } camera { location <2, 7, -2> look_at <0, 0, 0> }



cone { <0, 0, 0>, 1, <0, 4, 0>, 0 pigment { hexagon color rgb <1, 0.4, 0> color rgb <1, 1, 0> color rgb <1, 0.7, 0> scale 1/6 } } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <0, 2, -8> look_at <0, 2, 0> }



cone { <0, 0, 0>, 1, <0, 4, 0>, 0 pigment { hexagon color rgb <1, 0.4, 0> color rgb <1, 1, 0> color rgb <1, 0.7, 0> scale 1/6 } rotate <-90, 90, 0> } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <0, 2, -8> look_at <0, 2, 0> }



cone { <0, 0, 0>, 1, <0, 4, 0>, 0 pigment { hexagon color rgb <1, 0.4, 0> color rgb <1, 1, 0> color rgb <1, 0.7, 0> scale 1/6 } rotate 90*y rotate -90*x } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <0, 2, -8> look_at <0, 2, 0> }



union { cylinder { <1, 0, 0>, <1, 1, 0>, 0.25 } cylinder { <-0.5, 0, 0.866025>, <-0.5, 1, 0.866025>, 0.25 } cylinder { <-0.5, 0, -0.866025>, <-0.5, 1, -0.866025>, 0.25 } pigment { color rgb <0, 1, 1> } } disc { <0, 0, 0>, y, 3 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <1.5, 3, -1.5> look_at <0, 0, 0> }


http://library.thinkquest.org/3285/language/src/langua10.pov

union { cylinder { <1, 0, 0>, <1, 1, 0>, 0.25 } cylinder { <1, 0, 0>, <1, 1, 0>, 0.25 rotate 120*y } cylinder { <1, 0, 0>, <1, 1, 0>, 0.25 rotate 240*y } pigment { color rgb <0, 1, 1> } } disc { <0, 0, 0>, y, 3 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 0> } } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <1.5, 3, -1.5> look_at <0, 0, 0> }

http://library.thinkquest.org/3285/language/src/langua10.pov [9/12/2001 4:08:12 PM]


box { <0, 0, -0.5>, <1, 1, 0.5> pigment { checker color rgb <0.6, 0.6, 1.0> color rgb <0.2, 0.2, 1.0> scale 1/3.9 } } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <1.25, 1.25, -2> look_at <0, 0, 0> }



box { <0, 0, -0.5>, <1, 1, 0.5> pigment { checker color rgb <0.6, 0.6, 1.0> color rgb <0.2, 0.2, 1.0> scale 1/3.9 } scale <1, 1/3, 1> rotate 45*z } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <1.25, 1.25, -2> look_at <0, 0, 0> }



box { <0, 0, -0.5>, <1, 1, 0.5> pigment { checker color rgb <0.6, 0.6, 1.0> color rgb <0.2, 0.2, 1.0> scale 1/3.9 } rotate 45*z scale <1, 1/3, 1> } light_source { <50, 50, -50> color rgb <1, 1, 1> } camera { location <1.25, 1.25, -2> look_at <0, 0, 0> }



#declare Fin = finish { phong 0.9 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { phong 0.9 metallic } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { phong 0.9 phong_size 4 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { phong 0.9 phong_size 180 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { reflection 0.3 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { refraction 1 ior 1 } sphere { <1.5, 0, 0>, 1 pigment { color rgbf <1, 1, 0, 0.7> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgbf <1, 0, 1, 0.7> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { refraction 1 ior 1.5 } sphere { <1.5, 0, 0>, 1 pigment { color rgbf <1, 1, 0, 0.7> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgbf <1, 0, 1, 0.7> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { refraction 1 ior 2.0 } sphere { <1.5, 0, 0>, 1 pigment { color rgbf <1, 1, 0, 0.7> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgbf <1, 0, 1, 0.7> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { specular 0.9 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { specular 0.9 roughness 0.75 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }



#declare Fin = finish { specular 0.9 roughness 0.001 } sphere { <1.5, 0, 0>, 1 pigment { color rgb <1, 1, 0> } finish { Fin } } box { <-2.5, -1, -1>, <-0.5, 1, 1> pigment { color rgb <1, 0, 1> } finish { Fin } } plane { y, -1 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } } plane { -z, -4 pigment { checker color rgb <1, 1, 1> color rgb <0, 0, 1> } finish { ambient 0.5 } } light_source { <100, 500, -100> color rgb <1, 1, 1> } camera { location <2, 2, -5> look_at <0, 0, 0> }












#default { texture { finish { ambient 0 diffuse 1 } } } #declare sqrt2_2 = 0.707 #declare Light = light_source { <100, 100, -200> color rgb <1, 1, 1> spotlight point_at <0, 0, 0> radius 1.5 falloff 2 tightness 1 } union { torus { 5, 0.5 rotate <90, 0, 0> } cylinder { <0, 0, 0>, <0, 10, 0>, 0.5 } pigment { color rgb <0.5, 0.5, 1> } } plane { y, 0 pigment { checker color rgb <0.75, 0, 0.75> color rgb <0.5, 0, 0.5> scale 3 } } light_source { Light } camera { location <-2, 16, -8> look_at <0, 5, 0> }



#default { texture { finish { ambient 0 diffuse 1 } } } #declare sqrt2_2 = 0.707 #declare Light = light_source { <100, 100, -200> color rgb <1, 1, 1> spotlight point_at <0, 0, 0> radius 1.5 falloff 2 tightness 100 } union { torus { 5, 0.5 rotate <90, 0, 0> } cylinder { <0, 0, 0>, <0, 10, 0>, 0.5 } pigment { color rgb <0.5, 0.5, 1> } } plane { y, 0 pigment { checker color rgb <0.75, 0, 0.75> color rgb <0.5, 0, 0.5> scale 3 } } light_source { Light } camera { location <-2, 16, -8> look_at <0, 5, 0> }


Pov Ray Tutorial 5h573o

Overview 1s532p

More details 6h715l

Related Documents 2w1qw

Pov Ray Tutorial 5h573o

Tutorial Pov Ray 2e3148

Tutorial Pov Ray 2e3148

Tutorial V-ray - Iluminacion Exterior 4k3go

Aiden Pov 631245

Tutorial Grabar Blu-ray Bd25 Con Imgburn 51253f