| Age | Commit message (Collapse) | Author |
|---|
|
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
|
|
When using the Normal output of the Texture Coordinate node on Point and Spot lamps, the coordinates now depend on the rotation of the lamp.
On Area lamps, the Parametric output of the Geometry node now returns UV coordinates on the area lamp.
Credit for the Area lamp part goes to Stefan Werner (from D1995).
|
|
Update on Frame Change
Not really ideal fix at all, but we are at RC today, so better to play really safe.
|
|
Once again, should be no functional changes.
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
|
|
This unifies things around ignoring light due to lack of scene
contribution or due to other optimization tricks.
|
|
There were two issues:
1. Memory leak: std:;erase does not call delete on the
pointer (which is actually a good idea),
2. After MIS was disabled in viewport render there was
no way to bring MIS back.
Now instead of removing light from the scene data we
kind of tagging it for an ignore. Possible cleanup
would be to add Light::is_enabled and use that instead
of passing weird and wonderful function arguments.
|
|
This commit makes it so light which has zero energy or doesn't has
emission shader at all is being ignored by the path tracing.
|
|
This patch adds support for light portals: objects that help sampling the
environment light, therefore improving convergence. Using them tor other
lights in a unidirectional pathtracer is virtually useless.
The sampling is done with the area-preserving code already used for area lamps.
MIS is used both for combination of different portals and for combining portal-
and envmap-sampling.
The direction of portals is considered, they aren't used if the sampling point
is behind them.
Reviewers: sergey, dingto, #cycles
Reviewed By: dingto, #cycles
Subscribers: Lapineige, nutel, jtheninja, dsisco11, januz, vitorbalbio, candreacchio, TARDISMaker, lichtwerk, ace_dragon, marcog, mib2berlin, Tunge, lopataasdf, lordodin, sergey, dingto
Differential Revision: https://developer.blender.org/D1133
|
|
This was already mixed a bit, but the dot belongs there.
|
|
With this setting, we can limit the influence of a lamp to a certain amount of bounces.
0 = Only direct light contribution
1 = 1 light bounce
...
Differential revision: https://developer.blender.org/D860
You can find an example render in the release logs: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.73/Cycles
|
|
This adds a new "Volume Scatter" option to the "Ray Visibility" panels and can be used to e.g. exclude lamps from having an influence on the volume. See release logs for an example: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Cycles
Differential revision: https://developer.blender.org/D771
|
|
More information in this post:
http://code.blender.org/
Thanks to all contributes for giving their permission!
|
|
viewport render.
|
|
without
multiple importance sampling, so you can disable them for diffuse/glossy/transmission.
The Light Path node here is still weak and does not give this info. To make that
work we'd need to evaluate the shader multiple times which is slow and we can't
detect well enough when it is actually needed.
|
|
disabled by default for backwards compatibility.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Integrator
|
|
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.
|
|
|
|
By default lighting from the world is computed solely with indirect light
sampling. However for more complex environment maps this can be too noisy, as
sampling the BSDF may not easily find the highlights in the environment map
image. By enabling this option, the world background will be sampled as a lamp,
with lighter parts automatically given more samples.
Map Resolution specifies the size of the importance map (res x res). Before
rendering starts, an importance map is generated by "baking" a grayscale image
from the world shader. This will then be used to determine which parts of the
background are light and so should receive more samples than darker parts.
Higher resolutions will result in more accurate sampling but take more setup
time and memory.
Patch by Mike Farnsworth, thanks!
|
|
shader flags for various purposes, and some code for light types other than
points.
|
|
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
|
