Re: [Bf-committers] Volume Rendering Updates
On 27 January 2011 22:59, Matt Ebb m...@mke3.net wrote: First, let me clarify, you are talking about the existing light cache functionality inside blender right, not anything new you've coded? Yes, basically the light cache, but radiance cache is just the proper term, to what it is. I currently have a separate radiance cache for single and multiple scattering and build on top of this some artistic control, like blending between both caches and scaling single and multiple scattering radiance independently in a post process. More advanced radiance caching, as for e.g. in [Jarosz08] would be nice at some point, but also hard to do. I guess the trivial method, which I have implemented is a better starting point for now. 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. Yeah, that was also an issue, why I had no idea how to do this elegant. I guess it really should work for instances, tho it would be possible to just create copies, but then things start to get confusing. 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. Hm, I haven't thought of this, just baking to a texture and then doing volume ray casting without shading. That would work, but I also don't know if it is the best workflow. Another side effect is, that this would only work for the current isotropic radiance cache, but rules out any anisotropic caching, which could be implemented in the future. 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 guess this would be the most practical approach,... so I would just create files per object instance with an auto generated filename in the same directory, as the blendfile. And create those in a baking render pass. 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. That's the main thing I am concerned with. So to keep this consistent, I would need to introduce a new bake mode, volume radiance? And a special bake render pass for volumes, which then shades selected objects, saves the caches to those files and sets a flag in the material/object. I will try to come up with something, after I have finished multiple scattering. aurel ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Volume Rendering Updates
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
Re: [Bf-committers] Volume Rendering Updates
Hi Aurel Regarding baking of radiance cache, have you considered a camara/view independent baking?. A way to implement this is raycasting from ligth sources and not the camera, sice ligth is aditive, for baking with several ligth sources you simply iterates over them. Cheers Farsthary 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
Re: [Bf-committers] Volume Rendering Updates
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
Re: [Bf-committers] Volume Rendering Updates
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
Re: [Bf-committers] Volume Rendering Updates
Hi Aurel, if you can make a patch against current SVN of all completed things I can probably review it within a couple of weeks - perhaps less if it's nicely documented as to what I'm looking at. On Sun, Jan 23, 2011 at 8:39 PM, Aurel W. aure...@gmail.com wrote: Changes which still need work/reimplementation: * sigma_s for an RGB spectrum, currently only sigma_a can by tinted in a weird way This is intentional - since s and a are so closely related (added), it's much simpler for a user to just have one control here - having two colour swatches to tweak that basically do the same thing makes it more difficult to understand how the system works, and what to tweak in order to get a certain visual look, and wouldn't really provide any more helpful artistic functionality. The absorption is also used as the inverse to approximate the resultant colour you get after absorption. This is a lot easier to use as an artist than trying to think about if this colour is absorbed, then what gets left over. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Volume Rendering Updates
Hi Matt, This is intentional - since s and a are so closely related (added), it's much simpler for a user to just have one control here - having two colour swatches to tweak that basically do the same thing makes it more difficult to understand how the system works, and what to tweak in order to get a certain visual look, and wouldn't really provide any more helpful artistic functionality. The absorption is also used as the inverse to approximate the resultant colour you get after absorption. This is a lot easier to use as an artist than trying to think about if this colour is absorbed, then what gets left over. Well, it's certainly a good thing to add some abstraction on top, which makes control easier for an artist. After all, it's not about physical based rendering, but features which give artistic control. But I would really like to have a correct volume ray caster, which solves the RTE correctly for the single scattering case on the bottom of this. There is just one defined way to do this right and someone needs to stick to the basic math of it. I have to look into this, I can't remember exactly what the irregularities in blenders implementation are. But as far as I can remember this ends up in different sigma_a for the three RGB channels, but sigma_s is equal for all channels. Or do I remember incorrectly in this case? There are also a lot of available publications, with measured sigma values in RGB space for all different kind of materials. So I guess it's important to be able set these,... it would also be possible to provide presets. But of course I agree that there is a need of easy artistic control, which the current implementation provides. But as I said it would be possible to come up with nice and easy mappings from values which provide easy control, to the correct RTE parameters. As it is done with absorption at the moment, to reverse this and provide a tinting option. At least I think, this would need some review and maybe work, which I am happy to provide. But this sigma_s and sigma_a issue is just a minor problem for me atm. I can get a patch ready in 1-2 weeks and may also include some stuff which wouldn't be ready or intended at all to be merged, just for review. But I guess in the end it won't be just a one shot (patch-apply) commit, which I have to do. So I understand this rather as a proposal, to commit to the volume renderer for some time. ;) aurel ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Volume Rendering Updates
On Mon, Jan 24, 2011 at 11:51 AM, Aurel W. aure...@gmail.com wrote: I can get a patch ready in 1-2 weeks and may also include some stuff which wouldn't be ready or intended at all to be merged, just for review. It would be better to separate this out. I don't have a lot of time, and would prefer not to be looking through unfinished work during a review - I think that's fair. thanks Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Volume Rendering Updates
It would be better to separate this out. I don't have a lot of time, and would prefer not to be looking through unfinished work during a review - I think that's fair. Ok, i will try to split the patch in several small ones. thanks Matt ___ 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
