| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Conflicts:
intern/cycles/blender/blender_mesh.cpp
|
|
Purely developers-only feature which allows to disable some of the CPU
capabilities. This way it's easier to test different kernels on the
same machine.
|
|
In the worst case it'll do nothing, in the best case it might give some percent
of speedup because of better cache coherency.
Currently it's all handled as an override on blender_python level, don't really
see reason to penetrate the boolean flag further into sync code. This can always
be done later if needed.
|
|
|
|
Nothing special, just really handy for debugging.
|
|
This makes overall code of create_mesh() much cleaner and easier to follow.
|
|
Conflicts:
intern/cycles/kernel/kernel_types.h
intern/cycles/render/attribute.cpp
|
|
|
|
This attribute means how "pointy" the geometry surface is, which allows to do
effects like dirt maps and wear-off effects on render geometry. This means the
attribute is calculated for the final mesh which means no baking (which implies
UV unwrap) is needed. Apart from this the behavior is quite close to how vertex
dirty colors works.
The new attribute is available as an output socket of Geometry node.
There's no penalty for the render time, only some delay on scene preparation
(the delay is linear of the mesh complexity).
Reviewers: brecht, juicyfruit
Subscribers: eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1086
|
|
|
|
|
|
From more investigation of the numeric failures in the kernel it appears
the check was rather correct. But in theory it;s also needed for the motion
triangles.
|
|
The issue was caused by lack of check for whether fresnel term is actually
giving total internal reflection in refraction BSDFs. This lead to usage of
arbitrary vector of (0, 0, 0) as reflection, giving numeric issues in other
areas of the kernel.
This gives some visual changes of sharp reflection but it seems to be rather
proper now. Which also corresponds with rough glossy reflection with sharpness
set to 0.001 (previously it was totally different from sharpness of 0.0, which
is just weird).
|
|
This is the same issue T43475: SSE4 code is more robust to non-finite values
in the ray origin/direction. So for now added a check before doing BVH traversal
for pre-SSE4 CPUs.
For sure actual root of the issue is a bit different and much more tricky to
solve, especially without disturbing render results too much. Still looking
into this.
In any case, it's kinda fine to have such a check, we might later make it to be
a kernel_assert() instead of just a return.
|
|
|
|
Previous fix didn't quite work well. For some reason everything worked fine when
using native nvcc in 32bit environment, but cross-compiling from 64bit platform
it was still running out of memory.
For now just made it so all the kernels are slower on 32bit CUDA as a temporary
solution. Either it'll be solved in next CUDA releases (by dropped 32bit? =\) or
we'll find better workaround.
|
|
|
|
- Fix name of CMake option
- Fix path in BPX include
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Can be set via WITH_PTEX in CMake or WITH_BF_PTEX in SCons.
Not well tested yet.
|
|
|
|
|
|
|
|
|
|
|
|
TODO: this is much smaller now than before, can probably be moved to
better spot
|
|
|
|
|
|
This is the core code for it, tools (datatransfer and modifier) will come in next commits).
RNA api is already there, though.
See the code for details, but basically, we define, for each 'smooth fan'
(which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal),
a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store
custom normal as two angular factors inside that space. This allows to have custom normals
'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer.
Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals,
and be converted back into storage format at the end.
Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can
be rather heavy with high poly meshes.
Also, bumping subversion, and fix mess in 2.70 versioning code.
|
|
The issue was caused by the way how we shoot the ray to see which rays we're
inside which might start bouncing back-n-forth between two close to parallel
intersecting faces.
Real solution would be to record all the intersections when shooting the ray,
but it's kinda tricky on GPU because of needed sorting and uncertainty of
how huge intersection array should be.
For now we'll just limit number of steps in the check so in worst case we'll
have some samples not being correct which will be compensated with further
sampling. Shouldn't be an issue since probability of such a lock is quite
small actually.
|
|
Issue was in fact only visible in certain circumstances:
- OSL was compiled with Boost Wave
- or system's cpp didn't handle space between -I and path
Now made it so both wave and cpp code paths are always happy.
Original patch from Shane Ambler with own modifications to
mimic what variable holds on more verbose.
|
|
This gives small speedup (around 2% in quick tests) for ray scattering.
|
|
This is a bit of a mess because of the header dependency hell, but
since the tweak is small enough it's gonna be fine.
|
|
|
|
IN theory object might depend on camera location (spatial adaptive subdivisions
for example) which became not possible to achieve after camera in volume support.
Should be no functional changes for artists.
|
|
This warning provided too much false-positive issues in release version of the
kernel, making it really easy to miss actual warnings.
|
|
Was rather harmless since compiler will optimize it out, but nice to get
rid of this anyway.
|
|
Slowdown was caused by watertight intersection commit and follow-up workaorund
for compiler crash which uninlined utility function which rotates the ray.
Now it's only uninlined for sm_50 and sm_52 experimental kernels which are the
only ones which failed to compile.
Rendering still might be a bit slower but at least shouldn't be that dramatic.
|
|
Basically build-time compiled kernels were using --fast-math (which is correct)
but run-time compiled did not.
|
|
|
|
Basically title says it all. Could be not totally optimized but the code is there now.
|
|
This is for development and test environment setup only, not for
regular users usage hence no mentioning in the man page needed.
|
