From Wikibooks, open books for an open world
Jump to: navigation, search

Paul Stansifer

See en:User:Paullusmagnus

Installing Linux (outline)[edit]


  • Oftentimes, installing Linux is hard because you want to keep you data/OS
  • If not, (new computer, don't care about old OS + data backup), it's easier.
  • Depending on what hardware the computer has and your experience level, the ease of installation varies greatly

Do you want to install Linux?[edit]

  • Software
    • (usually) compatible and equivalent for most purposes, and (almost always) free (table of equivalents) (include narrower, deeper list)
  • Performance
    • Good idea!
  • Price
    • Not free but close
  • Ease-of-use
    • mixed ... getting better [1]
  • Stability
    • Good ... unless you get so hooked you start using nightly builds and unstable releases

Which of these goals apply?

  • keeping data
    • ...without restoring a backup
  • coexistence with another OS
  • sharing data with that OS
    • both ways?

Can it be done?[edit]

  • Low-end systems are almost always fine (unless you have a 286 lying around)
  • Can you backup? (do you need to?)
  • Does the hardware work? (see #Trying Linux)

Trying Linux[edit]

  • Floppy distros
  • en:Knoppix/en:Gnoppix
    • Very useful later on as well; if it provides an Internet connection while you're trying to set up the main one, it can save you a great deal of trouble.
  • Running Linux from another OS's partition.

Choosing a Linux[edit]

(or do you want a BSD instead?)

  • Desktop environment (GNOME/KDE/blackbox/wm/console)
  • Distros: ease-of-use vs. power, package management. A visit to should be mandantory.
    • Debian
      • Don't use the stable release (as of 2004, it is over three years old)! (unstable is better)
      • For a quick&easy install, get Knoppix 3.3 or later and install that.
      • Otherwise, be sure to have an Internet connection and be prepared to learn a lot.

Stuff you should learn[edit]

  • Basic command line manipulation
  • Text editor: vi/EMACS
  • Recompiling the kernel (not that hard, may be necessary).
  • Using Lynx

Getting Linux[edit]

  • Download
    • CD
    • Spare partition
  • Network install
    • CD
    • Floppies
    • Spare partition
  • Buy a CD/DVD
    • price/donations
  • Buy a computer with Linux on it


  • Nodestructive repartitioning
    • defragment first!
    • FAT - FIPS
    • NTFS - ntfsresize
  • Backup and reinstall
    • writable CD/DVD
    • network
    • tape


  • unnessecary sometimes, with FAT partitions
    • but you probably want to do it anyways
  • what partions you'll need to make
  • ext3? ReiserFS? XFS?
  • how much space per partition


  • You ought to already know enough about the hardware at this point.
  • This has become a lot easier.
  • But, know about your hardware, and be sure to have Internet access, in case something doesn't work.

After the install[edit]

  • Data transfer/conversion
  • Configuration
    • security
    • environment
  • Proceed to Using Linux

Computer Graphics: 3D[edit]

Because computers are millions of times as fast at arithmetic than humans, they can be used to generate the 2-dimensional view of a 3-dimensional scene algorithmically.

Raytracing describes the process of simulating the straight lines that light follows as it bounces off objects into the viewer's eye. Because determining the path of millions of photons is incredibly difficult, backwards raytracing traces the path from the eye to the object to the light source, so only one ray needs to be sent out per pixel in the finished product.

Here, the Persistance of Vision Raytracer, or POV-Ray, will be used to demonstrate raytracing for the following reasons:

  • It is free software, and availible on virtually all platforms, so it is accessible to everyone.
  • Scenes are defined by means of text files, so examples are easy to follow and the underlying aspects of raytracing are more evident.
  • The scene files are also modular as in a programming language, so it is easy to build off the work of others.
  • [plus, the author hasn't used anything else]

It may be downloaded from for Linux, Microsoft Windows, or MacOS. The help files are extensive and can serve as indrotuction to ray-tracing on their own.

Sanity check[edit]

We will now render the original computer graphics cliché: a mirrored sphere hovering over a checkered plane. Enter the following text into "lesson01-test.pov" (Windows users can enter it into POV-Ray for Windows's internal text editor and save it as this when prompted)

 /*Test scene*/
 #version 3.5;  //this code will work in POV-Ray version 3.5
    assumed_gamma 1.0 //make sure that this looks the same on all monitors

    color rgb <0,0,1>
    y, 0  /*normal vector, position along that vector*/
          color rgb <0,1,0> /*green*/
          color rgb <1,1,1> /*white*/
    <0,2,0>, 1 /*location, radius*/
          color rgb <0,0,0>
          reflection{0.9} ambient 0.0 specular 0.5
    <0,0,0> /*location*/
    color rgb <1,1,1> /*colored white*/
    location <-4,2.5,0>
    look_at <0,2,0>

What's antialiasing?

The pixels on your computer screen are large enough for you to see individually. Since the real world isn't made up of tiny squares like pictures on a computer screen are, diagonal lines and curves tend to come out looking jagged. Antialiasing counteracts this by making pixels that cover an edge border an average of the two colors. This looks better, but takes more time, as multiple rays must be sent out per pixel.

Render this with the command line parameters "+W320 +H240 +A0.3 +FN" to output a PNG file called "lesson01-test.png" that is 320x240 pixels and is antialiased. If it goes too slowly, use "-A" instead of "+A0.3" next time to turn off antialiasing. If you can see the preview window and don't want to save the image file, next time, use "-F" instead of "+FN".

If all goes well, you will see a mirrored sphere hovering over a green and white checkered floor against a blue sky.

POV-Ray's syntax[edit]

Programmers will feel right at home with POV-Ray's syntax, because it is inspired by the C programming language. Whitespace and ends of lines are ignored (camera{location<-4,2.5,0> look_at<0,2,0>} is perfectly legal), comments surrounded by /*...*/ are ignored, as are comments coming after // on a line. The scene file should consist of sequence of "scene items" (their order doesn't matter), where scene items are usually the camera, lights, and objects.

A page about setting up POV-Ray belongs here.

How to use objects[edit]

There are two objects in the test scene, the plane and the sphere. Let's look at the sphere.

     <0,2,0>, 1 /*location, radius*/
           color rgb <0,0,0>
           reflection{0.9} ambient 0.0 specular 0.5

Change the <0,2,0> to <0,0,0> and rerender. What happens?



Objects are made of primitives, simple and not-so-simple constructs like "plane", "sphere", "isosurface". They can be combined by means of Constructive Solid Geometry or CSG. CSG works by adding and subtracting primitives and is very useful for the creation of objects with a large number of simple surfaces, such as floppy disks and furniture.

POV-Ray primitives are seperated into categories:

finite solid primitives 
These are most like real objects. The simple finite solid primitives include box, sphere, cone, cylinder, lathe, torus, and text.
finite patch primitives 
These don't have any thickness. They are polygon, disc, triangle, and bicubic_patch. Triangles can be efficiently grouped in very large numbers with mesh and mesh2. Usually, this is used for files imported from other formats.
infinite solid primitives 
plane is the only common one, the others create surfaces defined by polynomial equations
special math objects 
parametric and isosurface can be used to mathematically define complex surfaces.

The CSG operations are

Combine multiple objects into one. merge removes internal surfaces for use in, for example, glass.
Cut out the shape of one object from another.
Remove all the shape that isn't in both (all) objects.

The inverse keyword turns an object inside-out. The difference is not visible with a plain object (because objects consist only of their surfaces and the surface is in the same place), but is very useful in CSG. intersection{object{A} object{B}} is the same as difference{object{A} object{B inverse}}. (The object{} syntax will be explained later).

For example, here is a coffee cup scene. Try this out in "lesson02-csg.pov"

  #version 3.5;
  background{color rgb <0,0,1>}
  plane{ y, 0 pigment{checker color rgb <0,1,0> color rgb <1,1,1>}}
           <0,0,0>, <0,2,0>, 1 /*bottom, top, radius of cylinder*/
              color rgb <1,0,0> //red
           <0,2.0001,0> /*results are unpredictable when this is <0,2,0>
                          because it creates "coincident surfaces"*/
              color rgb <0,1,0> //green
        .5, .15
        rotate x*90
        translate x*1.5+y*1
           color rgb <0,0,1> //blue
     translate z*1
  light_source{<2,5,-4> /*location*/ color rgb <1,1,1> /*colored white*/}
  camera{location <0,3.5,-4> look_at <0,2,0> right x*image_width/image_height }

Notice that the parts that we are not currently concerned with have been compressed onto their own lines.

Standard practice[edit]

But you've been leaving "texture" out!

texture blocks can contain pigment, normal, and finish blocks for objects with complicated surfaces. It becomes inconvenient to write "texture{ pigment{ color rgb <0,1,0> }}" if a pigment is all that's needed, so POV-Ray allows you to leave that. "texture" should be used if more than one of the above blocks are included, or if that object has layered textures (more on them later).

As in programming, POV-Ray files can become unreadable and hard to modify if not written well. The code structure is hiearchial — you could have a sphere which contains a texture block, which contains a pigment block, which contains a color_map block, for example. The general rule is that each level of hiearchy is indented one level further than the previous:

   <0,1,0>, .5
         /*don't worry about the unusualness of this section for now*/
         bozo scale .4 
            [0.0 color rgb <1.0,0.4,0.4>]
            [1.0 color rgb <0.1,0.4,0.9>]
       finish{ specular 1.0 diffuse 0.4}

Notice that the rule was violated in the above example - the finish block was squished onto one line. Well, this finish statement us very short (they almost always are), and one can save space and make the code more legible by violating the rule for simple statements, especially those deep in the hiearchy.


How does one represent colors in text? Simple names like "red" and "magenta" aren't good enough for duplicating that subtle purple-pinkish color on the main page. Any color can be described as a combination of red, green and blue because of the way the human eye works. POV-Ray represents colors as vectors of numbers between 0 and 1. color rgb <1.0, 0.4, 0.4> is a red color with extra green and blue added — this makes it a light-red color.

Sometimes, a partially-transparent color is needed, like for defining colored cellophane. In this case something like color rgbft <0.5, 0.2, 0.2, 0.4, 0.6> would be used, adding two numbers to describe the transparencey. But good-looking transparent objects require more than that, so we'll save that for later.

Needed/needs consideration[edit]

  • standardized code formats
  • should we introduce so many things at once? (copy&pasting text files could be annoying, so maybe we should keep the number of things introduced low)
    • how about a .zip or .tar.bz2 with all the files needed: one download, and instructions are of the form "open Chapter07/specular.pov"?
  • standard sidebars? ("what's antialiasing?" "why'd texture disappear?" "How do I do this?")