Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Irradiance Filtering with SH


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 jjtulip   Members   -  Reputation: 148

Like
0Likes
Like

Posted 13 July 2014 - 10:36 AM

Hi!

 

I'm trying to include in my code something like is done here: http://seblagarde.wordpress.com/2012/06/10/amd-cubemapgen-for-physically-based-rendering/ for the irradiance map computation.

Now although my code is a bit different, it strongly resemble what is in the post I linked before. Or at least I think so. 

The problem is that for the cubemap that is there as reference:

 

osuIkWZ.png

 

 

I obtain this result which is both different from the one in the site and also doesn't have the reddish hue that I was expecting: 

 

vqgghgX.png

 

 

I can post the code but is quite a lot. Is there evident what can be wrong? 

 

What I'm doing is:

 

For each face

   for each u,v 

        Compute direction vector for (u,v)

        Get solid angle

        Compute SH terms using  the "Y"s found on Stupid SH Tricks  (

        Use these to project the above said vector in SH     

                            for each u,v 
                                 ....
                               SHTerms = getSHTerms(...);
                               for(int i=0; i<SHTerms.size(); i++){
					projected.at(i) += RGB * SHTerms.at(i) * solidAngle;
				}

        Normalize each of these projected multiplying by 4*pi/sumSolidAngles

Then, with these projected values I get back to the env map using a formula like  projectedValue * SHTerm(i) * band(i) where i loops through the number of SH terms (the "Ys" ) 

 

 

These values are written back to the various cube faces and the result is the one posted above. 

 

 

What can be wrong? Thank you very much. 



Sponsor:

#2 Ohforf sake   Members   -  Reputation: 1832

Like
0Likes
Like

Posted 13 July 2014 - 12:40 PM

Are you using a Hdr version of that cubemap? The filter doesn't work with tonemapped data.

#3 jjtulip   Members   -  Reputation: 148

Like
0Likes
Like

Posted 13 July 2014 - 01:01 PM

Are you using a Hdr version of that cubemap? The filter doesn't work with tonemapped data.

 

No, I'm not using an HDR cubemap, but why it doesn't work? The AMD tool doesn't seem to make such limitations


Edited by jjtulip, 13 July 2014 - 01:12 PM.


#4 Ohforf sake   Members   -  Reputation: 1832

Like
0Likes
Like

Posted 13 July 2014 - 02:36 PM

I don't know about the amd tool, but the source data must be HDR.

#5 MJP   Moderators   -  Reputation: 11573

Like
1Likes
Like

Posted 13 July 2014 - 11:56 PM

Your irradiance calculation is a convolution with a cosine kernel over an entire hemisphere, and it essentially acts a low-pass filtering. So it's not unusual to "blur away" a lot of your details. With an HDR source it's possibly to have portions that are many many times brighter than other parts of the cubemap, which allows for certain features to come through more strongly in the filtered result. You should definitely try with an HDR source and see if you get results more inline with what you expect. 



#6 jjtulip   Members   -  Reputation: 148

Like
0Likes
Like

Posted 14 July 2014 - 03:55 AM

Your irradiance calculation is a convolution with a cosine kernel over an entire hemisphere, and it essentially acts a low-pass filtering. So it's not unusual to "blur away" a lot of your details. With an HDR source it's possibly to have portions that are many many times brighter than other parts of the cubemap, which allows for certain features to come through more strongly in the filtered result. You should definitely try with an HDR source and see if you get results more inline with what you expect. 

 

Thanks! 

Well I tried with an hdr version of the same cubemap the result mantains the reddish hue, but my result is still very different from the one produced with the cubemapgen tool 

 

87TYWaS.png

 

Whereas the one presented in the above article is:

 

skybeamshorder5filter.png

 

Now, the screenshot of my result has been taked from gDebugger so maybe the tonemapping is different (hence the texture is more dark, right?), but still the "shape" of the image is quite different


Edited by jjtulip, 14 July 2014 - 03:57 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS