> Fa3ien <fab### [at] yourshoesskynetbe> wrote:

> 
>>>   When POV-Ray renders the image it has tons of additional information
>>> about it besides simply the pixels. It has depth information, normal
>>> information, all kinds of other things. In order to post-process the
>>> image using this information you need to either save it all in files
>>> and then write a program which reads them and does the post-processing,
>>> or you can write a simple script in the future SDL to do the same thing.
> 
>> How, in this model, do you adjust a parameter like focal point (in
>> the case of a blur process) and get a new image within seconds ?
> 
>   I'm not really sure what you are asking.

Let's say I have a scene that takes 3 hours to render. It shows an 
orange, an apple and a banana, on a table.

I use post-processing to apply heavy focal blur (no oversampling
with the camera, it would take too long). Initially, the focal
point is the orange.  But then, I want it to be the banana.

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 ?

Fabien.

Post a reply to this message

Morpheus is fighting William Tracy!
>
[...]
> In all fairness, there *are* platform-independent uses for this sort of
> thing. How about being able to call Python from SDL? You don't want to
> just hard-code links to Python in POV...because then the Perl and Ruby
> hackers would get mad. ;-)
>
There's no need to fight : < http://www.parrotcode.org/ >
;)

> William Tracy

Slawek
-- 
  ________ 
_/ __/ __/ Kopernik ruszyl ziemie i dlatego zobaczyl, ze jest okragla
 \__ \__ \_______________________________________________________________

Post a reply to this message

> 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 ?

We could expose images as assignable objects during
the post_process stage, which would allow layering and
other tricks that now are done with other software. And
we could expose the depth of the rays to make certain
filtering options much more accurate. Syntax might be
something like...

pre_process {...}
// scene
post_process {
   #declare A = output_image;
   #declare B = file_image "file";
   #declare A = blurByDepth(A,focus_point,depth_of_field);
   #declare C = layerImages(A,B);
   final_image {
      use_image C
      type PNG
      image_name "newfile.png"
   }
}

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:

> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:

> >
> >>>   When POV-Ray renders the image it has tons of additional information
> >>> about it besides simply the pixels. It has depth information, normal
> >>> information, all kinds of other things. In order to post-process the
> >>> image using this information you need to either save it all in files
> >>> and then write a program which reads them and does the post-processing,
> >>> or you can write a simple script in the future SDL to do the same thing.
> >
> >> How, in this model, do you adjust a parameter like focal point (in
> >> the case of a blur process) and get a new image within seconds ?
> >
> >   I'm not really sure what you are asking.
>
> Let's say I have a scene that takes 3 hours to render. It shows an
> orange, an apple and a banana, on a table.
>
> I use post-processing to apply heavy focal blur (no oversampling
> with the camera, it would take too long). Initially, the focal
> point is the orange.  But then, I want it to be the banana.
>
> 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 ?
>
> Fabien.

Is it still ray-tracing? You only get an image that is based on a ray-traced
one. But if you end up with what you want, then OK.

My opinion is that ray-tracing is a technique that allows to apply physical
laws in order to match reality. I prefer 'match' than 'fake': POV's focal
blur matches a physical phenomenon, post-processing 'only' fakes. But in
many cases one may get satisfied. That's an essential point.

Bruno

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:

> As you might have noticed, not everybody is convinced we should have one.

Right.

But the concern is so present that the question of a new SDL is 'on air'
since quite a while, made this discussion happen, and interests a lot of
people (I think). And I bet that those people you mentionned, once/if ever
POV has its new nice syntax with new long-awaited features, will be the
first to use it with greed ... The demand for new POV-SDL araised from the
lacks and drawbacks of POV, even if it is a marvelous tool.

Bruno

Post a reply to this message

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.

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.

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.

-- 
                                                          - Warp

Post a reply to this message

Chris Cason wrote:
> andrel wrote:
>> Can someone set something up somewhere?
> 
> Can someone recommend specific Wiki software?
> 
> It'd need to support external authentication (to link in to the POV user
> registration system), and captchas or other anti-spam measures.

Mediawiki seems a natural choice because a lot of people know how to use 
it (from wikipedia) and anything we need in the lines of the above is 
probably already available in some form.  For authentication a long list 
of extensions can be found on:

http://www.mediawiki.org/wiki/Category:User_identity_extensions

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Warp wrote:
> 
> * Existing data containers, namely arrays and strings (which are special
> arrays of characters), should be enhanced and new data containers introduced.
> For example the current array could be internally implemented as a C++ deque,
> which would make it work like the current one plus you can freely resize it
> (larger or smaller), append elements at the beginning and at the end, and
> you can still access any element fast, and none of these operations will be
> slow (eg. resizing does not require copying/moving any existing elements).
> Even inserting or removing elements from the middle of the array would be
> possible, although it would not be a constant-time operation.

The Asymptote array concept provides a fairly flexible sort of array:

http://asymptote.sourceforge.net/doc/Arrays.html

The internal representation is derived from deque i think.

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

> Is it still ray-tracing? You only get an image that is based on a ray-traced
> one. But if you end up with what you want, then OK.

It's not raytracing, indeed, it's post-processing.  The post-processing
included in megapov (for example) isn't raytracing, either.  The purpose of
post-processing is precisely to allow some transformations over the already
rendered image, ideally using more data (like depth or normals) than the image
itself, but it happens AFTER rendering, which makes it fast and flexible.

If we are discussing render-time effects, well, okay, but let's not call it
POST-processing, then.  Just call it 'effects' (and limit them to things
that *cannot* be done in post-processing).

Nevertheless, simultaneous output of rendered image, and depth, normal,... data
would allow extremely interesting things to be done (besides being easy to
implement).

(BTW, thinking of it, being able to simultaneously output images with different
  settings would be great; i.e : rendering an image with and without media,
  but doing intersection calculations only once; of course, it  becomes
complicated...)

Fabien.

Post a reply to this message

> 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