[Bf-cycles] Volumetric patch update

Brecht Van Lommel brechtvanlommel at pandora.be
Mon Oct 21 18:35:51 CEST 2013

Great progress! Bidir MLT will be great to have eventually, for sure
it's proven to be important for difficult lighting scenarios.


On Mon, Oct 21, 2013 at 7:04 AM, storm <kartochka22 at yandex.ru> wrote:
> Markov Chain Monte Carlo (MCMC) a.k.a Metropolis Light Transport (MLT).
> No BS, it works. Ugliest ever hack to utilise Brecht tile based thread
> scheduler/manager in very perverted way, need to be rewritten ASAP, but
> it can render pictures. Expect wrong overall brightness, i think i
> calculate it wrong.
> If you dare to compile it and even run, try Mutations = 10000, it
> usually work safe.
> Brecht, i tested it a bit, and think it worth further development, as in
> some scenes it really rocks (method of sampling, _not_ my ugly patch).
> To all: it still slower then Cycles and glitching as hell, not worth
> Graphicall, need to rewrite almost all parts from scratch. But at least
> i now understand almost all details and after some hardcore complex
> light scenes tests i am sure it must be finished and included as
> experimental feature, at least on CPU.
> Bigger showstopper for now is proper support of asymmetric BSDF (smooth
> shading normals, bump maps, refraction w/o exit of media), not sure how
> to make it better w/o lot of extra code lines, and proper threading and
> GPU kernel parameters, to make code at least compile on OpenCL/CUDA.
> Also, all old bugs present as only perspective camera, no DOF for direct
> light (caustic from glass ball on floor not respect camera lens DOF),
> visibility booleans (at least to hide mesh light, many scenes use that),
> many other.
> BTW, I turn off many features in kernel_types.h, really need only
> MULTI_CLOSURES, but it seems broken and i need to turn off many other
> unrelated, as HAIR and PROGRESSIVE. It not needed, but problem is i copy
> too many data if MULTI_CLOSURE used in Markov chain mutations, it burn
> CPU like hell, so i just turn it off. Of course i will optimize that
> absurdly big data copied, i doing it as paranoic saving all as i can.
> I think i will post a bit better variant in week or two, that little
> success give some boost. But for now i busy re-rendering all
> collected .blends non stop :)
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles

More information about the Bf-cycles mailing list