Stochastic Progressive Photon Mapping back
Board: Board index ‹ Ray tracing ‹ !Real time ‹ Off-line
(L) [2009/10/27] [PauloFalcao] [Stochastic Progressive Photon Mapping] Wayback![LINK http://graphics.ucsd.edu/~toshiya/sppm.pdf]
This paper from SIGGRAPH Asia 2009 shows a more efficient algorithm to do photon mapping.
I like it [SMILEY =D>]
(L) [2009/10/28] [snow] [Stochastic Progressive Photon Mapping] Wayback!This is an extension of the previous of the previous in this thread right? [LINK http://ompf.org/forum/viewtopic.php?f=3&t=1071]
Seems like a pretty cool idea. I assume that unbiased photon mapping is a relatively new development then (or this was the first)? Would it be possible to implement a physically based renderer with photon mapping?
(L) [2009/10/28] [graphicsMan69] [Stochastic Progressive Photon Mapping] Wayback!Technically speaking, this is consistent with bounded memory (not unbiased). The paper has a loose proof-ish argument as to it's convergence. Note that an algorithm doesn't have to be unbiased to allow physically based rendering, and this technique does seem pretty promising.
(L) [2009/10/28] [snow] [Stochastic Progressive Photon Mapping] Wayback!>> graphicsMan69 wrote:Technically speaking, this is consistent with bounded memory (not unbiased)
Oh right, I understand.
>> graphicsMan69 wrote:Note that an algorithm doesn't have to be unbiased to allow physically based rendering, and this technique does seem pretty promising
I'm sure the unbiased rendering helps is very useful in this context though [SMILEY :)]. So what else would you need to add to photon mapping to more or less achieve physical accuracy in the sense of Maxwell and Kerkythea? It's mostly about taking into account the (range of?) wavelengths of photons when interacting with participating media right?
(L) [2009/10/28] [PauloFalcao] [Stochastic Progressive Photon Mapping] Wayback!Yes, this is an extencion to [LINK http://ompf.org/forum/viewtopic.php?f=3&t=1071].
The images comparing Bidirectional Path Tracing, Progressive Photon Mapping and Stochastic Progressive Photon Mapping are pretty impressive [SMILEY :D]
(L) [2009/10/28] [graphicsMan69] [Stochastic Progressive Photon Mapping] Wayback!You should be able to get the same image out if both algorithms are run for long enough. It's a matter of implementing those features and letting it go [SMILEY :)]. This is a great improvement over traditional photon mapping where more user intervention is required to get a comparable image. Of course I haven't implemented SPPM, so take what I'm saying with a grain of salt.
(L) [2009/10/29] [thachisu] [Stochastic Progressive Photon Mapping] Wayback!Thank you guys [SMILEY :-)] Speaking of which, I recently implemented SPPM using GLSL.
It is not really optimized, but (almost) everything is running on a GPU.
I am planning to post the source code on my website very soon.
By the way, it is in fact very easy to do naive full spectrum rendering with (S)PPM.
You just need to randomly pick wavelength of each photon and accumulate results
in RGB on eye-ray hit points. Unbiased vs biased is mostly a marketing buzzword IMHO.
(L) [2009/10/29] [fpsunflower] [Stochastic Progressive Photon Mapping] Wayback!One detail that wasn't clear to me from the paper: for motion blur, are photons of time t1 allowed to accumulate into hit points with time t2? Does this cause any artifacts with moving light sources, moving receivers or combinations of these?
For spectral rendering - you still have to do the camera pass bounces using rgb weights don't you?
Nice work by the way! Looking forward to seeing the GLSL demo.
(L) [2009/10/29] [graphicsMan69] [Stochastic Progressive Photon Mapping] Wayback!Camera space bounces could contain full-spectrum binned colors. I have found at least 11 bins evenly distributed over visible wavelengths to be pretty good. Then the photons would accumulate into the correct bin. Alternatively, both passes could pass this type of color around, but it makes techniques like dispersion a bit trickier.
(L) [2009/10/30] [thachisu] [Stochastic Progressive Photon Mapping] Wayback!I posted the GPU demo as well as its source code on my website. It is not well-tested yet (especially on NVIDIA's GPUs), so any bug report is always welcome. It should run on R600, G80 or later.
code & executable: [LINK http://graphics.ucsd.edu/~toshiya/gpusppm.zip]
EDIT: executable is now included in the zip file above.
>> fpsunflower wrote:One detail that wasn't clear to me from the paper: for motion blur, are photons of time t1 allowed to accumulate into hit points with time t2? Does this cause any artifacts with moving light sources, moving receivers or combinations of these?
What I did is sampling single time per pass, so all photons and eye-ray hit points have the same time sample *per pass*. Of course this will cause some artifact rather than noise, but we can just take more passes in SPPM.
>> fpsunflower wrote:For spectral rendering - you still have to do the camera pass bounces using rgb weights don't you?
As graphicsMan69 said, we can do binning on eye-ray hit points. Alternatively, we can pick single wavelength randomly per pass (similar to the motion blur example above) and just accumulate results as RGB assuming linear conversion from spectrum to RGB. I implemented the latter approach and things like dispersion are working at almost (well, we will have colored-noise) no cost. It probably would not be difficult to add this feature to the GPU demo if you are curious [SMILEY :wink:]
(L) [2009/10/30] [fpsunflower] [Stochastic Progressive Photon Mapping] Wayback!Okay - that's what I had assumed. Constant time per pass gives a "strobe" effect as the motion blur accumulates, but I guess it converges eventually. Not sure what the artifact is like for random wavelengths, but I'm sure it all looks ok in the end [SMILEY :)]
I'll be playing with your source now, gotta port it to OS X first ...
(L) [2009/10/30] [fpsunflower] [Stochastic Progressive Photon Mapping] Wayback!Well I get it to work, here are the stats from -DPROFILE in case its of any interest (card is a GeForce GT 120):
Code: [LINK # Select all]photon tracing :9.56245msec
eye ray tracing :8.48673msec
hash precompute :6.99541msec
hash scatter :7.10133msec
hash correction :7.06961msec
progressive update :7.406msec
total :47.4238msec
Thanks for posting the code! It'll be interesting to play around with.
Another question I had - what is your strategy for choosing the initial radius? Pixel footprint measured by ray differentials? What about in SPPM? Do you run a few passes to get a good average footprint to start from? Does it matter at all ?
(L) [2009/10/30] [calamari] [Stochastic Progressive Photon Mapping] Wayback!Thank you very much, thachisu!
Here's a small patch I needed to compile this for Linux:
Code: [LINK # Select all]27,29c27
< # define LINUX
< # include <GL/glx.h>
< # define glGetProcAddress(name) (*glXGetProcAddressARB)((GLubyte*) name)
---
> # define glGetProcAddress(name) (*glXGetProcAddressARB)(name)
93d90
< #ifndef LINUX
95d91
< #endif
734d729
< #ifndef LINUX
736d730
< #endif
(L) [2009/10/30] [toxie] [Stochastic Progressive Photon Mapping] Wayback!>> thachisu wrote:I posted the GPU demo as well as its source code on my website. It is not well-tested yet (especially on NVIDIA's GPUs), so any bug report is always welcome. It should run on R600, G80 or later.
works fine on a quadrofx5800/winxp32.. [SMILEY :)]
(L) [2009/10/30] [Screeb] [Stochastic Progressive Photon Mapping] Wayback!>> toxie wrote:thachisu wrote:I posted the GPU demo as well as its source code on my website. It is not well-tested yet (especially on NVIDIA's GPUs), so any bug report is always welcome. It should run on R600, G80 or later.
works fine on a quadrofx5800/winxp32..
GeForce 9800GTX on Vista x64 works fine too
(L) [2009/10/30] [Guest] [Stochastic Progressive Photon Mapping] Wayback!>> Screeb wrote:toxie wrote:thachisu wrote:I posted the GPU demo as well as its source code on my website. It is not well-tested yet (especially on NVIDIA's GPUs), so any bug report is always welcome. It should run on R600, G80 or later.
works fine on a quadrofx5800/winxp32..
GeForce 9800GTX on Vista x64 works fine too
Works perfectly on Quadro FX 770M/ xp64
(L) [2009/10/30] [thachisu] [Stochastic Progressive Photon Mapping] Wayback!> fpsunflower
The performance seems to be scaling ok [SMILEY :)] The total takes around 200ms on Radeon 2400 HD Pro. Unfortunately, the choice of initial radius does matter in practice, even though it does not affect its convergence property. The demo is using (the size of bounding box of the first hit points) / (image resolution) as a rough estimate of pixel size. Ray differential would be a better solution, but it gets tricky for motion blur and DOF with SPPM.
By the way, which part did you need to change to make it run on OS X? I would like to make the code more portable.
> calamari
Thanks for the patch!
> toxie, Screeb, Guest
Thanks for your reports. It is kind of surprising for me that a GLSL code is portable between NVIDIA and AMD because I used to suffer from a nasty incompatibility issue way back. Maybe it is because AMD's compiler is more strict than NVIDIA's.
(L) [2009/10/30] [oodmb] [Stochastic Progressive Photon Mapping] Wayback!I was looking forward to implementing this without any source available. [SMILEY :cry:]
(L) [2009/10/30] [beason] [Stochastic Progressive Photon Mapping] Wayback!>> oodmb wrote:I was looking forward to implementing this without any source available.
You don't have to refer to it [SMILEY :)]
Plus there was already his (Small) Progressive Photon Mapping source code, here: [LINK http://ompf.org/forum/viewtopic.php?t=1381 smallppm]
(L) [2009/10/30] [oodmb] [Stochastic Progressive Photon Mapping] Wayback!>> You don't have to refer to it
Plus there was already his (Small) Progressive Photon Mapping source code, here: smallppm
oodmb wrote:I was looking forward to implementing this without any source available.
You don't have to refer to it
Plus there was already his (Small) Progressive Photon Mapping source code, here: [LINK http://ompf.org/forum/viewtopic.php?t=1381 smallppm]
You are correct, I don't have to look at it. In fact, I did not look at it while implementing it. However its always nice, in that it gives me a warm feeling inside, to be able to say you implemented something before the code was available. (it also makes proving code originality easier.)
(L) [2009/10/31] [PauloFalcao] [Stochastic Progressive Photon Mapping] Wayback!Works perfectly on MOBILITY RADEON HD 2400 XT! Very nice and fast! [SMILEY :D]
(L) [2009/10/31] [Guest] [Stochastic Progressive Photon Mapping] Wayback!haveing trouble running the demo because i dont have the correct version of GLUT installed -- can you list the recommended dependencies to run the demo please - ive tried 3.4 - 3.7 and im having no luck
(L) [2009/10/31] [fpsunflower] [Stochastic Progressive Photon Mapping] Wayback!>> thachisu wrote:> fpsunflower
By the way, which part did you need to change to make it run on OS X? I would like to make the code more portable.
Diff attached. Apple GL headers contain all those fancy methods by default, so the extension stuff is not needed. The compiler wasn't happy about using glDeleteObjectARB instead of glDeleteProgram since one of them take GLhandleARGB and the other GLuint. I hope that change is correct. Header didn't have GL_RGBA32F either, I had to replace it with GL_RGBA_32F_ARB.
The numbers from clock() might actually be wrong so don't trust those benchmark results I posted before. I haven't fully tracked down the cause yet.
(L) [2009/10/31] [thachisu] [Stochastic Progressive Photon Mapping] Wayback!>> fpsunflower wrote:Diff attached.
Thank you! I will update the code accordingly soon.
> Guest
Just GLUT and OpenGL should be sufficient, and I confirmed that the demo works fine with GLUT 3.7.
Is the error you got really due to GLUT?
EDIT: The error is perhaps due to the dependency on VC runtime DLLs. I recompiled the file with BCC32 so this dependency should be gone now. I also updated the code a little bit.
(L) [2009/10/31] [oodmb] [Stochastic Progressive Photon Mapping] Wayback!I'm sensing this algorithm would benefit from having anywhere there is a large change from have larger initial radii and higher alpha (from my initial tests).
Btw, I tried out the hash map, and I am getting amazing speed ups.
(L) [2009/10/31] [ingenious] [Stochastic Progressive Photon Mapping] Wayback!What hash map are you using? The one from "Low Latency Photon Mapping using Block Hashing" ?
(L) [2009/10/31] [oodmb] [Stochastic Progressive Photon Mapping] Wayback!Nah, the one recommended by thachisu in my previous photon mapping thread:
>> "Optimized Spatial Hashing for Collision Detection of Deformable Objects" [LINK http://www.beosil.com/download/Collisio] ... _VMV03.pdf
But that one most certainly looks interesting, and I'm very thankful for my school's library for giving me access to it.
Note, I have an image rendered using this new method up on my blog now, [LINK http://tlrcam.blogspot.com/] but the convergence speed of the glossy materials was too embarrassing for me to bother showing here (everything else was fully converged after like 5 minutes).
(L) [2009/10/31] [hornet] [Stochastic Progressive Photon Mapping] Wayback!>> oodmb wrote:..and I'm very thankful for my school's library for giving me access to it.
- also available from [LINK http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.18.4166&rep=rep1&type=pdf citeseerx] via (found via scholar.google.com)
(L) [2009/11/03] [beason] [Stochastic Progressive Photon Mapping] Wayback!>> oodmb wrote:Nah, the one recommended by thachisu in my [LINK http://ompf.org/forum/viewtopic.php?p=13851#p13851 previous photon mapping thread]:
link to thread added.
This is interesting. I guess no kd-tree is needed. Will that spatial hashing work well for regular photon mapping also?
(L) [2009/11/04] [thachisu] [Stochastic Progressive Photon Mapping] Wayback!>> beason wrote:This is interesting. I guess no kd-tree is needed. Will that spatial hashing work well for regular photon mapping also?
If we need kNN query, that would be doable in the same way as "Photon Mapping on Programmable Graphics Hardware" by Purcell et al.
[LINK http://graphics.stanford.edu/papers/photongfx/]
They mentioned the idea of using hashed grid in the section 4.4.
# Actually, reading that section reminds me that I should probably add photon-in-grid-cell test to gpusppm.
If we just want to use range query (not kNN query) for radiance estimation, then exactly the same algorithm as in smallppm should work. Another idea would be using a two pass method like "The Beam Radiance Estimate for Volumetric Photon Mapping" by Jarosz et al.; The first pass estimates density of photons using a constant fixed radius, and the second pass rebuilds a spatial hash table with the radii from the first pass and peforms range query afterward.
There is also related work if you are interested in: "Low Latency Photon Mapping Using Block Hashing" by Ma and Mccool.
[LINK http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.4166]
(L) [2009/11/04] [beason] [Stochastic Progressive Photon Mapping] Wayback!Thanks for the info, Toshiya!
(L) [2009/11/12] [beason] [Stochastic Progressive Photon Mapping] Wayback!Worked for me on Win7 64bit / gtx260 after I copied glut32.dll from [LINK http://www.xmission.com/~nate/glut.html]
It's fun to watch it converge. Are there any controls? Thanks a lot for sharing and good work!
(L) [2009/11/12] [thachisu] [Stochastic Progressive Photon Mapping] Wayback!>> beason wrote:Worked for me on Win7 64bit / gtx260 after I copied glut32.dll from [LINK http://www.xmission.com/~nate/glut.html]
It's fun to watch it converge. Are there any controls? Thanks a lot for sharing and good work!
Great! How many photons/sec did you get? On Radeon HD 2400 Pro, I got about 1.36M photons/sec.
There is no GUI control, but you can edit 'raytrace.fs' to change the scene description
while running the executable and reload 'raytrace.fs' by right clicking the window.
(L) [2009/11/13] [beason] [Stochastic Progressive Photon Mapping] Wayback!>> thachisu wrote:Great! How many photons/sec did you get?
5.99 million/sec! I edited raytrace.fs to enable motion blur. Very cool!
(L) [2009/11/14] [thachisu] [Stochastic Progressive Photon Mapping] Wayback!>> beason wrote:thachisu wrote:Great! How many photons/sec did you get?
5.99 million/sec! I edited raytrace.fs to enable motion blur. Very cool!
Thanks! Hmm... it looks like it is not scaling very well. I expected more than 10x difference.
Maybe I should investigate it more when I got an access to a better GPU.
(L) [2009/11/16] [dr_eck] [Stochastic Progressive Photon Mapping] Wayback!I get 3M photons/sec on the Radeon HD 4350 I just bought for $20US. I like it! [SMILEY :D]
(L) [2009/11/19] [oodmb] [Stochastic Progressive Photon Mapping] Wayback!I finally have something moderately worthwhile to post here:
[IMG #1 Image]
I'm getting roughly 7000 samples/ms, although this should be taken lightly as I sample things more times than this is reporting.
There is more info on my blog.
[IMG #1]:
![[IMG:#0]](images/adea83eaf776e66a983f31a287adb6168f8d12cea66f5622aa80ebcf9347c868.png)
(L) [2009/11/19] [toxie] [Stochastic Progressive Photon Mapping] Wayback!and your blog is where? [SMILEY :)]
(L) [2009/11/19] [Guest] [Stochastic Progressive Photon Mapping] Wayback![LINK http://tlrcam.blogspot.com/]
(L) [2009/11/25] [jcosta] [Stochastic Progressive Photon Mapping] Wayback!I get 14.97M photons/sec on my GTX 280 Phenom II BE on Windows 7 64bits.
(L) [2009/11/25] [beason] [Stochastic Progressive Photon Mapping] Wayback!@jcosta
Wow. I must be doing something wrong to be getting 40% your performance with 80% of your video card specs. Are you overclocking? FYI my score was with Q6600 at stock speed.
(L) [2009/11/25] [thachisu] [Stochastic Progressive Photon Mapping] Wayback!I was told that unrolling the loop over spheres inside 'raytrace.fs' improved performance almost x2 on GTX 275. I modified and uploaded the code today, so maybe that is why? If it is somehow due to CPU, I will be [SMILEY :shock:]
EDIT: The only critical change is inside 'raytrace.fs'. This loop
Code: [LINK # Select all]void Intersect(const Ray ray, inout Intersection isect)
{
for (int c = 0; c < 9; c++)
{
shpere_intersect(sphere[c], ray, isect);
}
}
has been unrolled into
Code: [LINK # Select all]void Intersect(const Ray ray, inout Intersection isect)
{
shpere_intersect(sphere[0], ray, isect);
shpere_intersect(sphere[1], ray, isect);
shpere_intersect(sphere[2], ray, isect);
shpere_intersect(sphere[3], ray, isect);
shpere_intersect(sphere[4], ray, isect);
shpere_intersect(sphere[5], ray, isect);
shpere_intersect(sphere[6], ray, isect);
shpere_intersect(sphere[7], ray, isect);
shpere_intersect(sphere[8], ray, isect);
}
I assumed that this kind of loop is appropriately unrolled by a GLSL compiler, but at least this is not the case for NVIDIA's (I will try on AMD's). I did not notice this point, and the full credit is given to Oleg Bisker at UCSD.
(L) [2009/11/25] [jcosta] [Stochastic Progressive Photon Mapping] Wayback!Hi,
@Beason
I didn't overclock neither, cpu or gpu.
My CPU (Phenom II 940 BE) is running at 3Ghz, and the Windows 7 version is the last beta version.
The only thing I did was compile the glut 3.7.6 for my system, with VS 2008. So, I believe that this great difference on performance it is because the new source from toshiya.
@Toshiya
Do you still have the previous source? I can try it too.
(L) [2009/11/25] [toxie] [Stochastic Progressive Photon Mapping] Wayback!>> thachisu wrote:I was told that unrolling the loop over spheres inside 'raytrace.fs' improved performance almost x2 on GTX 275. I modified and uploaded the code today, so maybe that is why? If it is somehow due to CPU, I will be
initial version you posted: 7M/sec
newest version: 15.5M/sec
(on QuadroFX5800)
cool! [SMILEY :)]
(L) [2009/12/07] [beason] [Stochastic Progressive Photon Mapping] Wayback!Initial version: 6 M/s
Latest version: 28 M/s (after 30sec)
Wow, big speed up!
gtx 260 + q6600 + win 7 64-bits
(L) [2009/12/14] [Tonight's special guest] [Stochastic Progressive Photon Mapping] Wayback!impressive!!
(L) [2009/12/16] [SirSmackalot] [Stochastic Progressive Photon Mapping] Wayback!Hi there,
VERY impressive Demo! Workd on almost every Comp i found, but not for mine. Totally crashes on Ati 4890, reset required.
System: Win 7, x64, E6600, 4 GB.
Demo runs for 1 Second, producing 16,5 MP/s. No picture visible, there is just nothing painted. After commenting out 3 lines of code, the demo runs, does not crash, but produces no visible output.
I tried all day to find the problem, but no success. Possibly due to the fact i am new to GLSL.
Maybe someone can help.
Could track down the error to folowing lines: (the commented lines cause the crash).
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, QueryPointSurface);
glUseProgram(PSProgressiveUpdate);
glUniform4fv(glGetUniformLocation(PSProgressiveUpdate, "BufInfo"), 1, BufInfo);
glUniform1f(glGetUniformLocation(PSProgressiveUpdate, "HashNum"), HashNum);
glUniform1f(glGetUniformLocation(PSProgressiveUpdate, "HashScale"), HashScale);
glUniform3fv(glGetUniformLocation(PSProgressiveUpdate, "BBoxMin"), 1, BBMin);
//glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "QueryPositionTexture"), 3);
glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "QueryEmissionPhotonCountTexture"), 5);
glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "QueryFluxRadiusTexture"), 6);
//glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "QueryReflectanceTexture"), 7);
//glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "QueryDirectionTexture"), 2);
glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "HashedPhotonTexture"), 0);
glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "PhotonCorrectionTexture"), 1);
glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "PhotonFluxTexture"), 9);
glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "PhotonPositionTexture"), 10);
glUniform1i(glGetUniformLocation(PSProgressiveUpdate, "PhotonDirectionTexture"), 11);
(L) [2009/12/16] [graphicsMan69] [Stochastic Progressive Photon Mapping] Wayback!Have you tried updating your drivers?
(L) [2009/12/16] [SirSmackalot] [Stochastic Progressive Photon Mapping] Wayback!Hi, i did. Driver:
Catalyst™ Software Suite 9.11
Radeon™ display driver 8.671
(L) [2009/12/17] [patlefort] [Stochastic Progressive Photon Mapping] Wayback!I am getting 35 MP/s on my ASUS Radeon 4870 non overclocked. Unrolling the loop makes no difference for me.
back