Files
test/source/blender/render/intern/source/volume_precache.c

833 lines
22 KiB
C
Raw Normal View History

/**
*
* ***** BEGIN GPL LICENSE BLOCK *****
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): Matt Ebb, Ra˙l Fern·ndez Hern·ndez (Farsthary).
*
* ***** END GPL LICENSE BLOCK *****
*/
#include <math.h>
#include <stdlib.h>
#include <string.h>
#include <float.h>
#include "MEM_guardedalloc.h"
#include "BLI_blenlib.h"
#include "BLI_math.h"
#include "BLI_threads.h"
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
#include "BLI_voxel.h"
#include "BLI_utildefines.h"
#include "PIL_time.h"
#include "RE_shader_ext.h"
#include "RE_raytrace.h"
#include "DNA_material_types.h"
#include "render_types.h"
#include "rendercore.h"
#include "renderdatabase.h"
#include "volumetric.h"
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
#include "volume_precache.h"
#if defined( _MSC_VER ) && !defined( __cplusplus )
# define inline __inline
#endif // defined( _MSC_VER ) && !defined( __cplusplus )
#include "BKE_global.h"
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
/* defined in pipeline.c, is hardcopy of active dynamic allocated Render */
/* only to be used here in this file, it's for speed */
extern struct Render R;
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
/* *** utility code to set up an individual raytree for objectinstance, for checking inside/outside *** */
/* Recursive test for intersections, from a point inside the mesh, to outside
* Number of intersections (depth) determine if a point is inside or outside the mesh */
int intersect_outside_volume(RayObject *tree, Isect *isect, float *offset, int limit, int depth)
{
if (limit == 0) return depth;
if (RE_rayobject_raycast(tree, isect)) {
2009-10-07 12:17:29 +00:00
isect->start[0] = isect->start[0] + isect->labda*isect->vec[0];
isect->start[1] = isect->start[1] + isect->labda*isect->vec[1];
isect->start[2] = isect->start[2] + isect->labda*isect->vec[2];
isect->labda = FLT_MAX;
isect->skip = RE_SKIP_VLR_NEIGHBOUR;
isect->orig.face= isect->hit.face;
isect->orig.ob= isect->hit.ob;
return intersect_outside_volume(tree, isect, offset, limit-1, depth+1);
} else {
return depth;
}
}
/* Uses ray tracing to check if a point is inside or outside an ObjectInstanceRen */
int point_inside_obi(RayObject *tree, ObjectInstanceRen *UNUSED(obi), float *co)
{
Isect isect= {{0}};
float vec[3] = {0.0f,0.0f,1.0f};
int final_depth=0, depth=0, limit=20;
/* set up the isect */
VECCOPY(isect.start, co);
VECCOPY(isect.vec, vec);
isect.mode= RE_RAY_MIRROR;
isect.last_hit= NULL;
isect.lay= -1;
2009-10-07 12:17:29 +00:00
isect.labda = FLT_MAX;
isect.orig.face= NULL;
isect.orig.ob = NULL;
final_depth = intersect_outside_volume(tree, &isect, vec, limit, depth);
/* even number of intersections: point is outside
* odd number: point is inside */
if (final_depth % 2 == 0) return 0;
else return 1;
}
/* find the bounding box of an objectinstance in global space */
void global_bounds_obi(Render *re, ObjectInstanceRen *obi, float *bbmin, float *bbmax)
{
ObjectRen *obr = obi->obr;
VolumePrecache *vp = obi->volume_precache;
VertRen *ver= NULL;
float co[3];
int a;
if (vp->bbmin != NULL && vp->bbmax != NULL) {
copy_v3_v3(bbmin, vp->bbmin);
copy_v3_v3(bbmax, vp->bbmax);
return;
}
vp->bbmin = MEM_callocN(sizeof(float)*3, "volume precache min boundbox corner");
vp->bbmax = MEM_callocN(sizeof(float)*3, "volume precache max boundbox corner");
INIT_MINMAX(bbmin, bbmax);
for(a=0; a<obr->totvert; a++) {
if((a & 255)==0) ver= obr->vertnodes[a>>8].vert;
else ver++;
copy_v3_v3(co, ver->co);
/* transformed object instance in camera space */
if(obi->flag & R_TRANSFORMED)
mul_m4_v3(obi->mat, co);
/* convert to global space */
mul_m4_v3(re->viewinv, co);
DO_MINMAX(co, vp->bbmin, vp->bbmax);
}
copy_v3_v3(bbmin, vp->bbmin);
copy_v3_v3(bbmax, vp->bbmax);
}
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
/* *** light cache filtering *** */
static float get_avg_surrounds(float *cache, int *res, int xx, int yy, int zz)
{
int x, y, z, x_, y_, z_;
int added=0;
float tot=0.0f;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (z=-1; z <= 1; z++) {
z_ = zz+z;
if (z_ >= 0 && z_ <= res[2]-1) {
for (y=-1; y <= 1; y++) {
y_ = yy+y;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
if (y_ >= 0 && y_ <= res[1]-1) {
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (x=-1; x <= 1; x++) {
x_ = xx+x;
if (x_ >= 0 && x_ <= res[0]-1) {
const int i= V_I(x_, y_, z_, res);
if (cache[i] > 0.0f) {
tot += cache[i];
added++;
}
}
}
}
}
}
}
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
if (added > 0) tot /= added;
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
return tot;
}
/* function to filter the edges of the light cache, where there was no volume originally.
* For each voxel which was originally external to the mesh, it finds the average values of
* the surrounding internal voxels and sets the original external voxel to that average amount.
* Works almost a bit like a 'dilate' filter */
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
static void lightcache_filter(VolumePrecache *vp)
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
int x, y, z;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (z=0; z < vp->res[2]; z++) {
for (y=0; y < vp->res[1]; y++) {
for (x=0; x < vp->res[0]; x++) {
/* trigger for outside mesh */
const int i= V_I(x, y, z, vp->res);
if (vp->data_r[i] < -0.f)
vp->data_r[i] = get_avg_surrounds(vp->data_r, vp->res, x, y, z);
if (vp->data_g[i] < -0.f)
vp->data_g[i] = get_avg_surrounds(vp->data_g, vp->res, x, y, z);
if (vp->data_b[i] < -0.f)
vp->data_b[i] = get_avg_surrounds(vp->data_b, vp->res, x, y, z);
}
}
}
}
#if 0
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
static void lightcache_filter2(VolumePrecache *vp)
{
int x, y, z;
float *new_r, *new_g, *new_b;
int field_size = vp->res[0]*vp->res[1]*vp->res[2]*sizeof(float);
new_r = MEM_mallocN(field_size, "temp buffer for light cache filter r channel");
new_g = MEM_mallocN(field_size, "temp buffer for light cache filter g channel");
new_b = MEM_mallocN(field_size, "temp buffer for light cache filter b channel");
memcpy(new_r, vp->data_r, field_size);
memcpy(new_g, vp->data_g, field_size);
memcpy(new_b, vp->data_b, field_size);
for (z=0; z < vp->res[2]; z++) {
for (y=0; y < vp->res[1]; y++) {
for (x=0; x < vp->res[0]; x++) {
/* trigger for outside mesh */
const int i= V_I(x, y, z, vp->res);
if (vp->data_r[i] < -0.f)
new_r[i] = get_avg_surrounds(vp->data_r, vp->res, x, y, z);
if (vp->data_g[i] < -0.f)
new_g[i] = get_avg_surrounds(vp->data_g, vp->res, x, y, z);
if (vp->data_b[i] < -0.f)
new_b[i] = get_avg_surrounds(vp->data_b, vp->res, x, y, z);
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
}
}
}
SWAP(float *, vp->data_r, new_r);
SWAP(float *, vp->data_g, new_g);
SWAP(float *, vp->data_b, new_b);
if (new_r) { MEM_freeN(new_r); new_r=NULL; }
if (new_g) { MEM_freeN(new_g); new_g=NULL; }
if (new_b) { MEM_freeN(new_b); new_b=NULL; }
}
#endif
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
static inline int ms_I(int x, int y, int z, int *n) //has a pad of 1 voxel surrounding the core for boundary simulation
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
/* different ordering to light cache */
return x*(n[1]+2)*(n[2]+2) + y*(n[2]+2) + z;
}
static inline int v_I_pad(int x, int y, int z, int *n) //has a pad of 1 voxel surrounding the core for boundary simulation
{
/* same ordering to light cache, with padding */
return z*(n[1]+2)*(n[0]+2) + y*(n[0]+2) + x;
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
}
static inline int lc_to_ms_I(int x, int y, int z, int *n)
{
/* converting light cache index to multiple scattering index */
return (x-1)*(n[1]*n[2]) + (y-1)*(n[2]) + z-1;
}
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
/* *** multiple scattering approximation *** */
/* get the total amount of light energy in the light cache. used to normalise after multiple scattering */
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
static float total_ss_energy(VolumePrecache *vp)
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
int x, y, z;
int *res = vp->res;
float energy=0.f;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (z=0; z < res[2]; z++) {
for (y=0; y < res[1]; y++) {
for (x=0; x < res[0]; x++) {
const int i=V_I(x, y, z, res);
if (vp->data_r[i] > 0.f) energy += vp->data_r[i];
if (vp->data_g[i] > 0.f) energy += vp->data_g[i];
if (vp->data_b[i] > 0.f) energy += vp->data_b[i];
}
}
}
return energy;
}
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
static float total_ms_energy(float *sr, float *sg, float *sb, int *res)
{
int x, y, z;
float energy=0.f;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (z=1;z<=res[2];z++) {
for (y=1;y<=res[1];y++) {
for (x=1;x<=res[0];x++) {
const int i = ms_I(x,y,z,res);
if (sr[i] > 0.f) energy += sr[i];
if (sg[i] > 0.f) energy += sg[i];
if (sb[i] > 0.f) energy += sb[i];
}
}
}
return energy;
}
static void ms_diffuse(float *x0, float *x, float diff, int *n) //n is the unpadded resolution
{
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
int i, j, k, l;
const float dt = VOL_MS_TIMESTEP;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
const float a = dt*diff*n[0]*n[1]*n[2];
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
for (l=0; l<20; l++)
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (k=1; k<=n[2]; k++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (j=1; j<=n[1]; j++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (i=1; i<=n[0]; i++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
x[v_I_pad(i,j,k,n)] = (x0[v_I_pad(i,j,k,n)]) + a*( x0[v_I_pad(i-1,j,k,n)]+ x0[v_I_pad(i+1,j,k,n)]+ x0[v_I_pad(i,j-1,k,n)]+
x0[v_I_pad(i,j+1,k,n)]+ x0[v_I_pad(i,j,k-1,n)]+x0[v_I_pad(i,j,k+1,n)]
) / (1+6*a);
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
}
}
}
}
}
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
void multiple_scattering_diffusion(Render *re, VolumePrecache *vp, Material *ma)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
const float diff = ma->vol.ms_diff * 0.001f; /* compensate for scaling for a nicer UI range */
const int simframes = (int)(ma->vol.ms_spread * (float)MAX3(vp->res[0], vp->res[1], vp->res[2]));
const int shade_type = ma->vol.shade_type;
float fac = ma->vol.ms_intensity;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
int x, y, z, m;
int *n = vp->res;
const int size = (n[0]+2)*(n[1]+2)*(n[2]+2);
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
double time, lasttime= PIL_check_seconds_timer();
float total;
float c=1.0f;
float origf; /* factor for blending in original light cache */
float energy_ss, energy_ms;
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
float *sr0=(float *)MEM_callocN(size*sizeof(float), "temporary multiple scattering buffer");
float *sr=(float *)MEM_callocN(size*sizeof(float), "temporary multiple scattering buffer");
float *sg0=(float *)MEM_callocN(size*sizeof(float), "temporary multiple scattering buffer");
float *sg=(float *)MEM_callocN(size*sizeof(float), "temporary multiple scattering buffer");
float *sb0=(float *)MEM_callocN(size*sizeof(float), "temporary multiple scattering buffer");
float *sb=(float *)MEM_callocN(size*sizeof(float), "temporary multiple scattering buffer");
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
total = (float)(n[0]*n[1]*n[2]*simframes);
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
energy_ss = total_ss_energy(vp);
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
/* Scattering as diffusion pass */
for (m=0; m<simframes; m++)
{
/* add sources */
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (z=1; z<=n[2]; z++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (y=1; y<=n[1]; y++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (x=1; x<=n[0]; x++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
const int i = lc_to_ms_I(x, y ,z, n); //lc index
const int j = ms_I(x, y, z, n); //ms index
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
time= PIL_check_seconds_timer();
c++;
if (vp->data_r[i] > 0.0f)
sr[j] += vp->data_r[i];
if (vp->data_g[i] > 0.0f)
sg[j] += vp->data_g[i];
if (vp->data_b[i] > 0.0f)
sb[j] += vp->data_b[i];
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
/* Displays progress every second */
if(time-lasttime>1.0f) {
char str[64];
sprintf(str, "Simulating multiple scattering: %d%%", (int)(100.0f * (c / total)));
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
re->i.infostr= str;
re->stats_draw(re->sdh, &re->i);
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
re->i.infostr= NULL;
lasttime= time;
}
}
}
}
SWAP(float *,sr,sr0);
SWAP(float *,sg,sg0);
SWAP(float *,sb,sb0);
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
/* main diffusion simulation */
ms_diffuse(sr0, sr, diff, n);
ms_diffuse(sg0, sg, diff, n);
ms_diffuse(sb0, sb, diff, n);
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
if (re->test_break(re->tbh)) break;
}
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
/* normalisation factor to conserve energy */
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
energy_ms = total_ms_energy(sr, sg, sb, n);
fac *= (energy_ss / energy_ms);
/* blend multiple scattering back in the light cache */
if (shade_type == MA_VOL_SHADE_SHADEDPLUSMULTIPLE) {
/* conserve energy - half single, half multiple */
origf = 0.5f;
fac *= 0.5f;
} else {
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
origf = 0.0f;
}
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (z=1;z<=n[2];z++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (y=1;y<=n[1];y++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (x=1;x<=n[0];x++)
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
const int i = lc_to_ms_I(x, y ,z, n); //lc index
const int j = ms_I(x, y, z, n); //ms index
vp->data_r[i] = origf * vp->data_r[i] + fac * sr[j];
vp->data_g[i] = origf * vp->data_g[i] + fac * sg[j];
vp->data_b[i] = origf * vp->data_b[i] + fac * sb[j];
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
}
}
}
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
MEM_freeN(sr0);
MEM_freeN(sr);
MEM_freeN(sg0);
MEM_freeN(sg);
MEM_freeN(sb0);
MEM_freeN(sb);
}
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
#if 0 // debug stuff
static void *vol_precache_part_test(void *data)
{
VolPrecachePart *pa = data;
printf("part number: %d \n", pa->num);
printf("done: %d \n", pa->done);
printf("x min: %d x max: %d \n", pa->minx, pa->maxx);
printf("y min: %d y max: %d \n", pa->miny, pa->maxy);
printf("z min: %d z max: %d \n", pa->minz, pa->maxz);
return NULL;
}
#endif
/* Iterate over the 3d voxel grid, and fill the voxels with scattering information
*
* It's stored in memory as 3 big float grids next to each other, one for each RGB channel.
* I'm guessing the memory alignment may work out better this way for the purposes
* of doing linear interpolation, but I haven't actually tested this theory! :)
*/
static void *vol_precache_part(void *data)
{
VolPrecachePart *pa = (VolPrecachePart *)data;
ObjectInstanceRen *obi = pa->obi;
RayObject *tree = pa->tree;
ShadeInput *shi = pa->shi;
Rework of volume shading After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through. Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use. There's more detailed information and example images here: http://wiki.blender.org/index.php/User:Broken/VolumeRendering Also did some tweaks/optimisation: * Removed shading step size (was a bit annoying, if it comes back, it will be in a different form) * Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...) * Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly * Enabled voxeldata texture in preview render * Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff) More revisions to come later...
2009-09-29 22:01:32 +00:00
float scatter_col[3] = {0.f, 0.f, 0.f};
float co[3], cco[3];
int x, y, z, i;
int res[3];
res[0]= pa->res[0];
res[1]= pa->res[1];
res[2]= pa->res[2];
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (z= pa->minz; z < pa->maxz; z++) {
co[2] = pa->bbmin[2] + (pa->voxel[2] * (z + 0.5f));
for (y= pa->miny; y < pa->maxy; y++) {
co[1] = pa->bbmin[1] + (pa->voxel[1] * (y + 0.5f));
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
for (x=pa->minx; x < pa->maxx; x++) {
co[0] = pa->bbmin[0] + (pa->voxel[0] * (x + 0.5f));
/* convert from world->camera space for shading */
mul_v3_m4v3(cco, pa->viewmat, co);
i= V_I(x, y, z, res);
// don't bother if the point is not inside the volume mesh
if (!point_inside_obi(tree, obi, cco)) {
obi->volume_precache->data_r[i] = -1.0f;
obi->volume_precache->data_g[i] = -1.0f;
obi->volume_precache->data_b[i] = -1.0f;
continue;
}
/* this view coordinate is very wrong! */
copy_v3_v3(shi->view, cco);
normalize_v3(shi->view);
vol_get_scattering(shi, scatter_col, cco);
obi->volume_precache->data_r[i] = scatter_col[0];
obi->volume_precache->data_g[i] = scatter_col[1];
obi->volume_precache->data_b[i] = scatter_col[2];
}
}
}
pa->done = 1;
return 0;
}
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
static void precache_setup_shadeinput(Render *re, ObjectInstanceRen *obi, Material *ma, ShadeInput *shi)
{
memset(shi, 0, sizeof(ShadeInput));
shi->depth= 1;
shi->mask= 1;
shi->mat = ma;
shi->vlr = NULL;
memcpy(&shi->r, &shi->mat->r, 23*sizeof(float)); // note, keep this synced with render_types.h
shi->har= shi->mat->har;
shi->obi= obi;
shi->obr= obi->obr;
shi->lay = re->lay;
}
static void precache_init_parts(Render *re, RayObject *tree, ShadeInput *shi, ObjectInstanceRen *obi, int totthread, int *parts)
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
VolumePrecache *vp = obi->volume_precache;
int i=0, x, y, z;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
float voxel[3];
int sizex, sizey, sizez;
float bbmin[3], bbmax[3];
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
int *res;
int minx, maxx;
int miny, maxy;
int minz, maxz;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
if (!vp) return;
BLI_freelistN(&re->volume_precache_parts);
/* currently we just subdivide the box, number of threads per side */
parts[0] = parts[1] = parts[2] = totthread;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
res = vp->res;
/* using boundbox in worldspace */
global_bounds_obi(re, obi, bbmin, bbmax);
sub_v3_v3v3(voxel, bbmax, bbmin);
voxel[0] /= (float)res[0];
voxel[1] /= (float)res[1];
voxel[2] /= (float)res[2];
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
for (x=0; x < parts[0]; x++) {
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
sizex = ceil(res[0] / (float)parts[0]);
minx = x * sizex;
maxx = minx + sizex;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
maxx = (maxx>res[0])?res[0]:maxx;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
for (y=0; y < parts[1]; y++) {
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
sizey = ceil(res[1] / (float)parts[1]);
miny = y * sizey;
maxy = miny + sizey;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
maxy = (maxy>res[1])?res[1]:maxy;
for (z=0; z < parts[2]; z++) {
VolPrecachePart *pa= MEM_callocN(sizeof(VolPrecachePart), "new precache part");
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
sizez = ceil(res[2] / (float)parts[2]);
minz = z * sizez;
maxz = minz + sizez;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
maxz = (maxz>res[2])?res[2]:maxz;
pa->done = 0;
pa->working = 0;
pa->num = i;
pa->tree = tree;
pa->shi = shi;
pa->obi = obi;
copy_m4_m4(pa->viewmat, re->viewmat);
copy_v3_v3(pa->bbmin, bbmin);
copy_v3_v3(pa->voxel, voxel);
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
VECCOPY(pa->res, res);
pa->minx = minx; pa->maxx = maxx;
pa->miny = miny; pa->maxy = maxy;
pa->minz = minz; pa->maxz = maxz;
BLI_addtail(&re->volume_precache_parts, pa);
i++;
}
}
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
}
}
static VolPrecachePart *precache_get_new_part(Render *re)
{
VolPrecachePart *pa, *nextpa=NULL;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
for (pa = re->volume_precache_parts.first; pa; pa=pa->next)
{
if (pa->done==0 && pa->working==0) {
nextpa = pa;
break;
}
}
return nextpa;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
}
/* calculate resolution from bounding box in world space */
static int precache_resolution(Render *re, VolumePrecache *vp, ObjectInstanceRen *obi, int res)
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
{
float dim[3], div;
float bbmin[3], bbmax[3];
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
/* bound box in global space */
global_bounds_obi(re, obi, bbmin, bbmax);
sub_v3_v3v3(dim, bbmax, bbmin);
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
div = MAX3(dim[0], dim[1], dim[2]);
dim[0] /= div;
dim[1] /= div;
dim[2] /= div;
vp->res[0] = ceil(dim[0] * res);
vp->res[1] = ceil(dim[1] * res);
vp->res[2] = ceil(dim[2] * res);
if ((vp->res[0] < 1) || (vp->res[1] < 1) || (vp->res[2] < 1))
return 0;
return 1;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
}
/* Precache a volume into a 3D voxel grid.
* The voxel grid is stored in the ObjectInstanceRen,
* in camera space, aligned with the ObjectRen's bounding box.
* Resolution is defined by the user.
*/
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
void vol_precache_objectinstance_threads(Render *re, ObjectInstanceRen *obi, Material *ma)
{
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
VolumePrecache *vp;
VolPrecachePart *nextpa, *pa;
RayObject *tree;
ShadeInput shi;
ListBase threads;
int parts[3] = {1, 1, 1}, totparts;
int caching=1, counter=0;
int totthread = re->r.threads;
double time, lasttime= PIL_check_seconds_timer();
R = *re;
/* create a raytree with just the faces of the instanced ObjectRen,
* used for checking if the cached point is inside or outside. */
tree = makeraytree_object(&R, obi);
if (!tree) return;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
vp = MEM_callocN(sizeof(VolumePrecache), "volume light cache");
obi->volume_precache = vp;
if (!precache_resolution(re, vp, obi, ma->vol.precache_resolution)) {
MEM_freeN(vp);
vp = NULL;
return;
}
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
vp->data_r = MEM_callocN(sizeof(float)*vp->res[0]*vp->res[1]*vp->res[2], "volume light cache data red channel");
vp->data_g = MEM_callocN(sizeof(float)*vp->res[0]*vp->res[1]*vp->res[2], "volume light cache data green channel");
vp->data_b = MEM_callocN(sizeof(float)*vp->res[0]*vp->res[1]*vp->res[2], "volume light cache data blue channel");
if (vp->data_r==0 || vp->data_g==0 || vp->data_b==0) {
MEM_freeN(vp);
vp = NULL;
return;
}
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
/* Need a shadeinput to calculate scattering */
precache_setup_shadeinput(re, obi, ma, &shi);
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
precache_init_parts(re, tree, &shi, obi, totthread, parts);
totparts = parts[0] * parts[1] * parts[2];
BLI_init_threads(&threads, vol_precache_part, totthread);
while(caching) {
if(BLI_available_threads(&threads) && !(re->test_break(re->tbh))) {
nextpa = precache_get_new_part(re);
if (nextpa) {
nextpa->working = 1;
BLI_insert_thread(&threads, nextpa);
}
}
else PIL_sleep_ms(50);
caching=0;
counter=0;
for(pa= re->volume_precache_parts.first; pa; pa= pa->next) {
if(pa->done) {
counter++;
BLI_remove_thread(&threads, pa);
} else
caching = 1;
}
if (re->test_break(re->tbh) && BLI_available_threads(&threads)==totthread)
caching=0;
time= PIL_check_seconds_timer();
if(time-lasttime>1.0f) {
char str[64];
sprintf(str, "Precaching volume: %d%%", (int)(100.0f * ((float)counter / (float)totparts)));
re->i.infostr= str;
re->stats_draw(re->sdh, &re->i);
re->i.infostr= NULL;
lasttime= time;
}
}
BLI_end_threads(&threads);
BLI_freelistN(&re->volume_precache_parts);
if(tree) {
//TODO: makeraytree_object creates a tree and saves it on OBI, if we free this tree we should also clear other pointers to it
//RE_rayobject_free(tree);
//tree= NULL;
}
if (ELEM(ma->vol.shade_type, MA_VOL_SHADE_MULTIPLE, MA_VOL_SHADE_SHADEDPLUSMULTIPLE))
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
{
/* this should be before the filtering */
multiple_scattering_diffusion(re, obi->volume_precache, ma);
Volume rendering: multiple scattering This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for multiple scattering within volumes. Thanks, Raul! Where single scattering considers the path from the light to a point in the volume, and to the eye, multiple scattering approximates the interactions of light as it bounces around randomly within the volume, before eventually reaching the eye. It works as a diffusion process that effectively blurs the lighting information that's already stored within the light cache. A cloudy sky setup, with single scattering, and multiple scattering: http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpg http://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for later), that lets you choose between self-shading methods: * None: No attenuation of the light source by the volume - light passes straight through at full strength * Single Scattering: (same as previously, with 'self-shading' enabled) * Multiple Scattering: Uses multiple scattering only for shading information * Single + Multiple: Adds the multiple scattering lighting on top of the existing single scattered light - this can be useful to tweak the strength of the effect, while still retaining details in the lighting. An example of how the different scattering methods affect the visual result: http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpg http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend The multiple scattering methods introduce 3 new controls when enabled: * Blur: A factor blending between fully diffuse/blurred lighting, and sharper * Spread: The range that the diffuse blurred lighting spreads over - similar to a blur width. The higher the spread, the slower the processing time. * Intensity: A multiplier for the multiple scattering light brightness Here's the effect of multiple scattering on a tight beam (similar to a laser). The effect of the 'spread' value is pretty clear here: http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg Unlike the rest of the system so far, this part of the volume rendering engine isn't physically based, and currently it's not unusual to get non-physical results (i.e. much more light being scattered out then goes in via lamps or emit). To counter this, you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check on speeding this up further with threading too.
2009-01-26 02:42:17 +00:00
}
lightcache_filter(obi->volume_precache);
}
static int using_lightcache(Material *ma)
{
return (((ma->vol.shadeflag & MA_VOL_PRECACHESHADING) && (ma->vol.shade_type == MA_VOL_SHADE_SHADED))
|| (ELEM(ma->vol.shade_type, MA_VOL_SHADE_MULTIPLE, MA_VOL_SHADE_SHADEDPLUSMULTIPLE)));
}
/* loop through all objects (and their associated materials)
* marked for pre-caching in convertblender.c, and pre-cache them */
void volume_precache(Render *re)
{
ObjectInstanceRen *obi;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
VolumeOb *vo;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
for(vo= re->volumes.first; vo; vo= vo->next) {
if (using_lightcache(vo->ma)) {
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
for(obi= re->instancetable.first; obi; obi= obi->next) {
if (obi->obr == vo->obr) {
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
vol_precache_objectinstance_threads(re, obi, vo->ma);
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
}
}
}
}
re->i.infostr= NULL;
re->stats_draw(re->sdh, &re->i);
}
void free_volume_precache(Render *re)
{
ObjectInstanceRen *obi;
for(obi= re->instancetable.first; obi; obi= obi->next) {
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
if (obi->volume_precache != NULL) {
MEM_freeN(obi->volume_precache->data_r);
MEM_freeN(obi->volume_precache->data_g);
MEM_freeN(obi->volume_precache->data_b);
MEM_freeN(obi->volume_precache->bbmin);
MEM_freeN(obi->volume_precache->bbmax);
MEM_freeN(obi->volume_precache);
obi->volume_precache = NULL;
Voxel data & volume light cache * Added support for additional file types in the voxel data texture. I added support for 8 bit raw files, but most notably for image sequences. Image sequences generate the voxel grid by stacking layers of image slices on top of each other to generate the voxels in the Z axis - the number of slices in the sequence is the resolution of the voxel grid's Z axis. i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg The image sequence option is particularly useful for loading medical data into Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM format image sequences. It's not in Blender's scope to support the DICOM format, but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG. Here are some example renderings using these file formats to load medical data: http://vimeo.com/5242961 http://vimeo.com/5242989 http://vimeo.com/5243228 Currently the 8 bit raw and image sequence formats only support the 'still' rendering feature. * Changed the default texture placement to be centred around 0.5,0.5,0.5, rather than within the 0.0,1.0 cube. This is more consistent with image textures, and it also means you can easily add a voxel data texture to a default cube without having to mess around with mapping. * Added some more extrapolation modes such as Repeat and Extend rather than just clipping http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg * Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache) rather than storing in ram, to help cut down memory usage. * Refactored and cleaned up the code a lot. Now the access and interpolation code is separated into a separate voxel library inside blenlib. This is now properly shared between voxel data texture and light cache (previously there was some duplicated code). * Made volume light cache support non-cubic voxel grids. Now the resolution specified in the material properties is used for the longest edge of the volume object's bounding box, and the shorter edges are proportional (similar to how resolution is calculated for fluid sim domains). This is *much* more memory efficient for squashed volume regions like clouds layer bounding boxes, allowing you to raise the resolution considerably while still keeping memory usage acceptable.
2009-06-20 06:41:50 +00:00
}
}
BLI_freelistN(&re->volumes);
}
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
int point_inside_volume_objectinstance(Render *re, ObjectInstanceRen *obi, float *co)
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
{
RayObject *tree;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
int inside=0;
tree = makeraytree_object(re, obi);
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
if (!tree) return 0;
inside = point_inside_obi(tree, obi, co);
//TODO: makeraytree_object creates a tree and saves it on OBI, if we free this tree we should also clear other pointers to it
//RE_rayobject_free(tree);
//tree= NULL;
* Volume Rendering: Voxel data This commit introduces a new texture ('Voxel Data'), used to load up saved voxel data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández with some additional tweaks. Thanks, Raúl! The texture works similar to the existing point density texture, currently it only provides intensity information, which can then be mapped (for example) to density in a volume material. This is an early version, intended to read the voxel format saved by Raúl's command line simulators, in future revisions there's potential for making a more full-featured 'Blender voxel file format', and also for supporting other formats too. Note: Due to some subtleties in Raúl's existing released simulators, in order to load them correctly the voxel data texture, you'll need to raise the 'resolution' value by 2. So if you baked out the simulation at resolution 50, enter 52 for the resolution in the texture panel. This can possibly be fixed in the simulator later on. Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1 and it can appear rotated 90 degrees incorrectly. This will be tackled, for now, probably the easiest way to map it is with and empty, using Map Input -> Object. Smoke test: http://www.vimeo.com/2449270 One more note, trilinear interpolation seems a bit slow at the moment, we'll look into this. For curiosity, while testing/debugging this, I made a script that exports a mesh to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels, rendered as a volume: http://www.vimeo.com/2512028 The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py * Another smaller thing, brought back early ray termination (was disabled previously for debugging) and made it user configurable. It now appears as a new value in the volume material: 'Depth Cutoff'. For some background info on what this does, check: http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/ * Also some disabled work-in-progess code for light cache
2008-12-13 05:41:34 +00:00
return inside;
}