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