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): http://dtc-wsuv.org/jclarke/blender_cycles_mlt_osx64.7z
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
52sec
Mingw64 + ML Patch
58sec (wonder why its slower with MLT?)
any win x64 biuld to share? 
I posted one on page 1 of this thread.
Ooopsā¦ 
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 
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 developer.blender.org 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 developer.blender.org 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
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: http://www.luxrender.net/forum/viewtopic.php?f=13&t=10275
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 
I love to hear it is coming to Cycles!
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 developer.blender.org 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
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
