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.
This basically records all volumes steps, which can then later be used multiple
time to take scattering samples, without having to step through the volume
again. From the paper:
"Importance Sampling Techniques for Path Tracing in Participating Media"
This works only on the CPU, due to usage of malloc/free.
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.
A question here might be: why?
The answer is that GPUs will convert this to triangles so we are wasting
memory during conversion of the element buffer to a triangle buffer
anyway.
The second reason is that some modern GPUs are slower rendering GL_QUADS
The third reason is that due to element caching, this should not in
theory be slower (cached elements do not get recalculated on the GPU).
- display handles with solid color.
- active handle is highlighted.
- 1/4 of the colorband draws solid.
- use old-style handles when zoomed out.
D289 by Charlie Jolly with own modifications.
Issue is that sampling functions did not pass a thread index to the
texture sampler so all threads were contesting for the same pool.
Paint cursors and sculpting that used openmp for threading suffered from
this. Now use omp_get_thread_num to pass the thread number.
Summary:
The title actually says it all, it's just possible to
have independent free handles for mask splines. Also
it's now possible to have aligned handles displayed
as independent handles.
Required changes in quite a few places, but they're
rather straightforward.
From user perspective there's one really visible change
which is removed Handle Type menu from the panel. With
asymmetric handles it's not clear which handle type to
display there. So now the only way to change handle type
is via V-key menu.
Rewrote normal evaluation function to make it deal
with new type of handles we support. Now it works in
the following way:
- Offset the original spline by maximal weight
- Calculate vector between corresponding U positions
on offset and original spline
- Normalize this vector.
Seems to be giving more adequate results and doesn't
tend to self-intersect as much as old behavior used to,
There're still some changes which needed to be done, but
which are planned for further patch:
- Support colors and handle size via themes.
- Make handles color-coded, just the same as done for
regular bezier splines in 3D viewport.
Additional changes to make roto workflow even better:
- Use circles to draw handles
- Support AA for handles
- Change click-create-drag to change curvature of the
spline instead of adjusting point position.
Reviewers: campbellbarton
CC: sebastian_k, hype, cronk
Differential Revision: http://developer.blender.org/D121
Root of the issues comes to the fact that it's possible to produce
a situation when library object data uses local object. This is
actually forbidden and not supported by .blend IO.
Made it so Make Local wouldn't produce such an unsupported states.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D372
Bevel Factor Mapping allows to control the relation between bevel factors
(number between 0 and 1) and the rendered start and end point of a beveled
spline.
There are three options: "Resolution", "Segments", "Spline". "Resolution"
option maps bevel factors as it was done < 2.71, "Spline" and "Segments"
are new.
* "Resolution“: Map the bevel factor to the number of subdivisions of a
spline (U resolution).
* "Segments“: Map the bevel factor to the length of a segment and to the
number of subdivisions of a segment.
* "Spline": Map the bevel factor to the length of a spline.
Reviewers: yakca, sergey, campbellbarton
CC: sanne
Differential Revision: https://developer.blender.org/D294
