Jump to content
  • Advertisement

B_old

Member
  • Content Count

    767
  • Joined

  • Last visited

Community Reputation

689 Good

About B_old

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm currently looking at the Hosek sky model and experimenting with the provided source code. At the moment the results for arhosekskymodel_radiance() vs arhosekskymodel_solar_radiance() are confusing to me.   Using the spectral arhosekskymodel_radiance() and converting it to RGB gives me:   [attachment=31582:hosek_expected.jpg].   Notice that I manually added in a sun, but it only affects a very small area of the image.   Using arhosekskymodel_solar_radiance() and converting to RGB gives me:   [attachment=31583:hosek_actual.jpg]   In this case the sun is directly provided by the hosek model. The positions match but the color of the sky is completely different. I was expecting the exact same result, expect for the small area where the sun is visible. The bright point of the hosek sun is at the same position as my manually rendered solar disk, but I also get vastly different results for rays that don't directly hit the sun at all.   From looking at the interface I was expecting that I can call arhosekskymodel_solar_radiance() with the exact same parameters as arhosekskymodel_radiance() and it will just work. Is this assumption correct? Does anyone have experience with this model? I don't think it is a matter spectral to RGB conversion, as I use the spectral version of the hosek functions in both cases, so the conversion is identical.    Could it be that arhosekskymodel_solar_radiance() should only be used when rendering the solar disk? But that would mean, that you can render an arbitrarily large sun that don't match the assumptions the hosek model makes.   EDIT: After reading the comments in the code I'm now pretty sure that arhosekskymodel_solar_radiance() should only be used when rendering the solar disk!
  2. Hammersley sequences or the like are a higher level construct than radical inverse functions (in fact the "end product" of the whole algorithm), not a low-level primitive.   I read the paper and don't understand how they combine the routines to get their RDS.  The scrambled part still makes sense to me. func ScrambledHammersley(i, numSamples, r uint32) Vector2 { return MakeVector2(float32(i) / float32(numSamples), ScrambledRadicalInverse_vdC(i, r)) } But apparently they are combining all of the three radical inverse functions to get some result.
  3. In the paper Efficient Multidimensional Sampling the authors describe a technique they call Random Digit Scrambling (RDS). Has someone more implementation details on this algorithm? The paper gives source code for three different radical inverse functions that can be used to implement RDS but I don't understand how they should be applied. I especially don't understand how they jump from Hammersley samples to RDS.  func Hammersley(i, numSamples uint32) Vector2 { return MakeVector2(float32(i) / float32(numSamples), radicalInverse_vdC(i)) } Can the above snippet easily be changed to something that generates RDS?
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!