I am trying to visualise a point set from a laser scan using rholo command. To
keep the conversion to RADIANCE-format easier i created a .rad-file with small
spheres for each point to represent the original file. But as far as i know i
have to create an octree first, before running the actual rholo command. And
exactly this is my problem. Because I am working on a university computer,
memory used for calculations is restricted and the oconv process gets killed
after a couple of minutes each time I try to run it. The resulting .oct-file is
empty. The original point set is a file with a bit more than 200Mb. If i convert
each point in this file to a sphere, the resulting .rad-file is about 500Mb.
After the octree calculation for this 500Mb file failed, I reduced the number
of spheres by taking only each 3rd, then 10th, then 20th point. At the moment i
have a .rad-file with 31Mb and the oconv process still gets killed. Now I am
wondering how much memory does each sphere need in an octree? Is there any
approximate rule to calculate the required memory for .oct-files? Or may be
there is another possibility to create a holodeck-file out of my spheres?
might it help to use boxes instead of spheres? Just to reduce the number of faces (and make them bigger)... hmmm... does a sphere take more memory in radiance than a box? I guess so, at least it is worth trying. Reducing the resolution (-r) should also reduce memory needs, depending on your scenes, you get errors doing so. AFAIK (r=resolution of oconv, dmax_scene, dmin_scene) the resolution has to be r > dmax_scene / dmin_scene, and is preset to 16K at the moment.
I think it's not problem with the spheres (in fact a sphere is probably the primitive which uses the least amount of memory among all), but with the number of objects in general.
oconv - roughly spoken - inflates itself considerably during octree generation, to a far bigger size that the actual octree has in the end, when the process is finished.
This inflating can be reduced a bit by using a lower resolution, the current default is 16 K as Lars pointed out, you might try running oconv -r 8192 ..., if it still doesn't work, try 2048 or even 1024 (I think the latter was the default a long, long time ago). But this produces greater object sets at the leaves and thus slows down the rendering.
A better way is to divide your input file into separate ones, the sets of spheres should be disjoint in space, however, then set up a wrapping scene file with simply loads these separate octrees as instances. You can also nest instances, i.e. use instances which themselves contain instances.