The issue was caused by different AABB used by Cycles and texture sampler.
Instead of trying to keep this two functions in sync we now do have an
utility call in the point density node to query the AABB.
This changes the following defaults:
- Render settings:
* Samples: 100
* Preview Samples: 50
* Filter: Blackmann-Harris
* Tile Order: Hilbert Spiral
- Lamp settings:
* Use MIS: On
- Material settings:
* Volume Sampling: Multiple Importance
Old files are not affected, I tested the versioning code back and forth.
More changes are to come (World, BVH...) but that needs a bit more work.
Fix T47213.
There was actually no real bug here, just clarify now in the UI that Mesh, World and Lamp samples only have an effect if we sample all lights (direct or indirect).
The issue was discontinuity in logic when importing vertices from blender
and then importing data layers regardless of how we split the face. Quite
interesting we didn't notice this issue before.
Thanks Bastien for the investigation, based on D1742 but redid it to make
patch a bit more clear to follow.
The combined pass is built with the contributions the user finds fit.
It is useful for lightmap baking, as well as non-view dependent effects
baking.
The manual will be updated once we get closer to the 2.77 release.
Meanwhile the new page can be found here:
http://dalaifelinto.com/blender-manual/render/cycles/baking.html
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D1674
This commit removes the experimental CUDA kernel, making SSS and CMJ
regular features.
Several improvements have been made in the past few
weeks (thanks Sergey!) which make SSS render several times faster (2-3x
compared to 2.76b) on the GPU, and the increased VRAM usage has also been
fixed. Therefore the experimental kernel is no longer needed.
Differential Revision: https://developer.blender.org/D1726
Manual has been updated: too:
https://www.blender.org/manual/render/cycles/features.html
Should be no functional changes at all, just speeds up re-compilation
when some features needs to be disabled for development purposes.
For example, when running lots of Valgrind it's handy to disable any
GPU devices because otherwise you'll be wasting quite some time in
the driver while enumerating devices.
Reviewers: dingto, lukasstockner97, brecht, juicyfruit
Differential Revision: https://developer.blender.org/D1730
This panel is only visible when debug_value is set to 256 and has no
affect in other cases. However, if debug value is not set to this
value, environment variables will be used to control which features
are enabled, so there's no visible changes to anyone in fact.
There are some changes needed to prevent devices re-enumeration on
every Cycles session create.
Reviewers: juicyfruit, lukasstockner97, dingto, brecht
Reviewed By: lukasstockner97, dingto
Differential Revision: https://developer.blender.org/D1720
This patch adds the "Hilbert Spiral", a custom-designed continuous space-filling curve, as a tile order for rendering in Cycles.
It essentially works by dividing the tiles into tile blocks which are processed in a spiral outwards from the center. Inside each
block, the tiles are processed in a regular Hilbert curve pattern. By rotating that pattern according to the spiral direction,
a continuous curve is obtained, which helps with cache coherency and therefore rendering speed.
The curve is a compromise between the faster-rendering Bottom-to-Top etc. orders and the Center order, which is a bit slower,
but starts with the more important areas. The Hilbert Spiral also starts in the center (unless huge tiles are used) and is still
marginally slower than Bottom-to-Top, but noticeably faster than Center.
Reviewers: sergey, #cycles, dingto
Reviewed By: #cycles, dingto
Subscribers: iscream, gregzaal, sergey, mib2berlin
Differential Revision: https://developer.blender.org/D1166
This commit overrides the user's choice of tile order in the case of viewport rendering and always uses bottom-to-top instead.
This was already done until the TileManager redesign, but since it removed the distinction between viewport and regular rendering
in the manager, the viewport was now also using the selected order. Since this requires sorting of the generated tiles,
it slows down rendering a bit. With the forced bottom-to-top order, this sorting step can now be avoided again.
Since the tile order is invisible anyways for viewport rendering, this commit won't have any impact on users (apart from a slight speedup).
This commit adds "Bands Saw" and "Rings Saw" to the options for the Wave texture node in Cycles, behaving similar to the Saw option in BI textures.
Requested by @cekuhnen on BA.
Reviewers: dingto, sergey
Subscribers: cekuhnen
Differential Revision: https://developer.blender.org/D1699
This is an attempt to emulate real CMOS cameras which reads sensor by scanlines
and hence different scanlines are sampled at a different moment in time, which
causes so called rolling shutter effect. This effect will, for example, make
vertical straight lines being curved when doing horizontal camera pan.
This is controlled by the Shutter Type option in the Motion Blur panel.
Additionally, since scanline sampling is not instantaneous it's possible to have
motion blur on top of rolling shutter.
This is controlled by the Rolling Shutter Time slider which controls balance
between pure rolling shutter effect and pure motion blur effect.
Reviewers: brecht, juicyfruit, dingto, keir
Differential Revision: https://developer.blender.org/D1624
Vector mapping node was doing some weird mapping of both original and mapped
coordinates. Mapping of original coordinates was caused by the clamping nature
of the LUT generated from the node. Mapping of the mapped value again was quite
totally obscure -- one needed to constantly keep in mind that actual value will
be scaled up and moved down.
This commit makes it so values in the vector curve mapping are always absolute.
In fact, it is now behaving quite the same as RGB curve mapping node and the
code could be de-duplicated. Keeping the code duplicated for a bit so it's more
clear what exact parts of the node changed.
Reviewers: brecht
Subscribers: bassamk
Differential Revision: https://developer.blender.org/D1672
Previously RGB Curves node will clamp input to 0..1 which is rather useless
when one wants to use HDR image textures and do bit of correction on them.
Now kernel code supports extrapolation of baked LUT based on first/last two
table points and performs linear extrapolation.
The only tricky part is to guess the range to bake the LUT for. Currently
it's using simple approach -- minmax of the input curves. While this behaves
ok for the simple cases it's easy to trick the system up causing incorrect
results.
Not sure we can solve those issues in a general case and since the new code
is giving more expected results it's not that bad actually. In the worst
case artist migh always create explicit point to make sure LUT is created
for the needed HDR range.
Reviewers: brecht, juicyfruit
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D1658
Previously render nodes will be always created with just a VECTOR socket
type and then those sockets will try to be set as all point, vector and
normal to work around lack of such a subtype distinguishing in blender.
This change makes it so subtype is being queried from OSL itself and
proper subtupe is being used for socket.
It's still not in use for the official builds because it requires changes
applied recently on the 1.7 branch of OSL:
https://github.com/imageworks/OpenShadingLanguage/commit/f70e58f
This solves artists confusion reported in T46117.
Reviewers: #cycles, juicyfruit
Reviewed By: #cycles, juicyfruit
Subscribers: juicyfruit
Differential Revision: https://developer.blender.org/D1627
The issue was caused by possible use of object->derivedFinal from the render
thread, The patch tries to eliminate (or at least minimize, huh) amount of
access to the derivedFinal of a source object. It's still possible that in
the case of particle source derived mesh will be still unsafely used, but
with the patch applied we can easily change runtime part of the code and
cache derived mesh on the preparation stage.
Some ideas for the future:
- Check whether cache() was called on the point density node when calling
calc().
- Cache derivedMesh in the runtime part of point density node to avoid
possible remained thread conflicts.
- NULL the runtime part of the node on .blend load
Reviewers: campbellbarton, plasmasolutions
Reviewed By: plasmasolutions
Differential Revision: https://developer.blender.org/D1614
This is sort of extension of existing Use Environment option which now allows to
disable AO on the render layer basis.
Useful in cases like disabling AO for the background because it might make it
too flat and so.
Reviewers: juicyfruit, dingto, brecht
Reviewed By: brecht
Subscribers: eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1633
This commit adds the Blackman-Harris windows function as a pixel filter to Cycles. On some cases, such as wireframes or high-frequency textures,
Blackman-Harris can give subtle but noticable improvements over the Gaussian window.
Also, the gaussian window was truncated too early, which degraded quality a bit, therefore the evaluation region is now three times as wide.
To avoid artifacts caused by the wider curve, the filter table size is increased to 1024.
Reviewers: #cycles
Differential Revision: https://developer.blender.org/D1453
Shutter curve now can be controlled using curve mapping widget in the motion
blur panel in Render buttons. Only mapping from 0..1 by x axis are allowed,
Y values will be normalized to fill in 0..1 space as well automatically.
Y values of 0 means fully closed shutter, Y values of 1 means fully opened
shutter.
Default mapping is set to old behavior when shutter opens and closes instantly.
This shutter mapping curve could easily be used by any other render engine by
accessing scene.render.motion_blur_shutter_curve.
Reviewers: #cycles, brecht, juicyfruit, campbellbarton
Differential Revision: https://developer.blender.org/D1585
This adds an option to control at what time relative to the current frame
the shutter is fully opened. Supported options are:
- Shutter is starting to open at the current frame
- Shutter is fully opened at the current frame
- Shutter is fully closed at the current frame
Custom shutter time offset is possible, same as custom curve for shutter
openness but those are considered nice things to have rather than something
crucial.
Reviewers: juicyfruit, dingto
Subscribers: venomgfx, hjalti
Differential Revision: https://developer.blender.org/D1380
Title says it all, based on feedback of artists from gooseberry team.
This mainly affects cases when going to a local view from layers setup
when some lamps were on invisible layers. Those lights are no longer
becoming visible to the object in local view.
Reviewers: brecht, juicyfruit, dingto
Reviewed By: juicyfruit, dingto
Subscribers: maxon, eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1326
This commit exposes the interpolation parameter for environment textures (requested by DolpheenDream on IRC), just as it already is for image textures.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D1544
This removes the BVH cache feature from the UI, underlying code will be removed in a separate commit.
The BVH cache was added before we had a multi-threaded BVH build, and a lot of other optimizations were done since then, which makes this not useful anymore.
Fix T46162.
The issue was caused by wrong detection whether number of verticies
changed or not. Basically, it wasn't working correct in cases when
number of verticies is increasing compared to the current frame.
This is a bit tricky one -- ideally viewport should detect whether alpha is used
in the shader tree and if so do separate viewport pass for that objects. But in
practice it's really tricky to detect whether alpha is affected by shader or not
without evaluating the tree for all possible input values. We also can't assume
that alpha might always be affected because it'll slow viewport drawing down.
For until some smart solution is found simply expose alpha blending mode used
by the viewport. It could be found below the Viewport Color settings.
Technically it was all wrong and it should have been called Extend instead
of Clip. Got confused by the naming in different libraries.
More options are still to come.
