Experimental: Metropolis sampling
Lukasstockner97 is working on Metropolis sampling for Cycles. The code is far from done, but he’s already showing some great results with caustics. Metropolis light transport is a statistical method for determining light paths. In some cases, it can convert to a solution faster than other algorithms.
I recently decided to try adding a Metropolis sampler (no BPT, just the sampler) to Cycles to get some experience with the Cycles code layout, but it turned out working so well that I decided to post it here. Due to some problems, it’s not releasable yet, but these problems (more below) should be not too hard to fix.
The code is based on the SmallLuxGPU metropolis sampler, after I first tried the PBRT code, but that one didn’t seem to work nearly as well.
Basically, it works by bypassing the RNG functions: When they are called and metropolis sampling is selected, they just return a value from a sample array that is stored in the RNG pointer. This allows the sampler to make only minimal changes to the kernel, it even uses the standard kernel_path_integrate. The sampler itself is in the CPUDevice thread.
My current test scene is a simple pool with a modifier-displaced water surface, an absorption volume in the water (works great, by the way), a glass pane on one sine of the water and a Sun-HDR-combination lighting the scene.
I have a few questions. what were the render times on these images? because the caustics that the new algorithm produced are incredible and look like they took a long time to render. will this improvement make physically accurate caustics achievable with a low render time or will we still have to cheat using the fake shadow trick for caustics in animations? at what number of ray samples should we start to see believable caustics in our renders for an average lighting set-up? and when might we see Metropolis sampling implemented into cycles?
Cycles has come a long way in terms of capabilities, performance and render quality and the developers are definitely doing an excellent job improving it every day.
I put quotes around the links, since they weren’t being styled differently from the rest of the text..
——
The “pool scene was rendered in 8 minutes“.
The “caustics scene was rendered in 16 minutes on an i5“.
The render times will mostly depend on your scene (naturally), but note that the
above examples were rendered with older versions of the patch (the
current version is supposed to be considerably faster, but I haven’t
tried it yet)
And it is integrated in cycles, feel free to check
it out (though you will need to compile it yourself or use one of the
“prebuilt versions if you are windows“).
It. Is. Just. Gorgeous!!!
You’ve got me!
When I was 17… ♫
…Well, I wasn’t integrating sampling methods into a rendering engine. Nice work.
(Assuming you are 17, anyways, given your screen name)
LoL, Ironically it has been awhile since I saw someone use their birth year as the ending numbers on their name. Thought I might have been alone in doing that.
Wait…kids born in the 90s are 17 now??? I must be getting old….
Amazing, ain’t it? Time waits for no man. T_T
hmm… 17. who would have guessed.
Absolutely incredible! That looks so good, I wouldn’t have believed it was in Cycles if you hadn’t said so.
I appreciate the inclusion of Metropolis sampling in cycles, very very interesting saw caustic… But maybe not just the render time speed described but also the machine spec… I think its horrible if the render time just took a few seconds but done in a monster render farm………… :D
This is the power of open-source: anyone can make (brilliant) improvements. I love this!
The Lego render looks more realistic than ‘stock’ Cycles. Or am I mistaken?
that’s very interresting, is is supported on cpu (since the code is based on luxsmallgpu and i don’t know really what it means)
Excellent ! More power into Cycles :)
Just WOW, I’ve always have been a little bummed with the current caustics in cycles, after using yafaray and smallluxgpu, I am excited to see this!!