- In fresnel_dielectric, the differentials calculation sometimes divided by zero.
- When the normal map was (0.5, 0.5, 0.5), the code would try to normalize a zero vector. Now, it just uses the regular normal as a fallback.
- The approximate error function used in Beckmann sampling sometimes overflowed to inf while calculating r^16. The final value is 1 - 1/r^16, however,
so now it just returns 1 if the computation would overflow otherwise.
Also, this fixes a numerical issue where A would be inf.
Since later G is set to 1 if A is larger than 1.6, the code now checks the reciprocal of A for being smaller than 1/1.6 - same effect, but no inf involved.
While it's an extra option added to the interface which might not be
fully obvious for artists, it allows to save up to 20% of memory in
hairy scenes.
This is high enough memory saver in my opinion which might become
handy for some production files where it's more important to make
scene to fit into memory rather than trying to use more optimal BVH
structure but go into swap or crash.
Reviewers: dingto, brecht
Reviewed By: dingto, brecht
Differential Revision: https://developer.blender.org/D2090
After reformulation of SSS indirect rays it became possible to
try accessing dimension higher than was pre-calculated on scene
preparation.
This is because we're traversing rays backwards, which means we
are using higher dimensions first now.
It was possible to miss bounces termination criteria in this functions,
mainly when max_hits was set to 0.
Made the check more robust in traversal functions (which should not
affect performance, it's an operation of same complexity AFAIK).
Also avoid doing ray-scene intersection from shadow_blocked when
limit of transparent bounces was already reached.
This way restrict can be used for CUDA and OpenCL as well.
From quick tests in areas i've been testing this it might give some
barely measurable %% of speedup, but it increases registers pressure.
So use of this qualifier is still really limited.
Using camel case for variables is something what didn't came from our original
code, but rather from third party libraries. Let's avoid those as much as possible.
Matches better naming of volume traversal files, where we've got
optimized versions of a single step of volume intersection and
traversal which will gather all volume intersections.
BVH traversal is not really that much a geometry and we've got
quite some traversals now. Makes sense to keep them separate in
the name of source structure clarity.
The shader sync code used the anisotropic version of the Ashikhmin-Shirley closure for both
Anisotropic and Glossy BSDF, which caused a failed assert because the anisotropic closure
expects an addiitonal SVM node.
This commit enables new unaligned BVH builder and traversal for scenes
with hair. This happens automatically, no need of manual control over
this.
There are some possible optimization still to happen here and there,
but overall there's already nice speedup:
Master Hair BVH
bunny.blend 8:06.54 5:57.14
victor.blend 16:07.44 15:37.35
Unfortunately, such more complexity is not really coming for free,
so there's some downsides, but those are within acceptable range:
Master Hair BVH
classroom.blend 5:31.79 5:35.11
barcelona.blend 4:38.58 4:44.51
Memory usage is also somewhat bigger for hairy scenes, but speed
benefit pays well for that. Additionally as was mentioned in one
of previous commits we can add an option to disable hair BVH and
have similar render time but have memory saving.
Reviewers: brecht, dingto, lukasstockner97, juicyfruit, maiself
Differential Revision: https://developer.blender.org/D2086
This commit implements traversal of unaligned BVH nodes.
QBVH traversal is fully SIMD optimized and calculates orientation
for all 4 children at a time, regular BVH might probably be optimized
a bit more.
This is a special builder type which is allowed to orient nodes to
strands direction, hence minimizing their surface area in comparison
with axis-aligned nodes. Such nodes are much more efficient for hair
rendering.
Implementation of BVH builder is based on Embree, and generally idea
there is to calculate axis-aligned SAH and oriented SAH and if SAH
of oriented node is smaller than axis-aligned SAH we create unaligned
node.
We store both aligned and unaligned nodes in the same tree (which
seems to be different from what Embree is doing) so we don't have
any any extra calculations needed to set up hair ray for BVH
traversal, hence avoiding any possible negative effect of this new
BVH nodes type.
This new builder is currently not in use, still need to make BVH
traversal code aware of unaligned nodes.
This seems to be straightforward way to support heterogeneous nodes
in the same tree.
There is some penalty related on 4gig limit of the address space now,
but here's are the thing:
Traversal code was already using ints to store final offset, so
there can't be regressions really.
This is a required commit to make it possible to encode both aligned
and unaligned nodes in the same array. Also, in the future we can use
this to get rid of __leaf_nodes array (which is a bit tricky to do since
trickery in pack_instances().
There are several internal changes for this:
First idea is to make __tri_verts to behave similar to __tri_storage,
meaning, __tri_verts array now contains all vertices of all triangles
instead of just mesh vertices. This saves some lookup when reading
triangle coordinates in functions like triangle_normal().
In order to make it efficient needed to store global triangle offset
somewhere. So no __tri_vindex.w contains a global triangle index which
can be used to read triangle vertices.
Additionally, the order of vertices in that array is aligned with
primitives from BVH. This is needed to keep cache as much coherent as
possible for BVH traversal. This causes some extra tricks needed to
fill the array in and deal with True Displacement but those trickery
is fully required to prevent noticeable slowdown.
Next idea was to use this __tri_verts instead of __tri_storage in
intersection code. Unfortunately, this is quite tricky to do without
noticeable speed loss. Mainly this loss is caused by extra lookup
happening to access vertex coordinate.
Fortunately, tricks here and there (i,e, some types changes to avoid
casts which are not really coming for free) reduces those losses to
an acceptable level. So now they are within couple of percent only,
On a positive site we've achieved:
- Few percent of memory save with triangle-only scenes. Actual save
in this case is close to size of all vertices.
On a more fine-subdivided scenes this benefit might become more
obvious.
- Huge memory save of hairy scenes. For example, on koro.blend
there is about 20% memory save. Similar figure for bunny.blend.
This memory save was the main goal of this commit to move forward
with Hair BVH which required more memory per BVH node. So while
this sounds exciting, this memory optimization will become invisible
by upcoming Hair BVH work.
But again on a positive side, we can add an option to NOT use Hair
BVH and then we'll have same-ish render times as we've got currently
but will have this 20% memory benefit on hairy scenes.
It was initially unsupported because initial idea of checking visibility
of all children was slowing scenes down a lot. Now the idea has changed
and we only perform visibility check of current node. This avoids huge
slowdown (from tests here it seems to be withing 1-2%, but more tests
would never hurt) and gives nice speedup of ray traversal for complex
scenes which utilized ray visibility.
Here's timing of koro.blend:
Without visibility check With visibility check
Original file 4min 20sec 4min 23sec
Camera rays only 1min 43 sec 55sec
Unfortunately, this doesn't come for free and requires extra data in
BVH node, which increases memory usage of BVH nodes by 15%. This we
can solve with some future trickery of avoiding __tri_storage created
for curve segments.
Make sure we don't perform any implicit address space conversion.
A bit annoying, but less intrusive approaches (like using temp private
variable in .cl kernel) do not work correct here.
Using generic address space will help from code side here, but will
be somewhat slower due to extra things happening as far as i know.
As far as I can see, the second issue there was that the functions receive a pointer to a member variable of the
ShaderData, which is stored in global memory. However, this means that the pointer points to global memory as well,
therefore OpenCL requires the ccl_addr_space "keyword" in front of the pointer.
With this commit, the OpenCL kernels build on Linux with the Intel CPU OpenCL runtime - however, they already did
without the change and I don't have an AMD card, so I can't really test whether the AMD runtime is happy as well now.
Those (one per ID type!) were uselessly duplicated, and badly inconsistent
(some types were actually unlinking before deletion, others were only working if already unlinked!).
Now we use same func and same API for all types, by default deletion is performed only if ID is no more used,
set `do_unlink` parameter to True to always delete ID even if still in use.
Only exception now is with Scene, since we always want to keep at least one!
Note that this will change default behavior of some types (since unlinking is never done anymore by default).
This commit adds a new distribution to the Glossy, Anisotropic and Glass BSDFs that implements the
multiple-scattering microfacet model described in the paper "Multiple-Scattering Microfacet BSDFs with the Smith Model".
Essentially, the improvement is that unlike classical GGX, which only models single scattering and assumes
the contribution of multiple bounces to be zero, this new model performs a random walk on the microsurface until
the ray leaves it again, which ensures perfect energy conservation.
In practise, this means that the "darkening problem" - GGX materials becoming darker with increasing
roughness - is solved in a physically correct and efficient way.
The downside of this model is that it has no (known) analytic expression for evalation. However, it can be
evaluated stochastically, and although the correct PDF isn't known either, the properties of MIS and the
balance heuristic guarantee an unbiased result at the cost of slightly higher noise.
Reviewers: dingto, #cycles, brecht
Reviewed By: dingto, #cycles, brecht
Subscribers: bliblubli, ace_dragon, gregzaal, brecht, harvester, dingto, marcog, swerner, jtheninja, Blendify, nutel
Differential Revision: https://developer.blender.org/D2002
The function that assigns names to socket types missed an entry, therefore all entries after it were mapped to the wrong name.
Long-term, it might be a better solution to use a map to avoid issues like these, but for now this fix works.
In the OSL node compilation code for the Environment Texture, is_linear was used as a socket.
However, there was no socket for it, which caused Blender to crash.
Adding a socket doesn't really make sense since it's an internal value and not a parameter
of the node, so it now just uses the variable directly.
The problem here was that there are five path types internally (diffuse, glossy, transmission, subsurface and volume scatter), but subsurface isn't exposed to the user.
This caused some weird behaviour - if all four types are disabled on the lamp, Cycles doesn't even try sampling it, but if any type was active, the lamp would illuminate
the cube since none of the options set subsurface to zero.
In the future, it might be reasonable to add subsurface visibility as an option - but for now the weird and inconsistent behaviour can be fixed simply by setting both
diffuse and subsurface to zero if the user disables diffuse visibility.
