• Cycles: Fixed typos in Crytpomatte code.

Looks good to me except for one detail.

• Cycles: More Cryptomatte code review changes.
• Cycles: Skip calls to CPU kernel coverage buffer when accurate cryptomatte layers are turned off.

I support this.

@Lukas Stockner (lukasstockner97) can you check that one? Thanks.

Issue is not present in rB78c2063685cb6e0d0bcb895cf4eb70686455d596
Issue is present in rBdb333d9ea4881d9f48e3cc4b1ec59b4dafb27cc0

This was not the behaviour in rB7f86afec9d6

Some more inline comments.

Thanks for the link to CUDA-Z! Very helpful tool.
It is a system wide problem and not blender-related.
I passed this error to the GENTOO developer crew.
This task/ticket can closed.

Please check:

• If there is a separate package that needs to be installed for CUDA support.
• If there exists a libcuda.so.1 or libcuda.so in your computer and where it is located.

Confirmed, @Brecht Van Lommel (brecht) not sure if that’s known limitation or actual bug?

@Bastien Montagne (mont29) If you save the file, it will not crash anymore. You need to reproduce exactly this steps.

Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue (only ONE issue per report!), precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

@Brecht Van Lommel (brecht) after CUDA issues, OpenCL one…

@Brecht Van Lommel (brecht) I guess that one is for you? ;)

2.79.6 Win7 32

i tried and even on blender-2.80-0e8bd6ba8a2 crashes.

Hi guys,
some observations and wishes for microdisplacement.

• I wish you could have continuous displacement even in flat shading, especially for quick set ups of walls etc. (I think Vray has this option)
• the only workflow that does not rip geometry is smooth shading, subdivision to avoid artefacts, and box uv projection (3.)
• UV unwrapping produces beautiful edges (4.) unless you place a UV seam which rips the geometry, This should be fixed easily since box projection (3.) projects different image portion on cube face too, but does not rip the geometry.

I'm seeing CUDA renders on macOS giving wrong results starting with rBd611cf923358 (determined via git bisect, MBP Retina, 15-inch, Late 2013, GeForce GT 750M, Xcode 9.2, CUDA 9.2). The code in rBd611cf923358 looks innocent to me, may be that commit just exposed a compiler bug on macOS?

I'm not sure why you can't do much, seems like blender isn't interacting with the cuda libraries to detect gpus. Can you explain more?

Hi! Any thoughts on this one?

Layer weight is a camera view dependent effect, and for baking we assume every pixel is being viewed head on. The corresponding layer weight value is 0.0, so the baking result is black.

Thanks for testing, seems it was just running out of memory then.

i just found the problem:
the page file was too small (was set to 256MB), made it bigger and now it renders perfectly.

i tried to locate the object that is causing the issue.

Hey all,

I am not strong in this kind of things)) can anyone on Mac try this one?

I just gave it another try. Both with 2.79 latest master and 2.80 latest. This time under Windows. No artefacts there as well. So it might be a Mac thing, maybe OpenCL related?!

And also there is no artifacts if i render CPU only. Its only in Hybrid mode

Yes, sorry its my fault about the material =( but when i correct this its also the same artifacts here in the latest version of 2.79((( and if i render this in older 2.79.4 version its ok, even with the mistake in the material! maybe this issue on Mac Os, because you said that you have Linux Mint

@Bastien Montagne (mont29)
Indeed what I'm seeing appears to be 2.8-specific. Sorry, this is probably a different bug.

That’s probably and OIIO library issue, @Brecht Van Lommel (brecht)?

@MK (tm9000) Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue (only ONE issue per report!), precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

I guess the problem is not a bug in Cycles but rather a small mistake in your material:

Here it is! Please solve this problem ;) NOTE, that this problem also exist in 2.79.6

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

Please attach a simplified .blend to reproduce the problem. By incrementally removing objects, materials and nodes you can help us figure out what exactly is causing the problem.

The solidify modifier generates two cubes with in the exact same places with normals pointing in opposite directions. Cycles then can't properly detect inside and outside, which I don't consider a bug, we don't support rendering with coincident faces.

@Brecht Van Lommel (brecht) maybe you’ll want to check on that one too.

@Brecht Van Lommel (brecht), think you can check on that one? Thanks.

• Cycles: A little refactor of the cryptomatte ID pass writting to reduce #ifdef clutter
• Cycles: Removed PathState::matte_weight, using throughput instead for Cryptomatte

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

Addressed some of Sergey's comment.s

• Merge branch 'master' of git.blender.org:blender into cycles_cryptomatte
• Merge branch 'master' of git.blender.org:blender into cycles_cryptomatte
• Cycles: Implemented full sorting for Cryptomatte layers for all possible renderign devices.
• Cycles: Refactoring to remove duplicate Cyryptomatte id pass code.
• Cycles: Addressed some of Sergey's comments on D3538
• Cycles: Stochastic cryptomatte writing now adds coverage to last ID when it runs out of slots.

Thanks !

There are a number of optimizations in 2.79.4:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Cycles#Optimizations

Thanks for the report, but blender 2.79 won’t get any fix in that area. Can you please check if 2.8 also shows same issue?

Same problem here as well

Crash confirmed. @Brecht Van Lommel (brecht) think that one’s for you, here is ASAN backtrace:

To bad this is an ongoing issue with 2.79 i was already wondering why the particles where not following.

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

it's seem fixed 2018-7-17 version .

looked some more into this, looks like chrome ran into a similar issue coming from math.h, all i can say is 'yikes'

This is supposed to work, Lukas added support for it.

@Brecht Van Lommel (brecht) shall know staus of IE lights, but iirc it’s not really supported currently?

Not sure how much we support that kind of hydra… @Brecht Van Lommel (brecht) shall know. :)

@Brecht Van Lommel (brecht) assigning to you, no idea who/if OpenCL is a valid topic currently…

Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

It also depends on which GPU (from Intel or Radeon) it is running… not sure how is our support of OpenCL lately? But in any case, this sounds more like a configuration issue (as if you had to compile OpenCL Cycles kernel for one or both GPUs every time you open Blender, would explain the hanging up).

Can confirm that even though mblur is disabled for both operand objects, result in render is wrong. You have to disable mblur for whole Cycles (in its render settings) to get correct render.

Closed in rBL62073: Cycles tests: add principled hair tests..