[Bf-cycles] Volumetric patch update (now with new shiny bidirectional integrator)
storm
kartochka22 at yandex.ru
Thu Mar 14 04:06:54 CET 2013
I do not want to interrupt that scene, and going post final 7+ hour
image as well. Quality better to test using many scenes, i post that
patch only after 20+ local tests and they *looks* same as trunk. And
worse, that complex sceces that usually have some sort of visibility
tricks (mesh emission plain behind window), that by definition will
differ, as i do not support it for light->camera rays yet. Smooth
surfaces will produce artefacts as well (luckily, that kitchen scene
have few smooth surfaces in area where light tracer samples have big
weight, but other will make very visible artefacts). It is not time yet
to wide testing.
В Ср, 13/03/2013 в 19:52 -0700, 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
>
>
>
> _______________________________________________
> 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