Cycles MLT patch

im new with git how do i apply a diff(patch) ?
think i figured it out use (tortoiseGit)

OS X build of patch v14 (hope this build works for everyone):

Does it work with gpu ?

ok… just made a mingw64 build with this patch.
results are not what i was expecting…

AMD 8120 @ 3.2GHZ edit* opps @3.6GHZ
mike pan scene default tiles

Path Tracing(Cycles default)
Dingto’s MLT build with vc2008
4min 5sec

Mingw64 + ML Patch
2min 31sec

default scene MLT default settings

Dingto’s MLT VC2008 build

Mingw64 + ML Patch
58sec (wonder why its slower with MLT?)

any win x64 biuld to share? :wink:

I posted one on page 1 of this thread.

Ooops… :wink:

Thank you!

Okay, now finally my BA account works, so I think I gotta join the thread ^^
First of all, thanks for all the enthusiasm! It’s really great to see that my little project receives such a great reception!

Concerning the patch: Most importantly, don’t forget that it’s still not very stable. It might crash every second (although I don’t hope so), but if it does, please post a bugreport here :smiley:
The other stuff:

  • This is just Metropolis sampling, not MLT. MLT in the strict sense is Metropolis sampling + Bidirectional, and this patch is only the former one.
  • Currently it only runs on the CPU, not on the GPU. Basically, it could be added on GPU too, but it wouldn’t be as effective. The thing is: Metro (I’m just going to call it Metro in this post) works by deciding what to sample next by considering the last sample. GPUs, on the other hand, need very much (read: thousands and up) parallel tasks to do. With normal path tracing, this is quite easy, just distribute the pixels bewteen threads. For Metro to use the GPU, we would need to run thousands of independent samplers, thereby destroying most of the advantages. In fact, this is what is done for multithreading on the CPU, but with 4-8 samplers it’s still fine.
  • Adaptive sampling might work on the GPU, but since my GPU is not Cycles-capable, this will have to wait until I either buy a newer one or someone else does it (If you are interested in doing so, I already got some ideas how it should work).
  • The current patch version screws up volumetrics, apparently another change in master broke it. Of course, I’ll try to fix it.
  • Some render passes (Shadow, Mist and Emission) are currently overridden a debug output (Shadow is sample number, Mist is Variance and Emission is Metropolis-Importance).
  • Darker areas in Metropolis are noisier currently, once i got the Division-By-Mean-Brightness working again, this should get better.
  • The Mist pass is not “noise” or “difficulty”, it is Variance. The adaptive sampling computes difficulty by taking the Square root of Variance (giving RMS error) and dividing it by the TVI value determined from the brightness of the pixel, followed by a 4-pixel blur. This is currently only used internally, but you can get a sense of it by building a setup that does this in the compositor.
  • The Variance is not the remaining error, so even in a perfectly sampled image it will not go to zero.
  • Adaptive sampling will get better once it also considers distribution between tiles. I have two ideas how to solve this, one is to stop tiles once they reach a sampling number proportional to their difficulty, the other one is to choose which tile gets some more samples from its difficulty.
  • Metropolis sampling isn’t useful in every scene, basically is is good where classic PT fails: Caustics, especially light through glass panes, strong indirect lighting (consider the Sintel hair example in the thread, and that was even before the sample-pass breakthrough) and stuff like this. For the classical diffuse cube sitting on a plane, it won’t give superior results.
  • Generally, take a look at the examples in the thread.
  • Preview mode doesn’t work quite right, but Metro isn’t that suited for quick previewing anyways.
  • Do you think it would be useful to add a user-guided adaptive sampling (so that the user marks where more work should be spent)?
  • Adaptive sampling and Metro don’t combine at the moment.
  • The initial tiling issues in Metro are gone, now every threads operates on the whole image.

My next work will be on performance and image-wide adaptive sampling. I already found a change to the sample generation the nearly cuts rendertime in half on the default cube, but 1min for 10samples on the default cube is definitely still inacceptable. Just some quick tip regarding performance: Metro speed is extremely sensitive to bounce count.

I’m already looking forward to more input from you guys, if you have any idea/suggestion, just post it here :smiley:

Question. Does metro only give better or same results? If so, it may be hidden from the artist, as turning it off would be pointless.
I don’t know how it’s currently done in regards to artist control.

