POV-Ray : Newsgroups : povray.general : Status of Moray? : Re: New SDL for POVRay Server Time
17 Jul 2025 13:43:00 EDT (-0400)
  Re: New SDL for POVRay  
From: Fa3ien
Date: 3 Oct 2007 06:52:33
Message: <47037471$1@news.povray.org>

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> How, in the system you envision, will I be able to change the
>> focal point and get a new image within a few seconds, instead
>> of taking 3 hours to re-render everything ?
> 
>   Regardless of which method is used it's clear that povray must keep
> all the necessary information in files (or at the very least in memory)
> between renders.
> 
>   There could be a few possibilities:
> 
> 1) An option to tell POV-Ray to write all the necessary information on files.
>    Then if you want to re-post-process, you just use the option +C to skip
>    the rendering.
>    One disadvantage of this is that you have to remember to use the option
>    if you want to be able to post-process multiple times.

If POV-Ray "sees" there's a file with post-process data, it can ask the
user if he really wants to re-render or not.  Also, an "archival" mode (POV-Ray
gives an automatically numbered name to its output) would avoid any
dangerous overwrite (and allow to easily keep a record of an image's evolution,
which is currently tedious).

> 2) POV-Ray could always write the extra info on files, allowing
>    post-processing whenever you want.
>    The disadvantage is that it will consume disk space and the user would
>    have to manually delete those unneeded files to clean it up.

Disk space is cheap in these days of hard-disks filled with music and videos.

> 3) POV-Ray could automatically write the info on files and keep them there
>    as long a it's running, and when it's closed, it removes them (unless
>    an option is given). This would allow re-post-processing the image as
>    many times as necessary as long as POV-Ray is running.
>    The disadvantage is that this idea doesn't work with the command-line
>    version. Another slight disadvantage is that if the execution of the
>    program is ended abruptly, the files will be left there.
> 
> 4) As 3, but the info is kept in memory until next render.
>    Doesn't garbage the disk, but has the same disadvantages.
> 
>   Make your pick, or suggest something better.

All in all, I think that there could be a choice (for the user) between :
1) write to files, keep it forever (default)
2) write to files, keep it until session ends

I think that "keep in memory" would quickly lead to memory saturation (fast
memory is precious for rendering).

Option 2 would be unavailiable to command-line, but there could be a script
to clean unused files afterwards.  Maybe the files (in option 2) could be
written in some temporary path.

Fabien.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.