Tachyon exploration

Comments/Questions as I come across them
Written by Paul Bourke

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 requested

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().

Camera aperture

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.

aperture = 2 atan(width / (2 height zoom))

zoom = 0.5 / (height tan(aperture/2) / width)

Volume rendering

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.

Disk access

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:
   rt_outputfile(scene, "\0");

Bug Report

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.

raydepth artifacts

This image has raydepth set to 6, this one has raydepth of 20.

6 20

The model for this rendering is here: knot.dat.

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 coordinate system. 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.

pov tach

Polygon ordering

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).

Multithread performance

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 seconds
Two threads
    Preprocessing Time:    30.5968 seconds
      Ray Tracing Time:    40.2229 seconds
        Image I/O Time:     0.1249 seconds
Three threads
    Preprocessing Time:    32.3432 seconds
      Ray Tracing Time:    28.5348 seconds
        Image I/O Time:     0.1024 seconds
Four 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.

Large models

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.
Further suggestions.

I fixed it by hacking out the "/tmp/" strings in the files in the demosrc/ directory.

Include files

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 <johns@megapixel.com>
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 either

1. the messages from Tachyon were written to stderr
2. there was a quiet mode, except for errors
3. if there was a way to redirect them please let me know. I use tcsh and normally my cron jobs do >& logfile

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, ....

Texture placement

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 0
and then triangles that refer to these as follows
   V0 2108088.520235 -2650347.618574 -283971.309121
   V1 2107121.193637 -2650709.299505 -284425.870603
   V2 2107406.238332 -2650873.111086 -283294.078276
compared to just including the materials as so
   V0 2108088.520235 -2650347.618574 -283971.309121
   V1 2107121.193637 -2650709.299505 -284425.870603
   V2 2107406.238332 -2650873.111086 -283294.078276
      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:
1) reduced memory consumption since many objects can share a texture
2) improved rendering speed due to much better cache utilization
3) improved parsing speed
4) harder to organize your stuff into a useful palette of textures
Doing separate textures per objects:
1) increased memory usage, on data structure per object instead of sharing
2) reduced rendering speed due to cache missing on average
3) slower parsing speed (how much slower, don't know, never thought of that!)
4) easy, don't have to organize use of color/texture

Command line arguments

Tachyon Parallel/Multiprocessor Ray Tracer   Version 0.93.4 
Copyright 1994-2001,    John E. Stone <johns@megapixel.com>
  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)
 -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

   $(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"