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.
I suggest this is a priority.
I've started documenting the file format here.
This was greatly improved in v0.1 beta 12
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 messageHowever "yasrt bla.yst" doesn't actually work, one is required to use "yasrt -i bla.yst".
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.
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
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.
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
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!