Photon map addition

Greg Ward wrote:

I really appreciate the efforts Roland has put forth to get this out,
and to keep it updated with the latest source changes on our end. I
know this is no small task, and it feels cruel to make new releases
without incorporating his changes, because it just means more work for
him without any real benefit.

I think one of the most important "features" of his code is that
traditional simulations without any of his new options will just
behave as before. I recently had a short look at the code, and
the integration is rather straightforward from a coding point of
view (even if more of his code could be moved to seperate files).
So in theory, we could do the integration now, and just not tell
anyone except for the die-hards explicitly asking for it...

I previously thought that we should wait until we have cleaned
up Radiance itself a bit more, but I don't think that's really
necessary anymore. As you said, it would just make more work for
everybody to synchronize the two code bases again later. Rolands
patches conditionally compile using a PHOTON_MAP macro, so the
default could still be a classic compile. While we're still
trying to get rid of more preprocessor conditionals, I'd be
willing to ad this one to our collection.

It would help me to hear from users who have successfully applied the
photon map. I'd like to see how it helped them and hear what they have
to say about it, on the list or off. Theoretical discussions and
people saying this is a "good idea" are useful only up to a point.
Real experience is what matters, and that's what I need to hear from
people.

We could make it a lot easier for people to gather practical
experience by doing a preliminary integration into the HEAD code,
clearly labeling it "experimental". Otherwise, the requirement
for testing results before we make a final commitment might end
up as a hen and egg problem. Many of the possible candidates will
shy away from any third party modifications because they don't feel
comfortable applying patches or combining binaries from different
sources. I also assume that this could motivate Roland to invest
some more work eg. in those materials that aren't supported yet.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Perhaps this could be put into a CVS branch? That way, it would be
available to the adventurous, without affecting the mainline at all.
Of course the final integration might be more difficult.

Randolph, still v. busy

···

On Sun, Nov 30, 2003 at 11:16:45PM -0500, Georg Mischler wrote:

We could make it a lot easier for people to gather practical
experience by doing a preliminary integration into the HEAD code,
clearly labeling it "experimental". Otherwise, the requirement
for testing results before we make a final commitment might end
up as a hen and egg problem. Many of the possible candidates will
shy away from any third party modifications because they don't feel
comfortable applying patches or combining binaries from different
sources. I also assume that this could motivate Roland to invest
some more work eg. in those materials that aren't supported yet.

Greg Ward wrote:

We need to take a very careful look at this module's affect on the code as well as the rendering process -- does it support all material types (or at least do something reasonable with the types it doesn't support)? Does it place any restrictions on light sources? Participating media? How does it behave when the geometry gets complex? Does it burden or otherwise affect the calculation when it is switched off? Do we get the same results or nearly the same under all important circumstances?

Well, to paraphrase Greg in our very first mail exchange: Hey, I'm glad somebody's picking this up! :^)

Currently all of the more common (?) materials are supported. What's defnitely not supported are user defined BRDFs, i.e. {Met,Plas,Trans}{Data,Func} and BtdfFunc. This could be a serious constraint in some applications. The reason it's missing is simply that I haven't found an efficient way to sample these materials during the forward pass; the prototypes performed abysmally. This is because the BRDF has to be evaluated for the entire hemisphere of outgoing directions for *every* photon hit. A caching scheme might be worth considering, but the memory requirements would be substantial. This is pretty high on the to-do list.

There are a few other (minor?) oddities:

-- the spotlight focus is ignored by the photon map, although you probably won't notice the difference to RADIANCE Classic since the direct calculation is still done with the stock code and a shift in focus shouldn't affect the indirect illumination noticeably.

-- the Glow primitive acts like a standard light source with the photon map. There are no restricitions I'm aware of as far as sources are concerned. All types are supported, including light source modifiers to simulate goniometric diagrams such as IES and EULUMDAT files.

-- distant light sources (defined with the Source primitive) get special treatment and are inherently slow (photons are emitted from the scene cube surfaces). The photon port mechanism can be used here to speed things up (by defining windows and skylights as emitters, for example), but this requires user intervention.

-- light sources must be enclosed in bubbles in order to delineate participating media and obtain volume photons. This is an inconvenience, but bear in mind that RADIANCE Classic doesn't take any indirect illumination into account in participating media.

-- virtual light sources are ignored; caustics is what the photon map is all about.

Admittedly, the addon has seen limited use with really complex geometry, at least on my end. Most of the scenes I used are simple and tractable for the sake of debugging, which is why I'm relying on feedback from users with suitably complex scenes. I've received some interesting results tho, including caustics from a glass blob using a trimesh, which goes beyond anything I've tried.

The addon doesn't burden the standard code in any way: the forward pass is performed by a separate program (mkpmap) and thus self-contained. The backward pass is integrated into rpict/rview/rtrace, with calls to density estimation routines in ambient.c and source.c (for global/caustic, and volume photons, respectively). These calls are conditional, based on the existence of a photon map, i.e. a simple NULL pointer check. Furthermore, the standard functionality is preserved in every way; that was one of the primary design goals.

