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. <aure...@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, <ra...@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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers