Evaluation of

YASRT - Yet Another Simple Ray Tracer

YASRT written by Emmanuel Viale
http://www.yasrt.org/

The following evaluation was done using the DecAlpha version 0.1 beta 8 on an ES40 running Tru64 Unix.
Updated when v0.1 beta 12 was released.

Documentation

I suggest this is a priority.
I've started documenting the file format here.

This was greatly improved in v0.1 beta 12

Command line

The usage information is as follows:

 Usage: yasrt [options] scenefile [...]

 Example: yasrt scene.yst

 Options:
  -i/--input         filename    read filename as input
  -o/--ouput         filename    write output to 'filename' (no extension)
  -w/--width         integer     specify with of the output image
  -h/--height        integer     specify height of the output image
  -j/--jitter                    activate jittering
  -aaa/--aaadatpive  double      activate adaptive anti-aliasing
  -aaq/--aaquick                 activate quick anti-aliasing
  -aan/--aanone                  deactivate anti-aliasing
  -tga/--tga                     TGA output image
  -bmp/--bmp                     BMP output image
  -ppm/--ppm                     PPM output image
  -?/--help                      this help message

However "yasrt bla.yst" doesn't actually work, one is required to use "yasrt -i bla.yst".
It would seem this list of command line options needs to be updated to reflect the real state of affairs, where is the -pqs option for example.

Thermometer

The thermometer doesn't seem to work, well it goes from 0 to 100% without going through intermediate values. perhaps it is just a fflush() needed.

Example scenes

These all worked except for spheres2.yst which has an unsupplied include file (couleurs.inc), the jpeg output format wasn't supported in this release so had to be changed in spg2.yst, and there is a missing include file (oleander.inc) in plante.yst.

This was fixed in v0.1 beta 12

Memory problem

I regularly need to render scenes with thousands if not millions of objects. Memory requirements, and reliability and often more important than rendering speed. Unfortunately for even modest models I got messages of the form "YASRT is out of space... . This was on a machine with 2GB of RAM.
I don't hold much in the rendering times below, comparing renders is a tricky business at the best of times because of the big differences that can result from slightly different rendering settings.
The failure for these quite modest models is a serious bug. To recreate these runs, here are the necessary files.

	RAM	Time
PovRay	10,000 spheres: 22MB 30,000 spheres: 45MB 100,000 spheres: 180MB	10,000 spheres: 14 sec 30,000 spheres: 26 sec 100,000 spheres: 90 sec
YASRT	10,000 spheres: 9MB 20,000 spheres: 20MB	10,000 spheres: 240 sec 20,000 spheres: Failed

Note: the swapped appearance of the two images is due to the left hand coordinate system of PovRay and the right hand coordinate system of YASRT.

This seems to have been fixed in v0.1 beta 12 with the addition of the -pqs option. It would be "nice" if this could be handled automatically. How does the user know what to set it to? What happens in an animation where the geometry is being created by code on the fly.....where the scene complexity isn't known in advance. What are the implications of just settings it to a high value in an attempt to keep out of trouble? Is there a performance penalty or just a memory penalty.
The following "yasrt -pqs 1000 -i lorenz.yst" on a 100,000 spheres took over 900 seconds, 10 times onger than PovRay!