As for the results, I've made numerous comparisons with RADIANCE Classic using both local and distant sources, and feel that systematic deviations are minimal. That doesn't mean the results are identical; if they were, we wouldn't need the addon! Caustics pop up where RADIANCE Classic doesn't render them (or noisily at best), and the addon is generally faster than RADIANCE Classic. Moreover, it's more accurate with high reflectance scenes because RADIANCE Classic assumes an average reflectance of 0.5 and truncates rays prematurely in these cases. The downside may be a slight increase in noise in the ambient illumination, although this is largely subject to the global photon bandwidth.

At the end of the day tho, what ultimately matters -- at least in lighting applications -- is physical accuracy, and that's where the emphasis of this implementation lies. I'm not aware of other pmaps out there that can handle distant light sources and goniometric diagrams (ok, maybe Henrik Wann Jensen's can). To check the accuracy I spent the last two years checking the thing both analytically and experimentally using measurements done at Fraunhofer ISE.

The analytical validation was a simple "furnace" type scene. There was no bias to speak of when using floats for photon flux. When using RGBE I discovered an underprediction of 0.5% due to rounding errors introduced by this representation. I think everyone can live with this and it saves memory, so I left it as default (float photon flux is still available with the PMAP_FLOAT_FLUX define at compile time). Apart from the diffuse case I also tested specular reflection using a simplified cosine lobe model, and wound up with similar results. In both cases RADIANCE Classic exhibited considerable underprediction with high reflectance, requiring the use of the -lw and -ab options in order to force more ambient bounces, thus slowing things down even further compared to pmap. I elaborated on this stuff in my presentation at last year's RADIANCE workshop, check the workshop slides at radiance-online.

The experimental validation was an entirely different challenge and much more interesting. After countless headaches (I had been warned!) I finally managed to account for all the stuff that can go wrong in such an undertaking. The validation culminated in a case study involving diffuse interreflection plus caustics from a light shelf (the latter intentionally giving rise to more glossy than specular reflection in order to obtain useable results from RADIANCE Classic). Comparison between simulation and measurement revealed deviations well within 10%. Moreover, RADIANCE Classic and photon map delivered very similar results, although the latter was much faster.

For those interested on reading up on this, the validation stuff as well as the bias compensating operator are documented in my PhD thesis which I intend to wrap up and finally hand in this month -- insha'Allah. A paper on bias compensation will appear in this month's issue of Computer Graphics Forum, and I'm in the process of preparing another publication on the validation together with my colleagues at Fraunhofer ISE.

These concerns must be answered, and I'm sure Roland can answer some of them. For other concerns, I'll just have to pour over the source code and test it and test it. It would be very helpful to me if Roland and I could get together and run through everything, but that hasn't happened, and e-mail gets mixed in with all the other activities we have going on, making communication slow and difficult.

I'm sure we can arrange something. It's tough sifting through somebody else's code on your own even if it is commented (particularly if some comments use dodgy language... :^)

I really appreciate the efforts Roland has put forth to get this out, and to keep it updated with the latest source changes on our end. I know this is no small task, and it feels cruel to make new releases without incorporating his changes, because it just means more work for him without any real benefit.

Consequently I didn't even bother adapting to the HEAD release; currently the pmap addon is only compatible with official 3.5 release.

Thanks for bringing this up, Greg!

--Roland

···

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

Currently all of the more common (?) materials are supported. What's
defnitely not supported are user defined BRDFs, i.e.
{Met,Plas,Trans}{Data,Func} and BtdfFunc.

So what does actually happen when those are encountered?

-- the spotlight focus is ignored by the photon map,

Would it be difficult to do this "right"? Not saying that it's
necessary, just for the sake of completeness.

-- the Glow primitive acts like a standard light source with the photon
map. There are no restricitions I'm aware of as far as sources are
concerned. All types are supported, including light source modifiers to
simulate goniometric diagrams such as IES and EULUMDAT files.

I think the glow radius was introduced exclusively as a
performance optimisation for backwards raytracing, and usually
has a negative effect on simulation accuracy. If that is indeed
so, then I see no harm in ignoring it for the photon map, as
doing so will only improve the result, at a presumably very low
performance penalty.

The documentation never even mentions illum sources. Are they
ignored? If so, I think that would be one of the key problems yet
to solve. Since illums are often used as impostors to replace
other sources (or arbitrary geometry), I assume that any photon
hitting an illum source would need to be dropped, at least if it
hits from behind. Actually, what happens in general when photons
hit other light sources, from either side?

-- distant light sources (defined with the Source primitive) get special
treatment and are inherently slow (photons are emitted from the scene
cube surfaces).

What that means is that photon maps are not generally adequate to
render exterior scenes.

The photon port mechanism can be used here to speed
things up (by defining windows and skylights as emitters, for example),
but this requires user intervention.

If I'm not mistaken (and assuming illum support), then photon
ports are at least partly exchangeable with the use of mkillum
or other local preprocessing algorithms in window openings. This
also means that mkillum type programs would have to be run first,
and the resulting sources might serve as input into the photon
pool. Is this correct?

I'm just trying to consider a number of daylighting use cases, to
determine how the classic methods may or may not play well
together with the use of photon maps. In the following, the
output of each mkillum (or alternative) run might be fed into the
photon map, even though I didn't bother to explicitly mention it
each time.

A) Opening with simple window material like glass/trans/etc
   (or void surface if there is no window pane).
   Treatment choices:
   m: Apply mkillum to pane.
      Advantage: Takes exterior interreflections into account
      Disadvantage: May be slower if exterior is complex.
   p: Use the pane as photon port.
      Advantage: Probably very fast
      Disadvantage: Ignores exterior interreflections
   n: Do nothing special (if opening is very large)
      Advantage: Simple
      Disadvantage: Less accurate and slower than the above.

B) Opening contains some kind of approximately planar redirection
   system that can be geometrically modelled and traced.
   Treatment choices:
   m: Apply mkillum to surface on interior side.
      Advantage: Simple to implement and understand
      Disadvantage: Usually not very accurate, depending on the
      system.
   d: Apply a specialized mkillum replacement to simulate the
      effects of the redirection system.
      Advantage: Simple to use and understand as well as accurate
      Disadvantage: Requires custom algorithm/data for each type
      of system. Currently only available as a proprietary
      product, and for a very limited set of systems.
   p: Use a surface on exterior side as photon port.
      Advantage: Simple to use and understand
      Disadvantage: How robust is this with very complex
      reflection paths through the system?
   n: Do nothing special
      Advantage: No need to understand anything
      Disadvantage: Extremely inaccurate

C) Opening with shading/redirection system that is hard to model
   geometrically, let alone to trace (TWD, aerogel, etc.)
   Treatment choices:
   d: Apply a specialized mkillum replacement to simulate the
      effects of the system.
      Advantage: Simple to use and understand as well as accurate
      Disadvantage: Requires custom algorithm/data for each type
      of system. Not yet publicly available for this type of systems.
   n: No other solution yet that I know of.

D) Light pipes.
   Treatment choices:
   p: Photon port at entry of pipe.
      Advantage: Appears to work. :wink:
      Disadvantage: Are there restrictions on the pipe geometry
      and/or proportions?
   m: Mkillum surface at entry of pipe, feeding the result into
      the photon map.
      Advantage: Would that improve anything?
      Disadvantage: No idea...

- Any interesting situations I forgot?

-- light sources must be enclosed in bubbles in order to delineate
participating media and obtain volume photons.

No surprise, really. This is equivalent to the requirement that
view points and sensors be located outside of participating media
volumes.

Admittedly, the addon has seen limited use with really complex geometry,
at least on my end. Most of the scenes I used are simple and tractable
for the sake of debugging, which is why I'm relying on feedback from
users with suitably complex scenes.

That situation could be improved by an experimental HEAD merge.
Particularly, it would give Windows users access to photon maps
combined with all the recent improvements to Radiance, and
Francesco Anselmo wouldn't have to provide two seperate Cygwin
builds anymore.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

This thread caught my eye. I think I saw a demo of Roland's code at SG2000. It was rendering a medium complexity scene at near real time on a pentium laptop.

I have two concerns about a pair of limitations that Roland mentioned:

-- the Glow primitive acts like a standard light source with the photon
map. There are no restricitions I'm aware of as far as sources are
concerned. All types are supported, including light source modifiers to
simulate goniometric diagrams such as IES and EULUMDAT files.

-- virtual light sources are ignored; caustics is what the photon map is
all about.

Is the "illum" type considered one of the "virtual light source" types and is therefore ignored? These two limitations have an interesting implication for some expert users. The "glow" primitive is frequently used with zero radius of influence inside "illum" spheres to accurately model the appearance of luminaires without affecting the distribution of the luminaire described with the IES distribution. If the radius of effect of the glow is ignored, or if "glow" primitives inside "illum" spheres are not ignored (for shadow testing and for the ambient calculation), then there will definately be a modeling compatibility problem.

Other times the "glow" primitive is set with a non-zero radius of influence to optimize renderings in complex scenes. For example, if you have downlights on every floor of a multi-floor building, the radius can be set to just shy of two floor-to-floor heights so that beyond this distance, the shadow testing is avoided. This can have a profound impact on rendering speed with "Radiance Classic." This limitation is not as important if the photon mapping code deals with such optimizations automatically.

-- light sources must be enclosed in bubbles in order to delineate
participating media and obtain volume photons. This is an inconvenience,
but bear in mind that RADIANCE Classic doesn't take any indirect
illumination into account in participating media.

Now this sounds like a fantastic benefit of the new code. Any plans to validate these results? I presume this would be very useful for nighttime outdoor light pollution analysis, no?

There is another "chicken and egg" problem WRT the validation of new and experimental code in Radiance. If the new code is not part of the standard release, the average and even many advenuresome Radiance users will never have the opportunity to exercise the experimental parts of the code. This means that you get much less volume of feedback regarding the usefulness of the new code segments.

Wasn't someone working on a test suite? What is the status of this effort?

-Chas

Georg Mischler wrote:

Roland Schregle wrote:

Currently all of the more common (?) materials are supported. What's
defnitely not supported are user defined BRDFs, i.e.
{Met,Plas,Trans}{Data,Func} and BtdfFunc.

So what does actually happen when those are encountered?

Well, you get a pretty "unexpected object call" message that's used as default in the dispatch table, and mkpmap gracefully bails out. :^)

-- the spotlight focus is ignored by the photon map,

Would it be difficult to do this "right"? Not saying that it's
necessary, just for the sake of completeness.

Not that straightforward; photons would have to be emitted *behind* the light source and pass through it, requiring some ugly special hack. Didn't feel like messing with this 'cos I didn't consider it that important. I suppose you could find a workaround in the long run.

The documentation never even mentions illum sources. Are they
ignored? If so, I think that would be one of the key problems yet
to solve. Since illums are often used as impostors to replace
other sources (or arbitrary geometry), I assume that any photon
hitting an illum source would need to be dropped, at least if it
hits from behind.

Photon map doesn't parse its own light sources: it takes the standard source array delivered by marksources(), and whatever's in there is considered a source. Illums wind up in there too, if I remember correctly (haven't done much with them), and they're treated just like a regular source. I gave this some thought and realised that illums would probably be overkill if used together with exterior distant sources. While this would slow things down, photons hitting the illums from the back would be swallowed anyway, so I don't think it'll invalidate the results. Personally, I'm not sure about the wisdom of using illums with the pmap addon. As I understand it, this construct is often used to get a luminance distribution from a window with a facade. If you're using specular materials illum probably won't cut it and you'll need to use the pmap + port approach. On the other hand, diffuse external interreflections are probably better handled via an illum.

> Actually, what happens in general when photons

hit other light sources, from either side?

Light sources don't reflect in RADIANCE. Consequently, they aborb photons. Whether this behaviour is correct is debatable, fact is tho that RADIANCE Classic doesn't consider reflections from sources either. These contributions would most probably be insignificant anyway in most scenes (at least realistic ones).

-- distant light sources (defined with the Source primitive) get special
treatment and are inherently slow (photons are emitted from the scene
cube surfaces).

What that means is that photon maps are not generally adequate to
render exterior scenes.

Nope, there's a fundamental difficulty there for the same reason a backward raytracer can't handle caustics efficiently.

The photon port mechanism can be used here to speed
things up (by defining windows and skylights as emitters, for example),
but this requires user intervention.

If I'm not mistaken (and assuming illum support), then photon
ports are at least partly exchangeable with the use of mkillum
or other local preprocessing algorithms in window openings. This
also means that mkillum type programs would have to be run first,
and the resulting sources might serve as input into the photon
pool. Is this correct?

The photon port stuff is effectively just a hack I needed to get quick daylight simulations, and certainly shouldn't be considered the definitive workaround to the efficiency problems posed by distant sources. It's neither elegant nor flexible, but it gets the job done.

I too realised the similarity to illums and briefly even considered hacking the illums themselves to act as ports, which would also provide the benefit of accounting for external interreflection (which ports currently don't, although they do check for source occlusion). I discussed this with Peter A.B. and we concluded it was better to add an extra construct specifically for the purpose, although I can't exactly remember why. I think one of the main reasons was the limited spatial resolution of illums, which could give rise to aliasing and therefore bias in the photon distribution. Like I said, the ports are just a stopgap until a nifty importance based distribution scheme is developed. But that's another story (apologies to Billy WIlder)...

I'm just trying to consider a number of daylighting use cases, to
determine how the classic methods may or may not play well
together with the use of photon maps. In the following, the
output of each mkillum (or alternative) run might be fed into the
photon map, even though I didn't bother to explicitly mention it
each time.

A) Opening with simple window material like glass/trans/etc
   (or void surface if there is no window pane).
   Treatment choices:
   m: Apply mkillum to pane.
      Advantage: Takes exterior interreflections into account
      Disadvantage: May be slower if exterior is complex.
   p: Use the pane as photon port.
      Advantage: Probably very fast
      Disadvantage: Ignores exterior interreflections
   n: Do nothing special (if opening is very large)
      Advantage: Simple
      Disadvantage: Less accurate and slower than the above.

Case n will be slower than p or m, but not necessarily less accurate; brute force bombardment of the entire scene cube with photons is just much slower and dumber, but there's no bias I'm aware of (this distrubtion is infact stratified over each side of the scene cube).

B) Opening contains some kind of approximately planar redirection
   system that can be geometrically modelled and traced.
   Treatment choices:
   m: Apply mkillum to surface on interior side.
      Advantage: Simple to implement and understand
      Disadvantage: Usually not very accurate, depending on the
      system.

If your system produces highly localised caustics, you'll need to precompute some very hi-res illums; that would be a *lot* slower than photon ports.

   d: Apply a specialized mkillum replacement to simulate the
      effects of the redirection system.
      Advantage: Simple to use and understand as well as accurate
      Disadvantage: Requires custom algorithm/data for each type
      of system. Currently only available as a proprietary
      product, and for a very limited set of systems.

This is your approach, right? There's no doubt this is more accurate (based on analytical solution, if I'm not mistaken) and probably faster than the pmap approach. The fundamental problem as you point out is of course the lack of generality. This is the pmap's strong suit, and Wann Jensen has always emphasised generality and geometric independence (photons aren't associated with objects, but rather just with 3D points) in his publications. This also makes it relatively easy to integrate a photon map addon into an existing raytracer.

   p: Use a surface on exterior side as photon port.
      Advantage: Simple to use and understand
      Disadvantage: How robust is this with very complex
      reflection paths through the system?

