First Luxrender Windows builds with developed SPPM implementation, get them while hot

You can find them here (with the SPPM version of Luxblend25, requires you to set the renderer to Luxrender SPPM to work properly)
http://www.luxrender.net/forum/viewtopic.php?f=30&t=6085

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.

Lol, so neither you nor the thread you link to expands the sppm acronym… like we all should just know what that means!..

Stochastic Progressive Photon Mapping?

It allows you to use huge numbers of photons with lower RAM usage by dividing them into several passes, then combining them.

Stochastic Progressive Photon Mapping
http://www.luxrender.net/wiki/SPPM

Cool,thanks!

Must try this in the morning!

Well, since he’s doing it…

Mac users: my regular graphicall build now has SPPM support too: http://graphicall.org/78/

Also, if you want super-fresh luxblend25, I just merged the changes dougal2 made to luxblend25 today into the SPPM branch, you can grab a bundle from the mirror here: https://bitbucket.org/luxrender/luxblend25/get/sppm_cpu_only.zip

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).

Ok, have fun everyone. :slight_smile:

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.

this is SPPM? slow as hell

http://img703.imageshack.us/img703/3900/fgjjhgjhgjg.jpg

http://http://imageshack.us/photo/my-images/703/fgjjhgjhgjg.jpg/

Could you please supply some context with that…?

Did you remember your exit portals? I tried to replicate your test scene, here’s 90 seconds w/o portals:
http://img.photobucket.com/albums/v346/Omega_Pirate2/no_portal2.jpg

Here’s 90 seconds with portals:
http://img.photobucket.com/albums/v346/Omega_Pirate2/portal2.jpg

The with-portals version is able to get a result like your scene after about 3 passes (15 seconds or so)

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. :slight_smile:

SPPM should be able to light difficult scenes faster than Bidirectional path tracing with Metropolis Light Transport:

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: http://img.photobucket.com/albums/v346/Omega_Pirate2/portal_halfhour2.jpg

We need to get more builds with this on Graphicall. I don’t see any Windows builds yet.