Jump to content
  • Advertisement
Sign in to follow this  
Max_Payne

Irradiance Caching

This topic is 4412 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I need some help solving this problem... I've been working on implementing irradiance caching last night from Ward's original paper, but I'm getting some nasty artifacts. (ignore the boxes being black, I fixed that). It seems that some values in the corners (eg: top of left and green wall) are being used too far away. I don't really know what's going on though, because the harmonic mean distance does seem to be computed properly... And there should really be alot of samples on *all* corner edges (including the top of the green wall)... Yet that's just not what's happening and I'm clueless as to why this is the case. Sample image from cornell box (bright spots are irradiance samples): This is how it should be: I'm also posting the source for the involved code, if anyone feels like helping.... The irradiance cache implementation is (obviously) in irradiancecache.cpp/.h, the renderer uses the cache in the QueryCache() method (bottom of renderer.cpp). Linky for source download

Share this post


Link to post
Share on other sites
Advertisement
What are the white dots meant to be showing? Is that where you're storing irradiance cache entries? Or are those locations where the photon map was sampled directly?

I'm assuming those are the irradiance cache points, in which case your storage logic is borked. You should never be storing entries so close together on areas of low-frequency change, such as the middle of the walls and floor. Really the cieling is the only part that looks correct for cache storage locations.

I have to confess that I've worked with so many variations on this concept that I don't recall off the top of my head how Ward originally proposed to do this. So... what criteria are you using to decide where to store cache points? What are you basing your sampling criteria on? What steps are you taking to ensure you don't store redundant cache points? (If you're taking any such steps, they're not working right [smile])

Also, what criteria do you have for rejecting locations for caching? Seems like the gaps in cache points follow circular or semicircular areas, which might indicate the incorrect checking of a threshold radius for rejecting cache points. A wonky threshold might also explain the incorrect clustering that is rampant all over the walls and floor.


[edit] Oh, yeah - how are you gathering irradiance information when you decide what value to store in the cache? Depending on how you sample the photon map, you can hit threshold bugs where you don't gather enough photons to store a meaningful irradiance sample, and your cache gets crap data in it. That doesn't seem to be what's going on here (at least not exclusively) but the really nasty patches on the cieling reminded me of that.

Share this post


Link to post
Share on other sites
There is no photon mapping involved in this process. The dots are irradiance samples, and no, the logic isn't "borked" as for the closeness of the points. They're this close because I set a low "selectivity", that is, I only accept close-by points for interpolation.

The points are weighed by harmonic mean distance and normal (as Ward proposed). The distribution actually seems correct in the sense that they are closer near the edges (that's how it should be). What is incorrect is how there are gaps, which may be due to points with an incorrect harmonic mean distance being used. The semicircular nature of the artifacts is probably from on the rejection distance...

I haven't really looked into the bug in detail, I will need to implement some way of knowing which samples which are being used at a given point.

Share this post


Link to post
Share on other sites
Uhh... so where are you getting the irradiance data from?


I don't really follow your description here. It doesn't matter what your selectivity is - you shouldn't have samples clumping like that. It makes for bad artifacts when you get high-frequency interreflection phenomena. Your samples should be more-or-less uniformly (but stochastically) scattered across a flat surface. The ceiling is correct, the walls and floors are not - your sample points are going to lead to goofy interpolation most of the time. A low selectivity should tend to simply give you more density, not clumping.

The idea of irradiance caching is based on the rate of change of irradiance. When irradiance fluctuates slowly over a given area, you use few samples. When it fluctuates quickly (i.e. high-frequency) you need more samples. The trick is that in areas of slow change, a gentle interpolation is much less likely to generate a result that is incorrect (i.e. different from the real values). So by isolating areas of low-frequency change, irradiance caching lets us interpolate irradiance values as much as possible, thus saving on very expensive lookups in the actual irradiance data (often a photon map).


Look at the decision logic for where you place your sample points. You're not computing something right. Again: ceiling good, the rest very bad.

Share this post


Link to post
Share on other sites
What if you reduce the number of white dots projected?

The distribution looks identical, with the density in your version appearing to be simply greater. It could be my imagination of course.

If the scattering was visually identical, would that make it any easier to tweak the code to get to the root of the real problem?

Share this post


Link to post
Share on other sites
Quote:
Uhh... so where are you getting the irradiance data from?


Monte-carlo path tracing.

Quote:
Original post by ApochPiQ
Your samples should be more-or-less uniformly (but stochastically) scattered across a flat surface. The ceiling is correct, the walls and floors are not - your sample points are going to lead to goofy interpolation most of the time. A low selectivity should tend to simply give you more density, not clumping.


That is incorrect, if you look at the other image I posted (from Cornell), they have their samples closer at the edges and progressively less close near the center of the polygons as well. This is the same pattern as in my image, except that my samples get closer more rapidly. If I turn the selectivity lower, it actually looks almost exactly like that image, except for the artifacts which are still present.

Share this post


Link to post
Share on other sites
Err, sorry, I'm not communicating something clearly.

The density of sample points in the irradiance cache should change - that is correct. As I described in my last post, the idea is that cache points should become more dense as the rate of change of irradiance increases. That is, in areas where irradiance is changing rapidly (e.g. corners of a box room), the cache point density will be high. In areas where irradiance changes slowly, such as the middle of the floor, the cache point density should be low.

In a low-density area, the cached points should be placed with a uniform density but a non-uniform distribution. In other words, you should be getting randomly scattered points that are roughly the same distance away from other sample points, on average, that are in areas of similar density. Obviously as the differential of irradiance increases, the overall density of sample points must increase.


It is important to note that irradiance cache points are not selected randomly. The distribution is controlled primarily by the rate of change of irradiance; that should be your most important decision criteria, with stochastic sample placement as a secondary concern used to eliminate certain types of sampling bias. In other words, you should be focusing on getting the points distributed nicely first, then worry about random jittering of the sample points.

It is obvious that something is wrong, from your screenshot. Consider this example area extracted from the floor region of your image:

Irradiance cache problem

The circled points are wrong samplings. In those areas, the rate of change of irradiance is not locally very fast. In fact, in each circled area, the rate of change of irradiance is basically the same as the rate of change in all the surrounding area. Therefore, you should not be getting clumped sample points. The fact that you have multiple sample points clumping is a problem. Maybe it doesn't have the same cause as the circular "dead zone" artifacts that also occur, but it is very likely related. In any case that incorrect sampling bias needs to be fixed first so we know that your sampling method isn't buggy.

Look again at the reference image you posted - such clumpings do not occur. When sample points are dense, it is only because the local change of irradiance is fast. That is the correct way to sample points for an irradiance cache.

Either the way you are choosing sample points is wrong, or the way you are visualizing the chosen samples is wrong. It's thoroughly possible that the visualization of sample points is the real problem; how are you accomplishing the white dots in the final image? Can you produce a rendering that just shows the sample points and the irradiance data collected for each cache point, against a black background (i.e. no other rendering done)?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hi,

I am dealing with the same problem as you do, except the distribution of irradiance values
in my Cornell Box scene is uniform (ApochPiQ image in previous post).

If you have founded out the solution of the holes in irrad. cache, I would be VERY
grateful to you, if you send it in this discussion.

Thanks in advance.

ps. please, apologize my poor English

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hi,

I am dealing with the same problem as you do, except the distribution of irradiance values
in my Cornell Box scene is uniform (ApochPiQ image in previous post).

If you have founded out the solution of the holes in irrad. cache, I would be VERY
grateful to you, if you send it in this discussion.

Thanks in advance.

ps. please, apologize my poor English

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!