Fixed a rare case of NaN in Cycles
This fixes a rare case where NaNs could exist inside Cycles. When certain invalid meshes were passed in, Cycles would try too normalize a zero length normal during its setup stage. While it does check against division by zero, it still returns a zero length normal and passes it on to the path tracing kernel. The kernel then operates under the assumption that normals are valid, and in the case of such a zero length normal, would eventually create NaNs that propagate through and result in black pixels. Reviewers: #cycles Subscribers: brecht, sergey Projects: #cycles Differential Revision: https://developer.blender.org/D2008
This commit is contained in:
parent
cdcb0826ee
commit
7a35a0f419
|
@ -285,7 +285,7 @@ static float3 compute_face_normal(const Mesh::Triangle& t, float3 *verts)
|
|||
float normlen = len(norm);
|
||||
|
||||
if(normlen == 0.0f)
|
||||
return make_float3(0.0f, 0.0f, 0.0f);
|
||||
return make_float3(1.0f, 0.0f, 0.0f);
|
||||
|
||||
return norm / normlen;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue