PMAP simulation

Hi Folks,

I have successfully modelled a 'lightpipe' on the Desktop radiance software
2.0 but the results are pretty dull since it is just a backward ray tracer.

Can anyone tell me how I may model this on the photon mapping version. I
have successfully installed pmap version onto my linux. Do I simply copy all
the windows generated files (*.rad; *.oct; *.rif; etc.) to linux environment
and run the pmap software...what is the run command line if I want to simply
revisual the exact same illuminance simulation that I had done with the
Desktop version?

Much appreciate any contributions.

Thanks.

Anthony

···

--
This message has been scanned for content and
viruses by the DIT Information Services MailScanner
Service, and is believed to be clean.
http://www.dit.ie

Hi Anthony,

first of all, I think it's a good idea to read the documentation (which is part of the distribution) to have an idea what pmap does. Within that documentation all parameters are explained.

The quick instruction is:

0. You can use the standard radiance description (except user defined BRDFs). ->rad and oct

1. To distribute photon and store them in files (global and caustic photons separately)
e.g.
~/bin/radiance/pmap/mkpmap -apg f81_z.gp 700000 -apc f81_z.cp 700000 test.oct
700000 is the number of the photos emitted, gp : global photons, cp caustic photons

2. Count the photons, make a density estimate and generate a picture with the modified rpict:

~/bin/radiance/pmap/rpict -apg f81_z.gp 500 -apc f81_z.cp 500 -ab 1 -x 1200 -y 1200 -vf test.vf -o test.pic test.oct

Similar to the existing rpict, with additional options to read in the photon files. You can use most of the rpict options of the standard-rpict. Of course, the ambient options don't make really sense since the ambient calculation is replaced by the forward raytracer.
In many cases, the use of the photon port mechanism is extremely useful. With photon ports you can define materials, through which the light enters the scene. A typical example is an office scene, which is lit by the sky. Using this, you can avoid huge effort, since the photons are distributed mostly in "relevant" directions. In your case it could make sense to define the entering cross section as "photon port". You can use e.g. glass material with refraction index 1 (==air!!) without disturbing the simulation.

Good luck!

Jan

Anthony J. Farrell wrote:

···

Hi Folks,

I have successfully modelled a 'lightpipe' on the Desktop radiance software
2.0 but the results are pretty dull since it is just a backward ray tracer.

Can anyone tell me how I may model this on the photon mapping version. I
have successfully installed pmap version onto my linux. Do I simply copy all
the windows generated files (*.rad; *.oct; *.rif; etc.) to linux environment
and run the pmap software...what is the run command line if I want to simply
revisual the exact same illuminance simulation that I had done with the
Desktop version?

Much appreciate any contributions.

Thanks.

Anthony

Jan Wienold wrote:

1. To distribute photon and store them in files (global and caustic photons separately)

> e.g.

~/bin/radiance/pmap/mkpmap -apg f81_z.gp 700000 -apc f81_z.cp 700000 test.oct
700000 is the number of the photos emitted, gp : global photons, cp caustic photons

Actually, it's the number of *stored* photons, which is what the user really wants. The resultant number of emitted photons is usually much larger.

Of course, the ambient options don't make really sense
since the ambient calculation is replaced by the forward raytracer.

They do to some degree: the RADIANCE pmap uses a final gather, which means *one* ambient bounce is performed (if -ab > 0, regardless of actual value), with pmap lookups resulting for each sample ray. Consequently, the -ad, -ar, -aa params are still valid. They are *not* used for caustics, however.

In many cases, the use of the photon port mechanism is extremely useful. With photon ports you can define materials, through which the light enters the scene. A typical example is an office scene, which is lit by the sky. Using this, you can avoid huge effort, since the photons are distributed mostly in "relevant" directions. In your case it could make sense to define the entering cross section as "photon port". You can use e.g. glass material with refraction index 1 (==air!!) without disturbing the simulation.

