- User Since
- Mar 31 2015, 9:29 AM (172 w, 3 d)
- Cycles: Compile fixes for OpenCL kernel.
I think I found a way to write id passes using atomics.
- Cycles: Cryptomatte writing now uses atomics on GPUs to avoid race conditions.
- Cycles: Code style, fixed typos moving murmurhash to its own cpp file.
Wed, Jul 18
- Reverted an accidental change.
Mon, Jul 16
- Compositor: Fixed Cryptomatte string handling.
- Compositor: Applied Brecht's UI improvements to Cryptomatte node
- Compositor: Fixed broken add/remove in Cryptomatte node.
- Compositor: Raised default number of Crypto inputs to three, as recommended by the Cryptomatte specification.
- Compositor: Cryptomatte node now uses a dynamic string for matte ids, no more 1024 character limit.
Cryptomatte output for Cycles is now in D3538
Fri, Jul 13
- Cycles: Addressed Lukas' comments for Cryptomatte output.
Looks good to me. The test renders I did didn't show any differences.
Thu, Jul 12
Cryptomatte support for Cycles is in D3538.
Still to do:
- Fixed indentation.
@Brecht Van Lommel (brecht) This patch changes array<Pass> back to vector<Pass>, as it was before you did some refactoring. Is that safe to do or are there dangers that I'm overlooking? Since I'd like Pass to contain a name string, it would be important that its destructor gets called.
- Cycles: Fixed Cryptomatte pass names to match between Python and C++ code.
- Cycles: Code styling fixes for murmurhash.
Wed, Jul 11
A Cryptomatte compositing node is in this patch: https://developer.blender.org/D3531
- More code styling changes in Cryptomatte compositing node.
- Code styling and warning suppression in murmur3 hash.
- Removed unused code.
x - Compositor: Addressed Brecht's comments for Cryptomatte node.
- Compositor: Added static sizeof() checks before type punning. Currently, sizeof(float) == 4 on all of our supported platforms, but the standards don't require that. You never know...
Tue, Jul 10
This is a patch against the current master. Should I rather rebase this on top of the 2.8 branch?
Mon, Jul 9
Fri, Jul 6
Should be fixed now in d20d2bcb7fe7
Thu, Jul 5
- Removed whitespace change in unrelated code - let's keep this patch to the point.
- Addressed Sergey's comments regarding code style
Wed, Jun 27
Tue, Jun 26
Mon, Jun 25
Jun 19 2018
Jun 5 2018
The source of the problem is the use of ray_offset() to prevent self-intersections for rays that originate from a transparent surface. A solution to this problem is outlined in the paper "Robust Iterative Find-Next-Hit Ray Traversal": http://www.sci.utah.edu/~wald/Publications/2018/nexthit-pgv18.pdf
May 28 2018
The root cause is that PathState.volume_stack is a fixed size array and kernel_volume_stack_init() does not perform any bounds checking when writing to that array.