Tachyon by John Stone
Based upon Version 0.92 (November 2000)
Updated after release of Version 0.93.1 (February 2001)
API comments from Version 0.93.4 (October 2002)
Latest comments from Version 0.94 (March 2003)
Is there a difference between antaliasing 0 and 1?
Antialiasing of "0" shoots 1 ray per pixel, (only through the
center of the pixel). Antialiasing for N > 0 means:
- shoot 1 ray through the center of the pixel
- shoot N addtional randomly jittered rays through the the pixel
I'm always impressed with tachyons performance. The following has 3.2 million "box" primitives and originally rendered out at 2000x2000 pixels. It needed only 640MB RAM and took under 350s. (Dual processor 2.2GHz P4, 3 threads).
Frustums as per OpenGL style requested, in particular to support stereopair generation as well as image space splitting for distributed rendering using the library. For example, the following image was rendered across 20 machines, each one rendering a small portion as shown bounded in red.
Provided in version 0.94, and tested.
For more nformation see rt_camera_frustum().
Most people are used to dealing with camera apertures rather than zooms. The manual also makes an incorrect claim that a zoom of 1 corresponds to a aperture of 90 degrees...this is not correct in the current implementation. Assuming a unit view direction vector and a unity aspect ratio, the relationship between zoom and aperture are given below. An aperture of 90 degrees is actually a zoom of 0.5. Note the following refers to the horizontal aperture.
zoom = 0.5 / (height tan(aperture/2) / width)
This REALLY needs to be generalised.
How does one put comments in the scene file?No support for comments at the moment. I suggest that if one has a text and human editable scene format that comments (even simple ones) are useful. Perhaps # to end-of-line would do.
Now supported from version 0.93.1 by using '#'.
Is the scene file format case sensitive?There isn't any case sensitivity for things like SPHERE etc, but the texture names you use in the file, with TEXDEF are case sensitive. Filenames are also case sensitive (for the INCLUDE keyword). I'll document the case sensitivity issue better. The various keywords should _not_ be case sensitive.
I notice when I'm running my application (which doesn't write images) that I can hear my disk doing accesses....at the rendering framerate. Is your library doing some writing behind the scenes? For performance reasons I'd like to stop that.Do this to prevent the output from being written to disk:
When using the threaded version on a Dec Alpha the process doesn't always terminate. The image is written out and is complete, the tachyon process needs to be killed.
If one doesn't want to see lights, is a zero radius going to have any weird side effects?Nope, should work fine. The lights do not depend on their radius for anything presently. If you _do_ have any problem with using a 0.0 for radius, let me know. I just double checked the code, should be fine.
Ambient light level
How does one set the ambient light level.John Stone: Tachyon just uses the raw ambient light component supplied with the texture for a given object, it doesn't even multiply that with a global ambient light value, although doing so would be very easy to implement. If you think this is worth doing, I could add such a feature pretty quickly.
This image has raydepth set to 6, this one has raydepth of 20.
Seems to have been fixed from version 0.93
Comparison with PovRay for a large polygon model
Comparison between rendering packages is suspicious at best.
However, as a way of comparing tools to solve particular problems
it has some merit. In this case a high polygon count model was
chosen with over 2 million triangular facets.
As much as possible the parameters were matched between the two
packages, in particular antialising off, 1000x1000 image, raydepth
set to 5. The camera and single light positions were setup identically,
thankfully for this exercise both Tachyon and PovRay use a left hand
In PovRay the "triangle" primitive was inbedded within a "mesh".
In tachyon, "TRI" primitives were used. In both cases an indexed list
of 2000 textures were created.
Results, the most noticeable difference was the parsing time. About 200 seconds for Tachyon, 1300 seconds for PovRay. The rendering time for Tachyon was less than 4 seconds, PovRay took 12 seconds. there was only a small difference in the amount of memory used, 580MB for Tachyon, 620MB for PovRay (although PovRay seems to have s weird increasing power of 2 step size for memory).
For what it's worth the two images are given for comparison. mars_pov.jpg and mars_tach.jpg.
Is there a correct ordering for polygons, clockwise or anticlockwise? Does it matter?John Stone: Tachyon doesn't care what order you specify the polygon vertices, it currently uses other methods to determine the surface normal.
The documentation of the scene format needs to be sorted out. The specification that comes with the 0.92 tar distribution does not match with reality!HTML version please!
The best place for documentation on the API are the files rtcommon.h and tachyon.h (see src directory).
Compiled a multithread version for an ES40 (4 processor Dec Alpha server). The model was the mars one above but with 4 times antialiasing.One thread
Preprocessing Time: 17.6605 seconds Ray Tracing Time: 78.4053 seconds Image I/O Time: 0.1173 secondsTwo threads
Preprocessing Time: 30.5968 seconds Ray Tracing Time: 40.2229 seconds Image I/O Time: 0.1249 secondsThree threads
Preprocessing Time: 32.3432 seconds Ray Tracing Time: 28.5348 seconds Image I/O Time: 0.1024 secondsFour threads
Preprocessing Time: 21.5289 seconds Ray Tracing Time: 20.8849 seconds Image I/O Time: 0.1258 seconds
This is all surprisingly linear, the slight variations are undoubtedly due to other users running short jobs during the testing period.
My initial interest in Tachyon was for rendering large polygon models for which PovRay was proving somewhat less than satisfactory. Not only were the scene parsing times outrageous but the memory requirements seemed out of proportion to the data requirements. The above tests on the Mars dataset involved 2 million polygons, this was do-able with PovRay. On a 2GB machine the 1/8 degree data consisting of 6.8 million+ triangular facets and I ran out of memory with PovRay. With Tachyon the scene file took 230 seconds to parse (pretty good for 1 GB file). It used 1800MB (1500MB resident). Total rendering time for one thread was just under 250 seconds.
How do I get rid of those awful "Grid..." messages"? On a 56K ppp connection they take forever!This has been dealt with from version 0.93.1
A small piece of the result is shown below.
The order of the fields in the -camfile seems to be: direction, up, position.
Don't use /tmp/ for the animation files. Most people don't set /tmp up with enough space to hold the frames for a reasonable animation....well at least not the sites I work on. I don't see what's wrong with the current directory.
In the future you need to put all the possible camera attributes in the camera animation file. For example I often use aperture (zoom in your case) for dramatic effect.
Another suggestion is to support an include file facility. This is extremely useful for logically arranging models, lights, cameras, etc. For example my standard scene file for many packages is something like the following:
#include "camera.inc" #include "lights.inc" #include "sky.inc" #include "ground.inc" #include "model.inc"This has been supported in version 0.93.1 with a INCLUDE keyword.
It would be VERY useful to actually get better scene file parsing errors, for example I have no idea where to start looking when I get something like the following
Tachyon Parallel/Multiprocessor Ray Tracer Version 0.93.1 Copyright 1994-2001, John E. Stone <firstname.lastname@example.org> ----------------------------------------------------------- Scene Parsing Time: 0.0029 seconds Parser returned a non-zero error code reading scene Aborting Render...
There doesn't seem to be an obvious way to make the grit texture coherent, for animations say.
I haven't looked but how do you write the progress messages. It isn't stdout or stderr because I don't seem to be able to redirect them. This is a pain because the way I distribute jobs around our cluster (100+ processors now) uses cron. As a result I get emailed LOTS of messages (one per job) because cron emails the user any output. I suspect you're doing some TTY stuff, I don't know anything about that so I'm not sure. Anyway, it would be much more convenient for me if either1. the messages from Tachyon were written to stderr
This was my (Paul Bourke) fault, I wasn't redirecting the output from my cron scripts correctly. On the issue of quite/verbose reporting... at some stage more levels of verbosity would be useful, errors, warnings, info, debug, ....
What are the relative merits of defining a whole bunch of materials as so
texdef Mat10 ambient 0.2 diffuse 0.7 specular 0.05 opacity 1.0 phong plastic 0.2 phong_size 100 color 0.590196 0.276078 0.158235 texfunc 0and then triangles that refer to these as follows
TRI V0 2108088.520235 -2650347.618574 -283971.309121 V1 2107121.193637 -2650709.299505 -284425.870603 V2 2107406.238332 -2650873.111086 -283294.078276 Mat10compared to just including the materials as so
TRI V0 2108088.520235 -2650347.618574 -283971.309121 V1 2107121.193637 -2650709.299505 -284425.870603 V2 2107406.238332 -2650873.111086 -283294.078276 texture ambient 0.2 diffuse 0.7 specular 0.05 opacity 1.0 phong plastic 0.2 phong_size 100 color 0.590196 0.276078 0.158235
I assume the second is slower to parse but does it use more memory. I ask because at the moment I've defining 2000 textures and using them for millions of facets. Life would be easier if I just had the textures within the triangle, it might also help some of the discrete colour banding I think I'm seeing.So, the texture table:
Command line arguments
Tachyon Parallel/Multiprocessor Ray Tracer Version 0.93.4 Copyright 1994-2001, John E. Stone <email@example.com> ----------------------------------------------------------- Usage: tachyon modelfile [options] Model file formats supported: filename.dat -- The model files originated with this package. filename.nff -- The NFF scene format used by Eric Haines' SPD. Valid options: (** denotes default behaviour) ---------------------------------------------- Message Options: +V verbose messages on -V verbose messages off ** Speed Tuning Options: -numthreads xxx (** default is auto-determined) -nobounding -boundthresh xxx (** default threshold is 16) Shading Options: -fullshade best quality rendering (and slowest) ** -mediumshade good quality rendering, but no shadows -lowshade low quality rendering, preview (and fast) -lowestshade worst quality rendering, preview (and fastest) Antialiasing Options: -aasamples xxx (maximum supersamples taken per pixel) (** default is 0, or scene file determined) Output Options: -o outfile.tga set output file name -format TARGA 24-bit Targa (uncompressed) ** -format BMP 24-bit Windows BMP (uncompressed) -format PPM 24-bit PPM (uncompressed) -format RGB 24-bit SGI RGB (uncompressed) -format JPEG XXX Not compiled into this binary XXX -format PNG XXX Not compiled into this binary XXX Animation Related Options: -camfile filename.cam Animate using file of camera positions. -nosave Disable writing of output frames to disk (only used for doing real-time rendering)
Make file for Alpha (Tru64) and MPICH
tru64-alpha-mpich: $(MAKE) all \ "ARCH = tru64-alpha-mpich" \ "CC = cc" \ "CFLAGS = -std1 -fast -O4 -arch host -tune host -w0 -verbose $(MISCFLAGS) -I$(MPIINC) -DLP64 -DMPI" \ "AR = ar" \ "ARFLAGS = r" \ "STRIP = strip" \ "LIBS = -non_shared -om -L. -ltachyon -lmpich -L$(MPILIB) $(MISCLIB) -lm"