I would like to provide runnable version of the current incarnation of my raytracer.
I know it's nothing special, but maybe someone would like to run it, just for fun, I know I would.
Unpack the zip archive and there you have it - double click on reddot.jar or type:
java -jar reddot.jar -Xms1g -Xmx1g
(if you care about the performance it is acutally a lot, lot better if you specify those options from command line, because if not, jvm will get too little memory for photons, and GC will trigger like crazy)
It reads obj files (with its material representation) straight from blender exporter.
But since camera is fixed I didn't provide a gui for importing your own scenes yet.
Image is updated every each 5 seconds.
Moreover, rendering fashion depends on 3 parameters:
- initial radius = (world_max - world_min).length / 50
- photons_per_pass = 100000
- alpha = 0.5
Initial radius just like in regular photon mapping is a tradeoff between smoothness and details. If the initial radius was smaller, the caustic would be sharper from the start, but image would be noiser overall.
Instead of basing it on the world bounding box, I perhaps should base it on bounding box of the photon map. But in this case it's exactly the same.
Photons per pass means how many photons it shoots between ray tracing passes. It doesn't store photons for the first hit, because direct ligting is computed like in regular path tracer.
This is also kind of a tradeoff. In scenes where there is no direct ligting (emitter is not directly visible by the diffuse surfaces) all direct lighting computations (visibility checks mostly) are a waste of time. But in the other case, when surfaces are lit directly, those direct lighting computations helps quite a lot.
And an alpha parameter controls how fast the initial radius shrinks.
Here I attach my 45m render (mobile i7):
Nice demo, I recently played with sppm in LuxRender and I got images that I didn't even dream about no doubt sppm is the way to go when it comes to SDS path. I wonder why is it not so popular among the "unbiased" community...
ReplyDeleteBtw, what technique is optimal for point searching in sppm? And if you don't mind is there a difference between toshiya's sppm and
the one you implemented?
And how would you compare speed of the lux's implementation and my renderer?
ReplyDeleteI think it is not so popular yet because:
1. ppm is relatively a new idea, compared to for ex. bdpt/mlt.
2. it might be a bit harder to code it on gpu
I don't know if sppm is biased from the mathematical stand point. I know the images look okay so? The whole unbiased thing is just a marketing scam to me. Mental ray is biased as shit and nobody cares.
There is a difference in implementation of Toshiya's sppm and mine. He has "just" extended his ppm idea, so it's still a map of hitpoints, where photons add their contribution while shooting. And from time to time it traces new hitpoints to allow for antialiasing/dof/motionblur/brdf sampled phong etc. It does some magic with maintaining correct radius, or something. I didn't dive into it. After implementing his PPM I've tried the other implementation as standard photon mapper and found it much simpler.
That paper I posted a while back is all about differences between the two implementations, while I believe original sppm should be faster, they provide results that both implementations perform the same (but since it is THEIR implementation of sppm, results might be biased).
I'm not sure about acceleration structure for photons. I use uniform grid and it is fine, Toshiya advocates hashgrid which is quite similar thing. While if I recall corectly Jensen in his book says that grids are not that good, and recommends kdtree.
Thanks for the quick reply, you're right about the unbiasedness thing its just silly and the difference between a biased algorithm and an unbiased one is hardly noticeable anyway, so for the people like us who strive for pretty pictures we can simply ignore it.
ReplyDeleteAbout your demo, after playing with it for a while I think it performs the same as lux's sppm. My conclusion is that sppm is only efficient with interior scenes, for outdoors the result is too much blobby and the convergence become very slow.
I'll make a comparison render, wait a sec.
ReplyDeleteHi Michael,
ReplyDeleteHave you ever try to render this scene with a simple path tracer ? It will be interesting to compare the 'caustics' differences :-P
It is a very difficult scene for a PT !!
The equation of radiance estimate becomes unbiased as the radius of photon store reduces at every update. PPM is unbiased for diffuse scenes (including LSDSE ofcourse) but not glossy scenes where an estimate is done. The right words your looking for is "Its consistent".
ReplyDeleteawesome I put-off buying this for months, despite positive reviews.
ReplyDelete