[Bf-cycles] old volumetric patch rebased

[Kel M]

Hi, I found that if Homogenous volume is enabled, if the camera is
inside the volume, it goes dark. Is this supposed to happen?

On Mon, Dec 12, 2011 at 8:13 PM, storm <kartochka22 at yandex.ru> wrote:
> 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 пишет:
>> Hi,
>>
>> 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
>> then?
>>
>> 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?
>>
>> Thanks,
>> Brecht.
>>
>> 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
>> 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