In article <390835eb@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Don't tell me all this is stored into memory in order to be able to 
> apply the post processing?
> 
>   Hmm... Let's count.
>   If we make a 1024x768 image that would be 786432 pixels.
>   I suppose that the floating point numers are of 'double' type, which 
> means 8 bytes (in PC and most other systems).

True for most of these, but the COLOUR type is an array of 3 floats, not 
doubles.

>   This means that for each pixel the rgb info will take 3*8 bytes, the
> intersection point 3*8 bytes, the uv-coordinates 2*8 bytes, the depth 
> 8 bytes, surface normals and perturbed normals 6*8 bytes and finally 
> the ray direction 3*8 bytes.
>   Summing all this up we get:
>   786432*(3*8+3*8+2*8+8+6*8+3*8) = 113246208 bytes = 108 Megabytes.
> 
>   Taking into account that the average computer has 128 Megabytes of 
> memory, that would eat it up pretty efficiently.
> 
>   If all this is not stored into memory, then forget this :)

Currently, only the needed data is saved. Each post_process has a set of 
flags indicating which data it needs, and only that data is 
saved/loaded. This would be harder to do with the color_function filter, 
since you would have to detect which functions and/or variables are 
used, but it should still be possible.
Also, I don't know if this is the way it already is done, but it should 
be possible to save to a file and only read in the data as it is used. 
This would slow down some post_processes though...it would probably be 
best as an option that people could turn on for lower-memory systems.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message