Journal Articles
Browse in : |
All
> Journals
> CVu
> 133
(12)
|
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Members' Experiences
Author: Administrator
Date: 05 June 2001 13:15:46 +01:00 or Tue, 05 June 2001 13:15:46 +01:00
Summary:
POVray
Body:
I needed to illustrate some data structures in three dimensions, but I am not adept at drawing. I therefore hacked my Python program into outputting its data as a scene description file for POVray version 3, a freely-distributable multi-platform raytracing package (www.povray.org).
Ray tracing is a laborious, CPU-intensive process for generating bitmap images of three-dimensional scenes. The model is that there is some three-dimensional space behind the image; for each pixel on the image, an imaginary line is taken from the assumed eye position to that pixel, and continued into the scene space. The program solves intersection equations to find out which object (if any) the line will reach first, and calculates what effect that object would have on the light (depending on its colour, texture, translucency and so on). The ray may then be traced on to other parts of the image depending on the light sources (and how obscured they are), reflectivity and translucency parameters, and so forth. Once everything has been accounted for, the pixel is plotted using whatever colour was arrived at.
Clearly, more complicated scenes render more slowly, and certain things slow down the rendering more than others. POVray can render at various qualities, the highest ones adding radiosity (calculating how objects are illuminated by the diffuse light reflected from each other). I found that a small image of a reasonably simple scene could be generated quite quickly on a modern PC; a larger image took longer, and an animation of any more than a few frames took somewhat too long. When I tried to plot a very complicated image with tens of thousands of objects, I had to disable some of the optimisations because their data tables were taking up too much memory, and the program took many days to plot each pixel.
POVray's scene description file has a vaguely C-like syntax, and it is a list of declarations of objects. Thus you might start by saying where the camera is (in 3D space) and where it is looking, what the background is (several are supplied in the libraries), and what objects and light sources you want in the scene (with their locations, sizes and other parameters). I did not write any POVray code directly, but generated it from my Python program; it is also common for POVray users to generate at least some of the scene description from a C program (although this is often done to describe a complex structure for the artwork rather than to illustrate some data). I found that the positioning of the light sources is the most difficult thing to get right; it needs to bring out the three-dimensional structure without casting dark shadows over important data. I ended up putting a light source inside every single object, but this does tend to increase rendering times because plotting each point requires checking all the light sources.
Hand-coded POVray source can take advantage of POVray's preprocessor, which can set variables, evaluate mathematical expressions, and execute conditionals, switch statements and even loops (which are intended for replication of objects). At this point I wondered if it were possible to implement the animation of a complete algorithm (such as a sort) in POVray alone, without using another language; after all, animations can be generated from a single scene description by using the variable "clock" in expressions. POVray proved to be cumbersome as a general-purpose programming language, since there is no way to define or call procedures with parameters and there is no support for arrays or lists. However, the POVray website does contain links to scene description files that calculate the Mandelbrot Set and other fractals. Overall I am quite happy with POVray; it is well-documented and you can get up and running fairly quickly. If only it was not so slow. The main alternative to ray tracing is polygon scan conversion, which tends to be much faster even though the images it produces are not so accurate. Everything has to be rendered as polygons, so curved surfaces carry extra overhead (which is not so much the case in ray tracing). The only reason why I did not try polygon scan conversion is that I do not know of a good piece of free software that will take similar scene description files and render them using that method. (Writing my own would take too long.)
Notes:
More fields may be available via dynamicdata ..