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

1 files changed, 1 insertions, 1 deletions

diff --git a/intern/cycles/render/mesh.cpp b/intern/cycles/render/mesh.cpp
index de1533c26af..d26404035eb 100644
--- a/intern/cycles/render/mesh.cpp
+++ b/intern/cycles/render/mesh.cpp
@@ -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;
 }