Is this somewhere in your docs? Is it only useful for photons? I ask this
because you might want to change the keyword from "*_file" to "*_photons",
seeing as this might cause confusion later on.

This is pretty cool. I assume that it stores the photon map for situations
when there is no movement of the lightsource(s) itself(themselves), right?
Could a similar thing be done with radiosity, to avoid recalculation? I
remember that at a demonstration I went to, Lightscape would (AFAIK) only
precalculate the radiosity directly into the textures, and then you could
render normally with everything looking radiant.

Post a reply to this message

I might rename to *_photons.  However, if we keep it as save_file and
load_file, then we could use the same keywords in the radiosity{} block (no
need for new keywords) to save/load radiosity.  And yes, this could
definately be done with radiosity (the radiosity octree can already be
saved/loaded by POV for continued renders).  The only problem with radiosity
is that POV will usually calculate more radiosity data during the ray-trace
pass.  This could be prevented if necessary, though.

This feature (saving/loading the photon map) is also intended to help with
network rendering possibities in the future.  It should be in the docs
somewhere.  If not, I'll have to add it.

-Nathan


TonyB <ben### [at] panamaphoenixnet> wrote...
> Is this somewhere in your docs? Is it only useful for photons? I ask this
> because you might want to change the keyword from "*_file" to "*_photons",
> seeing as this might cause confusion later on.
>
> This is pretty cool. I assume that it stores the photon map for situations
> when there is no movement of the lightsource(s) itself(themselves), right?
> Could a similar thing be done with radiosity, to avoid recalculation? I
> remember that at a demonstration I went to, Lightscape would (AFAIK) only
> precalculate the radiosity directly into the textures, and then you could
> render normally with everything looking radiant.
>
>

Post a reply to this message

>I might rename to *_photons.  However, if we keep it as save_file and
>load_file, then we could use the same keywords in the radiosity{} block (no
>need for new keywords) to save/load radiosity.

Good foresight... it actually crossed my mind (very briefly, so I ignored
it...)

>And yes, this could
>definately be done with radiosity (the radiosity octree can already be
>saved/loaded by POV for continued renders).

Aha... so why isn't that being done already? <Yoda>Hmmmm?</Yoda>

>The only problem with radiosity
>is that POV will usually calculate more radiosity data during the ray-trace
>pass.  This could be prevented if necessary, though.

Please, be my guest... prevent it... :)

>This feature (saving/loading the photon map) is also intended to help with
>network rendering possibities in the future.  It should be in the docs
>somewhere.  If not, I'll have to add it.


I haven't read the docs extensively, but I don't think I saw that. The
network rendering would sure be swell.

Post a reply to this message

Are there any other advantages of saving the photon map than speeding up
a continued trace?
  The scene usually changes from render to render (trial and error style
modelling) so I think that the photon map changes as well.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
>   Are there any other advantages of saving the photon map than speeding up
> a continued trace?
>   The scene usually changes from render to render (trial and error style
> modelling) so I think that the photon map changes as well.

Personaly I do not even turn on photons until my scene is fully developed.
Then I spend time tweaking the photon and lighting settings to optimize
their effect for the scene I am working on. In either case a saved map
would serve no purpose because the parameters for the photons would change
between each render session.

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: Personaly I do not even turn on photons until my scene is fully developed.
: Then I spend time tweaking the photon and lighting settings to optimize
: their effect for the scene I am working on. In either case a saved map
: would serve no purpose because the parameters for the photons would change
: between each render session.

  That was what I meant.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

If you have an animation where the objects affecting the photons do not
change, this could save a lot of time.  One of the demo scenes for UVPov6.1
has the following code:
    #if(clock=0)
    save_file "mediaph.ph"
    #else
    load_file "mediaph.ph"
    #end

This is especially the case if the camera is the only thing that moves.

Now, as this relates to radiosity -- Unlike photons, the computation of
radiosity is very camera-dependant.  If generate the radiosity data and then
move the camera and re-use it, you will likely be missing some spots.

-Nathan

Nieminen Juha <war### [at] punarastascstutfi> wrote...
>   Are there any other advantages of saving the photon map than speeding up
> a continued trace?
>   The scene usually changes from render to render (trial and error style
> modelling) so I think that the photon map changes as well.
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I see three benefits:

a) Continued trace
b) Network rendering
c) Specific animations

In cases b and c, the same benefit repeats itself. Why recalculate the map,
when it won't change, no matter where you move the camera to? The idea in b
is that all computers will be working on the same frame. The idea in c is
that your lights and objects don't move. As long as this is true, why waste
time? Say you want to do a walkthrough down a hall with the lights pouring
through the windows and the media with the photons and everything. They
won't change, just the camera position. See what I mean?

Post a reply to this message