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.
This removes a few optimizations to avoid exp() calls and division, they will be
added back later, at the moment it's more important to make the code easier to
understand and refactor.
Rather use random point in each step instead of giving the steps random sizes.
Gives a bit more accurate results with large step sizes, but also convenient
convention for later changes.
These can currently be accessed by adding an Attribute node and specifying one
of those three names. A Smoke/Fire node should be added at some point to make
this more convenient.
These values might change still before the release, in particular for flame the
meaning seems unclear, it's just values in the 0..1 range. This is useful for
color ramps, but it might be good if this was also available as temperature in
kelvin so it can be plugged into the blackbody node. But I couldn't figure out
from the smoke code if or how this corresponds to a physical unit.
Here's a (quite poor) example file for a fire + smoke setup:
http://www.pasteall.org/blend/27990
These are internally stored as a 3D image textures, but accessible like e.g.
UV coordinates though the attribute node and getattribute().
This is convenient for rendering e.g. smoke objects where data like density is
really a property of the mesh, and it avoids having to specify the smoke object
in a texture node, instead the material will work with any smoke domain.
Notes:
* The motion steps only affect deformation motion blur.
* The actual number of steps is 2^(steps - 1). This avoids having to sample at
many different times for object with more/fewer steps, now the times overlap.
* Deformation motion blur is enabled by default in existing files that have
motion blur enabled. If the object is not deforming, this will be detected at
export time, so raytracing performance will not be affected.
Part of the code is from the summer of code project by Gavin Howard.
This now supports multiple steps and subframe sampling of motion.
There is one difference for object and camera transform motion blur. It still
only supports two steps there, but the transforms are now sampled at subframe
times instead of the previous and next frame and then interpolated/extrapolated.
This will give different render results in some cases but it's more accurate.
Part of the code is from the summer of code project by Gavin Howard, but it has
been significantly rewritten and extended.
added in rB74518b28267e9b18199212fbaa3c689fa018d20c.
No special bind/unbind needed for standalone viewer, so can just use a
static stub in the display callback.
Issue was caused by the wrong usage of OCIO GLSL binding API. To make it
work properly on pre-GLSL-1.3 drivers shader is to be enabled after the
texture is binded to the opengl context. Otherwise it wouldn't know the
proper texture size.
This is actually a regression in 2.70 and to be ported to 'a'.
There are a couple of bugs that come together here:
* Particle hacks: extra modifier stack evaluation just for particles in
rna_Object_create_duplilist. This is where the primary issue stems from,
the "for_render" setting replaced the G.is_rendering flag in threaded
depsgraph. This causes particles to recalculate the entire modifier
stack with _render_ settings instead of viewport settings now. Fixed by
taking the 'preview' parameter in Cycles into account.
* Buggy skin modifier: The skin modifier generates a different amount of
vertices and faces **on every execution**. This must be looked at
separately, but it could be another reason why cycles constantly
restarted the sync process.
* Particles get re-distributed randomly every time (changing seed). This
could be caused just by the broken skin modifier, but might still be an
issue when simply rendering with cycles, since the psys will be
evaluated for render settings, if just temporarily.
Gives ~11% speedup for hair.blend, ~10% for koro_final.blend
Also extract few common subexpressions in hair calculation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D318
