|
![](/i/fill.gif) |
In article <390835eb@news.povray.org>, Warp <war### [at] tag povray org>
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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |