[Bf-committers] Volume Rendering Updates

[Matt Ebb]

First, let me clarify, you are talking about the existing light cache
functionality inside blender right, not anything new you've coded?

To be clear, it doesn't just cache per object, it caches independently
per object instance in the render - if you've got multiple instances
you want them to be lit differently. I suppose it may be an acceptable
limitation if you want to bake and save lighting that it doesn't work
with instances, but it's not too elegant.

Currently most volume related things in blender happen on a material
level - aside from the smoke modifier, there's not really any way of
modifying volumes as geometry, or as object data, which would be a lot
better. This also makes it difficult in that the cache data is per
object, but applied on a per material basis. This is fine when it's
all taken care of inside the render, but makes it even more difficult
if you want to save it. It could then introduce even more limitations
- only one object per material, which isn't nice either and is
starting to veer outside blender's current paradigm. These are the
sorts of reasons that this sort of functionality hasn't really been
considered so far.

Some alternatives could be:
a) baking radiance to a format that can be loaded back up in the voxel
data texture and rendered using that. That would at least reduce and
make clearer any non-standard behaviour like not being able to share
materials among objects, since it would then be explicit.
b) perhaps you have an option to bake selected objects, and their
shaded grids get saved to a nominated folder, by name. Once it's
flagged as being baked (perhaps stored in the material), in a
pre-process per frame, the renderer looks in that folder for the right
files per object/objectinstance and loads up the data directly into
each objectinstance's light cache before rendering if the bake files
exist. If they don't exist, the light cache can remain null, and then
either get cached per frame as is done now, or left un-shaded, or
whatever.

I would also recommend that any kind of baking be done consistently
with other types of baking in blender, using the existing render
baking interface. It shouldn't have to introduce yet another
UI/workflow.

Matt


On Fri, Jan 28, 2011 at 1:35 AM, Aurel W. <aurel.w at gmail.com> wrote:
> Another problem I got, I have no good idea, how to add baking of radiance cache.
>
> So basically, the radiance cache, is aligned with the global bounding
> box of one object. For a relative static scene, including light
> sources and a static volume, this radiance cached can be cached or
> baked for several frames. For each frame, simple volume ray casting
> without shading each sample point can then be done, which is of course
> way faster.
>
> For a moving camera relative to the volume, this would currently only
> work with isotropic scattering, because I don't save the angular
> distribution of radiance. When doing multiple scattering, this would
> also be inherently isotropic. Doing this for the anisotropic case
> would be just way more advanced than this simple solution.
>
> For my purpose it was sufficient to just specify two cache files for
> the ms and ss radiance, compute and dump the cache in a binary format,
> when those files weren't in existence and load them, if they weren't.
> But I wonder, how to include this properly,.. should I come up with
> some cache file format, do this with baking, etc?
>
> Currently I also did just one completely normal render pass and dumped
> the radiance cache on the first frame,... but it may be more
> appropriate, when there is some baking option, that I don't do a full
> render, but just compute the radiance cache for selected objects.
>
> aurel
>
> On 24 January 2011 18:32,  <raulf at info.upr.edu.cu> wrote:
>> Hi Aurel :)
>>
>> Improvements are allways wellcome, thanks!
>>
>>> I have written a documentation back then, which is full of other
>>> details of the related project and a more general discussion on volume
>>> rendering. But in the volume rendering section, there should be a good
>>> explanation of my work:
>>> http://atommuell.mum.jku.at/~aurel/VolumeScatteringSimulation.pdf
>>>
>>> Again, it's really not an advanced multiple scattering technique,
>>> actually quite simple stuff. At the end of the document there are also
>>> some more formal tests, which proof the correctness of the single
>>> scattering implementation by comparing it to analytically solved
>>> scenes.
>>
>> I must say, is an excelnt paper, I enjoyed a lot reading it, congrats!
>> the technique may seems simple but is correct so is a nice adition to our
>> model... go for it :)
>>
>> Cheers
>> Farsthary
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>