I have to say that the SPPM implementation looks developed enough that it would actually enable me to make heavier use of Luxrender, the speed of photon-mapping with the accuracy of bi-directional lighting.
NOTE: Initial passes may show rather inaccurate coloring, but it should get corrected after several passes
NOTE2: Do not panic if Luxrender freezes every now and then, the SPPM algorithm is a CPU-intensive process and thus you may see brief freezes when the pass is done.
Or just hg up sppm_cpu_only if you keep a local luxblend25 repo
Remember that you must set BOTH the renderer and surface integrator to SPPM to get it work. (luxblend25 won’t export it otherwise).
Oh, and just to contain the excitement a bit: this almost certainly won’t be in the initial 0.8 release, it’ll probably be held over until 0.9 to finish polishing it. It’s not GPU accelerated at the moment, but that is planned in the future. This is based of the implementation of SPPM in smalluxgpu, so adding the GPU acceleration shouldn’t be too much of a big deal, I don’t think. (I don’t actually code that part though).
Hi all. I would like to reiterate what J_the_Ninja said. This is NOT an official weekly build. It has been posted so others can have fun with it too. SPPM is not complete, and will NOT ship with 0.8.
Hmmm, I’ve been trying to use SPPM on a scene of mine which I do understand can be a difficult situation for photorealistic renderers. (involving a complex glass mesh)
I’m still getting a few fireflies not entirely unlike the ones I get with Bi-directional lighting, only these are round, I also get some initial shading artifacts as well and notice that a few more may pop up overtime. Until any remaining shading and firefly problems are dealt with, we have Cycles.
Unfortunately, seems to feature the same issue as with all biased techniques. Namely, as the user images show, that it’s difficult to set up the right parameters, so there’s a lot of crying around… BTW, kids, the above is a nice scene to put Cycles under some stress…
No, that’s the nice thing about SPPM: it’ll aways converge eventually, it might just be slow if you set it wrong. And there are much fewer parameters than regular photon mapping. No final gather or photon counts or irradiance caches to deal with. The portals thing is a really common mistake, I think everyone who works with unbiased renderers has done it at some point.
And yes, SPPM does seem to still have at least 1 artifact sneaking around, it leaves weird edges on the default cube (+ground plane) for me. Dade (the guy writing most of this) said something along those lines…
EDIT: left the above render to cook while I was working out, this is after about 32 minutes of rendering:
