well, does the number of photons affect the rendertime ???

I mean, I know it takes longer to parse, but:

If I increase the number of photons, will the rendering also take longer, or
are the photons just a kind of "pigment" (excuse this word), that is mapped
onto the surface, and is handled like a textur ???


PS: My current scene will be done in about 10days ... anybody out there, who
wants to do this on his puter ??? (I only used some photons,area-lights,
dispersion, focal blur and variable reflection ... just a simple scene with
4 objects)

--
Jan Walzer

Post a reply to this message

In article <3a7d598a@news.povray.org> , "Jan Walzer" <jan### [at] lzernet> wrote:

> well, does the number of photons affect the rendertime ???

Yes, they will.

> PS: My current scene will be done in about 10days ... anybody out there, who
> wants to do this on his puter ??? (I only used some photons,area-lights,
> dispersion, focal blur and variable reflection ... just a simple scene with
> 4 objects)

Of course it depends on your computer and image size.  If it isn't a 486
rendering 1024*768 it should not take that long.  You may want to tune your
settings and the scene should render is at most a few hours on any Pentium
class system.


    Thorsten


PS: This question better fits in povray.unofficial.patches because photons
are not an official feature...

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> schrieb im Newsbeitrag
news:3a7d6e08$1@news.povray.org...
> In article <3a7d598a@news.povray.org> , "Jan Walzer" <jan### [at] lzernet>
wrote:
>
> > well, does the number of photons affect the rendertime ???
>
> Yes, they will.
Interesting .... didn't know that ...

> > PS: My current scene will be done in about 10days ... anybody out there,
who
> > wants to do this on his puter ??? (I only used some photons,area-lights,
> > dispersion, focal blur and variable reflection ... just a simple scene
with
> > 4 objects)
>
> Of course it depends on your computer and image size.  If it isn't a 486
> rendering 1024*768 it should not take that long.  You may want to tune
your
> settings and the scene should render is at most a few hours on any Pentium
> class system.
It's a PII-392MHz ... The Output will be in 1024x768

I'll post the scene to pov.text.sc-f

I rendered it with "+SP16 +EP16" to get approximate the rendering time ...
This first pass took about 1 hour, so the final pass will take 16x16 times
as long
(256h) ~10days ... This approx. should be quite ok because I use no AA
(focal blur is on)

To have a smooth image in the far parts I need that much blur-samples and if
I lower the disp_nelems, the glass will get a redish touch ...

So I don't know where to tweak this anymore ...


> PS: This question better fits in povray.unofficial.patches because photons
> are not an official feature...

Post a reply to this message

I have tried several things and the result/suggestions are below. But glass (=
many reflections/refractions), photons and folcal blur is a combination that just
will take some time to render.

Suggestions:
- use 'adc_bailout 1/16' in your global_settings
- use '+MB0' switch to turn on boundings
- you probably want to use 'ignore_photons' in your glass object; this will not
speed up the rendering much, but it is suggested in the docs
- focal blut makes your scene rendering about 10 times slower. have you tried
using the focal blur post processing filter? Though I don't know if it can handle
this scene correctly. But it is certainely worth a try
- are the area_lights really neccessary? Have you tried just to put point_lights
and see how much is the difference?
- you might try to group your bubbles according to their location in the glass
sphere and union them together in bounding boxes. I don't know if that will
really result in a speeding up tough.

BTW: I'm just rendering a julia fractal of glass lit by colored spotlights... it
takes a little time for rendering as well.

--
Micha Riser       email address: mri### [at] gmxnet
http://www.povworld.de/   The World of POV-Ray!

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
: If I increase the number of photons, will the rendering also take longer, or
: are the photons just a kind of "pigment" (excuse this word), that is mapped
: onto the surface, and is handled like a textur ???

  If you use a more complex pigment instead of a simpler one, the rendering
time gets longer.
  Why photons should be an exception?

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

"Micha Riser" <mri### [at] gmxnet> schrieb im Newsbeitrag
news:3A7ED973.D8A850EF@gmx.net...
> I have tried several things and the result/suggestions are below. But
glass (=
> many reflections/refractions), photons and folcal blur is a combination
that just
> will take some time to render.
>
> Suggestions:
> - use 'adc_bailout 1/16' in your global_settings
   ^^^ worth a try ...
> - use '+MB0' switch to turn on boundings
There is only the main object, and I don't think the single bubbles in the
glass will get bounded extra, will they ???
If they will, than it is surely worth a try, but I don't like to stop it
now, because I'm at line 184 after 2d4h41m.
> - you probably want to use 'ignore_photons' in your glass object; this
will not
> speed up the rendering much, but it is suggested in the docs
I want them all ! (also inner refraction and reflection)
> - focal blut makes your scene rendering about 10 times slower. have you
tried
> using the focal blur post processing filter? Though I don't know if it can
handle
> this scene correctly. But it is certainely worth a try
I know, that it can't handle this scene, because it "only" works with the
alpha-buffer of the image ...
The things, seen in the sphere would look like an pigment on the sphere...
> - are the area_lights really neccessary? Have you tried just to put
point_lights
> and see how much is the difference?
Sure ... I limited them to 2x2 I think ...
> - you might try to group your bubbles according to their location in the
glass
> sphere and union them together in bounding boxes. I don't know if that
will
> really result in a speeding up tough.
Group them ??? they're random ... I don't want to raise the parsetime by
doing an cluster-analasys in POV ;-)

