In article <3AA831AC.827EBB9E@rsp.com.au>, Ben Paschke 
<ben### [at] rspcomau> wrote:

> Is the main memory hit with df3's just the fact that it's a volume? (ie
> x*y*z values) I wonder how you could make a df3 optimised for use only on
> surfaces.. There must be so much data going to waste (ie all voxels that
> don't coincide with a shaded surafce) ...

Yes, they are just an uncompressed 3D pixelmap format, so doubling the 
size will multiply the memory usage by 8. A 64*64*64 df3 will take 
256KB, a 128*128*128 df3 will take 2MB. A 512*512*512 df3 would be 
128MB. (multiply the dimensions to get the number of voxels, each voxel 
takes 1 byte, divide by 1024 to get kilobytes, and again for megabytes)
This is why interpolation is so useful...

It wouldn't be very easy to code it so only some of the voxels are 
stored (some kind of tree structure?), it would probably have to be done 
from scratch, and it would probably be noticeably slower...but another 
optimization that would be useful would be to join groups of voxels with 
similar values into larger voxels.

I've often thought of designing a format that could handle 1 bit, 8 bit 
grayscale, and 24 bit color, and with the "compression" I mentioned 
above (with the change being that it would have to store the information 
on disk instead of in RAM), but it would be a lot of work on a subject I 
know little about, and I suspect there is already a better format 
available.


> BTW, i really like the idea of being able to blur patterns; i appreciate 
> you efforts! How's it going, anyway?

I haven't had time to code any more of it yet...I plan to try some more 
ideas this weekend.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message