Photon ports are a must for light pipes, unless you stick a light source right in front of the aperture (which would be a fake). An invisible port can simply be declared with antimatter -- see the lightpipe scene in the example tarball on the pmap page (URL below).

Good luck!

Ditto! :^)

···

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)

Roland Schregle wrote:

Actually, it's the number of *stored* photons, which is what the user really wants

Yeah, Roland, give us what we really want :slight_smile: (-: !

-cb

Roland Schregle wrote:

Jan Wienold wrote:

~/bin/radiance/pmap/mkpmap -apg f81_z.gp 700000 -apc f81_z.cp 700000 test.oct
700000 is the number of the photos emitted, gp : global photons, cp caustic photons

Actually, it's the number of *stored* photons, which is what the user really wants.

I might add that this is the *approximate* number of stored photons, since it's impossible to accurately predict the required number of emitted photons. Typically you'll get within +/- 10% of your spec.

And Carsten, what *do* you really want? :^)

···

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)

Roland Schregle wrote:

Roland Schregle wrote:

And Carsten, what *do* you really want? :^)

Money! ... and <beep> ! and more money .. and much more <beep> !

back to business: the number of photons is both straightforward and not very helpful at the same time (anyway, it is more intuitive than many other Radiance parameters). But what do e.g. 471100 photons really mean in terms of accuracy or even image appearance? (my personal rule of thumb is: never start with less than a million photons to get anything good-looking :-))

But I don't have a better idea, either, and concerning the lack of intuitivity, the photon-map in fact fits perfectly into the rest of the
Radiance-parametermania :slight_smile: (viewed from a non-scientists point of view)

Additionally, the photon-map currently is not adaptive, distributing and
gathering are strictly separated. So controlling pmap 'form the output
end of the line', i.e. the image, is not possible now. For comparison, in the ambient case addtional samples (the supersamples) are produced if the calculation doesn't meet a given accuracy criterion.(OK, this accuracy criterion is again rather obscure ...)
And I know, I know, I know of course similar adaptive behaviour would be
far more complex in the pmap case. Maybe one would even end in something like the metropolis stuff ...

-cb

Carsten Bauer wrote:

Roland Schregle wrote:

And Carsten, what *do* you really want? :^)

Money! ... and <beep> ! and more money .. and much more <beep> !

Well, I always appreciate frankness. :^)

back to business: the number of photons is both straightforward and not very helpful at the same time (anyway, it is more intuitive than many other Radiance parameters). But what do e.g. 471100 photons really mean in terms of accuracy or even image appearance?

Nothing -- they're just numbers. That'd be like interpreting the semantics of a knitting pattern. At least that's my conclusion after dabbling with it for 5 years. :^)

But seriously... there *is* an optimum photon count / bandwidth combination, but currently it's still a matter of trial and error. Bias compensation is a workaround, albeit a slow one, and not entirely devoid of artifacts.

Additionally, the photon-map currently is not adaptive, distributing and
gathering are strictly separated. So controlling pmap 'form the output
end of the line', i.e. the image, is not possible now.

You're probably suggesting something along the lines of Suykens' density control mechanism, which evaluates a local error metric during distribution. Of course that requires importance info, which is totally lacking in the current pmap implementation, and would require *major* revision. With the bare essentials you oh so subtly mentioned above (don't forget fame, fortune, learjet, mansion in Malibu, royal suite in Dubai's Burj Al Arab, weekends with starlets, stable of Ferraris, basement full of Crays, blah blah blah) not in the offing, I'm not inclined to invest the significant time and shove this functionality into the code. (Like I said, I appreciate frankness.)

Of course, *you're* welcome to try, seeing as you've already delved in the code. :^)

···

--
Roland Schregle
PhD candidate, Fraunhofer Institute for Solar Energy Systems
RADIANCE Photon Map page: www.ise.fhg.de/radiance/photon-map

END OF LINE. (MCP)