[Bf-cycles] old volumetric patch rebased
kartochka22 at yandex.ru
Tue Dec 13 02:13:47 CET 2011
Hi, I think it doable on GPU side, nothing fancy at all in patch, the
whole patch is around free_fly_distance = -log( 1 - random()) / sigma
formula, and HG importance sampling (another 5 lines of code). There are
no math that can stop to run ot on GPU, except maybe more careful data
alignment, make all floats, etc, but cannot proof it because damn OpenCL
AMD drivers very weak on linux.
Woodcock is very fast and efficient if we prepare max sigma values of 3d
texture at initial stage, put them in coarse low-res 3d acceletation
structure, maybe once per all animation, there are papers that show
near real time medicine 3d data visualisatiuon. Procedural textures are
questionable, maybe marshing will be better. I "push" woodcock in patch
because have trouble with marshing code, many time i spend to figure out
what matter must be accumulated when we goto other cell from physical
point of view, all that probabilitys not easy for me, then i spend some
time to try to analytically solve linear gradient density, got quadratic
equation solve, 3 roots, lot of code, lost interes because it too
complex, and MLT coolness pull me from that. Just like kid with new toy,
jumping from one flasy thing to other. I hope working opencl hardware
will pin me in one place.
About MLT-like algorithms, i stuck at ray generation from lights when
figure out that whole Velch-like bidir scheme (generate light vertex
pool, eye vertex pool, connect each vertex to other) is very stressful
to GPU, too many temporal data and random conditional branches. There
are many ideas, but without test on hardware they are useless. My last
idea is just to little extend current Cycles integrator loop to trace
light ray before main loop, and use that new light vertex as "artifical
extra" sources in direct light code. It must help a lot in scenes where
point or spot -like light source, maybe even small area lights, is close
to volume object boundary (or any other surface).
We all need robust solution with as less tuning knobs as possible, I
going to finish marching code, but no guarantees of course. Maybe for a
moment for Mango project there is more useful to add some fake volume
node that just attenuate color by exp(-dist*sigma) and lerp it with
constant, no shadow volumes but at least to make fog-like senes for no
cost of time. Introduce new input vector, distance from last collision,
or like that.
В Пн., 12/12/2011 в 22:43 +0100, Brecht Van Lommel пишет:
> Basic volume rendering might be a nice target for the next release, do
> you think that is feasible, is this something you want to finish by
> One thing I'm not sure about is using the woodcock algorithm. Being
> unbiased is nice, but it should come at too high a performance cost, a
> basic fixed step size with some randomization to decorrelate the noise
> seems to be more common in render engines?
> On Mon, Dec 12, 2011 at 4:07 PM, storm <kartochka22 at yandex.ru> wrote:
> > Please ignore MTL related property and kernel_mlt.c, it just joke, i am
> > too lazy to comment them out. Patch is snapshot of local current svn.
> > Nothing new, literally, except it rebased to latest Blender svn and
> > Density input now somewhat work, if Homogeneous check not set, you can
> > plug in some 3d procedural texture to play with woodcock algorithm.
> > Warning: woodcock constant hard coded to 0.95, so variable density
> > greater 0.95 do not work.
> > Just to be sure, i repeat: nothing MLT related in this patch, it is my
> > own stupid sandbox random lines of code.
> > Still waiting for new AMD drivers for linux, maybe after that i can do
> > something more useful. Patch work only on CPU if work at all.
> > _______________________________________________
> > 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
More information about the Bf-cycles