Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
Hopefully it works on all platforms now.
|
|
|
|
|
|
Was a bit confusing to have transparent and translucent depth
exposed but no diffuse or glossy.
Reviewers: brecht
Subscribers: eyecandy
Differential Revision: https://developer.blender.org/D2399
|
|
This is important for the reliable behavior or isnan/isfinite/min/max
functions to work with nan and non-finite values. Some of the issues
with fast math are possible to work around, but didn't find a way to
have reliable min/max implementation yet.
|
|
Currently unused, but might become really handy in the future.
|
|
Please NEVER EVER use such a statement, it's only causing HUGE
issues. What is even worse: it's not always possible to immediately
see that the hell is coming from such a statement.
There is still some statements in the existing code, will leave
those for a later cleanup.
|
|
last tile on CPU
|
|
|
|
|
|
This was a missing bit from b53ce9a.
|
|
|
|
makes code slightly shorter and uses idea of const qualifiers.
|
|
Run into some nasty bugs while trying various things here.
Wouldn't mind enabling -Wshadow for Cycles actually..
|
|
This avoids intersection AABB of different curve primitives
which makes it less ray-to-primitive intersections.
This gives about 30% speedup of hair rendering in the barber
shop scenes here. There is still some work to be done on those
files to solve major speed issues on certain frames.
|
|
per node
|
|
|
|
This way we can have different limits for regular and motion curves
which we'll do in one of the upcoming commits in order to gain some
percents of speedup.
The reasoning here is that motion curves are usually intersecting
lots of others bounding boxes, which makes it inefficient to have
single primitive in the leaf node.
|
|
Maximal number of elements is supposed to be inclusive. That is what
it was always meant in this file and what @brecht considered still
the case in 6974b69c6172.
In fact, the commit message to that change mentions that we allowed
up to 2 curve primitives per leaf while in fact it was doing up to 1
curve primitive.
Making it real 2 primitives at a max gives about 5% slowdown for the
koro.blend scene. This is a reason why BVHParams.max_curve_leaf_size
was changed to 1 by this change.
|
|
We don't have that in Blender style, no reason to violate it here.
|
|
Not only they don't really follow naming convention (we don't use
camel case) but also was not necessary to keep them in the global
symbol table.
|
|
|
|
This way it's more clear whether some issue is caused by lots of geometry in
the node or by lots of "transparent" BVH nodes.
|
|
|
|
|
|
|
|
|
|
About to add extra debug passes, which will be more clear to use switch().
|
|
Since the beginning of times hair settings in cycles were global for
the whole scene but were located in the particle context. This causes
quite some trickery to get shots set up for the movies here in the
studio by forcing artists to create dummy particle system to change
settings of hair on the shot.
While ideally this settings should be properly become per-particle
system for the time being it will save sweat and blood to move the
settings to scene context.
Reviewers: brecht
Subscribers: jtheninja, eyecandy, venomgfx, Blendify
Differential Revision: https://developer.blender.org/D2287
|
|
autosplit
The issue was that we used to compare number of vertices for mesh after the auto
smooth was applied (at the center of the shutter time) with number of vertices
prior to the auto smooth applied. This caused false-positive consideration of a
mesh as changing topology.
Now we do autosplit as early as possible and do it from blender side, so Cycles
does not need to re-implement splitting on it's side.
|
|
This allows us to do some extra logic checks there based on particular
subdivision type.
Additionally avoids implicit cast of enum to bool.
|
|
|
|
Next logical step is to expose this somehow to the interface.
|
|
|
|
|
|
|
|
This is undefined behavior in C++ and Clang was complaining a lot
about this.
|
|
Harmless since its not used, but good to fix.
|
|
|
|
This is a stand-alone logic, which becomes quite comprehensive now.
|
|
|
|
This matches behavior of Multiscatter GGX and could become handy later on
when/if we decide it would be beneficial to replace on closure with another.
Reviewers: lukasstockner97, brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2413
|
|
There was 16 bits reserved for primitive type, while we only need 4.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2401
|
|
There was fully wrong logic in comparison: was actually accessing memory
past the array boundary. Run test manually and the figure seems correct
to me now.
Spotted by @LazyDodo, thanks!
|
|
|