Once a photon has been emitted, it makes absolutely no difference whether it came from "outer space" (i.e. the scene cube) or the window. If it gets reflected back out through the port or bounces back inside, that's no problem. A port behaves according to its assigned material when a photon hits it. Problems may of course arise if the port is ill-defined (i.e. the system is partly outside, etc). Therein lies the inconvenience and potential pitfall for the user.

   n: Do nothing special
      Advantage: No need to understand anything
      Disadvantage: Extremely inaccurate

Again, this shouldn't be any less accurate than m or p, just stupefyingly slow. Of course, not having to know what you're doing is rather nice once in a while... :^)

C) Opening with shading/redirection system that is hard to model
   geometrically, let alone to trace (TWD, aerogel, etc.)
   Treatment choices:
   d: Apply a specialized mkillum replacement to simulate the
      effects of the system.
      Advantage: Simple to use and understand as well as accurate
      Disadvantage: Requires custom algorithm/data for each type
      of system. Not yet publicly available for this type of systems.
   n: No other solution yet that I know of.

Generally, if you can model it with RADIANCE Classic, pmap can trace it. Caveat preemptor once again: user-defined BRDFs. I have no idea how these materials are modeled, so I can't say for sure if pmap can handle this situation. Anyone out there try this?

D) Light pipes.
   Treatment choices:
   p: Photon port at entry of pipe.
      Advantage: Appears to work. :wink:

No, I didn't run that through the Gimp. :^)

      Disadvantage: Are there restrictions on the pipe geometry
      and/or proportions?

Nope. For all I care your pipes could be Pam Anderson shaped... (go for it, Rob!)

   m: Mkillum surface at entry of pipe, feeding the result into
      the photon map.
      Advantage: Would that improve anything?
      Disadvantage: No idea...

Beats me. I think this port/illum stuff should be thought out in detail again. As I said, it's not the last word.

--Roland

···

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

Charles Ehrlich wrote:

This thread caught my eye. I think I saw a demo of Roland's code at SG2000. It was rendering a medium complexity scene at near real time on a pentium laptop.

Hi Chas,

um, are you sure that was my code? I'd be flattered if it was anywhere near real time. Sounds more like Henrik's implementation. :^)

I have two concerns about a pair of limitations that Roland mentioned:

    -- the Glow primitive acts like a standard light source with the photon
    map. There are no restricitions I'm aware of as far as sources are
    concerned. All types are supported, including light source modifiers to
    simulate goniometric diagrams such as IES and EULUMDAT files.

    -- virtual light sources are ignored; caustics is what the photon
    map is
    all about.

Is the "illum" type considered one of the "virtual light source" types and is therefore ignored? These two limitations have an interesting implication for some expert users. The "glow" primitive is frequently used with zero radius of influence inside "illum" spheres to accurately model the appearance of luminaires without affecting the distribution of the luminaire described with the IES distribution. If the radius of effect of the glow is ignored, or if "glow" primitives inside "illum" spheres are not ignored (for shadow testing and for the ambient calculation), then there will definately be a modeling compatibility problem.

Sorry, with "virtual" sources I of course meant secondary sources defined by mirrors in order to accurately model reflections. These are basically redundant with photon map and therefore disabled when using this rendering technique.

I just took a look at marksources() again. Glows with zero radius are ignored. Consequently, pmap should ignore them too. Illums are treated as light sources, I believe, and should therefore act as the actual emitter in lieu of the Glow during photon distribution. As such, there shouldn't be a problem. This is admittedly just a vague line of reasoning; I honestly have never considered such a scenario. Should give this a shot.

    -- light sources must be enclosed in bubbles in order to delineate
    participating media and obtain volume photons. This is an
    inconvenience,
    but bear in mind that RADIANCE Classic doesn't take any indirect
    illumination into account in participating media.

Now this sounds like a fantastic benefit of the new code. Any plans to validate these results? I presume this would be very useful for nighttime outdoor light pollution analysis, no?

I'm not aware of any validation plans for participating media. This was considered pretty much peripheral at ISE, and I just put it in for completeness and "because I could" once I perused Wann Jensen's papers on volume rendering. Of course I'm sure there's people out there who don't merely regard this as a gimmick, but find it downright useful. As such I agree this feature should be checked for accuracy. This is the kind of feedback I'm really looking forward to. My experience with volume rendering is very limited, and I only had the formulae to go by, but I think I got it right the third time around or so. :^)

--Roland

···

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

Georg Mischler wrote:

Roland Schregle wrote:

What's defnitely not supported are user defined BRDFs, i.e.
{Met,Plas,Trans}{Data,Func} and BtdfFunc.

So what does actually happen when those are encountered?

Well, you get a pretty "unexpected object call" message that's used as
default in the dispatch table, and mkpmap gracefully bails out. :^)

Not good enough.

The very least we should do is to deposit the photon there, so
that it can get gathered again later. Since we'll be looking at
the situation from the other side at gathering time, shouldn't we
be able to do the right thing with the BR[T]DF then?

That would basically mean that those materials become a natural
energy transfer gateway between the forward and backward tracing
systems. In the worst case, you'll have to add a flag to the
photon saying "we still need to look at the surface interaction
with this one".