For relatively simple scenes, the default PT gives better results than Metro, also due to the fact that it is just faster. Metro is mainly useful for complex ArchViz and stuff like that.

Not really. If nothing else, since mutated samples are not stratified, it can look somewhat worse if the scene has almost nothing metro is good at. Actually, @lukasstockner97, does your patch do QMC yet? If so, what pattern does it use? The regular sobol one? You might find this test I did with Lux interesting:

Also, it requires that all samplers freely roam the image, which isn’t as good for cache coherency as keeping each thread to a small tile at a time. So eliminating the speed hit completely probably isn’t possible.

mm-mm… good old metropolis :slight_smile: I love to hear it is coming to Cycles! :slight_smile:

Exactly, both would complement each other, automatic and manual sampling. The painted mask is a manual step that the algorithm would not be calculating.

Here is a quote of something I wrote about automatic/manual sampling in the mentioned thread:

Not sure of how much automatic this kind of things can be. For instance, if you do an automatic “per object mask”, things like caustics won’t get the appropriate attention. A manual touch with human judgement according to the situation and needs in some cases can improve things better than an algorithm.

For instance, antialias passes and adaptive antialias in Yafaray. That is a great algorithm, and is great to go to sleep, let it work, and wake up with a great render.
But there were times that I stared at a render progress watching a lot of the automatically selected pixels which were a little out of the threshold matematically but looked fine, keep using process power, while I wanted for instance a very reflective rim (blury) to smooth out its noise and the floor to give proper shape to the caustics.
Or times when even by adding more AA passes those pixels never get smoothed enough and stay out of the threshold, so the adaptive AA keeps choosing them for next pass… you know it won’t get any better.

If we could mask those things with criteria like “is enough for this presentation”, or “a client cares about this other part”, or “you don’t fool me, I know you won’t get that part any better”… that kind of things are better left to a human brain/judgement.

Automatic and manual complement each other. Manual control comes handy where the automatic algorithm is not being pragmatic for a specific situation.

Well, J_the_Ninja, guess where I got the idea for it ^^
MCQMC is already in the patch, but for mathematical reasons, you can’t just throw any QMC pattern on it and expect correct results. I’m using the same approach as LuxRender: A cheap MLCG (I use different A and N parameters than Lux, I got them from some paper) that is then shifted by Cranley-Patterson rotation with a changing displacement vector.
Regarding the usermap: Sounds like an awesome idea, but I’m a catastrophical GUI coder, so if someone else could do this, it’d be great. Basically, the importance map is a simple float array that is updated every (by default, you can change it) 25 samples. Basically, the data flow would be: Cycles computes a new importance map -> UI draws it -> multiplies it with the user-defined map or does something else with it -> passes it back to Cycles, which then uses it for rendering.

Very interesting stuff.

I’m wondering what Brecht thinks of this? It’s been there for a month now and I didn’t see reactions of BI officials other than DingTo so far. I really hope there is some guidance going on behind the curtain.

Looking forward to it! Great, but is there have x86 build for Xp? If yes, link, please. I can’t doing by myself as I don’t know build making. Thanks.

Metropolis sampling isn’t useful in every scene, basically is is good where classic PT fails: Caustics, especially light through glass panes, strong indirect lighting (consider the Sintel hair example in the thread, and that was even before the sample-pass breakthrough) and stuff like this. For the classical diffuse cube sitting on a plane, it won’t give superior results.

Ahhh… ok… just ran some more tests…

Kitchen scene with glass windows. 10 samples
Dingto Metro VC2008
2min 47sec

Mingw + Metro
2min 9sec

Lukas has just reported that patch number 15 has solved a major performance bottleneck with the metropolis sampling, now if that issue highlighted by J_theNinja regarding volume sampling is fixed, it will be much closer to the point of testing general image render scenarios.

Keep up the good work Lukas, it would be especially exciting to see this in Blender 2.71, just look at how much better it does indirect lighting according to the Sintel comparison :smiley:

so now i wait for path 15 winndows 7 64bit bbuild ;]
and i can put some big sceens with on cpu i5 take 6H on official build

I love the MLT patch!
(Tested the win64 build by DingTo on the 1st page)

A situation like this was nearly impossible to render before.
Only 100 passes (x8 for Transmission)