| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Until now, single channel textures were packed into a float4, wasting 3 floats per pixel. Memory usage of such textures is now reduced by 3/4.
Voxel Attributes such as density, flame and heat benefit from this, but also Bumpmaps with one channel.
This commit also includes some cleanup and code deduplication for image loading.
Example Smoke render from Cosmos Laundromat: http://www.pasteall.org/pic/show.php?id=102972
Memory here went down from ~600MB to ~300MB.
Reviewers: #cycles, brecht
Differential Revision: https://developer.blender.org/D1981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit d91316dc672dc1ee69fbd24d2f00124a24b75c6b.
|
|
The improved Hosek / Wilkie model was added during my GSoC 2013 and the default since then.
The older model was kinda kept for compatibility, but after more than 2 years it's time to remove it.
The Hosek / Wilkie model is more realistic anyway, and people who really want a day / night transition can mix the Sky Shader with another one (e.g. color) and fade between the two.
|
|
This commit implements new panorama and environment texture projection
which is called after a dude named Lambert:
https://en.wikipedia.org/wiki/Lambert_cylindrical_equal-area_projection
Advantage of this projection is that it doesn't waste sampling time next
to the poles (which is a huge issue for the equirectangular projection).
Disadvantage of this model is that there'll be some distortion on the
poles when mapping it back to the sphere.
This is partially worked around by using scaling magic so there'll be
a bit more samples added on the top/bottom of the image (which makes it
technically a Roosendaal-Sharybin mapping since that's what we've been
discussing in the studio).
Maybe we should be more aggressive here with clamping of the sine, but
let's start doing some real-world tests first.
|
|
This commit implements a native cubemap rendering in Cycles,
which is currently a research project with the following goals:
- Make it easier to render cubemaps for engines which supports
or expects them to be used.
- Intermediate projection to optimize rendering of equirectangular
camera.
Cube map layout is not currently standart but it's most efficient
from the resolution and storage point of views and it's currently:
+-------+-------+--------+
| Back | Right | Bottom |
+-------+-------+--------+
| Front | Left | Top |
+-------+-------+--------+
It's easy to re-map views in the future.
There are still issues to be solved, but it'll be nice to get
VR and panorama artists involved into feedback already. So the
limitations are:
- There's no auto-remapping to equirectangular map happening yet,
so the only way to see result is to put result to an environment
map with cubemap projection and either re-render or investigate
it in viewport.
- Projection formulas are not optimized by any mean. This is to
keep them totally obvious to make it easier to make further
tweaks.
|
|
|
|
That means that we now only support OSL 1.7.1 or newer. Please update libs or re-run install-depsh.sh.
|
|
Using this paper:
http://graphics.pixar.com/library/ApproxBSSRDF/paper.pdf
This model gives less blurry results than the Cubic and Gaussian
we had implemented:
- Cubic: https://developer.blender.org/F279670
- Burley: https://developer.blender.org/F279671
The model is called "Christensen-Burley" in the interface, which
actually should be read as "Physically based" or "Realistic".
Reviewers: juicyfruit, dingto, lukasstockner97, brecht
Reviewed By: brecht, dingto
Subscribers: robocyte
Differential Revision: https://developer.blender.org/D1759
|
|
|
|
This commit changes the way how we pass bounce information to the Light
Path node. Instead of manualy copying the bounces into ShaderData, we now
directly pass PathState. This reduces the arguments that we need to pass
around and also makes it easier to extend the feature.
This commit also exposes the Transmission Bounce Depth to the Light Path
node. It works similar to the Transparent Depth Output: Replace a
Transmission lightpath after X bounces with another shader, e.g a Diffuse
one. This can be used to avoid black surfaces, due to low amount of max
bounces.
Reviewed by Sergey and Brecht, thanks for some hlp with this.
I tested compilation and usage on CPU (SVM and OSL), CUDA, OpenCL Split
and Mega kernel. Hopefully this covers all devices. :)
|
|
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
|
|
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
|
|
This way socket type conversions (such as color to float, or float to vector) do not stop the folding process.
Example: http://www.pasteall.org/pic/show.php?id=96803 (selected nodes are folded).
|
|
functions, it's obvious.
|
|
|
|
|
|
|
|
This way, connecting Value or RGB node to e.g. a Math node will still allow folding.
Note: The same should be done for the ConvertNode, but I leave that for another day.
|
|
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
|
|
|
|
* Move constant folding from nodes to the shader graph. This way it's part of our (later) 4-step optimization process.
* Instead of only doing a one level constant fold, we can now do a recursive constant fold, allowing us to simplify shaders much further.
Constant folding is implemented for Blackbody, Math and VectorMath nodes.
Example (the highlighted nodes are removed before rendering):
Before: http://archive.dingto.org/2015/blender/code/one_level_constant_fold.jpg
Now: http://archive.dingto.org/2015/blender/code/multi_level_constant_fold.jpg
Thanks to Sergey and Brecht for Review!
Differential Revision: https://developer.blender.org/D1626
|
|
Basically we can not use sharp closure as a substitude when filter glossy is
used. This is because we can not blur sharp reflection/refraction.
This is quite quick and not really clean implementation. Not really happy
with manual handling of original settings, but this is as good as we can do
in the quick patch. It's a good acknowledgment and we now can re-consider
some aspects of graph simplification to make such cases more natively
supported.
P.S. This failure would have been shown by our regression tests, so please,
bother a bit to run Cycles's test sweep before doing such optimizations.
|
|
We fallback to Sharp closures for Glossy, Glass and Refraction nodes now, in case the Roughness input is disconnected and 0 (< 1e-4f to be exact).
This way we gain a few percentages of performance, in case the user did not manually set the closure type to "Sharp" in the UI.
Sharp will probably be removed from the UI as a followup, not needed anymore with this internal optimization.
Original idea by Lukas Stockner(Differential Revision: https://developer.blender.org/D1439), code implementation by myself.
|
|
The issue was caused by non-continuous tangent space calculated for triangles.
This commit adds a Tangent input to Hair BSDF node which can be used to hook up
Tangent calculated form UV as an input to the node in order to make sure the
tangent space is continuous.
Doing this as an input instead of using default tangent layer from UV because of
several reasons:
- This way it's really easy to preserve compatibility with existing setups.
- Default UV map is not necessarily giving continuous space, one might want to
use other tangent space sources or distort the space for some artistic
decision.
Reviewers: juicyfruit, dingto
Reviewed By: dingto
Differential Revision: https://developer.blender.org/D1428
|
|
|
|
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
|
|
|
|
|
|
For now there's no OpenCL support, it'll come later.
|
|
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.
|
|
Currently only two mappings are supported by API, which is Repeat (old behavior)
and new Clip behavior. Internally this extension is being converted to periodic
flag which was already supported but wasn't exposed.
There's no support for OpenCL yet because of the way how we pack images into a
single texture.
Those settings are not exposed to UI or anywhere else and there should be no
functional changes so far.
|
|
The issue was caused by wrong fix for T22741 which forced redraws on any window
event, like Expose. Use proper NV_WM | ND_UNDO listener instead,
|
|
The idea of this node is to sampling of 3D voxels at a given coordinate
supporting different mapping strategies (world space mapping, object
local space etc).
Currently not in use, it's a preparation step for supporting point density
textures.
|
|
This way we can avoid building the split kernel with NODE_FEATURE_BUMP enabled, in case we don't need it.
|
|
|
|
Currently unused but will be needed soon for the split kernel work.
|
|
Previously it was only set at compilation time which is all fine but does
not let us to check which closure the node corresponds to prior to the
compilation.
|
|
Now we calculate color in range 800..12000 using an approximation a/x+bx+c for R and G and ((at + b)t + c)t + d) for B.
Max absolute error for RGB for non-lut function is less than 0.0001, which is enough to get the same 8 bit/channel color as for OSL with a noticeable performance difference.
However there is a slight visible difference between previous non-OSL implementation because of lookup table interpolation and offset-by-one mistake.
The previous implementation gave black color outside of soft range (t > 12000), now it gives the same color as for 12000.
Also blackbody node without input connected is being converted to value input at shader compile time.
Reviewers: dingto, sergey
Reviewed By: dingto
Subscribers: nutel, brecht, juicyfruit
Differential Revision: https://developer.blender.org/D1280
|
|
This more a workaround for CUDA optimizer which can't optimize clamp(x, 0, 1)
into a single instruction and uses 4 instructions instead.
Original patch by @lockal with own modification:
Don't make changes outside of the kernel. They don't make any difference
anyway and term saturate() has a bit different meaning outside of kernel.
This gives around 2% of speedup in Barcelona file, but in more complex shader
setups with lots of math nodes with clamping speedup could be much nicer.
Subscribers: dingto
Projects: #cycles
Differential Revision: https://developer.blender.org/D1224
|
|
This way memory overhead caused by the BVH building is not so visible and peak
memory usage will be reduced.
Implementing this idea is not so straightforward actually, because we need to
synchronize images used for true displacement before meshes. Detecting whether
image is used for true displacement is not so striaghtforward, so for now all
all displacement types will synchronize images used for them.
Such change brings memory usage from 4.1G to 4.0G with the 01_01_01_D scene
from gooseberry. With 01_01_01_G scene it's 7.6G vs. 6.8G (before and after
the patch).
Reviewers: campbellbarton, juicyfruit, brecht
Subscribers: eyecandy
Differential Revision: https://developer.blender.org/D1217
|
|
This attribute is not really supported for volumes, so it get's converted to
constant 0 at shader compile time.
TODO: We should consider doing the same for tangent attribute in order to save
some annoying checks at tracing time.
|