I'm still not completely clear about this transfer phase, btw.
If I run rpict with pmap and eg. 5 ambient bounces, is there any
risk of double counting any light paths? Or maybe more to the
point, how is this avoided?

Yeah, I know I should read up on Henrik Wann Jensen eventually,
but maybe you can still provide a few pointers about how the
interaction with Radiance classic is implemented.

-- the spotlight focus is ignored by the photon map,

Would it be difficult to do this "right"? Not saying that it's
necessary, just for the sake of completeness.

Not that straightforward; photons would have to be emitted *behind* the
light source and pass through it, requiring some ugly special hack.

At some point we'll probably want a good estimation of the
possible errors, but right now I don't see this as an obstacle.

Personally, I'm not sure about the wisdom of using illums with
the pmap addon. As I understand it, this construct is often used to get
a luminance distribution from a window with a facade.

We should probably differentiate between the illum material type
(which is a normal light source for pmap), and the mkillum
program (which happens to produce illums).

But apart from that, I think that potentially a mkillum generated
illum surface could replace a photon port at least in some
situations. However, the two approaches seem to have different
strengths and weeknesses.

If you're using
specular materials illum probably won't cut it and you'll need to use
the pmap + port approach. On the other hand, diffuse external
interreflections are probably better handled via an illum.

Maybe we could make a table what happens with each of them in all
relevant situations, to get an idea about how to reach the best
combined result. We should probably look at at least the
following matrix:

Receiving side:
- direct sun (light)
- direct sky (glow)
- reflected (sky and sun)

Emitting side:
- direct calculation
- ambient calculation
- direct view to surface
- direct ray with rtrace

For the moment, this is ignoring any other aspects, like geometry
elements in front of or behind the respective surface. We can
look at situations like this later.

The photon port stuff is effectively just a hack I needed to get quick
daylight simulations, and certainly shouldn't be considered the
definitive workaround to the efficiency problems posed by distant
sources. It's neither elegant nor flexible, but it gets the job done.

It follows an established pattern about how users can inform the
software about special properties of their scene geometry.
Implementation details can of course still be subject to debate
and possible improvements.

I discussed this with Peter A.B. and we concluded it was better to add an
extra construct specifically for the purpose, although I can't exactly
remember why. I think one of the main reasons was the limited spatial
resolution of illums, which could give rise to aliasing and therefore
bias in the photon distribution.

I think it would be helpful if either of you could dig up those
arguments (unless they were only exchanged verbally). To me it
currently feels like we have all (or most) of the building blocks
to make this really useful. We might just need to combine them
the right way, and maybe add one or two missing links.

>> d: Apply a specialized mkillum replacement to simulate the

      effects of the redirection system.
      Advantage: Simple to use and understand as well as accurate
      Disadvantage: Requires custom algorithm/data for each type
      of system. Currently only available as a proprietary
      product, and for a very limited set of systems.

This is your approach, right? There's no doubt this is more accurate
(based on analytical solution, if I'm not mistaken) and probably faster
than the pmap approach.

It's not really "my" approach, although I'm trying to sell it...
The improved accuracy doesn't actually have much to do with the
analytically generated data, working with measured data would at
least in theory be just as fine. The main advantage is that the
behaviour of the system is already known beforehand, and at an
appropriate resolution. During the simulation all that remains
to do are table lookups, which means the results are exactly as
accurate as the underlying data set.

   p: Use a surface on exterior side as photon port.
      Advantage: Simple to use and understand
      Disadvantage: How robust is this with very complex
      reflection paths through the system?

Once a photon has been emitted, it makes absolutely no difference
whether it came from "outer space" (i.e. the scene cube) or the window.
If it gets reflected back out through the port or bounces back inside,
that's no problem.

The question wasn't so much about the behaviour of the ports.
I guess I'm wondering generally about how the photon map will
perform when penetrating very detailed and convoluted geometry.

D) Light pipes.
   Treatment choices:
   p: Photon port at entry of pipe.
      Advantage: Appears to work. :wink:
      Disadvantage: Are there restrictions on the pipe geometry
      and/or proportions?

Nope. For all I care your pipes could be Pam Anderson shaped... (go for
it, Rob!)

That's basically again the same question as above: What happens
in practise if the pipe turns around two or three corners?
I assume that partly depends on the parameter settings. I'm just
trying to get a feeling about the possibilities and limitations.

For the same reason, and to give those theoretical deliberations
a more realistic foundation, I'd like to encourage other people
who have used the photon map extension to act on Gregs request,
and share their practical experiences. You can either do this
through one of the mailing lists, or directly to Greg and/or me.
Roland, do you have a list of users that you could politely ask
to chime in? The more feedback we get, the better.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Do the photon map routines work inside of rtrace, or are they strictly for the renderers? If they work on a ray-by-ray (bundle-by-bundle) basis, perhaps a version of mkillum could be developed that uses the photon map routines instead of "Radiance Classic" routines. I presume that mkillum would be much faster with photon mapping since mkillum uses a low resolution sampling of its environment.

-Chas

Charles Ehrlich wrote:

Do the photon map routines work inside of rtrace, or are they strictly for the renderers? If they work on a ray-by-ray (bundle-by-bundle) basis, perhaps a version of mkillum could be developed that uses the photon map routines instead of "Radiance Classic" routines. I presume that mkillum would be much faster with photon mapping since mkillum uses a low resolution sampling of its environment.
-Chas

