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

storm kartochka22 at yandex.ru
Thu Mar 14 03:35:47 CET 2013


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




More information about the Bf-cycles mailing list