[Bf-cycles] Volumetric patch update (now with new shiny bidirectional integrator)

[Dalai Felinto]

Hi Storm,

> Bidirectional can do some cool images (posting now Jay Hardy kitchen example
to testing therad on
>
http://blenderartists.org/forum/showthread.php?216866-Cycles-tests-the-new-blender-CPU-GPU-renderer-of-awesomeness&p=2329482&viewfull=1#post2329482

It's hard to tell from the two images whether this compare or surpass trunk
quality/performance.
Can you post the same  file rendered in the same machine but with trunk
instead?

It's nice to see progress in both fronts (volumetric and bi-di) regardless
:)

( btw, I love that kitchen scene, I use it for benchmarks as well
http://goo.gl/DFy98 )

Thanks,
Dalai



blendernetwork.org/member/dalai-felinto
www.dalaifelinto.com


2013/3/13 storm <kartochka22 at yandex.ru>

> Thanks.
>
> Yes, that was plan, but Blender is very big project, one man can barely
> understand every module, from probability theory to compiler graph
> theory and other inverse kinematics, graph black magic, so i deside do
> not burden core developers until patch pass some my own test and then
> wider testing by blender community, only then it can be passed to other
> developer attention.
>
> I am in very beginning state, patch do not pass my own testing, need fix
> 3 bugs at least - final render crasher (so nobody will say "that your
> Blender is crap, it crash immediately as i hit F12 to render defaul
> cube, i go Maya instead and never return" when download new shiny
> ghaphicall build "now with bidirectional volume spectral sampling"),
> Adjoint BSDF (need duplicate and rewrite a bit almost every BSDF to
> respect difference between geometry normal and smooth normal) - lot of
> code, better postpone for late as it affect shaders system, that can be
> changed in core Cycles for some reason, to not do work twice, and ray
> visibility flags, as many scenes have hidden emission plains and other
> tricks.
>
> Only then call for some test build on graphicall, maybe with few example
> scenes to save ppl time changing endless debug checkboxes in integrator
> property panel. Then, after some time (~month?) if get community
> positive answer to question "is it needed at all, maybe better drop it
> and go only Path tracer way?" call for core Blender team support, maybe
> some sort of official branch. Ideally, it must work somehow on GPU,
> maybe in very cutted form, but main MIS paths must work and benchmarked.
>
> The problem is that bidirectoinal thing a bit complicated (although very
> vell described in Veach dissertation, and many pbrt-derived projects
> exist), i suspect that everyone that get how it work tend to run away to
> commercial dark side, and it is better to faster make base that can be
> later expanded by ppl with less knowledge to probability theory, but
> skilled in other related parts (like code optimization or good knowledge
> of GPU internals), but that base at least must produce absolutely
> correct image, and have all math algorithms in place. Now i have almost
> good picture, but terrific "obfscated" by leftower code, and unresolved
> adjoint bsdfs. I must solve it myself to save other time.
>
> In short, current state is volume things guarantee some work with bidir
> off, and only background used as only light. Anything other have issues.
>
> Bidirectional can do some cool images (posting now Jay Hardy kitchen
> example to testing therad on
>
> http://blenderartists.org/forum/showthread.php?216866-Cycles-tests-the-new-blender-CPU-GPU-renderer-of-awesomeness&p=2329482&viewfull=1#post2329482),
> but only one man can set it up and not crash - I am. If you very
> adventurous and lucky, you can make some street light in fog town scene (be
> ready for 2+ hours minimum to start to see some solhoettes of light beams).
>
> В Ср, 13/03/2013 в 21:32 -0400, Matthew Heimlich пишет:
> > Very cool stuff Storm, but without context it's kind of hard to follow
> > what is/isn't working in the current condition of the patch. Do you
> > think you could do another post to the mailing list with a simple list
> > like:
> >
> > Volumes:
> >
> > This works:
> > 1. ...
> > 2. ...
> > 3. ...
> > etc.
> >
> > This doesn't work:
> > 1. ...
> > 2. ...
> > 3. ...
> > etc.
> >
> > BiDirectional:
> >
> > This works:
> >
> > This doesn't work:
> >
> >
> > I think it would be very helpful for sorting out the status of your
> progression.
> >
> > And congrats on crushing an old, annoying bug!
> >
> > Thanks, keep up the good work,
> >
> > Matt Heimlich
> >
> > On Wed, Mar 13, 2013 at 9:10 PM, storm <kartochka22 at yandex.ru> wrote:
> > > It Working !1!1111
> > >
> > > Fixed very stupid off-by-one array index offset in backward pdf
> > > calculation. I must admit, that bug tortured me more then 6 months if
> > > not longer. The problem it affect only paths with 2 and more bounces,
> > > and as energy usually lower it was barely noticeable on test scenes,
> and
> > > i have plenty of theories why sometime color bleeding too bright,
> > > blaming everything, from compiler optimizer up to FPU flaw. Now that
> > > nightmare over and my mind got a chance to stay clear.
> > >
> > > Many scenes converging so fast i cannot believe it possible (comparing
> > > to my old patch ofcourse, not other renderers) that bidirectional MIS
> is
> > > really cool stuff when it work (selected hard areas close to light
> > > covered by complex geometry).
> > >
> > > Also, i found that current algorithm that trying to track volime media
> > > material from light to camera direction is horrible, must to replace it
> > > by something different, so light sources inside object with volume
> media
> > > rendering wrong.
> > >
> > > Another bug is related to skin-like shaders, when "mix" or "add" used
> to
> > > combine other BSDF, then volume density get wrong values (i am think
> > > that random values used to mix clash with value used for distance or
> > > maybe other reason, but fact it completely broken), so only simple like
> > > single glass or transparent work.
> > >
> > > MLT replaced to more interactive approach, now you can set mutations to
> > > insane 25000 and get cool splashy useless pictures. But it force to
> > > single thread model as i do not want to hack deeper in Cycles and
> > > rewrite parts before kernel_integrate() call. I very doubt some one
> even
> > > test it, but must note that change.
> > >
> > > Other known bugs are same as previous patches, only preview window if
> > > light tracing enabled (segfault otherwise), only perspective camera w/o
> > > DoF, only flat triangles guarantee quality if bidirectional used, only
> > > zero size point and emission meshes as light sources (done sime initial
> > > support of spot lights, but it unfinished untested and buggy), no GPU,
> > > no OSL, no ray visibility flags respected for light->camera rays.
> > >
> > > Adjoint BSDF is next big target, as w/o it any surface with
> interpolated
> > > normals will have ugly errors, like flat with some weird gradients. In
> > > addition, I think that it is reason that bump not work for
> light->camera
> > > rays. No smooth surfaces, no bump maps -> unusable for wide testing.
> > >
> > > Short plan: get rid of stupid XXX_compensation constants and other
> debug
> > > leftowers, make code close to Blender coding style.
> > >
> > > _______________________________________________
> > > Bf-cycles mailing list
> > > Bf-cycles at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-cycles
> > >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130313/7e6d4219/attachment.htm