>
> BTW: I'm just rendering a julia fractal of glass lit by colored
spotlights... it
> takes a little time for rendering as well.
We want to see it then ... *g*

PS: I'm worried about something other ... I got a paper in my Snailmail,
that the electricity
    will be down at 8th.Feb. ... The pic won't have finished till then ...
    Does the "+C"-Switch work together with "+SPxx" ???
    Does it work, when I have startet the original pic with "+SPxx"  ?
    I hope ...

--
Jan Walzer

Post a reply to this message

Jan Walzer wrote:
> 
> > - use '+MB0' switch to turn on boundings
> There is only the main object, and I don't think the single bubbles in the
> glass will get bounded extra, will they ???
> If they will, than it is surely worth a try, but I don't like to stop it
> now, because I'm at line 184 after 2d4h41m.

well, I don't know exactly why, but it gave with me a speeding up of about 10%

> > - you might try to group your bubbles according to their location in the
> glass
> > sphere and union them together in bounding boxes. I don't know if that
> will
> > really result in a speeding up tough.
> Group them ??? they're random ... I don't want to raise the parsetime by

I'll try it out and see if renders faster.

> 
> PS: I'm worried about something other ... I got a paper in my Snailmail,
> that the electricity
>     will be down at 8th.Feb. ... The pic won't have finished till then ...
>     Does the "+C"-Switch work together with "+SPxx" ???
>     Does it work, when I have startet the original pic with "+SPxx"  ?
>     I hope ...

It should work fine. Just don't use +SPxx when you continue rendering. What I
don't understand is why you used SPxx at all... this is for preview only, there
is no reason in using that for the final rendering. POV also will not use pixel
which were rendered in the preview process for the final step! ... so if for
example your picture is still at 2x2 preview rendering and you see that you will
want it at final resolution you better stop it and start again (except you have a
HUGE parsing time.)

--
Micha Riser       email address: mri### [at] gmxnet
http://www.povworld.de/   The World of POV-Ray!

Post a reply to this message

If you don't make any more scene changes save your photon maps so they aren't
recalculated.

global_settings {
 photons {
  save_file "finalphotons.txt"
  // photon stuff
 }
 // global stuff
}

Use that for the preview then load_file for the final render.  You might
already have known about that.  I don't know if there's a problem or not with
mosaic preview and a saved photon map, just a suggestion.

Bob H.

Post a reply to this message

> > PS: I'm worried about something other ... I got a paper in my Snailmail,
> > that the electricity
> >     will be down at 8th.Feb. ... The pic won't have finished till then
...
> >     Does the "+C"-Switch work together with "+SPxx" ???
> >     Does it work, when I have startet the original pic with "+SPxx"  ?
> >     I hope ...
>
> It should work fine. Just don't use +SPxx when you continue rendering.
What I
> don't understand is why you used SPxx at all... this is for preview only,
there
> is no reason in using that for the final rendering. POV also will not use
pixel
> which were rendered in the preview process for the final step! ... so if
for
> example your picture is still at 2x2 preview rendering and you see that
you will
> want it at final resolution you better stop it and start again (except you
have a
> HUGE parsing time.)

Is that true ??? I don't believe it ... Why don't they use these Rays again
???
They are already computed, and mostly they are on the right position ...

I used it, because I didn't know, they're not reused and I wanted to
aproximate the final rendering time ...

--
Jan Walzer

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
: Is that true ??? I don't believe it ... Why don't they use these Rays again
: ???
: They are already computed, and mostly they are on the right position ...

  When the mosaic preview option was first introduced (I think it was in
3.0, or was it even before that? I don't remember), 8 megabytes of RAM was
a really huge amount of memory.
  If you think about what you need in order to be able to reuse the pixel
values of the mosaic preview step, you'll see that in practice you'll have
to keep the entire image in memory. It's not only necessary in order to be
able to save the whole image to disk in the right order but also for things
like antialiasing (antialiasing needs the nearby pixels in order to
calculate the antialiasing threshold).
  POV-Ray has always been designed to be able to create any sized images.
For example creating a 1600x1200 sized image with alpha channel should not be
a problem.

  Now, how much memory does this image take?
  This depends a lot in how do we store the image in memory. The obvious
answer "1 byte per color component" is not as obvious as one could think.
  AFAIK the antialiasing threshold needs floating point numbers to compare
whether the threshold is reached or not. This floating point number
(representing one channel of the pixel) is in the range between 0 and 1.
A byte per color component would give 256 steps between 0 and 1. Well, this
might be enough, or not. This would mean that "+a0.005" would be the same
as "+a0" although it shouldn't.

  Even if we use just 1 byte per color channel, that would be 4 bytes per
pixel in the worst case (that is, alpha channel is used). 1600x1200 pixels
take, thus, 7680000 bytes = 7.3 Megabytes.
  (If we have to use floating point numbers for the color channels and
a float takes 4 bytes, then one pixel would take 16 bytes and the whole
image would take 30720000 bytes = 29.3 Megabytes.)

  When we have 8 megs of RAM, using 7.3 Megs for the image doesn't sound like
a good option.

  Of course nowadays the situation is completely different. 128 Megs of RAM
is not unusual at all.
  However, modifying the mosaic preview code would require some work and
I suppose that the team has its hands full of more important work already.
This kind of optimization has quite low priority, after all.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message