Files
test2/source/blender/render/intern/texture_pointdensity.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

964 lines
25 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2001-2002 NaN Holding BV. All rights reserved.
*
* SPDX-License-Identifier: GPL-2.0-or-later */
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
/** \file
* \ingroup render
2011-02-27 19:31:27 +00:00
*/
#include <cmath>
#include <cstdio>
#include <cstdlib>
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
#include "MEM_guardedalloc.h"
#include "BLI_blenlib.h"
#include "BLI_kdopbvh.h"
#include "BLI_math_color.h"
#include "BLI_math_matrix.h"
#include "BLI_math_vector.h"
#include "BLI_noise.h"
#include "BLI_task.h"
#include "BLI_utildefines.h"
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
#include "BLT_translation.h"
#include "DNA_mesh_types.h"
#include "DNA_meshdata_types.h"
#include "DNA_object_types.h"
#include "DNA_particle_types.h"
#include "DNA_scene_types.h"
#include "DNA_texture_types.h"
#include "BKE_colorband.h"
#include "BKE_colortools.h"
#include "BKE_customdata.h"
#include "BKE_deform.h"
#include "BKE_lattice.h"
#include "BKE_mesh.hh"
#include "BKE_object.h"
Point Density texture The Point Density texture now has some additional options for how the point locations are cached. Previously it was all relative to worldspace, but there are now some other options that make things a lot more convenient for mapping the texture to Local (or Orco). Thanks to theeth for helping with the space conversions! The new Object space options allow this sort of thing to be possible - a particle system, instanced on a transformed renderable object: http://mke3.net/blender/devel/rendering/volumetrics/pd_objectspace.mov It's also a lot easier to use multiple instances, just duplicate the renderable objects and move them around. The new particle cache options are: * Emit Object space This caches the particles relative to the emitter object's coordinate space (i.e. relative to the emitter's object center). This makes it possible to map the Texture to Local or Orco easily, so you can easily move, rotate or scale the rendering object that has the Point Density texture. It's relative to the emitter's location, rotation and scale, so if the object you're rendering the texture on is aligned differently to the emitter, the results will be rotated etc. * Emit Object Location This offsets the particles to the emitter object's location in 3D space. It's similar to Emit Object Space, however the emitter object's rotation and scale are ignored. This is probably the easiest to use, since you don't need to worry about the rotation and scale of the emitter object (just the rendered object), so it's the default. * Global Space This is the same as previously, the particles are cached in global space, so to use this effectively you'll need to map the texture to Global, and have the rendered object in the right global location.
2008-09-29 04:19:24 +00:00
#include "BKE_particle.h"
#include "BKE_scene.h"
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
#include "DEG_depsgraph.h"
#include "DEG_depsgraph_query.h"
#include "texture_common.h"
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
#include "RE_texture.h"
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
static ThreadMutex sample_mutex = PTHREAD_MUTEX_INITIALIZER;
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
enum {
POINT_DATA_VEL = 1 << 0,
POINT_DATA_LIFE = 1 << 1,
POINT_DATA_COLOR = 1 << 2,
};
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
static int point_data_used(PointDensity *pd)
{
int pd_bitflag = 0;
if (pd->source == TEX_PD_PSYS) {
Remove Blender Internal and legacy viewport from Blender 2.8. Brecht authored this commit, but he gave me the honours to actually do it. Here it goes; Blender Internal. Bye bye, you did great! * Point density, voxel data, ocean, environment map textures were removed, as these only worked within BI rendering. Note that the ocean modifier and the Cycles point density shader node continue to work. * Dynamic paint using material shading was removed, as this only worked with BI. If we ever wanted to support this again probably it should go through the baking API. * GPU shader export through the Python API was removed. This only worked for the old BI GLSL shaders, which no longer exists. Doing something similar for Eevee would be significantly more complicated because it uses a lot of multiplass rendering and logic outside the shader, it's probably impractical. * Collada material import / export code is mostly gone, as it only worked for BI materials. We need to add Cycles / Eevee material support at some point. * The mesh noise operator was removed since it only worked with BI material texture slots. A displacement modifier can be used instead. * The delete texture paint slot operator was removed since it only worked for BI material texture slots. Could be added back with node support. * Not all legacy viewport features are supported in the new viewport, but their code was removed. If we need to bring anything back we can look at older git revisions. * There is some legacy viewport code that I could not remove yet, and some that I probably missed. * Shader node execution code was left mostly intact, even though it is not used anywhere now. We may eventually use this to replace the texture nodes with Cycles / Eevee shader nodes. * The Cycles Bake panel now includes settings for baking multires normal and displacement maps. The underlying code needs to be merged properly, and we plan to add back support for multires AO baking and add support to Cycles baking for features like vertex color, displacement, and other missing baking features. * This commit removes DNA and the Python API for BI material, lamp, world and scene settings. This breaks a lot of addons. * There is more DNA that can be removed or renamed, where Cycles or Eevee are reusing some old BI properties but the names are not really correct anymore. * Texture slots for materials, lamps and world were removed. They remain for brushes, particles and freestyle linestyles. * 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and other renderers use this to find all panels to show, minus a few panels that they have their own replacement for.
2018-04-19 17:34:44 +02:00
if ((pd->falloff_type == TEX_PD_FALLOFF_PARTICLE_VEL) ||
(pd->color_source == TEX_PD_COLOR_PARTVEL) || (pd->color_source == TEX_PD_COLOR_PARTSPEED))
{
pd_bitflag |= POINT_DATA_VEL;
}
Remove Blender Internal and legacy viewport from Blender 2.8. Brecht authored this commit, but he gave me the honours to actually do it. Here it goes; Blender Internal. Bye bye, you did great! * Point density, voxel data, ocean, environment map textures were removed, as these only worked within BI rendering. Note that the ocean modifier and the Cycles point density shader node continue to work. * Dynamic paint using material shading was removed, as this only worked with BI. If we ever wanted to support this again probably it should go through the baking API. * GPU shader export through the Python API was removed. This only worked for the old BI GLSL shaders, which no longer exists. Doing something similar for Eevee would be significantly more complicated because it uses a lot of multiplass rendering and logic outside the shader, it's probably impractical. * Collada material import / export code is mostly gone, as it only worked for BI materials. We need to add Cycles / Eevee material support at some point. * The mesh noise operator was removed since it only worked with BI material texture slots. A displacement modifier can be used instead. * The delete texture paint slot operator was removed since it only worked for BI material texture slots. Could be added back with node support. * Not all legacy viewport features are supported in the new viewport, but their code was removed. If we need to bring anything back we can look at older git revisions. * There is some legacy viewport code that I could not remove yet, and some that I probably missed. * Shader node execution code was left mostly intact, even though it is not used anywhere now. We may eventually use this to replace the texture nodes with Cycles / Eevee shader nodes. * The Cycles Bake panel now includes settings for baking multires normal and displacement maps. The underlying code needs to be merged properly, and we plan to add back support for multires AO baking and add support to Cycles baking for features like vertex color, displacement, and other missing baking features. * This commit removes DNA and the Python API for BI material, lamp, world and scene settings. This breaks a lot of addons. * There is more DNA that can be removed or renamed, where Cycles or Eevee are reusing some old BI properties but the names are not really correct anymore. * Texture slots for materials, lamps and world were removed. They remain for brushes, particles and freestyle linestyles. * 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and other renderers use this to find all panels to show, minus a few panels that they have their own replacement for.
2018-04-19 17:34:44 +02:00
if ((pd->color_source == TEX_PD_COLOR_PARTAGE) ||
(pd->falloff_type == TEX_PD_FALLOFF_PARTICLE_AGE))
{
pd_bitflag |= POINT_DATA_LIFE;
}
}
else if (pd->source == TEX_PD_OBJECT) {
if (ELEM(pd->ob_color_source,
TEX_PD_COLOR_VERTCOL,
TEX_PD_COLOR_VERTWEIGHT,
TEX_PD_COLOR_VERTNOR)) {
pd_bitflag |= POINT_DATA_COLOR;
}
}
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
return pd_bitflag;
}
static void point_data_pointers(PointDensity *pd,
float **r_data_velocity,
float **r_data_life,
float **r_data_color)
{
const int data_used = point_data_used(pd);
const int totpoint = pd->totpoints;
float *data = pd->point_data;
int offset = 0;
if (data_used & POINT_DATA_VEL) {
2019-04-22 09:08:06 +10:00
if (r_data_velocity) {
*r_data_velocity = data + offset;
2019-04-22 09:08:06 +10:00
}
offset += 3 * totpoint;
}
else {
2019-04-22 09:08:06 +10:00
if (r_data_velocity) {
*r_data_velocity = nullptr;
2019-04-22 09:08:06 +10:00
}
}
if (data_used & POINT_DATA_LIFE) {
2019-04-22 09:08:06 +10:00
if (r_data_life) {
*r_data_life = data + offset;
2019-04-22 09:08:06 +10:00
}
offset += totpoint;
}
else {
2019-04-22 09:08:06 +10:00
if (r_data_life) {
*r_data_life = nullptr;
2019-04-22 09:08:06 +10:00
}
}
if (data_used & POINT_DATA_COLOR) {
2019-04-22 09:08:06 +10:00
if (r_data_color) {
*r_data_color = data + offset;
2019-04-22 09:08:06 +10:00
}
offset += 3 * totpoint;
}
else {
2019-04-22 09:08:06 +10:00
if (r_data_color) {
*r_data_color = nullptr;
2019-04-22 09:08:06 +10:00
}
}
}
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
/* additional data stored alongside the point density BVH,
* accessible by point index number to retrieve other information
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
* such as particle velocity or lifetime */
static void alloc_point_data(PointDensity *pd)
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
{
const int totpoints = pd->totpoints;
int data_used = point_data_used(pd);
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
int data_size = 0;
if (data_used & POINT_DATA_VEL) {
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
/* store 3 channels of velocity data */
data_size += 3;
}
if (data_used & POINT_DATA_LIFE) {
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
/* store 1 channel of lifetime data */
data_size += 1;
}
if (data_used & POINT_DATA_COLOR) {
/* store 3 channels of RGB data */
data_size += 3;
}
if (data_size) {
pd->point_data = static_cast<float *>(
MEM_callocN(sizeof(float) * data_size * totpoints, "particle point data"));
}
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
static void pointdensity_cache_psys(
Depsgraph *depsgraph, Scene *scene, PointDensity *pd, Object *ob, ParticleSystem *psys)
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
{
ParticleKey state;
ParticleCacheKey *cache;
ParticleSimulationData sim = {nullptr};
ParticleData *pa = nullptr;
float cfra = BKE_scene_ctime_get(scene);
2023-03-03 10:09:20 +11:00
int i;
// int childexists = 0; /* UNUSED */
int total_particles;
int data_used;
float *data_vel, *data_life;
Point Density texture The Point Density texture now has some additional options for how the point locations are cached. Previously it was all relative to worldspace, but there are now some other options that make things a lot more convenient for mapping the texture to Local (or Orco). Thanks to theeth for helping with the space conversions! The new Object space options allow this sort of thing to be possible - a particle system, instanced on a transformed renderable object: http://mke3.net/blender/devel/rendering/volumetrics/pd_objectspace.mov It's also a lot easier to use multiple instances, just duplicate the renderable objects and move them around. The new particle cache options are: * Emit Object space This caches the particles relative to the emitter object's coordinate space (i.e. relative to the emitter's object center). This makes it possible to map the Texture to Local or Orco easily, so you can easily move, rotate or scale the rendering object that has the Point Density texture. It's relative to the emitter's location, rotation and scale, so if the object you're rendering the texture on is aligned differently to the emitter, the results will be rotated etc. * Emit Object Location This offsets the particles to the emitter object's location in 3D space. It's similar to Emit Object Space, however the emitter object's rotation and scale are ignored. This is probably the easiest to use, since you don't need to worry about the rotation and scale of the emitter object (just the rendered object), so it's the default. * Global Space This is the same as previously, the particles are cached in global space, so to use this effectively you'll need to map the texture to Global, and have the rendered object in the right global location.
2008-09-29 04:19:24 +00:00
float partco[3];
const bool use_render_params = (DEG_get_mode(depsgraph) == DAG_EVAL_RENDER);
data_used = point_data_used(pd);
if (!psys_check_enabled(ob, psys, use_render_params)) {
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
return;
}
sim.depsgraph = depsgraph;
sim.scene = scene;
sim.ob = ob;
sim.psys = psys;
sim.psmd = psys_get_modifier(ob, psys);
/* in case ob->world_to_object isn't up-to-date */
invert_m4_m4(ob->world_to_object, ob->object_to_world);
total_particles = psys->totpart + psys->totchild;
psys_sim_data_init(&sim);
pd->point_tree = BLI_bvhtree_new(total_particles, 0.0, 4, 6);
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
pd->totpoints = total_particles;
alloc_point_data(pd);
point_data_pointers(pd, &data_vel, &data_life, nullptr);
#if 0 /* UNUSED */
if (psys->totchild > 0 && !(psys->part->draw & PART_DRAW_PARENT)) {
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
childexists = 1;
}
#endif
for (i = 0, pa = psys->particles; i < total_particles; i++, pa++) {
if (psys->part->type == PART_HAIR) {
/* hair particles */
2019-04-22 09:08:06 +10:00
if (i < psys->totpart && psys->pathcache) {
cache = psys->pathcache[i];
2019-04-22 09:08:06 +10:00
}
else if (i >= psys->totpart && psys->childcache) {
cache = psys->childcache[i - psys->totpart];
2019-04-22 09:08:06 +10:00
}
else {
continue;
2019-04-22 09:08:06 +10:00
}
cache += cache->segments; /* use endpoint */
copy_v3_v3(state.co, cache->co);
zero_v3(state.vel);
state.time = 0.0f;
}
else {
/* emitter particles */
state.time = cfra;
if (!psys_get_particle_state(&sim, i, &state, false)) {
continue;
2019-04-22 09:08:06 +10:00
}
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
if (data_used & POINT_DATA_LIFE) {
if (i < psys->totpart) {
state.time = (cfra - pa->time) / pa->lifetime;
}
else {
ChildParticle *cpa = (psys->child + i) - psys->totpart;
float pa_birthtime, pa_dietime;
state.time = psys_get_child_time(psys, cpa, cfra, &pa_birthtime, &pa_dietime);
}
}
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
}
copy_v3_v3(partco, state.co);
2019-04-22 09:08:06 +10:00
if (pd->psys_cache_space == TEX_PD_OBJECTSPACE) {
mul_m4_v3(ob->world_to_object, partco);
2019-04-22 09:08:06 +10:00
}
else if (pd->psys_cache_space == TEX_PD_OBJECTLOC) {
sub_v3_v3(partco, ob->loc);
}
else {
/* TEX_PD_WORLDSPACE */
}
BLI_bvhtree_insert(static_cast<BVHTree *>(pd->point_tree), i, partco, 1);
if (data_vel) {
2019-03-25 11:55:36 +11:00
data_vel[i * 3 + 0] = state.vel[0];
data_vel[i * 3 + 1] = state.vel[1];
data_vel[i * 3 + 2] = state.vel[2];
}
if (data_life) {
data_life[i] = state.time;
}
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
}
BLI_bvhtree_balance(static_cast<BVHTree *>(pd->point_tree));
psys_sim_data_free(&sim);
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
}
static void pointdensity_cache_vertex_color(PointDensity *pd,
Object * /*ob*/,
Mesh *mesh,
float *data_color)
{
Mesh: Replace MLoop struct with generic attributes Implements #102359. Split the `MLoop` struct into two separate integer arrays called `corner_verts` and `corner_edges`, referring to the vertex each corner is attached to and the next edge around the face at each corner. These arrays can be sliced to give access to the edges or vertices in a face. Then they are often referred to as "poly_verts" or "poly_edges". The main benefits are halving the necessary memory bandwidth when only one array is used and simplifications from using regular integer indices instead of a special-purpose struct. The commit also starts a renaming from "loop" to "corner" in mesh code. Like the other mesh struct of array refactors, forward compatibility is kept by writing files with the older format. This will be done until 4.0 to ease the transition process. Looking at a small portion of the patch should give a good impression for the rest of the changes. I tried to make the changes as small as possible so it's easy to tell the correctness from the diff. Though I found Blender developers have been very inventive over the last decade when finding different ways to loop over the corners in a face. For performance, nearly every piece of code that deals with `Mesh` is slightly impacted. Any algorithm that is memory bottle-necked should see an improvement. For example, here is a comparison of interpolating a vertex float attribute to face corners (Ryzen 3700x): **Before** (Average: 3.7 ms, Min: 3.4 ms) ``` threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) { for (const int64_t i : range) { dst[i] = src[loops[i].v]; } }); ``` **After** (Average: 2.9 ms, Min: 2.6 ms) ``` array_utils::gather(src, corner_verts, dst); ``` That's an improvement of 28% to the average timings, and it's also a simplification, since an index-based routine can be used instead. For more examples using the new arrays, see the design task. Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
const int *corner_verts = BKE_mesh_corner_verts(mesh);
const int totloop = mesh->totloop;
char layername[MAX_CUSTOMDATA_LAYER_NAME];
int i;
BLI_assert(data_color);
if (!CustomData_has_layer(&mesh->loop_data, CD_PROP_BYTE_COLOR)) {
return;
2019-04-22 09:08:06 +10:00
}
CustomData_validate_layer_name(
&mesh->loop_data, CD_PROP_BYTE_COLOR, pd->vertex_attribute_name, layername);
const MLoopCol *mcol = static_cast<const MLoopCol *>(
CustomData_get_layer_named(&mesh->loop_data, CD_PROP_BYTE_COLOR, layername));
2019-04-22 09:08:06 +10:00
if (!mcol) {
return;
2019-04-22 09:08:06 +10:00
}
/* Stores the number of MLoops using the same vertex, so we can normalize colors. */
int *mcorners = static_cast<int *>(
MEM_callocN(sizeof(int) * pd->totpoints, "point density corner count"));
for (i = 0; i < totloop; i++) {
Mesh: Replace MLoop struct with generic attributes Implements #102359. Split the `MLoop` struct into two separate integer arrays called `corner_verts` and `corner_edges`, referring to the vertex each corner is attached to and the next edge around the face at each corner. These arrays can be sliced to give access to the edges or vertices in a face. Then they are often referred to as "poly_verts" or "poly_edges". The main benefits are halving the necessary memory bandwidth when only one array is used and simplifications from using regular integer indices instead of a special-purpose struct. The commit also starts a renaming from "loop" to "corner" in mesh code. Like the other mesh struct of array refactors, forward compatibility is kept by writing files with the older format. This will be done until 4.0 to ease the transition process. Looking at a small portion of the patch should give a good impression for the rest of the changes. I tried to make the changes as small as possible so it's easy to tell the correctness from the diff. Though I found Blender developers have been very inventive over the last decade when finding different ways to loop over the corners in a face. For performance, nearly every piece of code that deals with `Mesh` is slightly impacted. Any algorithm that is memory bottle-necked should see an improvement. For example, here is a comparison of interpolating a vertex float attribute to face corners (Ryzen 3700x): **Before** (Average: 3.7 ms, Min: 3.4 ms) ``` threading::parallel_for(loops.index_range(), 4096, [&](IndexRange range) { for (const int64_t i : range) { dst[i] = src[loops[i].v]; } }); ``` **After** (Average: 2.9 ms, Min: 2.6 ms) ``` array_utils::gather(src, corner_verts, dst); ``` That's an improvement of 28% to the average timings, and it's also a simplification, since an index-based routine can be used instead. For more examples using the new arrays, see the design task. Pull Request: https://projects.blender.org/blender/blender/pulls/104424
2023-03-20 15:55:13 +01:00
int v = corner_verts[i];
if (mcorners[v] == 0) {
rgb_uchar_to_float(&data_color[v * 3], &mcol[i].r);
}
else {
float col[3];
rgb_uchar_to_float(col, &mcol[i].r);
add_v3_v3(&data_color[v * 3], col);
}
++mcorners[v];
}
/* Normalize colors by averaging over mcorners.
* All the corners share the same vertex, ie. occupy the same point in space.
*/
for (i = 0; i < pd->totpoints; i++) {
2019-04-22 09:08:06 +10:00
if (mcorners[i] > 0) {
2019-03-25 11:55:36 +11:00
mul_v3_fl(&data_color[i * 3], 1.0f / mcorners[i]);
2019-04-22 09:08:06 +10:00
}
}
MEM_freeN(mcorners);
}
static void pointdensity_cache_vertex_weight(PointDensity *pd,
Object *ob,
Mesh *mesh,
float *data_color)
{
const int totvert = mesh->totvert;
int mdef_index;
int i;
BLI_assert(data_color);
const MDeformVert *mdef = static_cast<const MDeformVert *>(
CustomData_get_layer(&mesh->vert_data, CD_MDEFORMVERT));
2019-04-22 09:08:06 +10:00
if (!mdef) {
return;
2019-04-22 09:08:06 +10:00
}
mdef_index = BKE_id_defgroup_name_index(&mesh->id, pd->vertex_attribute_name);
2019-04-22 09:08:06 +10:00
if (mdef_index < 0) {
mdef_index = BKE_object_defgroup_active_index_get(ob) - 1;
2019-04-22 09:08:06 +10:00
}
if (mdef_index < 0) {
return;
2019-04-22 09:08:06 +10:00
}
const MDeformVert *dv;
for (i = 0, dv = mdef; i < totvert; i++, dv++, data_color += 3) {
MDeformWeight *dw;
int j;
for (j = 0, dw = dv->dw; j < dv->totweight; j++, dw++) {
if (dw->def_nr == mdef_index) {
copy_v3_fl(data_color, dw->weight);
break;
}
}
}
}
Refactor: Move normals out of MVert, lazy calculation As described in T91186, this commit moves mesh vertex normals into a contiguous array of float vectors in a custom data layer, how face normals are currently stored. The main interface is documented in `BKE_mesh.h`. Vertex and face normals are now calculated on-demand and cached, retrieved with an "ensure" function. Since the logical state of a mesh is now "has normals when necessary", they can be retrieved from a `const` mesh. The goal is to use on-demand calculation for all derived data, but leave room for eager calculation for performance purposes (modifier evaluation is threaded, but viewport data generation is not). **Benefits** This moves us closer to a SoA approach rather than the current AoS paradigm. Accessing a contiguous `float3` is much more efficient than retrieving data from a larger struct. The memory requirements for accessing only normals or vertex locations are smaller, and at the cost of more memory usage for just normals, they now don't have to be converted between float and short, which also simplifies code In the future, the remaining items can be removed from `MVert`, leaving only `float3`, which has similar benefits (see T93602). Removing the combination of derived and original data makes it conceptually simpler to only calculate normals when necessary. This is especially important now that we have more opportunities for temporary meshes in geometry nodes. **Performance** In addition to the theoretical future performance improvements by making `MVert == float3`, I've done some basic performance testing on this patch directly. The data is fairly rough, but it gives an idea about where things stand generally. - Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms), showing that accessing just `MVert` is now more efficient. - Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight change that at least shows there is no regression. - Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small but observable speedup. - Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms), shows that using normals in geometry nodes is faster. - Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms), shows that calculating normals is slightly faster now. - File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB), Normals are not saved in files, which can help with large meshes. As for memory usage, it may be slightly more in some cases, but I didn't observe any difference in the production files I tested. **Tests** Some modifiers and cycles test results need to be updated with this commit, for two reasons: - The subdivision surface modifier is not responsible for calculating normals anymore. In master, the modifier creates different normals than the result of the `Mesh` normal calculation, so this is a bug fix. - There are small differences in the results of some modifiers that use normals because they are not converted to and from `short` anymore. **Future improvements** - Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier already retrieves normals if they are needed anyway. - Copy normals as part of a better CoW system for attributes. - Make more areas use lazy instead of eager normal calculation. - Remove `BKE_mesh_normals_tag_dirty` in more places since that is now the default state of a new mesh. - Possibly apply a similar change to derived face corner normals. Differential Revision: https://developer.blender.org/D12770
2022-01-13 14:37:58 -06:00
static void pointdensity_cache_vertex_normal(Mesh *mesh, float *data_color)
{
BLI_assert(data_color);
const blender::Span<blender::float3> normals = mesh->vert_normals();
memcpy(data_color, normals.data(), sizeof(float[3]) * mesh->totvert);
}
static void pointdensity_cache_object(PointDensity *pd, Object *ob)
{
float *data_color;
int i;
Mesh *mesh = static_cast<Mesh *>(ob->data);
#if 0 /* UNUSED */
CustomData_MeshMasks mask = CD_MASK_BAREMESH;
mask.fmask |= CD_MASK_MTFACE | CD_MASK_MCOL;
switch (pd->ob_color_source) {
case TEX_PD_COLOR_VERTCOL:
mask.lmask |= CD_MASK_PROP_BYTE_COLOR;
break;
case TEX_PD_COLOR_VERTWEIGHT:
mask.vmask |= CD_MASK_MDEFORMVERT;
break;
}
#endif
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
const float(*positions)[3] = BKE_mesh_vert_positions(mesh); /* local object space */
pd->totpoints = mesh->totvert;
if (pd->totpoints == 0) {
return;
}
pd->point_tree = BLI_bvhtree_new(pd->totpoints, 0.0, 4, 6);
alloc_point_data(pd);
point_data_pointers(pd, nullptr, nullptr, &data_color);
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
for (i = 0; i < pd->totpoints; i++) {
float co[3];
Mesh: Move positions to a generic attribute **Changes** As described in T93602, this patch removes all use of the `MVert` struct, replacing it with a generic named attribute with the name `"position"`, consistent with other geometry types. Variable names have been changed from `verts` to `positions`, to align with the attribute name and the more generic design (positions are not vertices, they are just an attribute stored on the point domain). This change is made possible by previous commits that moved all other data out of `MVert` to runtime data or other generic attributes. What remains is mostly a simple type change. Though, the type still shows up 859 times, so the patch is quite large. One compromise is that now `CD_MASK_BAREMESH` now contains `CD_PROP_FLOAT3`. With the general move towards generic attributes over custom data types, we are removing use of these type masks anyway. **Benefits** The most obvious benefit is reduced memory usage and the benefits that brings in memory-bound situations. `float3` is only 3 bytes, in comparison to `MVert` which was 4. When there are millions of vertices this starts to matter more. The other benefits come from using a more generic type. Instead of writing algorithms specifically for `MVert`, code can just use arrays of vectors. This will allow eliminating many temporary arrays or wrappers used to extract positions. Many possible improvements aren't implemented in this patch, though I did switch simplify or remove the process of creating temporary position arrays in a few places. The design clarity that "positions are just another attribute" brings allows removing explicit copying of vertices in some procedural operations-- they are just processed like most other attributes. **Performance** This touches so many areas that it's hard to benchmark exhaustively, but I observed some areas as examples. * The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster. * The Spring splash screen went from ~4.3 to ~4.5 fps. * The subdivision surface modifier/node was slightly faster RNA access through Python may be slightly slower, since now we need a name lookup instead of just a custom data type lookup for each index. **Future Improvements** * Remove uses of "vert_coords" functions: * `BKE_mesh_vert_coords_alloc` * `BKE_mesh_vert_coords_get` * `BKE_mesh_vert_coords_apply{_with_mat4}` * Remove more hidden copying of positions * General simplification now possible in many areas * Convert more code to C++ to use `float3` instead of `float[3]` * Currently `reinterpret_cast` is used for those C-API functions Differential Revision: https://developer.blender.org/D15982
2023-01-10 00:10:43 -05:00
copy_v3_v3(co, positions[i]);
switch (pd->ob_cache_space) {
case TEX_PD_OBJECTSPACE:
break;
case TEX_PD_OBJECTLOC:
mul_m4_v3(ob->object_to_world, co);
sub_v3_v3(co, ob->loc);
break;
case TEX_PD_WORLDSPACE:
default:
mul_m4_v3(ob->object_to_world, co);
break;
}
BLI_bvhtree_insert(static_cast<BVHTree *>(pd->point_tree), i, co, 1);
}
switch (pd->ob_color_source) {
case TEX_PD_COLOR_VERTCOL:
pointdensity_cache_vertex_color(pd, ob, mesh, data_color);
break;
case TEX_PD_COLOR_VERTWEIGHT:
pointdensity_cache_vertex_weight(pd, ob, mesh, data_color);
break;
case TEX_PD_COLOR_VERTNOR:
Refactor: Move normals out of MVert, lazy calculation As described in T91186, this commit moves mesh vertex normals into a contiguous array of float vectors in a custom data layer, how face normals are currently stored. The main interface is documented in `BKE_mesh.h`. Vertex and face normals are now calculated on-demand and cached, retrieved with an "ensure" function. Since the logical state of a mesh is now "has normals when necessary", they can be retrieved from a `const` mesh. The goal is to use on-demand calculation for all derived data, but leave room for eager calculation for performance purposes (modifier evaluation is threaded, but viewport data generation is not). **Benefits** This moves us closer to a SoA approach rather than the current AoS paradigm. Accessing a contiguous `float3` is much more efficient than retrieving data from a larger struct. The memory requirements for accessing only normals or vertex locations are smaller, and at the cost of more memory usage for just normals, they now don't have to be converted between float and short, which also simplifies code In the future, the remaining items can be removed from `MVert`, leaving only `float3`, which has similar benefits (see T93602). Removing the combination of derived and original data makes it conceptually simpler to only calculate normals when necessary. This is especially important now that we have more opportunities for temporary meshes in geometry nodes. **Performance** In addition to the theoretical future performance improvements by making `MVert == float3`, I've done some basic performance testing on this patch directly. The data is fairly rough, but it gives an idea about where things stand generally. - Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms), showing that accessing just `MVert` is now more efficient. - Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight change that at least shows there is no regression. - Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small but observable speedup. - Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms), shows that using normals in geometry nodes is faster. - Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms), shows that calculating normals is slightly faster now. - File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB), Normals are not saved in files, which can help with large meshes. As for memory usage, it may be slightly more in some cases, but I didn't observe any difference in the production files I tested. **Tests** Some modifiers and cycles test results need to be updated with this commit, for two reasons: - The subdivision surface modifier is not responsible for calculating normals anymore. In master, the modifier creates different normals than the result of the `Mesh` normal calculation, so this is a bug fix. - There are small differences in the results of some modifiers that use normals because they are not converted to and from `short` anymore. **Future improvements** - Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier already retrieves normals if they are needed anyway. - Copy normals as part of a better CoW system for attributes. - Make more areas use lazy instead of eager normal calculation. - Remove `BKE_mesh_normals_tag_dirty` in more places since that is now the default state of a new mesh. - Possibly apply a similar change to derived face corner normals. Differential Revision: https://developer.blender.org/D12770
2022-01-13 14:37:58 -06:00
pointdensity_cache_vertex_normal(mesh, data_color);
break;
}
BLI_bvhtree_balance(static_cast<BVHTree *>(pd->point_tree));
}
Remove Blender Internal and legacy viewport from Blender 2.8. Brecht authored this commit, but he gave me the honours to actually do it. Here it goes; Blender Internal. Bye bye, you did great! * Point density, voxel data, ocean, environment map textures were removed, as these only worked within BI rendering. Note that the ocean modifier and the Cycles point density shader node continue to work. * Dynamic paint using material shading was removed, as this only worked with BI. If we ever wanted to support this again probably it should go through the baking API. * GPU shader export through the Python API was removed. This only worked for the old BI GLSL shaders, which no longer exists. Doing something similar for Eevee would be significantly more complicated because it uses a lot of multiplass rendering and logic outside the shader, it's probably impractical. * Collada material import / export code is mostly gone, as it only worked for BI materials. We need to add Cycles / Eevee material support at some point. * The mesh noise operator was removed since it only worked with BI material texture slots. A displacement modifier can be used instead. * The delete texture paint slot operator was removed since it only worked for BI material texture slots. Could be added back with node support. * Not all legacy viewport features are supported in the new viewport, but their code was removed. If we need to bring anything back we can look at older git revisions. * There is some legacy viewport code that I could not remove yet, and some that I probably missed. * Shader node execution code was left mostly intact, even though it is not used anywhere now. We may eventually use this to replace the texture nodes with Cycles / Eevee shader nodes. * The Cycles Bake panel now includes settings for baking multires normal and displacement maps. The underlying code needs to be merged properly, and we plan to add back support for multires AO baking and add support to Cycles baking for features like vertex color, displacement, and other missing baking features. * This commit removes DNA and the Python API for BI material, lamp, world and scene settings. This breaks a lot of addons. * There is more DNA that can be removed or renamed, where Cycles or Eevee are reusing some old BI properties but the names are not really correct anymore. * Texture slots for materials, lamps and world were removed. They remain for brushes, particles and freestyle linestyles. * 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and other renderers use this to find all panels to show, minus a few panels that they have their own replacement for.
2018-04-19 17:34:44 +02:00
static void cache_pointdensity(Depsgraph *depsgraph, Scene *scene, PointDensity *pd)
{
if (pd == nullptr) {
return;
}
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
if (pd->point_tree) {
BLI_bvhtree_free(static_cast<BVHTree *>(pd->point_tree));
pd->point_tree = nullptr;
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
}
Point Density texture The Point Density texture now has some additional options for how the point locations are cached. Previously it was all relative to worldspace, but there are now some other options that make things a lot more convenient for mapping the texture to Local (or Orco). Thanks to theeth for helping with the space conversions! The new Object space options allow this sort of thing to be possible - a particle system, instanced on a transformed renderable object: http://mke3.net/blender/devel/rendering/volumetrics/pd_objectspace.mov It's also a lot easier to use multiple instances, just duplicate the renderable objects and move them around. The new particle cache options are: * Emit Object space This caches the particles relative to the emitter object's coordinate space (i.e. relative to the emitter's object center). This makes it possible to map the Texture to Local or Orco easily, so you can easily move, rotate or scale the rendering object that has the Point Density texture. It's relative to the emitter's location, rotation and scale, so if the object you're rendering the texture on is aligned differently to the emitter, the results will be rotated etc. * Emit Object Location This offsets the particles to the emitter object's location in 3D space. It's similar to Emit Object Space, however the emitter object's rotation and scale are ignored. This is probably the easiest to use, since you don't need to worry about the rotation and scale of the emitter object (just the rendered object), so it's the default. * Global Space This is the same as previously, the particles are cached in global space, so to use this effectively you'll need to map the texture to Global, and have the rendered object in the right global location.
2008-09-29 04:19:24 +00:00
if (pd->source == TEX_PD_PSYS) {
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
Object *ob = pd->object;
ParticleSystem *psys;
if (!ob || !pd->psys) {
return;
}
psys = static_cast<ParticleSystem *>(BLI_findlink(&ob->particlesystem, pd->psys - 1));
if (!psys) {
return;
}
pointdensity_cache_psys(depsgraph, scene, pd, ob, psys);
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
}
else if (pd->source == TEX_PD_OBJECT) {
Object *ob = pd->object;
2019-04-22 09:08:06 +10:00
if (ob && ob->type == OB_MESH) {
pointdensity_cache_object(pd, ob);
2019-04-22 09:08:06 +10:00
}
}
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
}
Remove Blender Internal and legacy viewport from Blender 2.8. Brecht authored this commit, but he gave me the honours to actually do it. Here it goes; Blender Internal. Bye bye, you did great! * Point density, voxel data, ocean, environment map textures were removed, as these only worked within BI rendering. Note that the ocean modifier and the Cycles point density shader node continue to work. * Dynamic paint using material shading was removed, as this only worked with BI. If we ever wanted to support this again probably it should go through the baking API. * GPU shader export through the Python API was removed. This only worked for the old BI GLSL shaders, which no longer exists. Doing something similar for Eevee would be significantly more complicated because it uses a lot of multiplass rendering and logic outside the shader, it's probably impractical. * Collada material import / export code is mostly gone, as it only worked for BI materials. We need to add Cycles / Eevee material support at some point. * The mesh noise operator was removed since it only worked with BI material texture slots. A displacement modifier can be used instead. * The delete texture paint slot operator was removed since it only worked for BI material texture slots. Could be added back with node support. * Not all legacy viewport features are supported in the new viewport, but their code was removed. If we need to bring anything back we can look at older git revisions. * There is some legacy viewport code that I could not remove yet, and some that I probably missed. * Shader node execution code was left mostly intact, even though it is not used anywhere now. We may eventually use this to replace the texture nodes with Cycles / Eevee shader nodes. * The Cycles Bake panel now includes settings for baking multires normal and displacement maps. The underlying code needs to be merged properly, and we plan to add back support for multires AO baking and add support to Cycles baking for features like vertex color, displacement, and other missing baking features. * This commit removes DNA and the Python API for BI material, lamp, world and scene settings. This breaks a lot of addons. * There is more DNA that can be removed or renamed, where Cycles or Eevee are reusing some old BI properties but the names are not really correct anymore. * Texture slots for materials, lamps and world were removed. They remain for brushes, particles and freestyle linestyles. * 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and other renderers use this to find all panels to show, minus a few panels that they have their own replacement for.
2018-04-19 17:34:44 +02:00
static void free_pointdensity(PointDensity *pd)
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
{
if (pd == nullptr) {
return;
}
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
if (pd->point_tree) {
BLI_bvhtree_free(static_cast<BVHTree *>(pd->point_tree));
pd->point_tree = nullptr;
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
}
2021-08-06 13:59:38 +10:00
MEM_SAFE_FREE(pd->point_data);
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
pd->totpoints = 0;
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
}
struct PointDensityRangeData {
float *density;
float squared_radius;
float *point_data_life;
float *point_data_velocity;
float *point_data_color;
float *vec;
float *col;
float softness;
short falloff_type;
short noise_influence;
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
float *age;
CurveMapping *density_curve;
float velscale;
};
static float density_falloff(PointDensityRangeData *pdr, int index, float squared_dist)
{
const float dist = (pdr->squared_radius - squared_dist) / pdr->squared_radius * 0.5f;
float density = 0.0f;
switch (pdr->falloff_type) {
case TEX_PD_FALLOFF_STD:
density = dist;
break;
case TEX_PD_FALLOFF_SMOOTH:
density = 3.0f * dist * dist - 2.0f * dist * dist * dist;
break;
case TEX_PD_FALLOFF_SOFT:
density = pow(dist, pdr->softness);
break;
case TEX_PD_FALLOFF_CONSTANT:
density = pdr->squared_radius;
break;
case TEX_PD_FALLOFF_ROOT:
density = sqrtf(dist);
break;
case TEX_PD_FALLOFF_PARTICLE_AGE:
2019-04-22 09:08:06 +10:00
if (pdr->point_data_life) {
density = dist * MIN2(pdr->point_data_life[index], 1.0f);
2019-04-22 09:08:06 +10:00
}
else {
density = dist;
2019-04-22 09:08:06 +10:00
}
break;
case TEX_PD_FALLOFF_PARTICLE_VEL:
2019-04-22 09:08:06 +10:00
if (pdr->point_data_velocity) {
density = dist * len_v3(&pdr->point_data_velocity[index * 3]) * pdr->velscale;
2019-04-22 09:08:06 +10:00
}
else {
density = dist;
2019-04-22 09:08:06 +10:00
}
break;
}
if (pdr->density_curve && dist != 0.0f) {
BKE_curvemapping_init(pdr->density_curve);
density = BKE_curvemapping_evaluateF(pdr->density_curve, 0, density / dist) * dist;
}
return density;
}
static void accum_density(void *userdata, int index, const float co[3], float squared_dist)
{
PointDensityRangeData *pdr = (PointDensityRangeData *)userdata;
float density = 0.0f;
UNUSED_VARS(co);
if (pdr->point_data_velocity) {
pdr->vec[0] += pdr->point_data_velocity[index * 3 + 0]; // * density;
pdr->vec[1] += pdr->point_data_velocity[index * 3 + 1]; // * density;
pdr->vec[2] += pdr->point_data_velocity[index * 3 + 2]; // * density;
}
if (pdr->point_data_life) {
*pdr->age += pdr->point_data_life[index]; // * density;
}
if (pdr->point_data_color) {
add_v3_v3(pdr->col, &pdr->point_data_color[index * 3]); // * density;
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
density = density_falloff(pdr, index, squared_dist);
*pdr->density += density;
}
2019-03-25 11:55:36 +11:00
static void init_pointdensityrangedata(PointDensity *pd,
PointDensityRangeData *pdr,
float *density,
float *vec,
float *age,
float *col,
CurveMapping *density_curve,
2019-03-25 11:55:36 +11:00
float velscale)
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
{
pdr->squared_radius = pd->radius * pd->radius;
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
pdr->density = density;
pdr->falloff_type = pd->falloff_type;
pdr->vec = vec;
pdr->age = age;
pdr->col = col;
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
pdr->softness = pd->falloff_softness;
pdr->noise_influence = pd->noise_influence;
point_data_pointers(
pd, &pdr->point_data_velocity, &pdr->point_data_life, &pdr->point_data_color);
pdr->density_curve = density_curve;
pdr->velscale = velscale;
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
static int pointdensity(PointDensity *pd,
const float texvec[3],
TexResult *texres,
float r_vec[3],
float *r_age,
float r_col[3])
* Volumetrics Removed all the old particle rendering code and options I had in there before, in order to make way for... A new procedural texture: 'Point Density' Point Density is a 3d texture that find the density of a group of 'points' in space and returns that in the texture as an intensity value. Right now, its at an early stage and it's only enabled for particles, but it would be cool to extend it later for things like object vertices, or point cache files from disk - i.e. to import point cloud data into Blender for rendering volumetrically. Currently there are just options for an Object and its particle system number, this is the particle system that will get cached before rendering, and then used for the texture's density estimation. It works totally consistent with as any other procedural texture, so previously where I've mapped a clouds texture to volume density to make some of those test renders, now I just map a point density texture to volume density. Here's a version of the same particle smoke test file from before, updated to use the point density texture instead: http://mke3.net/blender/devel/rendering/volumetrics/smoke_test02.blend There are a few cool things about implementing this as a texture: - The one texture (and cache) can be instanced across many different materials: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_instanced.png This means you can calculate and bake one particle system, but render it multiple times across the scene, with different material settings, at no extra memory cost. Right now, the particles are cached in world space, so you have to map it globally, and if you want it offset, you have to do it in the material (as in the file above). I plan to add an option to bake in local space, so you can just map the texture to local and it just works. - It also works for solid surfaces too, it just gets the density at that particular point on the surface, eg: http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_solid.mov - You can map it to whatever you want, not only density but the various emissions and colours as well. I'd like to investigate using the other outputs in the texture too (like the RGB or normal outputs), perhaps with options to colour by particle age, generating normals for making particle 'dents' in a surface, whatever!
2008-09-28 08:00:22 +00:00
{
int retval = TEX_INT;
PointDensityRangeData pdr;
Remove Blender Internal and legacy viewport from Blender 2.8. Brecht authored this commit, but he gave me the honours to actually do it. Here it goes; Blender Internal. Bye bye, you did great! * Point density, voxel data, ocean, environment map textures were removed, as these only worked within BI rendering. Note that the ocean modifier and the Cycles point density shader node continue to work. * Dynamic paint using material shading was removed, as this only worked with BI. If we ever wanted to support this again probably it should go through the baking API. * GPU shader export through the Python API was removed. This only worked for the old BI GLSL shaders, which no longer exists. Doing something similar for Eevee would be significantly more complicated because it uses a lot of multiplass rendering and logic outside the shader, it's probably impractical. * Collada material import / export code is mostly gone, as it only worked for BI materials. We need to add Cycles / Eevee material support at some point. * The mesh noise operator was removed since it only worked with BI material texture slots. A displacement modifier can be used instead. * The delete texture paint slot operator was removed since it only worked for BI material texture slots. Could be added back with node support. * Not all legacy viewport features are supported in the new viewport, but their code was removed. If we need to bring anything back we can look at older git revisions. * There is some legacy viewport code that I could not remove yet, and some that I probably missed. * Shader node execution code was left mostly intact, even though it is not used anywhere now. We may eventually use this to replace the texture nodes with Cycles / Eevee shader nodes. * The Cycles Bake panel now includes settings for baking multires normal and displacement maps. The underlying code needs to be merged properly, and we plan to add back support for multires AO baking and add support to Cycles baking for features like vertex color, displacement, and other missing baking features. * This commit removes DNA and the Python API for BI material, lamp, world and scene settings. This breaks a lot of addons. * There is more DNA that can be removed or renamed, where Cycles or Eevee are reusing some old BI properties but the names are not really correct anymore. * Texture slots for materials, lamps and world were removed. They remain for brushes, particles and freestyle linestyles. * 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and other renderers use this to find all panels to show, minus a few panels that they have their own replacement for.
2018-04-19 17:34:44 +02:00
float density = 0.0f, age = 0.0f;
float vec[3] = {0.0f, 0.0f, 0.0f}, col[3] = {0.0f, 0.0f, 0.0f}, co[3];
float turb, noise_fac;
int num = 0;
texres->tin = 0.0f;
init_pointdensityrangedata(pd,
&pdr,
&density,
vec,
&age,
col,
(pd->flag & TEX_PD_FALLOFF_CURVE ? pd->falloff_curve : nullptr),
2019-03-25 11:55:36 +11:00
pd->falloff_speed_scale * 0.001f);
noise_fac = pd->noise_fac * 0.5f; /* better default */
copy_v3_v3(co, texvec);
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
if (point_data_used(pd)) {
/* does a BVH lookup to find accumulated density and additional point data *
* stores particle velocity vector in 'vec', and particle lifetime in 'time' */
num = BLI_bvhtree_range_query(
static_cast<const BVHTree *>(pd->point_tree), co, pd->radius, accum_density, &pdr);
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
if (num > 0) {
age /= num;
mul_v3_fl(vec, 1.0f / num);
mul_v3_fl(col, 1.0f / num);
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
/* reset */
density = 0.0f;
zero_v3(vec);
zero_v3(col);
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
if (pd->flag & TEX_PD_TURBULENCE) {
turb = BLI_noise_generic_turbulence(pd->noise_size,
texvec[0] + vec[0],
texvec[1] + vec[1],
texvec[2] + vec[2],
pd->noise_depth,
false,
pd->noise_basis);
2019-03-25 11:55:36 +11:00
turb -= 0.5f; /* re-center 0.0-1.0 range around 0 to prevent offsetting result */
/* now we have an offset coordinate to use for the density lookup */
co[0] = texvec[0] + noise_fac * turb;
co[1] = texvec[1] + noise_fac * turb;
co[2] = texvec[2] + noise_fac * turb;
}
/* BVH query with the potentially perturbed coordinates */
num = BLI_bvhtree_range_query(
static_cast<const BVHTree *>(pd->point_tree), co, pd->radius, accum_density, &pdr);
if (num > 0) {
age /= num;
mul_v3_fl(vec, 1.0f / num);
mul_v3_fl(col, 1.0f / num);
}
texres->tin = density;
if (r_age != nullptr) {
*r_age = age;
}
if (r_vec != nullptr) {
copy_v3_v3(r_vec, vec);
}
if (r_col != nullptr) {
copy_v3_v3(r_col, col);
}
return retval;
}
2018-05-13 14:10:05 +02:00
static void pointdensity_color(
PointDensity *pd, TexResult *texres, float age, const float vec[3], const float col[3])
{
2022-01-28 13:28:31 +01:00
copy_v4_fl(texres->trgba, 1.0f);
if (pd->source == TEX_PD_PSYS) {
float rgba[4];
switch (pd->color_source) {
case TEX_PD_COLOR_PARTAGE:
if (pd->coba) {
2017-12-07 15:52:59 +11:00
if (BKE_colorband_evaluate(pd->coba, age, rgba)) {
texres->talpha = true;
2022-01-28 13:28:31 +01:00
copy_v3_v3(texres->trgba, rgba);
texres->tin *= rgba[3];
2022-01-28 13:28:31 +01:00
texres->trgba[3] = texres->tin;
}
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
break;
case TEX_PD_COLOR_PARTSPEED: {
float speed = len_v3(vec) * pd->speed_scale;
if (pd->coba) {
2017-12-07 15:52:59 +11:00
if (BKE_colorband_evaluate(pd->coba, speed, rgba)) {
texres->talpha = true;
2022-01-28 13:28:31 +01:00
copy_v3_v3(texres->trgba, rgba);
texres->tin *= rgba[3];
2022-01-28 13:28:31 +01:00
texres->trgba[3] = texres->tin;
}
}
break;
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
case TEX_PD_COLOR_PARTVEL:
texres->talpha = true;
2022-01-28 13:28:31 +01:00
mul_v3_v3fl(texres->trgba, vec, pd->speed_scale);
texres->trgba[3] = texres->tin;
break;
case TEX_PD_COLOR_CONSTANT:
default:
break;
}
}
else {
float rgba[4];
switch (pd->ob_color_source) {
case TEX_PD_COLOR_VERTCOL:
texres->talpha = true;
2022-01-28 13:28:31 +01:00
copy_v3_v3(texres->trgba, col);
texres->trgba[3] = texres->tin;
break;
case TEX_PD_COLOR_VERTWEIGHT:
texres->talpha = true;
2017-12-07 15:52:59 +11:00
if (pd->coba && BKE_colorband_evaluate(pd->coba, col[0], rgba)) {
2022-01-28 13:28:31 +01:00
copy_v3_v3(texres->trgba, rgba);
texres->tin *= rgba[3];
}
else {
2022-01-28 13:28:31 +01:00
copy_v3_v3(texres->trgba, col);
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
2022-01-28 13:28:31 +01:00
texres->trgba[3] = texres->tin;
break;
case TEX_PD_COLOR_VERTNOR:
texres->talpha = true;
2022-01-28 13:28:31 +01:00
copy_v3_v3(texres->trgba, col);
texres->trgba[3] = texres->tin;
break;
case TEX_PD_COLOR_CONSTANT:
default:
break;
Point Density texture: colouring This introduces a few new ways of modifying the intensity and colour output generated by the Point Density texture. Previously, the texture only output intensity information, but now you can map it to colours along a gradient ramp, based on information coming out of a particle system. This lets you do things like colour a particle system based on the individual particles' age - the main reason I need it is to fade particles out over time. The colorband influences both the colour and intensity (using the colorband's alpha value), which makes it easy to map a single point density texture to both intensity values in the Map To panel (such as density or emit) and colour values (such as absorb col or emit col). This is how the below examples are set up, an example .blend file is available here: http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend The different modes: * Constant No modifications to intensity or colour (pure white) * Particle Age Maps the color ramp along the particles' lifetimes: http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov * Particle Speed Maps the color ramp to the particles' absolute speed per frame (in Blender units). There's an additional scale parameter that you can use to bring this speed into a 0.0 - 1.0 range, if your particles are travelling too faster or slower than 0-1. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov * Velocity -> RGB Outputs the particle XYZ velocity vector as RGB colours. This may be useful for comp work, or maybe in the future things like displacement. Again, there's a scale parameter to control it. http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
2008-11-09 01:16:12 +00:00
}
}
}
static void sample_dummy_point_density(int resolution, float *values)
{
memset(values, 0, sizeof(float[4]) * resolution * resolution * resolution);
}
static void particle_system_minmax(Depsgraph *depsgraph,
Scene *scene,
Object *object,
ParticleSystem *psys,
float radius,
float min[3],
float max[3])
{
const float size[3] = {radius, radius, radius};
const float cfra = BKE_scene_ctime_get(scene);
ParticleSettings *part = psys->part;
ParticleSimulationData sim = {nullptr};
ParticleData *pa = nullptr;
int i;
int total_particles;
float mat[4][4], imat[4][4];
INIT_MINMAX(min, max);
if (part->type == PART_HAIR) {
/* TODO(sergey): Not supported currently. */
return;
}
unit_m4(mat);
sim.depsgraph = depsgraph;
sim.scene = scene;
sim.ob = object;
sim.psys = psys;
sim.psmd = psys_get_modifier(object, psys);
invert_m4_m4(imat, object->object_to_world);
total_particles = psys->totpart + psys->totchild;
psys_sim_data_init(&sim);
for (i = 0, pa = psys->particles; i < total_particles; i++, pa++) {
float co_object[3], co_min[3], co_max[3];
ParticleKey state;
state.time = cfra;
if (!psys_get_particle_state(&sim, i, &state, false)) {
continue;
}
mul_v3_m4v3(co_object, imat, state.co);
sub_v3_v3v3(co_min, co_object, size);
add_v3_v3v3(co_max, co_object, size);
minmax_v3v3_v3(min, max, co_min);
minmax_v3v3_v3(min, max, co_max);
}
psys_sim_data_free(&sim);
}
void RE_point_density_cache(Depsgraph *depsgraph, PointDensity *pd)
{
Scene *scene = DEG_get_evaluated_scene(depsgraph);
2019-09-19 11:30:01 +02:00
/* Same matrices/resolution as dupli_render_particle_set(). */
BLI_mutex_lock(&sample_mutex);
cache_pointdensity(depsgraph, scene, pd);
BLI_mutex_unlock(&sample_mutex);
}
void RE_point_density_minmax(Depsgraph *depsgraph,
PointDensity *pd,
float r_min[3],
float r_max[3])
{
Scene *scene = DEG_get_evaluated_scene(depsgraph);
Object *object = pd->object;
if (object == nullptr) {
zero_v3(r_min);
zero_v3(r_max);
return;
}
if (pd->source == TEX_PD_PSYS) {
ParticleSystem *psys;
if (pd->psys == 0) {
zero_v3(r_min);
zero_v3(r_max);
return;
}
psys = static_cast<ParticleSystem *>(BLI_findlink(&object->particlesystem, pd->psys - 1));
if (psys == nullptr) {
zero_v3(r_min);
zero_v3(r_max);
return;
}
particle_system_minmax(depsgraph, scene, object, psys, pd->radius, r_min, r_max);
}
else {
const float radius[3] = {pd->radius, pd->radius, pd->radius};
const BoundBox *bb = BKE_object_boundbox_get(object);
if (bb != nullptr) {
BLI_assert((bb->flag & BOUNDBOX_DIRTY) == 0);
copy_v3_v3(r_min, bb->vec[0]);
copy_v3_v3(r_max, bb->vec[6]);
/* Adjust texture space to include density points on the boundaries. */
sub_v3_v3(r_min, radius);
add_v3_v3(r_max, radius);
}
else {
zero_v3(r_min);
zero_v3(r_max);
}
}
}
struct SampleCallbackData {
PointDensity *pd;
int resolution;
float *min, *dim;
float *values;
};
static void point_density_sample_func(void *__restrict data_v,
const int iter,
const TaskParallelTLS *__restrict /*tls*/)
{
SampleCallbackData *data = (SampleCallbackData *)data_v;
const int resolution = data->resolution;
const int resolution2 = resolution * resolution;
const float *min = data->min, *dim = data->dim;
PointDensity *pd = data->pd;
float *values = data->values;
2018-05-13 14:10:05 +02:00
if (!pd || !pd->point_tree) {
return;
}
size_t z = size_t(iter);
for (size_t y = 0; y < resolution; y++) {
for (size_t x = 0; x < resolution; x++) {
size_t index = z * resolution2 + y * resolution + x;
float texvec[3];
float age, vec[3], col[3];
TexResult texres;
copy_v3_v3(texvec, min);
texvec[0] += dim[0] * float(x) / float(resolution);
texvec[1] += dim[1] * float(y) / float(resolution);
texvec[2] += dim[2] * float(z) / float(resolution);
2018-04-21 19:35:12 +02:00
pointdensity(pd, texvec, &texres, vec, &age, col);
pointdensity_color(pd, &texres, age, vec, col);
2022-01-28 13:28:31 +01:00
copy_v3_v3(&values[index * 4 + 0], texres.trgba);
2019-03-25 11:55:36 +11:00
values[index * 4 + 3] = texres.tin;
}
}
}
void RE_point_density_sample(Depsgraph *depsgraph,
PointDensity *pd,
const int resolution,
float *values)
{
Object *object = pd->object;
float min[3], max[3], dim[3];
/* TODO(sergey): Implement some sort of assert() that point density
* was cached already.
*/
if (object == nullptr) {
sample_dummy_point_density(resolution, values);
return;
}
BLI_mutex_lock(&sample_mutex);
RE_point_density_minmax(depsgraph, pd, min, max);
BLI_mutex_unlock(&sample_mutex);
sub_v3_v3v3(dim, max, min);
if (dim[0] <= 0.0f || dim[1] <= 0.0f || dim[2] <= 0.0f) {
sample_dummy_point_density(resolution, values);
return;
}
SampleCallbackData data;
data.pd = pd;
data.resolution = resolution;
data.min = min;
data.dim = dim;
data.values = values;
TaskParallelSettings settings;
BLI_parallel_range_settings_defaults(&settings);
settings.use_threading = (resolution > 32);
BLI_task_parallel_range(0, resolution, &data, point_density_sample_func, &settings);
free_pointdensity(pd);
}
void RE_point_density_free(PointDensity *pd)
{
free_pointdensity(pd);
}
Remove Blender Internal and legacy viewport from Blender 2.8. Brecht authored this commit, but he gave me the honours to actually do it. Here it goes; Blender Internal. Bye bye, you did great! * Point density, voxel data, ocean, environment map textures were removed, as these only worked within BI rendering. Note that the ocean modifier and the Cycles point density shader node continue to work. * Dynamic paint using material shading was removed, as this only worked with BI. If we ever wanted to support this again probably it should go through the baking API. * GPU shader export through the Python API was removed. This only worked for the old BI GLSL shaders, which no longer exists. Doing something similar for Eevee would be significantly more complicated because it uses a lot of multiplass rendering and logic outside the shader, it's probably impractical. * Collada material import / export code is mostly gone, as it only worked for BI materials. We need to add Cycles / Eevee material support at some point. * The mesh noise operator was removed since it only worked with BI material texture slots. A displacement modifier can be used instead. * The delete texture paint slot operator was removed since it only worked for BI material texture slots. Could be added back with node support. * Not all legacy viewport features are supported in the new viewport, but their code was removed. If we need to bring anything back we can look at older git revisions. * There is some legacy viewport code that I could not remove yet, and some that I probably missed. * Shader node execution code was left mostly intact, even though it is not used anywhere now. We may eventually use this to replace the texture nodes with Cycles / Eevee shader nodes. * The Cycles Bake panel now includes settings for baking multires normal and displacement maps. The underlying code needs to be merged properly, and we plan to add back support for multires AO baking and add support to Cycles baking for features like vertex color, displacement, and other missing baking features. * This commit removes DNA and the Python API for BI material, lamp, world and scene settings. This breaks a lot of addons. * There is more DNA that can be removed or renamed, where Cycles or Eevee are reusing some old BI properties but the names are not really correct anymore. * Texture slots for materials, lamps and world were removed. They remain for brushes, particles and freestyle linestyles. * 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and other renderers use this to find all panels to show, minus a few panels that they have their own replacement for.
2018-04-19 17:34:44 +02:00
void RE_point_density_fix_linking() {}