Page MenuHome

Cycles Crash - Cycles crashes before sampling when certain meshes have autosmooth enabled.
Closed, ResolvedPublic


System Information
Windows 7, core i7 920 x64 gtx1080

Blender Version
Broken: 80444ef (first crash on our builds was from 5c3216e)
Worked: 5552e83

Short description of error
On certain meshes with autosmooth enabled, cycles crashes out.

Exact steps for others to reproduce the error

  1. Open attached blend file
  2. press f12
  3. crash
  4. open attached blend file again
  5. open mesh data tab
  6. turn off autosmooth
  7. press f12
  8. no crash

It does not matter whether CPU or GPU rendering is enabled.

Event Timeline

Potentially could be caused by rB36c4fc1

Sergey Sharybin (sergey) lowered the priority of this task from 90 to 50.

Can confirm the crash, but not really familiar with the re-worked code from @Bastien Montagne (mont29).

@Bastien Montagne (mont29), mind having a look? The input mesh is valid, but for some reason *lnor_space is NULL. So either it's a bug somewhere deeper in lnot space calculation or we are missing some NULL pointer checks?

Issue is deep in loop normals code actually, not specific to split faces. It's due to weird geometry, simplified the case in file below in case you'd like to add it as test @Sergey Sharybin (sergey)?

Still looking into a proper fix… :/

@Bastien Montagne (mont29), nice simplification. I'll add it to the unit tests once the issue is solved, so we don't move tests/code into inconsistent state.

We have figured out how we are creating these meshes (combination of remove doubles -> limited dissolve with autosmooth shade enabled, our usual process for cleaning up high poly objects which don't need to have that much complexity to them)

Just wondering if there has been any update to this bug?

Yes there, I understand the problem and have a first version of fix, but not much happy with it currently, trying to find a better solution.

Note that it’s actually a bug deep in custom normals process, which can also (among other thing) generate wrong normals at those vertices…