sandey/blender
1
0
Fork 0
forked from bartvdbraak/blender
Code Pull Requests Activity
6f43e1dfef
blender/intern/cycles/kernel/kernel_path.h

1270 lines
38 KiB
C
Raw Normal View History

Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/*
Cycles: relicense GNU GPL source code to Apache version 2.0. More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
* Copyright 2011-2013 Blender Foundation
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
*
Cycles: relicense GNU GPL source code to Apache version 2.0. More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
*
Cycles: relicense GNU GPL source code to Apache version 2.0. More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
* http://www.apache.org/licenses/LICENSE-2.0
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
*
Cycles: relicense GNU GPL source code to Apache version 2.0. More information in this post: http://code.blender.org/ Thanks to all contributes for giving their permission!
2013-08-18 14:16:15 +00:00
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
Cleanup: Fix Cycles Apache header. This was already mixed a bit, but the dot belongs there.
2014-12-25 01:50:24 +00:00
* limitations under the License.
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
*/
Fix #33375: OSL geom:trianglevertices gave wrong coordinates for static BVH. Also some simple OSL optimization, passing thread data pointer directly instead of via thread local storage, and creating ustrings for attribute lookup.
2012-12-01 19:15:05 +00:00
#ifdef __OSL__
#include "osl_shader.h"
#endif
Cycles code refactor: move geometry related kernel files into own directory.
2014-03-29 12:03:45 +00:00
#include "kernel_random.h"
Cycles code refactor: move more code to geom folder, add some comments.
2014-03-29 12:03:48 +00:00
#include "kernel_projection.h"
#include "kernel_montecarlo.h"
#include "kernel_differential.h"
#include "kernel_camera.h"
Cycles code refactor: move geometry related kernel files into own directory.
2014-03-29 12:03:45 +00:00
Cycles code refactor: move more code to geom folder, add some comments.
2014-03-29 12:03:48 +00:00
#include "geom/geom.h"
Cycles code refactor: move geometry related kernel files into own directory.
2014-03-29 12:03:45 +00:00
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
#include "kernel_accumulate.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
#include "kernel_shader.h"
#include "kernel_light.h"
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
#include "kernel_passes.h"
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
#ifdef __SUBSURFACE__
#include "kernel_subsurface.h"
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
#ifdef __VOLUME__
#include "kernel_volume.h"
#endif
Cycles Volume Render: add support for overlapping volume objects. This works pretty much as you would expect, overlapping volume objects gives a more dense volume. What did change is that world volume shaders are now active everywhere, they are no longer excluded inside objects. This may not be desirable and we need to think of better control over this. In some cases you clearly want it to happen, for example if you are rendering a fire in a foggy environment. In other cases like the inside of a house you may not want any fog, but it doesn't seem possible in general for the renderer to automatically determine what is inside or outside of the house. This is implemented using a simple fixed size array of shader/object ID pairs, limited to max 15 overlapping objects. The closures from all shaders are put into a single closure array, exactly the same as if an add shader was used to combine them.
2013-12-28 19:02:40 +00:00
#include "kernel_path_state.h"
Code cleanup: move shadow_blocked function into separate file.
2013-12-28 01:56:53 +00:00
#include "kernel_shadow.h"
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
#include "kernel_emission.h"
Cycles code refactor: move some surface and volume path code to separate files.
2014-04-04 12:35:30 +00:00
#include "kernel_path_surface.h"
#include "kernel_path_volume.h"
Cycles: * Fix missing update when editing objects with emission materials. * Fix preview pass rendering set to 1 not showing full resolution. * Fix CUDA runtime compiling failing due to missing cache directory. * Use settings from first render layer for visibility and material override. And a bunch of incomplete and still disabled code mostly related to closure sampling.
2011-09-12 13:13:56 +00:00
Cycles: Add support for debug passes Currently only summed number of traversal steps and intersections used by the camera ray intersection pass is implemented, but in the future we will support more debug passes which would help checking what things makes the scene slow. Example of such extra passes could be number of bounces, time spent on the shader tree evaluation and so. Implementation from the Cycles side is pretty much straightforward, could only mention here that it's a build-time option disabled by default. From the blender side it's implemented as a PASS_DEBUG with several subtypes possible. This way we don't need to create an extra DNA pass type for each of the debug passes, saving us a bits. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D813
2014-10-04 13:00:26 +00:00
#ifdef __KERNEL_DEBUG__
Cycles: Make OpenCL folks happy to use __KERNEL_DEBUG__ Quite straightforward change, the only annoying thing is that we can't use indentation for include directive just because of the way headers inlineing works for OpenCL. Might do smarter job in path_source_replace_includes() but don't want to spend time on this yet.
2014-10-05 10:00:23 +00:00
#include "kernel_debug.h"
Cycles: Add support for debug passes Currently only summed number of traversal steps and intersections used by the camera ray intersection pass is implemented, but in the future we will support more debug passes which would help checking what things makes the scene slow. Example of such extra passes could be number of bounces, time spent on the shader tree evaluation and so. Implementation from the Cycles side is pretty much straightforward, could only mention here that it's a build-time option disabled by default. From the blender side it's implemented as a PASS_DEBUG with several subtypes possible. This way we don't need to create an extra DNA pass type for each of the debug passes, saving us a bits. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D813
2014-10-04 13:00:26 +00:00
#endif
Code cleanup: move shadow_blocked function into separate file.
2013-12-28 01:56:53 +00:00
CCL_NAMESPACE_BEGIN
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 21:05:07 +00:00
ccl_device void kernel_path_indirect(KernelGlobals *kg, RNG *rng, Ray ray,
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
float3 throughput, int num_samples, PathState state, PathRadiance *L)
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
{
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* path iteration */
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
for(;;) {
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* intersect scene */
Intersection isect;
Cycles: code refactoring, to do render layer visibility test a bit different, replacing the camera visibility flag with object layer flags.
2011-12-21 20:51:43 +00:00
uint visibility = path_state_ray_visibility(kg, &state);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
bool hit = scene_intersect(kg, &ray, visibility, &isect, NULL, 0.0f, 0.0f);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
#ifdef __LAMP_MIS__
Cycles: make multiple importance sampling for lamps an option per lamp now, disabled by default for backwards compatibility. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Integrator
2013-01-30 15:57:15 +00:00
if(kernel_data.integrator.use_lamp_mis && !(state.flag & PATH_RAY_CAMERA)) {
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
/* ray starting from previous non-transparent bounce */
Ray light_ray;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
light_ray.P = ray.P - state.ray_t*ray.D;
state.ray_t += isect.t;
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
light_ray.D = ray.D;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
light_ray.t = state.ray_t;
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
light_ray.time = ray.time;
Possible fix for #35198: uninitialized memory access with background multiple importance sampling + OSL.
2013-05-03 05:24:05 +00:00
light_ray.dD = ray.dD;
light_ray.dP = ray.dP;
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
/* intersect with lamp */
float3 emission;
Cycles: MIS for lamps now loops over all lamps instead of picking one. Probably will not be noticed in most scenes. This helps reduce noise when you have multiple lamps with MIS enabled, at the cost of some performance, but from testing some scenes this seems better.
2014-05-01 17:18:42 +00:00
if(indirect_lamp_emission(kg, &state, &light_ray, &emission))
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
path_radiance_accum_emission(L, throughput, emission, state.bounce);
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
}
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
#ifdef __VOLUME__
Code refactor: better distinguish scatter and absorption for volume integration.
2013-12-29 14:49:16 +00:00
/* volume attenuation, emission, scatter */
Cycles code refactor: replace magic ~0 values in the code with defines.
2014-03-29 12:03:47 +00:00
if(state.volume_stack[0].shader != SHADER_NONE) {
Cycles Volume Render: heterogeneous (textured) volumes support. Volumes can now have textured colors and density. There is a Volume Sampling panel in the Render properties with these settings: * Step size: distance between volume shader samples when rendering the volume. Lower values give more accurate and detailed results but also increased render time. * Max steps: maximum number of steps through the volume before giving up, to protect from extremely long render times with big objects or small step sizes. This is much more compute intensive than homogeneous volume, so when you are not using a texture you should enable the Homogeneous Volume option in the material or world for faster rendering. One important missing feature is that Generated texture coordinates are not yet working in volumes, and they are the default coordinates for nearly all texture nodes. So until that works you need to plug in object texture coordinates or a world space position. This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-29 21:19:38 +00:00
Ray volume_ray = ray;
volume_ray.t = (hit)? isect.t: FLT_MAX;
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
bool heterogeneous = volume_stack_is_heterogeneous(kg, state.volume_stack);
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#ifdef __VOLUME_DECOUPLED__
Cycles: Avoid call to volume_stack_sampling_method() on GPU, Decoupled is required for Equi-Angular/MIS.
2014-08-24 13:58:41 +00:00
int sampling_method = volume_stack_sampling_method(kg, state.volume_stack);
Cycles: volume sampling method can now be set per material/world. This gives you "Multiple Importance", "Distance" and "Equiangular" choices. What multiple importance sampling does is make things more robust to certain types of noise at the cost of a bit more noise in cases where the individual strategies are always better. So if you've got a pretty dense volume that's lit from far away then distance sampling is usually more efficient. If you've got a light inside or near the volume then equiangular sampling is better. If you have a combination of both, then the multiple importance sampling will be better.
2014-06-07 16:47:14 +00:00
bool decoupled = kernel_volume_use_decoupled(kg, heterogeneous, false, sampling_method);
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
if(decoupled) {
/* cache steps along volume for repeated sampling */
VolumeSegment volume_segment;
ShaderData volume_sd;
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
shader_setup_from_volume(kg, &volume_sd, &volume_ray, state.bounce, state.transparent_bounce);
kernel_volume_decoupled_record(kg, &state,
&volume_ray, &volume_sd, &volume_segment, heterogeneous);
Cycles: volume sampling method can now be set per material/world. This gives you "Multiple Importance", "Distance" and "Equiangular" choices. What multiple importance sampling does is make things more robust to certain types of noise at the cost of a bit more noise in cases where the individual strategies are always better. So if you've got a pretty dense volume that's lit from far away then distance sampling is usually more efficient. If you've got a light inside or near the volume then equiangular sampling is better. If you have a combination of both, then the multiple importance sampling will be better.
2014-06-07 16:47:14 +00:00
volume_segment.sampling_method = sampling_method;
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* emission */
if(volume_segment.closure_flag & SD_EMISSION)
path_radiance_accum_emission(L, throughput, volume_segment.accum_emission, state.bounce);
/* scattering */
VolumeIntegrateResult result = VOLUME_PATH_ATTENUATED;
if(volume_segment.closure_flag & SD_SCATTER) {
bool all = kernel_data.integrator.sample_all_lights_indirect;
/* direct light sampling */
kernel_branched_path_volume_connect_light(kg, rng, &volume_sd,
Cycles: Simplify volume light connect code.
2015-03-12 23:09:13 +00:00
throughput, &state, L, all, &volume_ray, &volume_segment);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* indirect sample. if we use distance sampling and take just
* one sample for direct and indirect light, we could share
* this computation, but makes code a bit complex */
float rphase = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_PHASE);
float rscatter = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_SCATTER_DISTANCE);
result = kernel_volume_decoupled_scatter(kg,
&state, &volume_ray, &volume_sd, &throughput,
rphase, rscatter, &volume_segment, NULL, true);
}
/* free cached steps */
kernel_volume_decoupled_free(kg, &volume_segment);
if(result == VOLUME_PATH_SCATTERED) {
Cleanup: Remove unused variable in kernel_path_volume_bounce().
2014-08-24 21:06:30 +00:00
if(kernel_path_volume_bounce(kg, rng, &volume_sd, &throughput, &state, L, &ray))
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
continue;
else
break;
}
Cycles: Small improvement for volume render (decoupled) Simplify branching here a bit, helps ~3% in volume_light_sampling.blend (Branched MIS scene).
2015-02-14 19:44:30 +00:00
else {
throughput *= volume_segment.accum_transmittance;
}
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
}
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
else
#endif
{
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* integrate along volume segment with distance sampling */
ShaderData volume_sd;
VolumeIntegrateResult result = kernel_volume_integrate(
Cycles: Avoid redundant call to volume_stack_is_heterogeneous() for Distance Sampling.
2014-08-24 14:15:57 +00:00
kg, &state, &volume_sd, &volume_ray, L, &throughput, rng, heterogeneous);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#ifdef __VOLUME_SCATTER__
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
if(result == VOLUME_PATH_SCATTERED) {
/* direct lighting */
Fix T41693: Volumes get brightened with extra volume samples on GPU + BPT
2014-09-03 15:23:07 +00:00
kernel_path_volume_connect_light(kg, rng, &volume_sd, throughput, &state, L);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* indirect light bounce */
Cleanup: Remove unused variable in kernel_path_volume_bounce().
2014-08-24 21:06:30 +00:00
if(kernel_path_volume_bounce(kg, rng, &volume_sd, &throughput, &state, L, &ray))
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
continue;
else
break;
}
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#endif
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
}
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
}
#endif
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
if(!hit) {
Cycles: fixes for OpenCL build after pass changes, patch by Daniel Genrich.
2012-01-26 15:37:33 +00:00
#ifdef __BACKGROUND__
Cycles: merging features from tomato branch. === BVH build time optimizations === * BVH building was multithreaded. Not all building is multithreaded, packing and the initial bounding/splitting is still single threaded, but recursive splitting is, which was the main bottleneck. * Object splitting now uses binning rather than sorting of all elements, using code from the Embree raytracer from Intel. http://software.intel.com/en-us/articles/embree-photo-realistic-ray-tracing-kernels/ * Other small changes to avoid allocations, pack memory more tightly, avoid some unnecessary operations, ... These optimizations do not work yet when Spatial Splits are enabled, for that more work is needed. There's also other optimizations still needed, in particular for the case of many low poly objects, the packing step and node memory allocation. BVH raytracing time should remain about the same, but BVH build time should be significantly reduced, test here show speedup of about 5x to 10x on a dual core and 5x to 25x on an 8-core machine, depending on the scene. === Threads === Centralized task scheduler for multithreading, which is basically the CPU device threading code wrapped into something reusable. Basic idea is that there is a single TaskScheduler that keeps a pool of threads, one for each core. Other places in the code can then create a TaskPool that they can drop Tasks in to be executed by the scheduler, and wait for them to complete or cancel them early. === Normal ==== Added a Normal output to the texture coordinate node. This currently gives the object space normal, which is the same under object animation. In the future this might become a "generated" normal so it's also stable for deforming objects, but for now it's already useful for non-deforming objects. === Render Layers === Per render layer Samples control, leaving it to 0 will use the common scene setting. Environment pass will now render environment even if film is set to transparent. Exclude Layers" added. Scene layers (all object that influence the render, directly or indirectly) are shared between all render layers. However sometimes it's useful to leave out some object influence for a particular render layer. That's what this option allows you to do. === Filter Glossy === When using a value higher than 0.0, this will blur glossy reflections after blurry bounces, to reduce noise at the cost of accuracy. 1.0 is a good starting value to tweak. Some light paths have a low probability of being found while contributing much light to the pixel. As a result these light paths will be found in some pixels and not in others, causing fireflies. An example of such a difficult path might be a small light that is causing a small specular highlight on a sharp glossy material, which we are seeing through a rough glossy material. With path tracing it is difficult to find the specular highlight, but if we increase the roughness on the material the highlight gets bigger and softer, and so easier to find. Often this blurring will be hardly noticeable, because we are seeing it through a blurry material anyway, but there are also cases where this will lead to a loss of detail in lighting.
2012-04-28 08:53:59 +00:00
/* sample background shader */
Cleanup: Pass PathState as a whole, instead of individual members. Differential Revision: https://developer.blender.org/D477
2014-04-21 15:51:51 +00:00
float3 L_background = indirect_background(kg, &state, &ray);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
path_radiance_accum_background(L, throughput, L_background, state.bounce);
Cycles: fixes for OpenCL build after pass changes, patch by Daniel Genrich.
2012-01-26 15:37:33 +00:00
#endif
Cycles: * Add alpha pass output, to use set Transparent option in Film panel. * Add Holdout closure (OSL terminology), this is like the Sky option in the internal renderer, objects with this closure show the background / zero alpha. * Add option to use Gaussian instead of Box pixel filter in the UI. * Remove camera response curves for now, they don't really belong here in the pipeline, should be moved to compositor. * Output full float values for rendering now, previously was only byte precision. * Add a patch from Thomas to get a preview passes option, but still disabled because it isn't quite working right yet. * CUDA: don't compile shader graph evaluation inline. * Convert tabs to spaces in python files.
2011-08-28 13:55:59 +00:00
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
break;
}
/* setup shading */
ShaderData sd;
Cycles: add Transparent Depth output to Light Path node. This can for example be useful if you want to manually terminate the path at some point and use a color other than black. Reviewed By: brecht Differential Revision: https://developer.blender.org/D454
2014-04-21 12:20:29 +00:00
shader_setup_from_ray(kg, &sd, &isect, &ray, state.bounce, state.transparent_bounce);
Fix T39804: cycles smoke domain visible in rendering. Transparent objects could become subtly visible by the different sampling patterns for pixels covered and not covered by the object. It still converged to the right solution but that can take a while. Now we try to use the same sampling pattern here.
2014-05-29 12:12:12 +00:00
float rbsdf = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_BSDF);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
shader_eval_surface(kg, &sd, rbsdf, state.flag, SHADER_CONTEXT_INDIRECT);
Cycles: * Fix some compile errors, when building without Branched Path.
2013-09-08 17:20:47 +00:00
#ifdef __BRANCHED_PATH__
Cycles Volume Render: add support for overlapping volume objects. This works pretty much as you would expect, overlapping volume objects gives a more dense volume. What did change is that world volume shaders are now active everywhere, they are no longer excluded inside objects. This may not be desirable and we need to think of better control over this. In some cases you clearly want it to happen, for example if you are rendering a fire in a foggy environment. In other cases like the inside of a house you may not want any fog, but it doesn't seem possible in general for the renderer to automatically determine what is inside or outside of the house. This is implemented using a simple fixed size array of shader/object ID pairs, limited to max 15 overlapping objects. The closures from all shaders are put into a single closure array, exactly the same as if an add shader was used to combine them.
2013-12-28 19:02:40 +00:00
shader_merge_closures(&sd);
Cycles: * Fix some compile errors, when building without Branched Path.
2013-09-08 17:20:47 +00:00
#endif
Fix #35614: cycles objects on mask layer in render layers were writing passes such as motion/uv/normal but they should have been excluded from them.
2013-06-04 15:41:45 +00:00
/* blurring of bsdf after bounces, for rays that have a small likelihood
* of following this particular path (diffuse, rough glossy) */
if(kernel_data.integrator.filter_glossy != FLT_MAX) {
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
float blur_pdf = kernel_data.integrator.filter_glossy*state.min_ray_pdf;
Fix #35614: cycles objects on mask layer in render layers were writing passes such as motion/uv/normal but they should have been excluded from them.
2013-06-04 15:41:45 +00:00
if(blur_pdf < 1.0f) {
float blur_roughness = sqrtf(1.0f - blur_pdf)*0.5f;
shader_bsdf_blur(kg, &sd, blur_roughness);
}
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
#ifdef __EMISSION__
/* emission */
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
if(sd.flag & SD_EMISSION) {
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
float3 emission = indirect_primitive_emission(kg, &sd, isect.t, state.flag, state.ray_pdf);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
path_radiance_accum_emission(L, throughput, emission, state.bounce);
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
}
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
#endif
/* path termination. this is a strange place to put the termination, it's
style cleanup: block comments
2012-06-09 17:22:52 +00:00
* mainly due to the mixed in MIS that we use. gives too many unneeded
* shader evaluations, only need emission if we are going to terminate */
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
float probability = path_state_terminate_probability(kg, &state, throughput*num_samples);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
if(probability == 0.0f) {
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
break;
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
}
else if(probability != 1.0f) {
Fix T39804: cycles smoke domain visible in rendering. Transparent objects could become subtly visible by the different sampling patterns for pixels covered and not covered by the object. It still converged to the right solution but that can take a while. Now we try to use the same sampling pattern here.
2014-05-29 12:12:12 +00:00
float terminate = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_TERMINATE);
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
if(terminate >= probability)
break;
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
throughput /= probability;
}
Cycles: * Add max diffuse/glossy/transmission bounces * Add separate min/max for transparent depth * Updated/added some presets that use these options * Add ray visibility options for objects, to hide them from camera/diffuse/glossy/transmission/shadow rays * Is singular ray output for light path node Details here: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/LightPaths
2011-09-01 15:53:36 +00:00
Cycles: ambient occlusion support, with AO factor and distance, and a render pass. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/World#Ambient_Occlusion http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes#Lighting_Passes
2012-02-28 16:45:08 +00:00
#ifdef __AO__
/* ambient occlusion */
Cycles: 4 new nodes. * Tangent: generate a tangent direction for anisotropic shading. Can be either radial around X/Y/Z axis, or from a UV map. The default tangent for the anisotropic BSDF and geometry node is now always radial Z, for UV tangent use this node now. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Tangent * Normal Map: generate a perturbed normal from an RGB normal map image. This is usually chained with an Image Texture node in the color input, to specify the normal map image. For tangent space normal maps, the UV coordinates for the image must match, and the image texture should be set to Non-Color mode to give correct results. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Normal_Map * Refraction BSDF: for best results this node should be considered as a building block and not be used on its own, but rather mixed with a glossy node using a fresnel type factor. Otherwise it will give quite dark results at the edges for glossy refraction. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Refraction * Ambient Occlusion: controls the amount of AO a surface receives, rather than having just a global factor in the world. Note that this outputs a shader and not a color, that's for another time. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Ambient_Occlusion
2012-11-06 19:59:02 +00:00
if(kernel_data.integrator.use_ambient_occlusion || (sd.flag & SD_AO)) {
Fix #35665: more CUDA issues with recent kernel changes, tested on sm_20, sm_21 and sm_30 cards, so hopefully it should all work now. Also includes some warnings fixes related to nvcc compiler arguments, should make no difference otherwise.
2013-06-11 21:58:48 +00:00
float bsdf_u, bsdf_v;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
path_state_rng_2D(kg, rng, &state, PRNG_BSDF_U, &bsdf_u, &bsdf_v);
Cycles: ambient occlusion support, with AO factor and distance, and a render pass. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/World#Ambient_Occlusion http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes#Lighting_Passes
2012-02-28 16:45:08 +00:00
Cycles: ambient occlusion now takes per-BSDF normals into account.
2012-11-15 15:37:58 +00:00
float ao_factor = kernel_data.background.ao_factor;
float3 ao_N;
float3 ao_bsdf = shader_bsdf_ao(kg, &sd, ao_factor, &ao_N);
Cycles: ambient occlusion support, with AO factor and distance, and a render pass. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/World#Ambient_Occlusion http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes#Lighting_Passes
2012-02-28 16:45:08 +00:00
float3 ao_D;
float ao_pdf;
Fix #36741: cycles AO pass giving values > 1.0 with transparency.
2013-09-17 13:22:42 +00:00
float3 ao_alpha = make_float3(0.0f, 0.0f, 0.0f);
Cycles: ambient occlusion support, with AO factor and distance, and a render pass. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/World#Ambient_Occlusion http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes#Lighting_Passes
2012-02-28 16:45:08 +00:00
Cycles: ambient occlusion now takes per-BSDF normals into account.
2012-11-15 15:37:58 +00:00
sample_cos_hemisphere(ao_N, bsdf_u, bsdf_v, &ao_D, &ao_pdf);
Cycles: ambient occlusion support, with AO factor and distance, and a render pass. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/World#Ambient_Occlusion http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes#Lighting_Passes
2012-02-28 16:45:08 +00:00
Fix #33188: AO pass wrong after recent change.
2012-11-15 21:32:05 +00:00
if(dot(sd.Ng, ao_D) > 0.0f && ao_pdf != 0.0f) {
Cycles: ambient occlusion support, with AO factor and distance, and a render pass. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/World#Ambient_Occlusion http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes#Lighting_Passes
2012-02-28 16:45:08 +00:00
Ray light_ray;
float3 ao_shadow;
light_ray.P = ray_offset(sd.P, sd.Ng);
light_ray.D = ao_D;
light_ray.t = kernel_data.background.ao_distance;
Cycles: camera motion blur enabled. Still more work needed to get object motion blur ready.
2012-10-09 18:37:14 +00:00
#ifdef __OBJECT_MOTION__
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 12:49:26 +00:00
light_ray.time = sd.time;
#endif
Fix #35207: addition to previous fix to avoid OSL getting uninitialized ray differentials for lighting, which could cause bad texture filtering artifacts or performance.
2013-05-03 21:34:51 +00:00
light_ray.dP = sd.dP;
light_ray.dD = differential3_zero();
Cycles: ambient occlusion support, with AO factor and distance, and a render pass. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/World#Ambient_Occlusion http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes#Lighting_Passes
2012-02-28 16:45:08 +00:00
Cycles: ambient occlusion now takes per-BSDF normals into account.
2012-11-15 15:37:58 +00:00
if(!shadow_blocked(kg, &state, &light_ray, &ao_shadow))
Fix #36741: cycles AO pass giving values > 1.0 with transparency.
2013-09-17 13:22:42 +00:00
path_radiance_accum_ao(L, throughput, ao_alpha, ao_bsdf, ao_shadow, state.bounce);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
}
}
#endif
#ifdef __SUBSURFACE__
/* bssrdf scatter to a different location on the same object, replacing
* the closures with a diffuse BSDF */
if(sd.flag & SD_BSSRDF) {
float bssrdf_probability;
ShaderClosure *sc = subsurface_scatter_pick_closure(kg, &sd, &bssrdf_probability);
/* modify throughput for picking bssrdf or bsdf */
throughput *= bssrdf_probability;
/* do bssrdf scatter step if we picked a bssrdf closure */
if(sc) {
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
uint lcg_state = lcg_state_init(rng, &state, 0x68bc21eb);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
Cycles / SSS: * Remove the compatible falloff SSS implementation. We shouldn't support two implementations in the long term, and 2.7x is a good release number do break some compatibility as well. * Version patch added, so Files with Compatible falloff will automatically use Cubic now. It was already mentioned in the manual, that Compatible is deprecated. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF
2013-10-08 17:07:18 +00:00
float bssrdf_u, bssrdf_v;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
path_state_rng_2D(kg, rng, &state, PRNG_BSDF_U, &bssrdf_u, &bssrdf_v);
Cycles / SSS: * Remove the compatible falloff SSS implementation. We shouldn't support two implementations in the long term, and 2.7x is a good release number do break some compatibility as well. * Version patch added, so Files with Compatible falloff will automatically use Cubic now. It was already mentioned in the manual, that Compatible is deprecated. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF
2013-10-08 17:07:18 +00:00
subsurface_scatter_step(kg, &sd, state.flag, sc, &lcg_state, bssrdf_u, bssrdf_v, false);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
state.flag |= PATH_RAY_BSSRDF_ANCESTOR;
Cycles: ambient occlusion support, with AO factor and distance, and a render pass. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/World#Ambient_Occlusion http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes#Lighting_Passes
2012-02-28 16:45:08 +00:00
}
}
#endif
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 21:05:07 +00:00
#if defined(__EMISSION__) && defined(__BRANCHED_PATH__)
Cycles: internal changes that should have no effect on user level yet, added shader flags for various purposes, and some code for light types other than points.
2011-09-27 20:37:24 +00:00
if(kernel_data.integrator.use_direct_light) {
Cycles: Option to Sample all Lights in the Branched Path integrator for indirect samples This adds a new option "Sample All Lights" to the Sampling panel in Cycles (Branched Path). When enabled, Cycles will sample all the lights in the scene for the indirect samples, instead of randomly picking one. This is already happening for direct samples, now you can optionally enable it for indirect. Example file and renders: Blend file: http://www.pasteall.org/blend/27411 Random: http://www.pasteall.org/pic/show.php?id=68033 All: http://www.pasteall.org/pic/show.php?id=68034 Sampling all lights is a bit slower, but there is less variance, so it should help in situations with many lights. Patch by myself with some tweaks by Brecht. Differential Revision: https://developer.blender.org/D391
2014-03-09 21:19:27 +00:00
bool all = kernel_data.integrator.sample_all_lights_indirect;
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
kernel_branched_path_surface_connect_light(kg, rng, &sd, &state, throughput, 1.0f, L, all);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
}
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
if(!kernel_path_surface_bounce(kg, rng, &sd, &throughput, &state, L, &ray))
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
break;
}
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
}
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 21:05:07 +00:00
ccl_device void kernel_path_ao(KernelGlobals *kg, ShaderData *sd, PathRadiance *L, PathState *state, RNG *rng, float3 throughput)
{
/* todo: solve correlation */
float bsdf_u, bsdf_v;
path_state_rng_2D(kg, rng, state, PRNG_BSDF_U, &bsdf_u, &bsdf_v);
float ao_factor = kernel_data.background.ao_factor;
float3 ao_N;
float3 ao_bsdf = shader_bsdf_ao(kg, sd, ao_factor, &ao_N);
float3 ao_D;
float ao_pdf;
float3 ao_alpha = shader_bsdf_alpha(kg, sd);
sample_cos_hemisphere(ao_N, bsdf_u, bsdf_v, &ao_D, &ao_pdf);
if(dot(sd->Ng, ao_D) > 0.0f && ao_pdf != 0.0f) {
Ray light_ray;
float3 ao_shadow;
light_ray.P = ray_offset(sd->P, sd->Ng);
light_ray.D = ao_D;
light_ray.t = kernel_data.background.ao_distance;
#ifdef __OBJECT_MOTION__
light_ray.time = sd->time;
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
#endif
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 21:05:07 +00:00
light_ray.dP = sd->dP;
light_ray.dD = differential3_zero();
if(!shadow_blocked(kg, state, &light_ray, &ao_shadow))
path_radiance_accum_ao(L, throughput, ao_alpha, ao_bsdf, ao_shadow, state->bounce);
}
}
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Code refactor: move branched path AO and SSS code into functions.
2014-05-19 13:07:40 +00:00
ccl_device void kernel_branched_path_ao(KernelGlobals *kg, ShaderData *sd, PathRadiance *L, PathState *state, RNG *rng, float3 throughput)
{
int num_samples = kernel_data.integrator.ao_samples;
float num_samples_inv = 1.0f/num_samples;
float ao_factor = kernel_data.background.ao_factor;
float3 ao_N;
float3 ao_bsdf = shader_bsdf_ao(kg, sd, ao_factor, &ao_N);
float3 ao_alpha = shader_bsdf_alpha(kg, sd);
for(int j = 0; j < num_samples; j++) {
float bsdf_u, bsdf_v;
path_branched_rng_2D(kg, rng, state, j, num_samples, PRNG_BSDF_U, &bsdf_u, &bsdf_v);
float3 ao_D;
float ao_pdf;
sample_cos_hemisphere(ao_N, bsdf_u, bsdf_v, &ao_D, &ao_pdf);
if(dot(sd->Ng, ao_D) > 0.0f && ao_pdf != 0.0f) {
Ray light_ray;
float3 ao_shadow;
light_ray.P = ray_offset(sd->P, sd->Ng);
light_ray.D = ao_D;
light_ray.t = kernel_data.background.ao_distance;
#ifdef __OBJECT_MOTION__
light_ray.time = sd->time;
#endif
light_ray.dP = sd->dP;
light_ray.dD = differential3_zero();
if(!shadow_blocked(kg, state, &light_ray, &ao_shadow))
path_radiance_accum_ao(L, throughput*num_samples_inv, ao_alpha, ao_bsdf, ao_shadow, state->bounce);
}
}
}
Cycles-Bake: Subsurface Scattering support (fix T40060) This fixes the SSS Direct/Indirect passes as well as the Combined pass. Patch reviewed and with fixes and contributions from Brecht van Lommel. Note: displacement/bump map (related to the report) will be handled separately Reviewers: brecht Differential Revision: https://developer.blender.org/D503
2014-05-07 14:55:09 +00:00
#ifdef __SUBSURFACE__
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
Code style.
2014-09-26 00:04:18 +00:00
#ifdef __VOLUME__
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
ccl_device void kernel_path_subsurface_update_volume_stack(KernelGlobals *kg,
Ray *ray,
VolumeStack *stack)
{
kernel_assert(kernel_data.integrator.use_volumes);
Ray volume_ray = *ray;
Intersection isect;
Fix T43562: Cycles gets stuck with camera in volume in certain setup The issue was caused by the way how we shoot the ray to see which rays we're inside which might start bouncing back-n-forth between two close to parallel intersecting faces. Real solution would be to record all the intersections when shooting the ray, but it's kinda tricky on GPU because of needed sorting and uncertainty of how huge intersection array should be. For now we'll just limit number of steps in the check so in worst case we'll have some samples not being correct which will be compensated with further sampling. Shouldn't be an issue since probability of such a lock is quite small actually.
2015-02-05 11:06:22 +00:00
int step = 0;
while(step < VOLUME_STACK_SIZE &&
scene_intersect_volume(kg, &volume_ray, &isect))
Cycles: Cleanup of the SSS volume stack update code Was a leftover after the changed scene_intersect() which used to be ifdefed depending on the __HAIR__ in the original patch.
2014-09-27 20:19:17 +00:00
{
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
ShaderData sd;
shader_setup_from_ray(kg, &sd, &isect, &volume_ray, 0, 0);
kernel_volume_stack_enter_exit(kg, &sd, stack);
/* Move ray forward. */
volume_ray.P = ray_offset(sd.P, -sd.Ng);
Cycles: Optimize of volume stack update when sampling SSS basically we skip all non-volume objects now in the volume stack function. Depending on the show it might give some percent of speedup. Most of the speedup would be gained in the scenes when having SSS object intersecting the volume and taking a reasonable amount of frame space.
2014-10-06 10:23:16 +00:00
volume_ray.t -= sd.ray_length;
Fix T43562: Cycles gets stuck with camera in volume in certain setup The issue was caused by the way how we shoot the ray to see which rays we're inside which might start bouncing back-n-forth between two close to parallel intersecting faces. Real solution would be to record all the intersections when shooting the ray, but it's kinda tricky on GPU because of needed sorting and uncertainty of how huge intersection array should be. For now we'll just limit number of steps in the check so in worst case we'll have some samples not being correct which will be compensated with further sampling. Shouldn't be an issue since probability of such a lock is quite small actually.
2015-02-05 11:06:22 +00:00
++step;
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
}
}
Code style.
2014-09-26 00:04:18 +00:00
#endif
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
Cycles-Bake: Subsurface Scattering support (fix T40060) This fixes the SSS Direct/Indirect passes as well as the Combined pass. Patch reviewed and with fixes and contributions from Brecht van Lommel. Note: displacement/bump map (related to the report) will be handled separately Reviewers: brecht Differential Revision: https://developer.blender.org/D503
2014-05-07 14:55:09 +00:00
ccl_device bool kernel_path_subsurface_scatter(KernelGlobals *kg, ShaderData *sd, PathRadiance *L, PathState *state, RNG *rng, Ray *ray, float3 *throughput)
{
float bssrdf_probability;
ShaderClosure *sc = subsurface_scatter_pick_closure(kg, sd, &bssrdf_probability);
/* modify throughput for picking bssrdf or bsdf */
*throughput *= bssrdf_probability;
/* do bssrdf scatter step if we picked a bssrdf closure */
if(sc) {
uint lcg_state = lcg_state_init(rng, state, 0x68bc21eb);
ShaderData bssrdf_sd[BSSRDF_MAX_HITS];
float bssrdf_u, bssrdf_v;
path_state_rng_2D(kg, rng, state, PRNG_BSDF_U, &bssrdf_u, &bssrdf_v);
int num_hits = subsurface_scatter_multi_step(kg, sd, bssrdf_sd, state->flag, sc, &lcg_state, bssrdf_u, bssrdf_v, false);
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
#ifdef __VOLUME__
Ray volume_ray = *ray;
Cycles: Implement preliminary test for volume stack update from SSS This adds an AABB collision check for objects with volumes and if there's a collision detected then the object will have SD_OBJECT_INTERSECTS_VOLUME flag. This solves a speed regression introduced by the fix for T39823 by skipping volume stack update in cases no volumes intersects the current SSS object.
2014-10-03 08:52:04 +00:00
bool need_update_volume_stack = kernel_data.integrator.use_volumes &&
sd->flag & SD_OBJECT_INTERSECTS_VOLUME;
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
#endif
Cycles-Bake: Subsurface Scattering support (fix T40060) This fixes the SSS Direct/Indirect passes as well as the Combined pass. Patch reviewed and with fixes and contributions from Brecht van Lommel. Note: displacement/bump map (related to the report) will be handled separately Reviewers: brecht Differential Revision: https://developer.blender.org/D503
2014-05-07 14:55:09 +00:00
/* compute lighting with the BSDF closure */
for(int hit = 0; hit < num_hits; hit++) {
float3 tp = *throughput;
PathState hit_state = *state;
Ray hit_ray = *ray;
hit_state.flag |= PATH_RAY_BSSRDF_ANCESTOR;
hit_state.rng_offset += PRNG_BOUNCE_NUM;
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
kernel_path_surface_connect_light(kg, rng, &bssrdf_sd[hit], tp, state, L);
Cycles-Bake: Subsurface Scattering support (fix T40060) This fixes the SSS Direct/Indirect passes as well as the Combined pass. Patch reviewed and with fixes and contributions from Brecht van Lommel. Note: displacement/bump map (related to the report) will be handled separately Reviewers: brecht Differential Revision: https://developer.blender.org/D503
2014-05-07 14:55:09 +00:00
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
if(kernel_path_surface_bounce(kg, rng, &bssrdf_sd[hit], &tp, &hit_state, L, &hit_ray)) {
Cycles-Bake: Subsurface Scattering support (fix T40060) This fixes the SSS Direct/Indirect passes as well as the Combined pass. Patch reviewed and with fixes and contributions from Brecht van Lommel. Note: displacement/bump map (related to the report) will be handled separately Reviewers: brecht Differential Revision: https://developer.blender.org/D503
2014-05-07 14:55:09 +00:00
#ifdef __LAMP_MIS__
hit_state.ray_t = 0.0f;
#endif
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
#ifdef __VOLUME__
Cycles: Implement preliminary test for volume stack update from SSS This adds an AABB collision check for objects with volumes and if there's a collision detected then the object will have SD_OBJECT_INTERSECTS_VOLUME flag. This solves a speed regression introduced by the fix for T39823 by skipping volume stack update in cases no volumes intersects the current SSS object.
2014-10-03 08:52:04 +00:00
if(need_update_volume_stack) {
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
/* Setup ray from previous surface point to the new one. */
volume_ray.D = normalize_len(hit_ray.P - volume_ray.P,
&volume_ray.t);
kernel_path_subsurface_update_volume_stack(
kg,
&volume_ray,
hit_state.volume_stack);
/* Move volume ray forward. */
volume_ray.P = hit_ray.P;
}
#endif
Cycles-Bake: Subsurface Scattering support (fix T40060) This fixes the SSS Direct/Indirect passes as well as the Combined pass. Patch reviewed and with fixes and contributions from Brecht van Lommel. Note: displacement/bump map (related to the report) will be handled separately Reviewers: brecht Differential Revision: https://developer.blender.org/D503
2014-05-07 14:55:09 +00:00
kernel_path_indirect(kg, rng, hit_ray, tp, state->num_samples, hit_state, L);
/* for render passes, sum and reset indirect light pass variables
* for the next samples */
path_radiance_sum_indirect(L);
path_radiance_reset_indirect(L);
}
}
return true;
}
return false;
}
#endif
Cycles: change __device and similar qualifiers to ccl_device in kernel code. This to avoids build conflicts with libc++ on FreeBSD, these __ prefixed values are reserved for compilers. I apologize to anyone who has patches or branches and has to go through the pain of merging this change, it may be easiest to do these same replacements in your code and then apply/merge the patch. Ref T37477.
2013-11-15 23:17:10 +00:00
ccl_device float4 kernel_path_integrate(KernelGlobals *kg, RNG *rng, int sample, Ray ray, ccl_global float *buffer)
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
{
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
/* initialize */
PathRadiance L;
float3 throughput = make_float3(1.0f, 1.0f, 1.0f);
float L_transparent = 0.0f;
path_radiance_init(&L, kernel_data.film.use_light_pass);
PathState state;
Cycles: Add support for cameras inside volume Basically the title says it all, volume stack initialization now is aware that camera might be inside of the volume. This gives quite noticeable render time regressions in cases camera is in the volume (didn't measure them yet) because this requires quite a few of ray-casting per camera ray in order to check which objects we're inside. Not quite sure if this might be optimized. But the good thing is that we can do quite a good job on detecting whether camera is outside of any of the volumes and in this case there should be no time penalty at all (apart from some extra checks during the sync state). For now we're only doing rather simple AABB checks between the viewplane and volume objects. This could give some false-positives, but this should be good starting point. Need to mention panoramic cameras here, for them it's only check for whether there are volumes in the scene, which would lead to speed regressions even if the camera is outside of the volumes. Would need to figure out proper check for such cameras. There are still quite a few of TODOs in the code, but the patch is good enough to start playing around with it checking whether there are some obvious mistakes somewhere. Currently the feature is only available in the Experimental feature sey, need to solve some of the TODOs and look into making things faster before considering the feature is ready for the official feature set. This would still likely happen in current release cycle. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D794
2014-09-16 17:49:59 +00:00
path_state_init(kg, &state, rng, sample, &ray);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
Cycles: Add support for debug passes Currently only summed number of traversal steps and intersections used by the camera ray intersection pass is implemented, but in the future we will support more debug passes which would help checking what things makes the scene slow. Example of such extra passes could be number of bounces, time spent on the shader tree evaluation and so. Implementation from the Cycles side is pretty much straightforward, could only mention here that it's a build-time option disabled by default. From the blender side it's implemented as a PASS_DEBUG with several subtypes possible. This way we don't need to create an extra DNA pass type for each of the debug passes, saving us a bits. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D813
2014-10-04 13:00:26 +00:00
#ifdef __KERNEL_DEBUG__
DebugData debug_data;
debug_data_init(&debug_data);
#endif
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
/* path iteration */
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
for(;;) {
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
/* intersect scene */
Intersection isect;
uint visibility = path_state_ray_visibility(kg, &state);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
Cycles OpenCL: fix other build issues when enabling more features.
2013-05-09 15:28:38 +00:00
#ifdef __HAIR__
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
float difl = 0.0f, extmax = 0.0f;
uint lcg_state = 0;
if(kernel_data.bvh.have_curves) {
if((kernel_data.cam.resolution == 1) && (state.flag & PATH_RAY_CAMERA)) {
float3 pixdiff = ray.dD.dx + ray.dD.dy;
/*pixdiff = pixdiff - dot(pixdiff, ray.D)*ray.D;*/
difl = kernel_data.curve.minimum_width * len(pixdiff) * 0.5f;
}
extmax = kernel_data.curve.maximum_width;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
lcg_state = lcg_state_init(rng, &state, 0x51633e2d);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
}
bool hit = scene_intersect(kg, &ray, visibility, &isect, &lcg_state, difl, extmax);
Cycles OpenCL: fix other build issues when enabling more features.
2013-05-09 15:28:38 +00:00
#else
Cleanup: Avoid some defines for scene_intersect(), related to Min Width.
2014-09-24 09:32:29 +00:00
bool hit = scene_intersect(kg, &ray, visibility, &isect, NULL, 0.0f, 0.0f);
Cycles OpenCL: fix other build issues when enabling more features.
2013-05-09 15:28:38 +00:00
#endif
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Cycles: Add support for debug passes Currently only summed number of traversal steps and intersections used by the camera ray intersection pass is implemented, but in the future we will support more debug passes which would help checking what things makes the scene slow. Example of such extra passes could be number of bounces, time spent on the shader tree evaluation and so. Implementation from the Cycles side is pretty much straightforward, could only mention here that it's a build-time option disabled by default. From the blender side it's implemented as a PASS_DEBUG with several subtypes possible. This way we don't need to create an extra DNA pass type for each of the debug passes, saving us a bits. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D813
2014-10-04 13:00:26 +00:00
#ifdef __KERNEL_DEBUG__
if(state.flag & PATH_RAY_CAMERA) {
debug_data.num_bvh_traversal_steps += isect.num_traversal_steps;
}
#endif
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
#ifdef __LAMP_MIS__
Cycles: make multiple importance sampling for lamps an option per lamp now, disabled by default for backwards compatibility. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Integrator
2013-01-30 15:57:15 +00:00
if(kernel_data.integrator.use_lamp_mis && !(state.flag & PATH_RAY_CAMERA)) {
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
/* ray starting from previous non-transparent bounce */
Ray light_ray;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
light_ray.P = ray.P - state.ray_t*ray.D;
state.ray_t += isect.t;
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
light_ray.D = ray.D;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
light_ray.t = state.ray_t;
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
light_ray.time = ray.time;
Possible fix for #35198: uninitialized memory access with background multiple importance sampling + OSL.
2013-05-03 05:24:05 +00:00
light_ray.dD = ray.dD;
light_ray.dP = ray.dP;
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
/* intersect with lamp */
float3 emission;
Cycles: MIS for lamps now loops over all lamps instead of picking one. Probably will not be noticed in most scenes. This helps reduce noise when you have multiple lamps with MIS enabled, at the cost of some performance, but from testing some scenes this seems better.
2014-05-01 17:18:42 +00:00
if(indirect_lamp_emission(kg, &state, &light_ray, &emission))
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
path_radiance_accum_emission(&L, throughput, emission, state.bounce);
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
}
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
#ifdef __VOLUME__
Code refactor: better distinguish scatter and absorption for volume integration.
2013-12-29 14:49:16 +00:00
/* volume attenuation, emission, scatter */
Cycles code refactor: replace magic ~0 values in the code with defines.
2014-03-29 12:03:47 +00:00
if(state.volume_stack[0].shader != SHADER_NONE) {
Cycles Volume Render: heterogeneous (textured) volumes support. Volumes can now have textured colors and density. There is a Volume Sampling panel in the Render properties with these settings: * Step size: distance between volume shader samples when rendering the volume. Lower values give more accurate and detailed results but also increased render time. * Max steps: maximum number of steps through the volume before giving up, to protect from extremely long render times with big objects or small step sizes. This is much more compute intensive than homogeneous volume, so when you are not using a texture you should enable the Homogeneous Volume option in the material or world for faster rendering. One important missing feature is that Generated texture coordinates are not yet working in volumes, and they are the default coordinates for nearly all texture nodes. So until that works you need to plug in object texture coordinates or a world space position. This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-29 21:19:38 +00:00
Ray volume_ray = ray;
volume_ray.t = (hit)? isect.t: FLT_MAX;
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
bool heterogeneous = volume_stack_is_heterogeneous(kg, state.volume_stack);
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#ifdef __VOLUME_DECOUPLED__
Cycles: Avoid call to volume_stack_sampling_method() on GPU, Decoupled is required for Equi-Angular/MIS.
2014-08-24 13:58:41 +00:00
int sampling_method = volume_stack_sampling_method(kg, state.volume_stack);
Cycles: volume sampling method can now be set per material/world. This gives you "Multiple Importance", "Distance" and "Equiangular" choices. What multiple importance sampling does is make things more robust to certain types of noise at the cost of a bit more noise in cases where the individual strategies are always better. So if you've got a pretty dense volume that's lit from far away then distance sampling is usually more efficient. If you've got a light inside or near the volume then equiangular sampling is better. If you have a combination of both, then the multiple importance sampling will be better.
2014-06-07 16:47:14 +00:00
bool decoupled = kernel_volume_use_decoupled(kg, heterogeneous, true, sampling_method);
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
if(decoupled) {
/* cache steps along volume for repeated sampling */
VolumeSegment volume_segment;
ShaderData volume_sd;
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
shader_setup_from_volume(kg, &volume_sd, &volume_ray, state.bounce, state.transparent_bounce);
kernel_volume_decoupled_record(kg, &state,
&volume_ray, &volume_sd, &volume_segment, heterogeneous);
Cycles: volume sampling method can now be set per material/world. This gives you "Multiple Importance", "Distance" and "Equiangular" choices. What multiple importance sampling does is make things more robust to certain types of noise at the cost of a bit more noise in cases where the individual strategies are always better. So if you've got a pretty dense volume that's lit from far away then distance sampling is usually more efficient. If you've got a light inside or near the volume then equiangular sampling is better. If you have a combination of both, then the multiple importance sampling will be better.
2014-06-07 16:47:14 +00:00
volume_segment.sampling_method = sampling_method;
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* emission */
if(volume_segment.closure_flag & SD_EMISSION)
path_radiance_accum_emission(&L, throughput, volume_segment.accum_emission, state.bounce);
/* scattering */
VolumeIntegrateResult result = VOLUME_PATH_ATTENUATED;
if(volume_segment.closure_flag & SD_SCATTER) {
bool all = false;
/* direct light sampling */
kernel_branched_path_volume_connect_light(kg, rng, &volume_sd,
Cycles: Simplify volume light connect code.
2015-03-12 23:09:13 +00:00
throughput, &state, &L, all, &volume_ray, &volume_segment);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* indirect sample. if we use distance sampling and take just
* one sample for direct and indirect light, we could share
* this computation, but makes code a bit complex */
float rphase = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_PHASE);
float rscatter = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_SCATTER_DISTANCE);
result = kernel_volume_decoupled_scatter(kg,
&state, &volume_ray, &volume_sd, &throughput,
rphase, rscatter, &volume_segment, NULL, true);
}
/* free cached steps */
kernel_volume_decoupled_free(kg, &volume_segment);
if(result == VOLUME_PATH_SCATTERED) {
Cleanup: Remove unused variable in kernel_path_volume_bounce().
2014-08-24 21:06:30 +00:00
if(kernel_path_volume_bounce(kg, rng, &volume_sd, &throughput, &state, &L, &ray))
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
continue;
else
break;
}
Cycles: Small improvement for volume render (decoupled) Simplify branching here a bit, helps ~3% in volume_light_sampling.blend (Branched MIS scene).
2015-02-14 19:44:30 +00:00
else {
throughput *= volume_segment.accum_transmittance;
}
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
}
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
else
#endif
{
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* integrate along volume segment with distance sampling */
ShaderData volume_sd;
VolumeIntegrateResult result = kernel_volume_integrate(
Cycles: Avoid redundant call to volume_stack_is_heterogeneous() for Distance Sampling.
2014-08-24 14:15:57 +00:00
kg, &state, &volume_sd, &volume_ray, &L, &throughput, rng, heterogeneous);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#ifdef __VOLUME_SCATTER__
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
if(result == VOLUME_PATH_SCATTERED) {
/* direct lighting */
Fix T41693: Volumes get brightened with extra volume samples on GPU + BPT
2014-09-03 15:23:07 +00:00
kernel_path_volume_connect_light(kg, rng, &volume_sd, throughput, &state, &L);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* indirect light bounce */
Cleanup: Remove unused variable in kernel_path_volume_bounce().
2014-08-24 21:06:30 +00:00
if(kernel_path_volume_bounce(kg, rng, &volume_sd, &throughput, &state, &L, &ray))
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
continue;
else
break;
}
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#endif
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
}
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
}
#endif
Cycles: multiple importance sampling for lamps, which helps reduce noise for big lamps and sharp glossy reflections. This was already supported for mesh lights and the background, so lamps should do it too. This is not for free and it's a bit slower than I hoped even though there is no extra BVH ray intersection. I'll try to optimize it more later. * Area lights look a bit different now, they had the wrong shape before. * Also fixes a sampling issue in the non-progressive integrator. * Only enabled for the CPU, will test on the GPU later. * An option to disable this will be added for situations where it does not help. Same time comparison before/after: http://www.pasteall.org/pic/show.php?id=43313 http://www.pasteall.org/pic/show.php?id=43314
2013-01-09 21:09:20 +00:00
if(!hit) {
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
/* eval background shader if nothing hit */
if(kernel_data.background.transparent && (state.flag & PATH_RAY_CAMERA)) {
L_transparent += average(throughput);
#ifdef __PASSES__
if(!(kernel_data.film.pass_flag & PASS_BACKGROUND))
#endif
break;
}
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
#ifdef __BACKGROUND__
/* sample background shader */
Cleanup: Pass PathState as a whole, instead of individual members. Differential Revision: https://developer.blender.org/D477
2014-04-21 15:51:51 +00:00
float3 L_background = indirect_background(kg, &state, &ray);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
path_radiance_accum_background(&L, throughput, L_background, state.bounce);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
#endif
break;
}
/* setup shading */
ShaderData sd;
Cycles: add Transparent Depth output to Light Path node. This can for example be useful if you want to manually terminate the path at some point and use a color other than black. Reviewed By: brecht Differential Revision: https://developer.blender.org/D454
2014-04-21 12:20:29 +00:00
shader_setup_from_ray(kg, &sd, &isect, &ray, state.bounce, state.transparent_bounce);
Fix T39804: cycles smoke domain visible in rendering. Transparent objects could become subtly visible by the different sampling patterns for pixels covered and not covered by the object. It still converged to the right solution but that can take a while. Now we try to use the same sampling pattern here.
2014-05-29 12:12:12 +00:00
float rbsdf = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_BSDF);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
shader_eval_surface(kg, &sd, rbsdf, state.flag, SHADER_CONTEXT_MAIN);
/* holdout */
#ifdef __HOLDOUT__
if((sd.flag & (SD_HOLDOUT|SD_HOLDOUT_MASK)) && (state.flag & PATH_RAY_CAMERA)) {
if(kernel_data.background.transparent) {
float3 holdout_weight;
if(sd.flag & SD_HOLDOUT_MASK)
holdout_weight = make_float3(1.0f, 1.0f, 1.0f);
else
holdout_weight = shader_holdout_eval(kg, &sd);
/* any throughput is ok, should all be identical here */
L_transparent += average(holdout_weight*throughput);
}
if(sd.flag & SD_HOLDOUT_MASK)
break;
}
#endif
/* holdout mask objects do not write data passes */
Cycles: add pass alpha threshold value to render layers. Z, Index, normal, UV and vector passes are only affected by surfaces with alpha transparency equal to or higher than this threshold. With value 0.0 the first surface hit will always write to these passes, regardless of transparency. With higher values surfaces that are mostly transparent can be skipped until an opaque surface is encountered.
2014-02-06 14:18:34 +00:00
kernel_write_data_passes(kg, buffer, &L, &sd, sample, &state, throughput);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
/* blurring of bsdf after bounces, for rays that have a small likelihood
* of following this particular path (diffuse, rough glossy) */
if(kernel_data.integrator.filter_glossy != FLT_MAX) {
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
float blur_pdf = kernel_data.integrator.filter_glossy*state.min_ray_pdf;
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
if(blur_pdf < 1.0f) {
float blur_roughness = sqrtf(1.0f - blur_pdf)*0.5f;
shader_bsdf_blur(kg, &sd, blur_roughness);
}
}
#ifdef __EMISSION__
/* emission */
if(sd.flag & SD_EMISSION) {
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
/* todo: is isect.t wrong here for transparent surfaces? */
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
float3 emission = indirect_primitive_emission(kg, &sd, isect.t, state.flag, state.ray_pdf);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
path_radiance_accum_emission(&L, throughput, emission, state.bounce);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
}
#endif
/* path termination. this is a strange place to put the termination, it's
* mainly due to the mixed in MIS that we use. gives too many unneeded
* shader evaluations, only need emission if we are going to terminate */
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
float probability = path_state_terminate_probability(kg, &state, throughput);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
if(probability == 0.0f) {
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
break;
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
}
else if(probability != 1.0f) {
Fix T39804: cycles smoke domain visible in rendering. Transparent objects could become subtly visible by the different sampling patterns for pixels covered and not covered by the object. It still converged to the right solution but that can take a while. Now we try to use the same sampling pattern here.
2014-05-29 12:12:12 +00:00
float terminate = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_TERMINATE);
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
if(terminate >= probability)
break;
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
throughput /= probability;
}
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
#ifdef __AO__
/* ambient occlusion */
Cycles: 4 new nodes. * Tangent: generate a tangent direction for anisotropic shading. Can be either radial around X/Y/Z axis, or from a UV map. The default tangent for the anisotropic BSDF and geometry node is now always radial Z, for UV tangent use this node now. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Tangent * Normal Map: generate a perturbed normal from an RGB normal map image. This is usually chained with an Image Texture node in the color input, to specify the normal map image. For tangent space normal maps, the UV coordinates for the image must match, and the image texture should be set to Non-Color mode to give correct results. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/More#Normal_Map * Refraction BSDF: for best results this node should be considered as a building block and not be used on its own, but rather mixed with a glossy node using a fresnel type factor. Otherwise it will give quite dark results at the edges for glossy refraction. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Refraction * Ambient Occlusion: controls the amount of AO a surface receives, rather than having just a global factor in the world. Note that this outputs a shader and not a color, that's for another time. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Ambient_Occlusion
2012-11-06 19:59:02 +00:00
if(kernel_data.integrator.use_ambient_occlusion || (sd.flag & SD_AO)) {
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 21:05:07 +00:00
kernel_path_ao(kg, &sd, &L, &state, rng, throughput);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
}
Cycles: * Fix missing update when editing objects with emission materials. * Fix preview pass rendering set to 1 not showing full resolution. * Fix CUDA runtime compiling failing due to missing cache directory. * Use settings from first render layer for visibility and material override. And a bunch of incomplete and still disabled code mostly related to closure sampling.
2011-09-12 13:13:56 +00:00
#endif
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
#ifdef __SUBSURFACE__
/* bssrdf scatter to a different location on the same object, replacing
* the closures with a diffuse BSDF */
if(sd.flag & SD_BSSRDF) {
Cycles-Bake: Subsurface Scattering support (fix T40060) This fixes the SSS Direct/Indirect passes as well as the Combined pass. Patch reviewed and with fixes and contributions from Brecht van Lommel. Note: displacement/bump map (related to the report) will be handled separately Reviewers: brecht Differential Revision: https://developer.blender.org/D503
2014-05-07 14:55:09 +00:00
if(kernel_path_subsurface_scatter(kg, &sd, &L, &state, rng, &ray, &throughput))
Cycles / SSS: * Remove the compatible falloff SSS implementation. We shouldn't support two implementations in the long term, and 2.7x is a good release number do break some compatibility as well. * Version patch added, so Files with Compatible falloff will automatically use Cubic now. It was already mentioned in the manual, that Compatible is deprecated. http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF
2013-10-08 17:07:18 +00:00
break;
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
}
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
/* direct lighting */
kernel_path_surface_connect_light(kg, rng, &sd, throughput, &state, &L);
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
/* compute direct lighting and next bounce */
if(!kernel_path_surface_bounce(kg, rng, &sd, &throughput, &state, &L, &ray))
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
break;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
Cycles: Separation of Indirect and Direct clamping. Indirect and Direct samples can now be clamped individually. This way we can clamp the indirect samples (fireflies), while keeping the direct highlights. Example render: http://www.pasteall.org/pic/show.php?id=66586 WARNING: This breaks backwards compatibility. If you had Clamping enabled in an old file, you must re-enable either Direct/Indirect clamping or both again. Reviewed by: brecht Differential Revision: https://developer.blender.org/D303
2014-02-10 20:44:49 +00:00
float3 L_sum = path_radiance_clamp_and_sum(kg, &L);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
kernel_write_light_passes(kg, buffer, &L, sample);
Cycles: Add support for debug passes Currently only summed number of traversal steps and intersections used by the camera ray intersection pass is implemented, but in the future we will support more debug passes which would help checking what things makes the scene slow. Example of such extra passes could be number of bounces, time spent on the shader tree evaluation and so. Implementation from the Cycles side is pretty much straightforward, could only mention here that it's a build-time option disabled by default. From the blender side it's implemented as a PASS_DEBUG with several subtypes possible. This way we don't need to create an extra DNA pass type for each of the debug passes, saving us a bits. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D813
2014-10-04 13:00:26 +00:00
#ifdef __KERNEL_DEBUG__
kernel_write_debug_passes(kg, buffer, &state, &debug_data, sample);
#endif
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
return make_float4(L_sum.x, L_sum.y, L_sum.z, 1.0f - L_transparent);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
}
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
#ifdef __BRANCHED_PATH__
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
/* branched path tracing: bounce off surface and integrate indirect light */
ccl_device_noinline void kernel_branched_path_surface_indirect_light(KernelGlobals *kg,
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
RNG *rng, ShaderData *sd, float3 throughput, float num_samples_adjust,
Fix T40135: cycles baking did not support branched path settings yet.
2014-05-19 13:14:43 +00:00
PathState *state, PathRadiance *L)
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
{
for(int i = 0; i< sd->num_closure; i++) {
const ShaderClosure *sc = &sd->closure[i];
if(!CLOSURE_IS_BSDF(sc->type))
continue;
/* transparency is not handled here, but in outer loop */
if(sc->type == CLOSURE_BSDF_TRANSPARENT_ID)
continue;
int num_samples;
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
if(CLOSURE_IS_BSDF_DIFFUSE(sc->type))
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
num_samples = kernel_data.integrator.diffuse_samples;
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
else if(CLOSURE_IS_BSDF_BSSRDF(sc->type))
num_samples = 1;
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
else if(CLOSURE_IS_BSDF_GLOSSY(sc->type))
num_samples = kernel_data.integrator.glossy_samples;
else
num_samples = kernel_data.integrator.transmission_samples;
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
num_samples = ceil_to_int(num_samples_adjust*num_samples);
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
float num_samples_inv = num_samples_adjust/num_samples;
Fix #35665: cycles CUDA crash after recent changes. This works around a compiler bug in CUDA 4.2 (solved in 5.5) with typedef'd function parameters.
2013-06-09 16:37:04 +00:00
RNG bsdf_rng = cmj_hash(*rng, i);
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
for(int j = 0; j < num_samples; j++) {
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
PathState ps = *state;
Cycles code refactor: move some surface and volume path code to separate files.
2014-04-04 12:35:30 +00:00
float3 tp = throughput;
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
Ray bsdf_ray;
Cycles code refactor: move some surface and volume path code to separate files.
2014-04-04 12:35:30 +00:00
if(!kernel_branched_path_surface_bounce(kg, &bsdf_rng, sd, sc, j, num_samples, &tp, &ps, L, &bsdf_ray))
continue;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
Cycles Bake Expand Cycles to use the new baking API in Blender. It works on the selected object, and the panel can be accessed in the Render panel (similar to where it is for the Blender Internal). It bakes for the active texture of each material of the object. The active texture is currently defined as the active Image Texture node present in the material nodetree. If you don't want the baking to override an existent material, make sure the active Image Texture node is not connected to the nodetree. The active texture is also the texture shown in the viewport in the rendered mode. Remember to save your images after the baking is complete. Note: Bake currently only works in the CPU Note: This is not supported by Cycles standalone because a lot of the work is done in Blender as part of the operator only, not the engine (Cycles). Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake Supported Passes: ----------------- Data Passes * Normal * UV * Diffuse/Glossy/Transmission/Subsurface/Emit Color Light Passes * AO * Combined * Shadow * Diffuse/Glossy/Transmission/Subsurface/Emit Direct/Indirect * Environment Review: D421 Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge Original design by Brecht van Lommel. The entire commit history can be found on the branch: bake-cycles
2014-01-02 21:05:07 +00:00
kernel_path_indirect(kg, rng, bsdf_ray, tp*num_samples_inv, num_samples, ps, L);
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
/* for render passes, sum and reset indirect light pass variables
* for the next samples */
path_radiance_sum_indirect(L);
path_radiance_reset_indirect(L);
}
}
}
Code refactor: move branched path AO and SSS code into functions.
2014-05-19 13:07:40 +00:00
#ifdef __SUBSURFACE__
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
ccl_device void kernel_branched_path_subsurface_scatter(KernelGlobals *kg,
ShaderData *sd,
PathRadiance *L,
PathState *state,
RNG *rng,
Ray *ray,
float3 throughput)
Code refactor: move branched path AO and SSS code into functions.
2014-05-19 13:07:40 +00:00
{
for(int i = 0; i< sd->num_closure; i++) {
ShaderClosure *sc = &sd->closure[i];
if(!CLOSURE_IS_BSSRDF(sc->type))
continue;
/* set up random number generator */
uint lcg_state = lcg_state_init(rng, state, 0x68bc21eb);
int num_samples = kernel_data.integrator.subsurface_samples;
float num_samples_inv = 1.0f/num_samples;
RNG bssrdf_rng = cmj_hash(*rng, i);
state->flag |= PATH_RAY_BSSRDF_ANCESTOR;
/* do subsurface scatter step with copy of shader data, this will
* replace the BSSRDF with a diffuse BSDF closure */
for(int j = 0; j < num_samples; j++) {
ShaderData bssrdf_sd[BSSRDF_MAX_HITS];
float bssrdf_u, bssrdf_v;
path_branched_rng_2D(kg, &bssrdf_rng, state, j, num_samples, PRNG_BSDF_U, &bssrdf_u, &bssrdf_v);
int num_hits = subsurface_scatter_multi_step(kg, sd, bssrdf_sd, state->flag, sc, &lcg_state, bssrdf_u, bssrdf_v, true);
Code style.
2014-09-26 00:04:18 +00:00
#ifdef __VOLUME__
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
Ray volume_ray = *ray;
Cycles: Implement preliminary test for volume stack update from SSS This adds an AABB collision check for objects with volumes and if there's a collision detected then the object will have SD_OBJECT_INTERSECTS_VOLUME flag. This solves a speed regression introduced by the fix for T39823 by skipping volume stack update in cases no volumes intersects the current SSS object.
2014-10-03 08:52:04 +00:00
bool need_update_volume_stack = kernel_data.integrator.use_volumes &&
sd->flag & SD_OBJECT_INTERSECTS_VOLUME;
Code style.
2014-09-26 00:04:18 +00:00
#endif
Code refactor: move branched path AO and SSS code into functions.
2014-05-19 13:07:40 +00:00
/* compute lighting with the BSDF closure */
for(int hit = 0; hit < num_hits; hit++) {
PathState hit_state = *state;
path_state_branch(&hit_state, j, num_samples);
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
#ifdef __VOLUME__
Cycles: Implement preliminary test for volume stack update from SSS This adds an AABB collision check for objects with volumes and if there's a collision detected then the object will have SD_OBJECT_INTERSECTS_VOLUME flag. This solves a speed regression introduced by the fix for T39823 by skipping volume stack update in cases no volumes intersects the current SSS object.
2014-10-03 08:52:04 +00:00
if(need_update_volume_stack) {
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
/* Setup ray from previous surface point to the new one. */
float3 P = ray_offset(bssrdf_sd[hit].P, -bssrdf_sd[hit].Ng);
volume_ray.D = normalize_len(P - volume_ray.P,
&volume_ray.t);
kernel_path_subsurface_update_volume_stack(
kg,
&volume_ray,
hit_state.volume_stack);
/* Move volume ray forward. */
volume_ray.P = P;
}
#endif
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
#if defined(__EMISSION__) && defined(__BRANCHED_PATH__)
/* direct light */
if(kernel_data.integrator.use_direct_light) {
bool all = kernel_data.integrator.sample_all_lights_direct;
kernel_branched_path_surface_connect_light(kg, rng,
&bssrdf_sd[hit], &hit_state, throughput, num_samples_inv, L, all);
}
#endif
/* indirect light */
kernel_branched_path_surface_indirect_light(kg, rng,
&bssrdf_sd[hit], throughput, num_samples_inv,
&hit_state, L);
Code refactor: move branched path AO and SSS code into functions.
2014-05-19 13:07:40 +00:00
}
}
state->flag &= ~PATH_RAY_BSSRDF_ANCESTOR;
}
}
#endif
Cycles: change __device and similar qualifiers to ccl_device in kernel code. This to avoids build conflicts with libc++ on FreeBSD, these __ prefixed values are reserved for compilers. I apologize to anyone who has patches or branches and has to go through the pain of merging this change, it may be easiest to do these same replacements in your code and then apply/merge the patch. Ref T37477.
2013-11-15 23:17:10 +00:00
ccl_device float4 kernel_branched_path_integrate(KernelGlobals *kg, RNG *rng, int sample, Ray ray, ccl_global float *buffer)
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
{
/* initialize */
PathRadiance L;
float3 throughput = make_float3(1.0f, 1.0f, 1.0f);
float L_transparent = 0.0f;
path_radiance_init(&L, kernel_data.film.use_light_pass);
PathState state;
Cycles: Add support for cameras inside volume Basically the title says it all, volume stack initialization now is aware that camera might be inside of the volume. This gives quite noticeable render time regressions in cases camera is in the volume (didn't measure them yet) because this requires quite a few of ray-casting per camera ray in order to check which objects we're inside. Not quite sure if this might be optimized. But the good thing is that we can do quite a good job on detecting whether camera is outside of any of the volumes and in this case there should be no time penalty at all (apart from some extra checks during the sync state). For now we're only doing rather simple AABB checks between the viewplane and volume objects. This could give some false-positives, but this should be good starting point. Need to mention panoramic cameras here, for them it's only check for whether there are volumes in the scene, which would lead to speed regressions even if the camera is outside of the volumes. Would need to figure out proper check for such cameras. There are still quite a few of TODOs in the code, but the patch is good enough to start playing around with it checking whether there are some obvious mistakes somewhere. Currently the feature is only available in the Experimental feature sey, need to solve some of the TODOs and look into making things faster before considering the feature is ready for the official feature set. This would still likely happen in current release cycle. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D794
2014-09-16 17:49:59 +00:00
path_state_init(kg, &state, rng, sample, &ray);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Cycles: Add support for debug passes Currently only summed number of traversal steps and intersections used by the camera ray intersection pass is implemented, but in the future we will support more debug passes which would help checking what things makes the scene slow. Example of such extra passes could be number of bounces, time spent on the shader tree evaluation and so. Implementation from the Cycles side is pretty much straightforward, could only mention here that it's a build-time option disabled by default. From the blender side it's implemented as a PASS_DEBUG with several subtypes possible. This way we don't need to create an extra DNA pass type for each of the debug passes, saving us a bits. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D813
2014-10-04 13:00:26 +00:00
#ifdef __KERNEL_DEBUG__
DebugData debug_data;
debug_data_init(&debug_data);
#endif
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
for(;;) {
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
/* intersect scene */
Intersection isect;
uint visibility = path_state_ray_visibility(kg, &state);
Cycles Hair: Strand Minimum Pixel Size Code is added to restrict the pixel size of strands in cycles. It works best with ribbon primitives and a preset for these is included. It uses distance dependent expansion of the strands and then stochastic strand removal to give a fading. To prevent a slowdown for triangle mesh objects in the BVH an extra visibility flag has been added. It is also only applied for camera rays. The strand width settings are also changed, so that the particle size is not included in the width calculation. Instead there is a separate particle system parameter for width scaling.
2013-04-15 21:38:31 +00:00
#ifdef __HAIR__
Cycles: code refactoring to deduplicate the various BVH traversal variations. Now there is a single BVH traversal code with #ifdefs for various features. At runtime it will then select the appropriate variation to use depending if instancing, hair or motion blur is in use. This makes scenes without hair render a bit faster, especially after the minimum width feature was added. It's not the most beautiful code, but we can't use c++ templates and there were already 4 copies, adding 4 more to handle the hair case separately would be too much.
2013-04-17 20:07:22 +00:00
float difl = 0.0f, extmax = 0.0f;
uint lcg_state = 0;
if(kernel_data.bvh.have_curves) {
if((kernel_data.cam.resolution == 1) && (state.flag & PATH_RAY_CAMERA)) {
float3 pixdiff = ray.dD.dx + ray.dD.dy;
/*pixdiff = pixdiff - dot(pixdiff, ray.D)*ray.D;*/
Code cleanup / Cycles: * Rename "curve_kernel_data" to just "curve", to avoid redundant naming.
2013-08-11 15:27:04 +00:00
difl = kernel_data.curve.minimum_width * len(pixdiff) * 0.5f;
Cycles: code refactoring to deduplicate the various BVH traversal variations. Now there is a single BVH traversal code with #ifdefs for various features. At runtime it will then select the appropriate variation to use depending if instancing, hair or motion blur is in use. This makes scenes without hair render a bit faster, especially after the minimum width feature was added. It's not the most beautiful code, but we can't use c++ templates and there were already 4 copies, adding 4 more to handle the hair case separately would be too much.
2013-04-17 20:07:22 +00:00
}
Code cleanup / Cycles: * Rename "curve_kernel_data" to just "curve", to avoid redundant naming.
2013-08-11 15:27:04 +00:00
extmax = kernel_data.curve.maximum_width;
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
lcg_state = lcg_state_init(rng, &state, 0x51633e2d);
Cycles Hair: Strand Minimum Pixel Size Code is added to restrict the pixel size of strands in cycles. It works best with ribbon primitives and a preset for these is included. It uses distance dependent expansion of the strands and then stochastic strand removal to give a fading. To prevent a slowdown for triangle mesh objects in the BVH an extra visibility flag has been added. It is also only applied for camera rays. The strand width settings are also changed, so that the particle size is not included in the width calculation. Instead there is a separate particle system parameter for width scaling.
2013-04-15 21:38:31 +00:00
}
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
bool hit = scene_intersect(kg, &ray, visibility, &isect, &lcg_state, difl, extmax);
Cycles Hair: Strand Minimum Pixel Size Code is added to restrict the pixel size of strands in cycles. It works best with ribbon primitives and a preset for these is included. It uses distance dependent expansion of the strands and then stochastic strand removal to give a fading. To prevent a slowdown for triangle mesh objects in the BVH an extra visibility flag has been added. It is also only applied for camera rays. The strand width settings are also changed, so that the particle size is not included in the width calculation. Instead there is a separate particle system parameter for width scaling.
2013-04-15 21:38:31 +00:00
#else
Cleanup: Avoid some defines for scene_intersect(), related to Min Width.
2014-09-24 09:32:29 +00:00
bool hit = scene_intersect(kg, &ray, visibility, &isect, NULL, 0.0f, 0.0f);
Cycles Hair: Strand Minimum Pixel Size Code is added to restrict the pixel size of strands in cycles. It works best with ribbon primitives and a preset for these is included. It uses distance dependent expansion of the strands and then stochastic strand removal to give a fading. To prevent a slowdown for triangle mesh objects in the BVH an extra visibility flag has been added. It is also only applied for camera rays. The strand width settings are also changed, so that the particle size is not included in the width calculation. Instead there is a separate particle system parameter for width scaling.
2013-04-15 21:38:31 +00:00
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
Cycles: Add support for debug passes Currently only summed number of traversal steps and intersections used by the camera ray intersection pass is implemented, but in the future we will support more debug passes which would help checking what things makes the scene slow. Example of such extra passes could be number of bounces, time spent on the shader tree evaluation and so. Implementation from the Cycles side is pretty much straightforward, could only mention here that it's a build-time option disabled by default. From the blender side it's implemented as a PASS_DEBUG with several subtypes possible. This way we don't need to create an extra DNA pass type for each of the debug passes, saving us a bits. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D813
2014-10-04 13:00:26 +00:00
#ifdef __KERNEL_DEBUG__
if(state.flag & PATH_RAY_CAMERA) {
debug_data.num_bvh_traversal_steps += isect.num_traversal_steps;
}
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
#ifdef __VOLUME__
Code refactor: better distinguish scatter and absorption for volume integration.
2013-12-29 14:49:16 +00:00
/* volume attenuation, emission, scatter */
Cycles code refactor: replace magic ~0 values in the code with defines.
2014-03-29 12:03:47 +00:00
if(state.volume_stack[0].shader != SHADER_NONE) {
Cycles Volume Render: heterogeneous (textured) volumes support. Volumes can now have textured colors and density. There is a Volume Sampling panel in the Render properties with these settings: * Step size: distance between volume shader samples when rendering the volume. Lower values give more accurate and detailed results but also increased render time. * Max steps: maximum number of steps through the volume before giving up, to protect from extremely long render times with big objects or small step sizes. This is much more compute intensive than homogeneous volume, so when you are not using a texture you should enable the Homogeneous Volume option in the material or world for faster rendering. One important missing feature is that Generated texture coordinates are not yet working in volumes, and they are the default coordinates for nearly all texture nodes. So until that works you need to plug in object texture coordinates or a world space position. This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-29 21:19:38 +00:00
Ray volume_ray = ray;
volume_ray.t = (hit)? isect.t: FLT_MAX;
Cycles: Avoid redundant call to volume_stack_is_heterogeneous() for Distance Sampling.
2014-08-24 14:15:57 +00:00
bool heterogeneous = volume_stack_is_heterogeneous(kg, state.volume_stack);
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#ifdef __VOLUME_DECOUPLED__
Cycles volume: change heterogeneous volume sampling in branched path first hit. This now uses decoupled ray marching, and removes the probalistic scattering. What this means is that each AA sample will be slower but contain less noise, hopefully giving less render time to reach the same noise levels. For those following along, there's still a bunch of volume sampling improvements to do: all-light sampling, multiple importance sampling, transmittance threshold, better indirect light handling, multiple scatter approximation.
2014-03-29 12:03:50 +00:00
/* decoupled ray marching only supported on CPU */
/* cache steps along volume for repeated sampling */
VolumeSegment volume_segment;
ShaderData volume_sd;
Cycles: add Transparent Depth output to Light Path node. This can for example be useful if you want to manually terminate the path at some point and use a color other than black. Reviewed By: brecht Differential Revision: https://developer.blender.org/D454
2014-04-21 12:20:29 +00:00
shader_setup_from_volume(kg, &volume_sd, &volume_ray, state.bounce, state.transparent_bounce);
Cycles volume: change heterogeneous volume sampling in branched path first hit. This now uses decoupled ray marching, and removes the probalistic scattering. What this means is that each AA sample will be slower but contain less noise, hopefully giving less render time to reach the same noise levels. For those following along, there's still a bunch of volume sampling improvements to do: all-light sampling, multiple importance sampling, transmittance threshold, better indirect light handling, multiple scatter approximation.
2014-03-29 12:03:50 +00:00
kernel_volume_decoupled_record(kg, &state,
&volume_ray, &volume_sd, &volume_segment, heterogeneous);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* direct light sampling */
if(volume_segment.closure_flag & SD_SCATTER) {
Cycles: volume sampling method can now be set per material/world. This gives you "Multiple Importance", "Distance" and "Equiangular" choices. What multiple importance sampling does is make things more robust to certain types of noise at the cost of a bit more noise in cases where the individual strategies are always better. So if you've got a pretty dense volume that's lit from far away then distance sampling is usually more efficient. If you've got a light inside or near the volume then equiangular sampling is better. If you have a combination of both, then the multiple importance sampling will be better.
2014-06-07 16:47:14 +00:00
volume_segment.sampling_method = volume_stack_sampling_method(kg, state.volume_stack);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
bool all = kernel_data.integrator.sample_all_lights_direct;
Cycles: volume sampling method can now be set per material/world. This gives you "Multiple Importance", "Distance" and "Equiangular" choices. What multiple importance sampling does is make things more robust to certain types of noise at the cost of a bit more noise in cases where the individual strategies are always better. So if you've got a pretty dense volume that's lit from far away then distance sampling is usually more efficient. If you've got a light inside or near the volume then equiangular sampling is better. If you have a combination of both, then the multiple importance sampling will be better.
2014-06-07 16:47:14 +00:00
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
kernel_branched_path_volume_connect_light(kg, rng, &volume_sd,
Cycles: Simplify volume light connect code.
2015-03-12 23:09:13 +00:00
throughput, &state, &L, all, &volume_ray, &volume_segment);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* indirect light sampling */
int num_samples = kernel_data.integrator.volume_samples;
float num_samples_inv = 1.0f/num_samples;
for(int j = 0; j < num_samples; j++) {
/* workaround to fix correlation bug in T38710, can find better solution
* in random number generator later, for now this is done here to not impact
* performance of rendering without volumes */
RNG tmp_rng = cmj_hash(*rng, state.rng_offset);
PathState ps = state;
Ray pray = ray;
float3 tp = throughput;
/* branch RNG state */
path_state_branch(&ps, j, num_samples);
/* scatter sample. if we use distance sampling and take just one
* sample for direct and indirect light, we could share this
* computation, but makes code a bit complex */
float rphase = path_state_rng_1D_for_decision(kg, &tmp_rng, &ps, PRNG_PHASE);
float rscatter = path_state_rng_1D_for_decision(kg, &tmp_rng, &ps, PRNG_SCATTER_DISTANCE);
VolumeIntegrateResult result = kernel_volume_decoupled_scatter(kg,
&ps, &pray, &volume_sd, &tp, rphase, rscatter, &volume_segment, NULL, false);
Cycles: Further tweak for Decoupled Ray Marching Avoid some if checks when probalistic_scatter is false. Differential Revision: https://developer.blender.org/D743
2014-08-20 19:53:52 +00:00
Cleanup: Silence compiler warning.
2014-09-01 00:49:28 +00:00
(void)result;
Cycles: Further tweak for Decoupled Ray Marching Avoid some if checks when probalistic_scatter is false. Differential Revision: https://developer.blender.org/D743
2014-08-20 19:53:52 +00:00
kernel_assert(result == VOLUME_PATH_SCATTERED);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
Cleanup: Remove unused variable in kernel_path_volume_bounce().
2014-08-24 21:06:30 +00:00
if(kernel_path_volume_bounce(kg, rng, &volume_sd, &tp, &ps, &L, &pray)) {
Cycles: Further tweak for Decoupled Ray Marching Avoid some if checks when probalistic_scatter is false. Differential Revision: https://developer.blender.org/D743
2014-08-20 19:53:52 +00:00
kernel_path_indirect(kg, rng, pray, tp*num_samples_inv, num_samples, ps, &L);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
Cycles: Further tweak for Decoupled Ray Marching Avoid some if checks when probalistic_scatter is false. Differential Revision: https://developer.blender.org/D743
2014-08-20 19:53:52 +00:00
/* for render passes, sum and reset indirect light pass variables
* for the next samples */
path_radiance_sum_indirect(&L);
path_radiance_reset_indirect(&L);
Cycles volume: change heterogeneous volume sampling in branched path first hit. This now uses decoupled ray marching, and removes the probalistic scattering. What this means is that each AA sample will be slower but contain less noise, hopefully giving less render time to reach the same noise levels. For those following along, there's still a bunch of volume sampling improvements to do: all-light sampling, multiple importance sampling, transmittance threshold, better indirect light handling, multiple scatter approximation.
2014-03-29 12:03:50 +00:00
}
}
}
/* emission and transmittance */
if(volume_segment.closure_flag & SD_EMISSION)
path_radiance_accum_emission(&L, throughput, volume_segment.accum_emission, state.bounce);
throughput *= volume_segment.accum_transmittance;
/* free cached steps */
kernel_volume_decoupled_free(kg, &volume_segment);
#else
/* GPU: no decoupled ray marching, scatter probalistically */
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
int num_samples = kernel_data.integrator.volume_samples;
float num_samples_inv = 1.0f/num_samples;
/* todo: we should cache the shader evaluations from stepping
* through the volume, for now we redo them multiple times */
for(int j = 0; j < num_samples; j++) {
PathState ps = state;
Ray pray = ray;
ShaderData volume_sd;
Fix T41693: Volumes get brightened with extra volume samples on GPU + BPT
2014-09-03 15:23:07 +00:00
float3 tp = throughput * num_samples_inv;
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
/* branch RNG state */
path_state_branch(&ps, j, num_samples);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
VolumeIntegrateResult result = kernel_volume_integrate(
Cycles: Avoid redundant call to volume_stack_is_heterogeneous() for Distance Sampling.
2014-08-24 14:15:57 +00:00
kg, &ps, &volume_sd, &volume_ray, &L, &tp, rng, heterogeneous);
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#ifdef __VOLUME_SCATTER__
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
if(result == VOLUME_PATH_SCATTERED) {
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
/* todo: support equiangular, MIS and all light sampling.
* alternatively get decoupled ray marching working on the GPU */
Fix T41693: Volumes get brightened with extra volume samples on GPU + BPT
2014-09-03 15:23:07 +00:00
kernel_path_volume_connect_light(kg, rng, &volume_sd, tp, &state, &L);
Cycles: volume light sampling * Volume multiple importace sampling support to combine equiangular and distance sampling, for both homogeneous and heterogeneous volumes. * Branched path "Sample All Direct Lights" and "Sample All Indirect Lights" now apply to volumes as well as surfaces. Implementation note: For simplicity this is all done with decoupled ray marching, the only case we do not use decoupled is for distance only sampling with one light sample. The homogeneous case should still compile on the GPU because it only requires fixed size storage, but the heterogeneous case will be trickier to get working.
2014-04-04 14:45:49 +00:00
Cleanup: Remove unused variable in kernel_path_volume_bounce().
2014-08-24 21:06:30 +00:00
if(kernel_path_volume_bounce(kg, rng, &volume_sd, &tp, &ps, &L, &pray)) {
Fix T41693: Volumes get brightened with extra volume samples on GPU + BPT
2014-09-03 15:23:07 +00:00
kernel_path_indirect(kg, rng, pray, tp, num_samples, ps, &L);
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
/* for render passes, sum and reset indirect light pass variables
* for the next samples */
path_radiance_sum_indirect(&L);
path_radiance_reset_indirect(&L);
}
}
Code refactor: Split __VOLUME__ defines in Cycles. * __VOLUME__ is basic volume support with Emission and Absorption. * __VOLUME_SCATTER__ enables volume Scattering support. * __VOLUME_DECOUPLED__ enables Decoupled Ray Marching.
2014-08-20 21:15:30 +00:00
#endif
Cycles Volume Render: scattering support. This is done by adding a Volume Scatter node. In many cases you will want to add together a Volume Absorption and Volume Scatter node with the same color and density to get the expected results. This should work with branched path tracing, mixing closures, overlapping volumes, etc. However there's still various optimizations needed for sampling. The main missing thing from the volume branch is the equiangular sampling for homogeneous volumes. The heterogeneous scattering code was arranged such that we can use a single stratified random number for distance sampling, which gives less noise than pseudo random numbers for each step. For volumes where the color is textured there still seems to be something off, needs to be investigated.
2013-12-29 14:40:43 +00:00
}
Cycles volume: change homogeneous volume sampling in branched path first hit. Similar to surfaces, this will now always scatter rather than probabilistically scattering or not depending on the transmittance. This also makes calculation of branched path throughput non-probalistic, which makes thing slower too. That's to be solved by decoupled ray marching later.
2014-03-29 12:03:49 +00:00
/* todo: avoid this calculation using decoupled ray marching */
kernel_volume_shadow(kg, &state, &volume_ray, &throughput);
Cycles volume: change heterogeneous volume sampling in branched path first hit. This now uses decoupled ray marching, and removes the probalistic scattering. What this means is that each AA sample will be slower but contain less noise, hopefully giving less render time to reach the same noise levels. For those following along, there's still a bunch of volume sampling improvements to do: all-light sampling, multiple importance sampling, transmittance threshold, better indirect light handling, multiple scatter approximation.
2014-03-29 12:03:50 +00:00
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
}
#endif
if(!hit) {
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
/* eval background shader if nothing hit */
if(kernel_data.background.transparent) {
L_transparent += average(throughput);
#ifdef __PASSES__
if(!(kernel_data.film.pass_flag & PASS_BACKGROUND))
#endif
break;
}
#ifdef __BACKGROUND__
/* sample background shader */
Cleanup: Pass PathState as a whole, instead of individual members. Differential Revision: https://developer.blender.org/D477
2014-04-21 15:51:51 +00:00
float3 L_background = indirect_background(kg, &state, &ray);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
path_radiance_accum_background(&L, throughput, L_background, state.bounce);
#endif
break;
}
/* setup shading */
ShaderData sd;
Cycles: add Transparent Depth output to Light Path node. This can for example be useful if you want to manually terminate the path at some point and use a color other than black. Reviewed By: brecht Differential Revision: https://developer.blender.org/D454
2014-04-21 12:20:29 +00:00
shader_setup_from_ray(kg, &sd, &isect, &ray, state.bounce, state.transparent_bounce);
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
shader_eval_surface(kg, &sd, 0.0f, state.flag, SHADER_CONTEXT_MAIN);
Cycles Volume Render: add support for overlapping volume objects. This works pretty much as you would expect, overlapping volume objects gives a more dense volume. What did change is that world volume shaders are now active everywhere, they are no longer excluded inside objects. This may not be desirable and we need to think of better control over this. In some cases you clearly want it to happen, for example if you are rendering a fire in a foggy environment. In other cases like the inside of a house you may not want any fog, but it doesn't seem possible in general for the renderer to automatically determine what is inside or outside of the house. This is implemented using a simple fixed size array of shader/object ID pairs, limited to max 15 overlapping objects. The closures from all shaders are put into a single closure array, exactly the same as if an add shader was used to combine them.
2013-12-28 19:02:40 +00:00
shader_merge_closures(&sd);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
/* holdout */
#ifdef __HOLDOUT__
Cleanup: typos and extra brackets.
2014-08-14 14:31:34 +00:00
if(sd.flag & (SD_HOLDOUT|SD_HOLDOUT_MASK)) {
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
if(kernel_data.background.transparent) {
float3 holdout_weight;
if(sd.flag & SD_HOLDOUT_MASK)
holdout_weight = make_float3(1.0f, 1.0f, 1.0f);
else
Fix #32205: Holdout shader + transparent background stays black with Alpha = 1 It was read of initialized memory around holdout_weight in cases when holdout material is used. Seems that it should be assigned to result of shader_holdout_eval here. If Brecht could double check this it'll be great. This could potentially fix #32224: Holdout Error with CUDA Cycles Render
2012-08-01 12:59:47 +00:00
holdout_weight = shader_holdout_eval(kg, &sd);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
/* any throughput is ok, should all be identical here */
L_transparent += average(holdout_weight*throughput);
}
Cycles: small code cleanup + fix SSS closure mixed with other closures doing a bit too much work.
2013-04-02 16:37:28 +00:00
if(sd.flag & SD_HOLDOUT_MASK)
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
break;
}
#endif
Fix #35614: cycles objects on mask layer in render layers were writing passes such as motion/uv/normal but they should have been excluded from them.
2013-06-04 15:41:45 +00:00
/* holdout mask objects do not write data passes */
Cycles: add pass alpha threshold value to render layers. Z, Index, normal, UV and vector passes are only affected by surfaces with alpha transparency equal to or higher than this threshold. With value 0.0 the first surface hit will always write to these passes, regardless of transparency. With higher values surfaces that are mostly transparent can be skipped until an opaque surface is encountered.
2014-02-06 14:18:34 +00:00
kernel_write_data_passes(kg, buffer, &L, &sd, sample, &state, throughput);
Fix #35614: cycles objects on mask layer in render layers were writing passes such as motion/uv/normal but they should have been excluded from them.
2013-06-04 15:41:45 +00:00
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
#ifdef __EMISSION__
/* emission */
if(sd.flag & SD_EMISSION) {
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
float3 emission = indirect_primitive_emission(kg, &sd, isect.t, state.flag, state.ray_pdf);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
path_radiance_accum_emission(&L, throughput, emission, state.bounce);
}
#endif
/* transparency termination */
if(state.flag & PATH_RAY_TRANSPARENT) {
/* path termination. this is a strange place to put the termination, it's
* mainly due to the mixed in MIS that we use. gives too many unneeded
* shader evaluations, only need emission if we are going to terminate */
float probability = path_state_terminate_probability(kg, &state, throughput);
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
if(probability == 0.0f) {
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
break;
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
}
else if(probability != 1.0f) {
Fix T39804: cycles smoke domain visible in rendering. Transparent objects could become subtly visible by the different sampling patterns for pixels covered and not covered by the object. It still converged to the right solution but that can take a while. Now we try to use the same sampling pattern here.
2014-05-29 12:12:12 +00:00
float terminate = path_state_rng_1D_for_decision(kg, rng, &state, PRNG_TERMINATE);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
if(terminate >= probability)
break;
throughput /= probability;
}
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
}
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
#ifdef __AO__
/* ambient occlusion */
if(kernel_data.integrator.use_ambient_occlusion || (sd.flag & SD_AO)) {
Code refactor: move branched path AO and SSS code into functions.
2014-05-19 13:07:40 +00:00
kernel_branched_path_ao(kg, &sd, &L, &state, rng, throughput);
Cycles: reduce noise using regular path tracing + subsurface scattering with new cubic and gaussian falloff. Like the branched path tracer, this will now shade all intersection points instead of using one at random.
2013-08-24 15:02:08 +00:00
}
#endif
Cycles: initial subsurface multiple scattering support. It's not working as well as I would like, but it works, just add a subsurface scattering node and you can use it like any other BSDF. It is using fully raytraced sampling compatible with progressive rendering and other more advanced rendering algorithms we might used in the future, and it uses no extra memory so it's suitable for complex scenes. Disadvantage is that it can be quite noisy and slow. Two limitations that will be solved are that it does not work with bump mapping yet, and that the falloff function used is a simple cubic function, it's not using the real BSSRDF falloff function yet. The node has a color input, along with a scattering radius for each RGB color channel along with an overall scale factor for the radii. There is also no GPU support yet, will test if I can get that working later. Node Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF Implementation notes: http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Subsurface_Scattering
2013-04-01 20:26:52 +00:00
#ifdef __SUBSURFACE__
/* bssrdf scatter to a different location on the same object */
if(sd.flag & SD_BSSRDF) {
Fix T39823: SSS scatter doesn't update volume stack, causing shading artifacts Basically the title says it all, we need to update volume stack when doing ray scatter for SSS. This leads to speed regressions in cases scene does have both volume and SSS (performance in case there's no SSS or no volume should be the same). We might try optimizing kernel_path_subsurface_update_volume_stack() a bit by either recording all intersections or using some more appropriate visibility flags. Reviewers: brecht, juicyfruit, dingto Differential Revision: https://developer.blender.org/D795
2014-09-18 11:06:05 +00:00
kernel_branched_path_subsurface_scatter(kg, &sd, &L, &state,
rng, &ray, throughput);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
}
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
if(!(sd.flag & SD_HAS_ONLY_VOLUME)) {
Code refactor: move random number and MIS variables into PathState. This makes it easier to pass this state around, and wraps some common RNG dimension computations in utility functions.
2014-01-03 01:48:48 +00:00
PathState hit_state = state;
Cycles code refactor: deduplicate and symmetrize some path tracing code.
2014-04-04 12:21:35 +00:00
#ifdef __EMISSION__
/* direct light */
if(kernel_data.integrator.use_direct_light) {
bool all = kernel_data.integrator.sample_all_lights_direct;
kernel_branched_path_surface_connect_light(kg, rng,
&sd, &hit_state, throughput, 1.0f, &L, all);
}
#endif
/* indirect light */
kernel_branched_path_surface_indirect_light(kg, rng,
Fix T40135: cycles baking did not support branched path settings yet.
2014-05-19 13:14:43 +00:00
&sd, throughput, 1.0f, &hit_state, &L);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
/* continue in case of transparency */
throughput *= shader_bsdf_transparency(kg, &sd);
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
if(is_zero(throughput))
break;
}
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
path_state_next(kg, &state, LABEL_TRANSPARENT);
ray.P = ray_offset(sd.P, -sd.Ng);
Fix #33257: cycles camera clipping did not work through transparent objects.
2012-11-21 13:22:24 +00:00
ray.t -= sd.ray_length; /* clipping works through transparent */
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
Fix T41709: Bump not rendered correctly behind transparency using Branched Path Tracing
2014-09-06 12:16:38 +00:00
#ifdef __RAY_DIFFERENTIALS__
ray.dP = sd.dP;
ray.dD.dx = -sd.dI.dx;
ray.dD.dy = -sd.dI.dy;
#endif
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
#ifdef __VOLUME__
/* enter/exit volume */
Cycles Volume Render: add support for overlapping volume objects. This works pretty much as you would expect, overlapping volume objects gives a more dense volume. What did change is that world volume shaders are now active everywhere, they are no longer excluded inside objects. This may not be desirable and we need to think of better control over this. In some cases you clearly want it to happen, for example if you are rendering a fire in a foggy environment. In other cases like the inside of a house you may not want any fog, but it doesn't seem possible in general for the renderer to automatically determine what is inside or outside of the house. This is implemented using a simple fixed size array of shader/object ID pairs, limited to max 15 overlapping objects. The closures from all shaders are put into a single closure array, exactly the same as if an add shader was used to combine them.
2013-12-28 19:02:40 +00:00
kernel_volume_stack_enter_exit(kg, &sd, state.volume_stack);
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
#endif
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
}
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Separation of Indirect and Direct clamping. Indirect and Direct samples can now be clamped individually. This way we can clamp the indirect samples (fireflies), while keeping the direct highlights. Example render: http://www.pasteall.org/pic/show.php?id=66586 WARNING: This breaks backwards compatibility. If you had Clamping enabled in an old file, you must re-enable either Direct/Indirect clamping or both again. Reviewed by: brecht Differential Revision: https://developer.blender.org/D303
2014-02-10 20:44:49 +00:00
float3 L_sum = path_radiance_clamp_and_sum(kg, &L);
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
kernel_write_light_passes(kg, buffer, &L, sample);
Cycles: Add support for debug passes Currently only summed number of traversal steps and intersections used by the camera ray intersection pass is implemented, but in the future we will support more debug passes which would help checking what things makes the scene slow. Example of such extra passes could be number of bounces, time spent on the shader tree evaluation and so. Implementation from the Cycles side is pretty much straightforward, could only mention here that it's a build-time option disabled by default. From the blender side it's implemented as a PASS_DEBUG with several subtypes possible. This way we don't need to create an extra DNA pass type for each of the debug passes, saving us a bits. Reviewers: campbellbarton Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D813
2014-10-04 13:00:26 +00:00
#ifdef __KERNEL_DEBUG__
kernel_write_debug_passes(kg, buffer, &state, &debug_data, sample);
#endif
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
return make_float4(L_sum.x, L_sum.y, L_sum.z, 1.0f - L_transparent);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: first step for implementation of non-progressive sampler that handles direct and indirect lighting differently. Rather than picking one light for each point on the path, it now loops over all lights for direct lighting. For indirect lighting it still picks a random light each time. It gives control over the number of AA samples, and the number of Diffuse, Glossy, Transmission, AO, Mesh Light, Background and Lamp samples for each AA sample. This helps tuning render performance/noise and tends to give less noise for renders dominated by direct lighting. This sampling mode only works on the CPU, and still needs proper tile rendering to show progress (will follow tommorrow or so), because each AA sample can be quite slow now and so the delay between each update wil be too long.
2012-06-13 11:44:48 +00:00
#endif
Cycles: change __device and similar qualifiers to ccl_device in kernel code. This to avoids build conflicts with libc++ on FreeBSD, these __ prefixed values are reserved for compilers. I apologize to anyone who has patches or branches and has to go through the pain of merging this change, it may be easiest to do these same replacements in your code and then apply/merge the patch. Ref T37477.
2013-11-15 23:17:10 +00:00
ccl_device_inline void kernel_path_trace_setup(KernelGlobals *kg, ccl_global uint *rng_state, int sample, int x, int y, RNG *rng, Ray *ray)
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
{
float filter_u;
float filter_v;
Cleanup: Same thing in path trace setup, we can safely always assign the proper value.
2014-07-09 23:49:34 +00:00
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
int num_samples = kernel_data.integrator.aa_samples;
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles / Non-Progressive integrator: * Non-Progressive integrator is now available on the GPU (CUDA, sm_20 and above). Implementation details: * kernel_path_trace() has been split up into two functions: kernel_path_trace_non_progressive() and kernel_path_trace_progressive(). * We compile two CUDA kernel entry functions (in kernel.cu) for the two integrators, they are still inside one .cubin file but due to the kernel separation there should be no performance problem. I tested with the BMW file on my Geforce 540M and the render times were the same for 100 samples (1.57 min in my case). This is part of my GSoC project, SVN merge of r59032 + manual merge of UI changes for this from my branch.
2013-08-09 18:47:25 +00:00
path_rng_init(kg, rng_state, sample, num_samples, rng, x, y, &filter_u, &filter_v);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* sample camera ray */
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
Cycles: * Move some hair width related code into a dedicated branch. * Don't calculate time/lens RNG when Motion Blur or Depth of Field are disabled
2013-05-30 11:05:02 +00:00
float lens_u = 0.0f, lens_v = 0.0f;
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
Fix #35665: more CUDA issues with recent kernel changes, tested on sm_20, sm_21 and sm_30 cards, so hopefully it should all work now. Also includes some warnings fixes related to nvcc compiler arguments, should make no difference otherwise.
2013-06-11 21:58:48 +00:00
if(kernel_data.cam.aperturesize > 0.0f)
Cycles / Non-Progressive integrator: * Non-Progressive integrator is now available on the GPU (CUDA, sm_20 and above). Implementation details: * kernel_path_trace() has been split up into two functions: kernel_path_trace_non_progressive() and kernel_path_trace_progressive(). * We compile two CUDA kernel entry functions (in kernel.cu) for the two integrators, they are still inside one .cubin file but due to the kernel separation there should be no performance problem. I tested with the BMW file on my Geforce 540M and the render times were the same for 100 samples (1.57 min in my case). This is part of my GSoC project, SVN merge of r59032 + manual merge of UI changes for this from my branch.
2013-08-09 18:47:25 +00:00
path_rng_2D(kg, rng, sample, num_samples, PRNG_LENS_U, &lens_u, &lens_v);
Cycles: experimental correlated multi-jittered sampling pattern that can be used instead of sobol. So far one doesn't seem to be consistently better or worse than the other for the same number of samples but more testing is needed. The random number generator itself is slower than sobol for most number of samples, except 16, 64, 256, .. because they can be computed faster. This can probably be optimized, but we can do that when/if this actually turns out to be useful. Paper this implementation is based on: http://graphics.pixar.com/library/MultiJitteredSampling/ Also includes some refactoring of RNG code, fixing a Sobol correlation issue with the first BSDF and < 16 samples, skipping some unneeded RNG calls and using a simpler unit square to unit disk function.
2013-06-07 16:06:22 +00:00
Revert "Cleanup: Simplify camera sample motion blur code." This reverts commit 8197f0bb645f73f41071daaccf205a7583e695f5.
2015-02-26 12:27:02 +00:00
float time = 0.0f;
Cycles: * Move some hair width related code into a dedicated branch. * Don't calculate time/lens RNG when Motion Blur or Depth of Field are disabled
2013-05-30 11:05:02 +00:00
#ifdef __CAMERA_MOTION__
Revert "Cleanup: Simplify camera sample motion blur code." This reverts commit 8197f0bb645f73f41071daaccf205a7583e695f5.
2015-02-26 12:27:02 +00:00
if(kernel_data.cam.shuttertime != -1.0f)
time = path_rng_1D(kg, rng, sample, num_samples, PRNG_TIME);
Cycles: support for motion vector and UV passes. Most of the changes are related to adding support for motion data throughout the code. There's some code for actual camera/object motion blur raytracing but it's unfinished (it badly slows down the raytracing kernel even when the option is turned off), so that code it disabled still. Motion vector export from Blender tries to avoid computing derived meshes when the mesh does not have a deforming modifier, and it also won't store motion vectors for every vertex if only the object or camera is moving.
2012-04-30 12:49:26 +00:00
#endif
Revert "Cleanup: Simplify camera sample motion blur code." This reverts commit 8197f0bb645f73f41071daaccf205a7583e695f5.
2015-02-26 12:27:02 +00:00
camera_sample(kg, x, y, filter_u, filter_v, lens_u, lens_v, time, ray);
Cycles / Non-Progressive integrator: * Non-Progressive integrator is now available on the GPU (CUDA, sm_20 and above). Implementation details: * kernel_path_trace() has been split up into two functions: kernel_path_trace_non_progressive() and kernel_path_trace_progressive(). * We compile two CUDA kernel entry functions (in kernel.cu) for the two integrators, they are still inside one .cubin file but due to the kernel separation there should be no performance problem. I tested with the BMW file on my Geforce 540M and the render times were the same for 100 samples (1.57 min in my case). This is part of my GSoC project, SVN merge of r59032 + manual merge of UI changes for this from my branch.
2013-08-09 18:47:25 +00:00
}
Cycles: change __device and similar qualifiers to ccl_device in kernel code. This to avoids build conflicts with libc++ on FreeBSD, these __ prefixed values are reserved for compilers. I apologize to anyone who has patches or branches and has to go through the pain of merging this change, it may be easiest to do these same replacements in your code and then apply/merge the patch. Ref T37477.
2013-11-15 23:17:10 +00:00
ccl_device void kernel_path_trace(KernelGlobals *kg,
ccl_global float *buffer, ccl_global uint *rng_state,
Cycles / Non-Progressive integrator: * Non-Progressive integrator is now available on the GPU (CUDA, sm_20 and above). Implementation details: * kernel_path_trace() has been split up into two functions: kernel_path_trace_non_progressive() and kernel_path_trace_progressive(). * We compile two CUDA kernel entry functions (in kernel.cu) for the two integrators, they are still inside one .cubin file but due to the kernel separation there should be no performance problem. I tested with the BMW file on my Geforce 540M and the render times were the same for 100 samples (1.57 min in my case). This is part of my GSoC project, SVN merge of r59032 + manual merge of UI changes for this from my branch.
2013-08-09 18:47:25 +00:00
int sample, int x, int y, int offset, int stride)
{
/* buffer offset */
int index = offset + x + y*stride;
int pass_stride = kernel_data.film.pass_stride;
rng_state += index;
buffer += index*pass_stride;
/* initialize random numbers and ray */
RNG rng;
Ray ray;
kernel_path_trace_setup(kg, rng_state, sample, x, y, &rng, &ray);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* integrate */
Fisheye Camera for Cycles For sample images see: http://www.dalaifelinto.com/?p=399 (equisolid) http://www.dalaifelinto.com/?p=389 (equidistant) The 'use_panorama' option is now part of a new Camera type: 'Panorama'. Created two other panorama cameras: - Equisolid: most of lens in the market simulate this lens - e.g. Nikon, Canon, ...) this works as a real lens up to an extent. The final result takes the sensor dimensions into account also. .:. to simulate a Nikon DX2S with a 10.5mm lens do: sensor: 23.7 x 15.7 fisheye lens: 10.5 fisheye fov: 180 render dimensions: 4288 x 2848 - Equidistant: this is not a real lens model. Although the old equidistant lens simulate this lens. The result is always as a circular fisheye that takes the whole sensor (in other words, it doesn't take the sensor into consideration). This is perfect for fulldomes ;) For the UI we have 10 to 360 as soft values and 10 to 3600 as hard values (because we can). Reference material: http://www.hdrlabs.com/tutorials/downloads_files/HDRI%20for%20CGI.pdf http://www.bobatkins.com/photography/technical/field_of_view.html Note, this is not a real simulation of the light path through the lens. The ideal solution would be this: https://graphics.stanford.edu/wikis/cs348b-11/Assignment3 http://www.graphics.stanford.edu/papers/camera/ Thanks Brecht for the fix, suggestions and code review. Kudos for the dome community for keeping me stimulated on the topic since 2009 ;) Patch partly implemented during lab time at VisGraf, IMPA - Rio de Janeiro.
2012-05-04 16:20:51 +00:00
float4 L;
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
if(ray.t != 0.0f)
Fix #36545: crash with branched path tracing, correlated multi-jittered sampling and subsurface scattering.
2013-08-23 23:04:50 +00:00
L = kernel_path_integrate(kg, &rng, sample, ray, buffer);
Cycles / Non-Progressive integrator: * Non-Progressive integrator is now available on the GPU (CUDA, sm_20 and above). Implementation details: * kernel_path_trace() has been split up into two functions: kernel_path_trace_non_progressive() and kernel_path_trace_progressive(). * We compile two CUDA kernel entry functions (in kernel.cu) for the two integrators, they are still inside one .cubin file but due to the kernel separation there should be no performance problem. I tested with the BMW file on my Geforce 540M and the render times were the same for 100 samples (1.57 min in my case). This is part of my GSoC project, SVN merge of r59032 + manual merge of UI changes for this from my branch.
2013-08-09 18:47:25 +00:00
else
L = make_float4(0.0f, 0.0f, 0.0f, 0.0f);
/* accumulate result in output buffer */
kernel_write_pass_float4(buffer, sample, L);
path_rng_end(kg, rng_state, rng);
}
Cycles: more code refactoring to rename things internally as well. Also change property name back so we keep compatibility.
2013-08-23 14:34:34 +00:00
#ifdef __BRANCHED_PATH__
Cycles: change __device and similar qualifiers to ccl_device in kernel code. This to avoids build conflicts with libc++ on FreeBSD, these __ prefixed values are reserved for compilers. I apologize to anyone who has patches or branches and has to go through the pain of merging this change, it may be easiest to do these same replacements in your code and then apply/merge the patch. Ref T37477.
2013-11-15 23:17:10 +00:00
ccl_device void kernel_branched_path_trace(KernelGlobals *kg,
ccl_global float *buffer, ccl_global uint *rng_state,
Cycles / Non-Progressive integrator: * Non-Progressive integrator is now available on the GPU (CUDA, sm_20 and above). Implementation details: * kernel_path_trace() has been split up into two functions: kernel_path_trace_non_progressive() and kernel_path_trace_progressive(). * We compile two CUDA kernel entry functions (in kernel.cu) for the two integrators, they are still inside one .cubin file but due to the kernel separation there should be no performance problem. I tested with the BMW file on my Geforce 540M and the render times were the same for 100 samples (1.57 min in my case). This is part of my GSoC project, SVN merge of r59032 + manual merge of UI changes for this from my branch.
2013-08-09 18:47:25 +00:00
int sample, int x, int y, int offset, int stride)
{
/* buffer offset */
int index = offset + x + y*stride;
int pass_stride = kernel_data.film.pass_stride;
rng_state += index;
buffer += index*pass_stride;
/* initialize random numbers and ray */
RNG rng;
Ray ray;
kernel_path_trace_setup(kg, rng_state, sample, x, y, &rng, &ray);
/* integrate */
float4 L;
Cycles Volume Render: support for rendering of homogeneous volume with absorption. This is the simplest possible volume rendering case, constant density inside the volume and no scattering or emission. My plan is to tweak, verify and commit more volume rendering effects one by one, doing it all at once makes it difficult to verify correctness and track down bugs. Documentation is here: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Materials/Volume Currently this hooks into path tracing in 3 ways, which should get us pretty far until we add more advanced light sampling. These 3 hooks are repeated in the path tracing, branched path tracing and transparent shadow code: * Determine active volume shader at start of the path * Change active volume shader on transmission through a surface * Light attenuation over line segments between camera, surfaces and background This is work by "storm", Stuart Broadfoot, Thomas Dinges and myself.
2013-12-28 15:56:19 +00:00
if(ray.t != 0.0f)
Cycles: more code refactoring to rename things internally as well. Also change property name back so we keep compatibility.
2013-08-23 14:34:34 +00:00
L = kernel_branched_path_integrate(kg, &rng, sample, ray, buffer);
Fisheye Camera for Cycles For sample images see: http://www.dalaifelinto.com/?p=399 (equisolid) http://www.dalaifelinto.com/?p=389 (equidistant) The 'use_panorama' option is now part of a new Camera type: 'Panorama'. Created two other panorama cameras: - Equisolid: most of lens in the market simulate this lens - e.g. Nikon, Canon, ...) this works as a real lens up to an extent. The final result takes the sensor dimensions into account also. .:. to simulate a Nikon DX2S with a 10.5mm lens do: sensor: 23.7 x 15.7 fisheye lens: 10.5 fisheye fov: 180 render dimensions: 4288 x 2848 - Equidistant: this is not a real lens model. Although the old equidistant lens simulate this lens. The result is always as a circular fisheye that takes the whole sensor (in other words, it doesn't take the sensor into consideration). This is perfect for fulldomes ;) For the UI we have 10 to 360 as soft values and 10 to 3600 as hard values (because we can). Reference material: http://www.hdrlabs.com/tutorials/downloads_files/HDRI%20for%20CGI.pdf http://www.bobatkins.com/photography/technical/field_of_view.html Note, this is not a real simulation of the light path through the lens. The ideal solution would be this: https://graphics.stanford.edu/wikis/cs348b-11/Assignment3 http://www.graphics.stanford.edu/papers/camera/ Thanks Brecht for the fix, suggestions and code review. Kudos for the dome community for keeping me stimulated on the topic since 2009 ;) Patch partly implemented during lab time at VisGraf, IMPA - Rio de Janeiro.
2012-05-04 16:20:51 +00:00
else
Code cleanup / Cycles: * Simplify shaperadius() function a bit to avoid castings. * Style cleanup 1.f -> 1.0f, to follow rest of Cycles code.
2013-05-18 11:04:29 +00:00
L = make_float4(0.0f, 0.0f, 0.0f, 0.0f);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
/* accumulate result in output buffer */
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
kernel_write_pass_float4(buffer, sample, L);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
Cycles: Render Passes Currently supported passes: * Combined, Z, Normal, Object Index, Material Index, Emission, Environment, Diffuse/Glossy/Transmission x Direct/Indirect/Color Not supported yet: * UV, Vector, Mist Only enabled for CPU devices at the moment, will do GPU tweaks tommorrow, also for environment importance sampling. Documentation: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Passes
2012-01-25 17:23:52 +00:00
path_rng_end(kg, rng_state, rng);
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
}
Cycles: * GPU kernel can now be compiled without __NON_PROGRESSIVE__ again, was broken after my last commit. Also add a check for have_error(), in case the GPU kernel comes without Non-Progressive, to avoid a crash. * Don't compile progressive kernel twice on CPU, if __NON_PROGRESSIVE__ would be disabled there.
2013-08-09 20:03:49 +00:00
#endif
Cycles render engine, initial commit. This is the engine itself, blender modifications and build instructions will follow later. Cycles uses code from some great open source projects, many thanks them: * BVH building and traversal code from NVidia's "Understanding the Efficiency of Ray Traversal on GPUs": http://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/ * Open Shading Language for a large part of the shading system: http://code.google.com/p/openshadinglanguage/ * Blender for procedural textures and a few other nodes. * Approximate Catmull Clark subdivision from NVidia Mesh tools: http://code.google.com/p/nvidia-mesh-tools/ * Sobol direction vectors from: http://web.maths.unsw.edu.au/~fkuo/sobol/ * Film response functions from: http://www.cs.columbia.edu/CAVE/software/softlib/dorf.php
2011-04-27 11:58:34 +00:00
CCL_NAMESPACE_END
Copy Permalink