octree size


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?

Thanks in advance!

Best regards,



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.

CU, Lars.

Lars O. Grobe
[email protected]


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.