Hi Chas,

the photon distribution is indeed ray-by-ray (or photon-by-photon, for that matter), except that the emission loop is selfcontained, so you can't emit individual photons via external calls at the moment. Currently the emission routine has to know a priori the required number of *stored* photons (corresponding to mkpmap's -apg/-apc/-apv parameters). The number of photons actually *emitted* depends on your geometry and is impossible to predict a priori. It's a non-trivial technicality, but we should be able to provide a more general interface if the need arises.

--Roland

···

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

Georg Mischler wrote:

Roland Schregle wrote:

Well, you get a pretty "unexpected object call" message that's used as
default in the dispatch table, and mkpmap gracefully bails out. :^)

Not good enough.

No?

The very least we should do is to deposit the photon there, so
that it can get gathered again later. Since we'll be looking at
the situation from the other side at gathering time, shouldn't we
be able to do the right thing with the BR[T]DF then?

That's not gonna help ya if you don't propagate the photon, and for that you need the BRDF. The BRDF's contributions to the other surfaces will still be missing, and postprocessing in the backward pass won't cut it either because at most 1 ambient bounce is performed with pmap. Your solution will still be incomplete.

Caustics from such a material won't show up with this scheme either, since specular reflections from surfaces hit by ambient rays are suppressed, because this is exactly what the caustic photons account for. Failure to ignore these transport paths would result in overcounting.

Finally, note that the current implementation doesn't store the photon's incident direction, so that info wouldn't be available during the backward pass when applying the BRDF. I considered this info redundant because photons only account for the diffusely reflected indirect illumination; the specularly reflected indirect illumination is still handled via the stock code (unless it's already accounted for by caustic photons, as noted above).

I'm still not completely clear about this transfer phase, btw.
If I run rpict with pmap and eg. 5 ambient bounces, is there any
risk of double counting any light paths? Or maybe more to the
point, how is this avoided?

If -ab is nonzero, the actual number is irrelevant: global photon contributions are always visualised via *one* intermediate ambient bounce. If you set -ab to zero, the global photons are visualised directly at the primary ray (which is faster but pretty noisy). Caustic photons are always visualised directly.

Double counting is ruled out for caustics as described above. For diffuse illumination, double counting is avoided by not tracing ambient rays when global photon contributions are evaluated -- these components account for the same transport paths, expect the photon density estimate is generally faster than tracing ambient rays.

For the same reason, and to give those theoretical deliberations
a more realistic foundation, I'd like to encourage other people
who have used the photon map extension to act on Gregs request,
and share their practical experiences. You can either do this
through one of the mailing lists, or directly to Greg and/or me.
Roland, do you have a list of users that you could politely ask
to chime in? The more feedback we get, the better.

I'll go through my old musty MailCrypt[tm] and see who I can dig up... :^)

--Roland

···

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

Charles Ehrlich wrote:

Do the photon map routines work inside of rtrace, or are they strictly for
the renderers? If they work on a ray-by-ray (bundle-by-bundle) basis,
perhaps a version of mkillum could be developed that uses the photon map
routines instead of "Radiance Classic" routines. I presume that mkillum
would be much faster with photon mapping since mkillum uses a low resolution
sampling of its environment.

Backwards raytracing (classic Radiance) is most efficient when
the emitting area of the scene is large relative to the receiving
area, iow. when we need to "collect" light.
Photon mapping (~= forward raytracing) is most efficient when the
emitting area of the scene is small relative to the receiving
area, iow. when we need to "distribute" light.

In an architectural daylighting simulation, we have two geometric
bottlenecks. One are the window openings, and the other are the
view points and other sensor points. Collecting light from the
sky and the environment to the window openings is best solved by
backwards raytracing (mkillum+rtrace). Distributing light from
the window openings (plus any artificial sources) into the
interior spaces is best solved by photon mapping. And collecting
light from interior spaces to the viewpoints and sensors is again
best handled by backwards raytracing (rpict/rview/rtrace).

This is why we're discussing how the output of mkillum (or a
similar program) could be used as input into the photon map
algorithm, instead of the other way round.

That's the global picture, anyway. As you see from the remaining
discussion, there are still a few problems to be solved at the
transfer points between the different methods.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Roland Schregle wrote:

Georg Mischler wrote:
> Roland Schregle wrote:
>
>>Well, you get a pretty "unexpected object call" message that's used as
>>default in the dispatch table, and mkpmap gracefully bails out. :^)
>
> Not good enough.

No?

It's not my decision in the end, but as a first gut reaction
I'd really prefer to see a complete solution. On the other hand,
I think I understand the problems involved a little better now.

One point to note is that the xxxfunc and xxxdata primitives only
perform their magic with light that is contributed by direct
sources. For reflected input they seem to behave like standard
plastic/metal/trans. Could the "abysmal performance" you cited
earlier for scanning the outgoing hemisphere be more tolerable
when restricted to brand new photons on their first hop?

In general, abysmal performance looks still better to me than
missing functionality. I can live with telling people those
materials don't perform well with pmap, but would hate to have to
tell them they simply don't work.

Well, at least until we find a better solution...

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

Georg Mischler wrote:

One point to note is that the xxxfunc and xxxdata primitives only
perform their magic with light that is contributed by direct
sources. For reflected input they seem to behave like standard
plastic/metal/trans. Could the "abysmal performance" you cited
earlier for scanning the outgoing hemisphere be more tolerable
when restricted to brand new photons on their first hop?

Most defnitely, but I personally wouldn't be too happy with that. I'm also aware of RADIANCE Classic's shortcut with these materials (it's basically the same problem, just the other way round), and if pmap were to recitfy this, I agree with you that it should do so fully (but don't ask me how).

In general, abysmal performance looks still better to me than
missing functionality. I can live with telling people those
materials don't perform well with pmap, but would hate to have to
tell them they simply don't work.

Well, I initially felt that way too, then quickly changed my mind when I cranked out the last release. Again, I felt it'd be just a half baked solution no one would be really happy with.

Well, at least until we find a better solution...

Alas, not any day soon as far as I'm concerned. Currently I've shelved the code and am wrapping up my thesis, so I'm not actively poring over a solution.

Uh... is anybody actually still *reading* this thread? :^)

--Roland

···

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

Uh... is anybody actually still *reading* this thread? :^)

Yes, even if 70% of it bounces off my thick skull, which could be modeled like so, using Radiance Classic [TM]:

void trans robs_skull
0
7
.91 .91 .91 0 0.05 0.23 .048

This allows for a slight specular lobe in the direction of my frontal lobe, though reflection and absorption are really having a negative impact on my understanding of all of this. =8-)

(sorry)

···

----

      Rob Guglielmetti

e. [email protected]
w. www.rumblestrip.org

Rob Guglielmetti wrote:

Roland Schregle wrote:

Uh... is anybody actually still *reading* this thread? :^)

Yes, even if 70% of it bounces off my thick skull, which could be modeled like so, using Radiance Classic [TM]:

void trans robs_skull
0
7
.91 .91 .91 0 0.05 0.23 .048

This allows for a slight specular lobe in the direction of my frontal lobe, though reflection and absorption are really having a negative impact on my understanding of all of this. =8-)

Cool, a specular skull! :^)
Actually, you might wanna take a look at Wann Jensen's book. It's more straightforward than his papers (although HWJ's papers generally read much better than some others I've pored over). Speaking of which, I'm poring over a few right now as references for my thesis. Totally mind numbing stuff... sometimes I really wonder who the hell reads this crap, and for that matter, who the hell's gonna read my thesis! :^)

See ya!

--Roland

···

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

  ... sometimes I really wonder who the hell reads this crap, and for that matter, who the hell's gonna read my thesis! :^)

if you write it in the same style as your source code comments, anyone who doesn't read it surely's gonna miss something !!!

still czeching it out, man

-Carsten

This is largely my fault for not taking the time to really go through the photon map changes to see what they were about. I started looking through Roland's docs a year ago, and never got back to it. I simply haven't had time to play with it, and I don't see the time appearing anywhere in the immediate future.

If the photon map had been implemented as a mkillum substitute, i.e., a separate program that creates light sources for Radiance, there would be no hesitation to include it in the main distribution. In that case, there would have been no risk whatsoever to the renderer, and it wouldn't have affected any of the rendering options. However, my understanding is that the photon map has been folded right into the main rendering code, with quite a few new options associated with its use. This makes it critical to do a fitness evaluation before we fold it into the main source, and that requires testing.

We need to take a very careful look at this module's affect on the code as well as the rendering process -- does it support all material types (or at least do something reasonable with the types it doesn't support)? Does it place any restrictions on light sources? Participating media? How does it behave when the geometry gets complex? Does it burden or otherwise affect the calculation when it is switched off? Do we get the same results or nearly the same under all important circumstances?

These concerns must be answered, and I'm sure Roland can answer some of them. For other concerns, I'll just have to pour over the source code and test it and test it. It would be very helpful to me if Roland and I could get together and run through everything, but that hasn't happened, and e-mail gets mixed in with all the other activities we have going on, making communication slow and difficult.

I really appreciate the efforts Roland has put forth to get this out, and to keep it updated with the latest source changes on our end. I know this is no small task, and it feels cruel to make new releases without incorporating his changes, because it just means more work for him without any real benefit.

It would help me to hear from users who have successfully applied the photon map. I'd like to see how it helped them and hear what they have to say about it, on the list or off. Theoretical discussions and people saying this is a "good idea" are useful only up to a point. Real experience is what matters, and that's what I need to hear from people. I have not used the photon map myself at this point, so I have no direct experience of my own.

Thanks,
-Greg

···

From: Roland Schregle <[email protected]>
Date: November 30, 2003 5:04:25 AM PST

Lars O. Grobe wrote:

(...) Note that RADIANCE modified with pmap behaves exactly like RADIANCE Classic unless you explicitly use pmap options. As such, you don't need the original RADIANCE binaries anyway.

Hi,
hmmm... maybe this has been on the dev-list before, but if this feature can be used like this without problems - will it be included in the main distribution of radiance one day?

Good question -- that's up to Fraunhofer and Berkeley, I guess. I don't expect that to be resolved anytime soon... :^(

--Roland