Cycles: rays miss triangles #46110

New Issue

Felix · 2015-09-14T18:14:56+02:00

Felix commented

2015-09-14 18:14:56 +02:00

System Information
OS: windows 7 64bit, CPU: i5-3550 GPU: ATI HD7850

Blender Version
2.75a c27589e

Short description of error
I found these reoprts connected to this problem: #34094 D819 f770bc4757 (9489205c5c)

I found that it seems to be a particular range of angle between faces in wich the rays are able to miss the triangles.
Fireflies or worse are the consequences.

Exact steps for others to reproduce the error
1.put the camera inside a cylinder (32 vertices)
2.rotate the cam so it is looking at the round part of the cylinder
3. set the background shader strength to 5000
4.render it on 200 samples

It should show some fireflies all over the image.

File: triangle_miss.blend

This problem occured to me on an extreme case as I built a sealing for a room.
I'll attach a simplified file of it: sealing_light.blend

btw. the "a" version of blender 2.75 has some problem with my GPU so I renderd with CPU.

**System Information** OS: windows 7 64bit, CPU: i5-3550 GPU: ATI HD7850 **Blender Version** 2.75a c27589e **Short description of error** I found these reoprts connected to this problem: #34094 [D819](https://archive.blender.org/developer/D819) f770bc4757 (9489205c5c) I found that it seems to be a particular range of angle between faces in wich the rays are able to miss the triangles. Fireflies or worse are the consequences. **Exact steps for others to reproduce the error** 1.put the camera inside a cylinder (32 vertices) 2.rotate the cam so it is looking at the round part of the cylinder 3. set the background shader strength to 5000 4.render it on 200 samples ![triangle_miss02.png](https://archive.blender.org/developer/F233297/triangle_miss02.png) It should show some fireflies all over the image. ![triangle_miss01.png](https://archive.blender.org/developer/F233294/triangle_miss01.png) File: [triangle_miss.blend](https://archive.blender.org/developer/F233291/triangle_miss.blend) ___________________________________________________ This problem occured to me on an extreme case as I built a sealing for a room. I'll attach a simplified file of it: [sealing_light.blend](https://archive.blender.org/developer/F233293/sealing_light.blend) btw. the "a" version of blender 2.75 has some problem with my GPU so I renderd with CPU.

Felix commented

2015-09-14 18:14:56 +02:00

Changed status to: 'Open'

Felix commented

2015-09-14 18:14:56 +02:00

Added subscriber: @BOBtheROSS

Philip Holzmann commented

2015-09-15 17:07:14 +02:00

Added subscriber: @Foaly

Philip Holzmann commented

2015-09-15 17:07:14 +02:00

Tried it on GPU. I also get the fireflies.
And I noticed: the bigger the cylinder, the more fireflies.

Tried it on GPU. I also get the fireflies. And I noticed: the bigger the cylinder, the more fireflies.

Sergey Sharybin was assigned by Thomas Dinges

2015-09-15 21:11:31 +02:00

Sergey Sharybin commented

2015-09-16 15:14:34 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2015-09-16 15:14:34 +02:00

Sergey Sharybin commented

2015-09-16 15:14:34 +02:00

There are two sources of issue:

Original watertight paper suggests fallback to double precision arithmetic when it's detected system determinant is zero. This gives some extra stability (of watertight-ness if you want) in cases when ray hits exact edge of a triangle.
BVH nodes intersection was never implemented to be watertight, which might cause missing ray-triangle checks all together if ray hits exact boundary of the node.

Here's a quick patch which might be considered a proof of concept solution of the issue

P261: Patch for #46110

diff --git a/intern/cycles/bvh/bvh_build.cpp b/intern/cycles/bvh/bvh_build.cpp
index 45b0aaa..1dc4d7c 100644
--- a/intern/cycles/bvh/bvh_build.cpp
+++ b/intern/cycles/bvh/bvh_build.cpp
@@ -114,6 +114,7 @@ void BVHBuild::add_reference_mesh(BoundBox& root, BoundBox& center, Mesh *mesh,
 		}
 
 		if(bounds.valid()) {
+			bounds.extend(1e-6f);
 			references.push_back(BVHReference(bounds, j, i, type));
 			root.grow(bounds);
 			center.grow(bounds.center2());
@@ -146,6 +147,7 @@ void BVHBuild::add_reference_mesh(BoundBox& root, BoundBox& center, Mesh *mesh,
 			}
 
 			if(bounds.valid()) {
+				bounds.extend(1e-6f);
 				int packed_type = PRIMITIVE_PACK_SEGMENT(type, k);
 				
 				references.push_back(BVHReference(bounds, j, i, packed_type));
@@ -158,9 +160,11 @@ void BVHBuild::add_reference_mesh(BoundBox& root, BoundBox& center, Mesh *mesh,
 
 void BVHBuild::add_reference_object(BoundBox& root, BoundBox& center, Object *ob, int i)
 {
-	references.push_back(BVHReference(ob->bounds, -1, i, 0));
-	root.grow(ob->bounds);
-	center.grow(ob->bounds.center2());
+	BoundBox bounds = ob->bounds;
+	bounds.extend(1e-6f);
+	references.push_back(BVHReference(bounds, -1, i, 0));
+	root.grow(bounds);
+	center.grow(bounds.center2());
 }
 
 static size_t count_curve_segments(Mesh *mesh)
diff --git a/intern/cycles/kernel/geom/geom_triangle_intersect.h b/intern/cycles/kernel/geom/geom_triangle_intersect.h
index 65f6c9a..68b8637 100644
--- a/intern/cycles/kernel/geom/geom_triangle_intersect.h
+++ b/intern/cycles/kernel/geom/geom_triangle_intersect.h
@@ -142,6 +142,19 @@ ccl_device_inline bool triangle_intersect(KernelGlobals *kg,
 	float U = Cx * By - Cy * Bx;
 	float V = Ax * Cy - Ay * Cx;
 	float W = Bx * Ay - By * Ax;
+
+	if(U == 0.0f || V == 0.0f || W == 0.0f) {
+		double CxBy = (double)Cx * (double)By;
+		double CyBx = (double)Cy * (double)Bx;
+		U = (float)(CxBy - CyBx);
+		double AxCy = (double)Ax * (double)Cy;
+		double AyCx = (double)Ay * (double)Cx;
+		V = (float)(AxCy - AyCx);
+		double BxAy = (double)Bx * (double)Ay;
+		double ByAx = (double)By * (double)Ax;
+		W = (float)(BxAy - ByAx);
+	}
+
 	const int sign_mask = (__float_as_int(U) & 0x80000000);
 	/* TODO(sergey): Check if multiplication plus sign check is faster
 	 * or at least same speed (but robust for endian types).
diff --git a/intern/cycles/util/util_boundbox.h b/intern/cycles/util/util_boundbox.h
index cef5adc..228e571 100644
--- a/intern/cycles/util/util_boundbox.h
+++ b/intern/cycles/util/util_boundbox.h
@@ -176,6 +176,12 @@ public:
 		       fabsf(center_diff.y) <= total_size.y &&
 		       fabsf(center_diff.z) <= total_size.z;
 	}
+
+	__forceinline void extend(float value)
+	{
+		min = min - make_float3(value, value, value);
+		max = max + make_float3(value, value, value);
+	}
 };
 
 __forceinline BoundBox merge(const BoundBox& bbox, const float3& pt)

However, it has two issues still:

a. Consumer GPUs are really slow for double precision arithmetic
b. Extending BVH node boundary might cause some slowdown

But since this never really worked 100% robust it's still considered a TODO. So thanks for the report, but will look into this as a part of general improvement after 2.76 release.

There are two sources of issue: - Original watertight paper suggests fallback to double precision arithmetic when it's detected system determinant is zero. This gives some extra stability (of watertight-ness if you want) in cases when ray hits exact edge of a triangle. - BVH nodes intersection was never implemented to be watertight, which might cause missing ray-triangle checks all together if ray hits exact boundary of the node. Here's a quick patch which might be considered a proof of concept solution of the issue [P261: Patch for #46110](https://archive.blender.org/developer/P261.txt) ``` diff --git a/intern/cycles/bvh/bvh_build.cpp b/intern/cycles/bvh/bvh_build.cpp index 45b0aaa..1dc4d7c 100644 --- a/intern/cycles/bvh/bvh_build.cpp +++ b/intern/cycles/bvh/bvh_build.cpp @@ -114,6 +114,7 @@ void BVHBuild::add_reference_mesh(BoundBox& root, BoundBox& center, Mesh *mesh, } if(bounds.valid()) { + bounds.extend(1e-6f); references.push_back(BVHReference(bounds, j, i, type)); root.grow(bounds); center.grow(bounds.center2()); @@ -146,6 +147,7 @@ void BVHBuild::add_reference_mesh(BoundBox& root, BoundBox& center, Mesh *mesh, } if(bounds.valid()) { + bounds.extend(1e-6f); int packed_type = PRIMITIVE_PACK_SEGMENT(type, k); references.push_back(BVHReference(bounds, j, i, packed_type)); @@ -158,9 +160,11 @@ void BVHBuild::add_reference_mesh(BoundBox& root, BoundBox& center, Mesh *mesh, void BVHBuild::add_reference_object(BoundBox& root, BoundBox& center, Object *ob, int i) { - references.push_back(BVHReference(ob->bounds, -1, i, 0)); - root.grow(ob->bounds); - center.grow(ob->bounds.center2()); + BoundBox bounds = ob->bounds; + bounds.extend(1e-6f); + references.push_back(BVHReference(bounds, -1, i, 0)); + root.grow(bounds); + center.grow(bounds.center2()); } static size_t count_curve_segments(Mesh *mesh) diff --git a/intern/cycles/kernel/geom/geom_triangle_intersect.h b/intern/cycles/kernel/geom/geom_triangle_intersect.h index 65f6c9a..68b8637 100644 --- a/intern/cycles/kernel/geom/geom_triangle_intersect.h +++ b/intern/cycles/kernel/geom/geom_triangle_intersect.h @@ -142,6 +142,19 @@ ccl_device_inline bool triangle_intersect(KernelGlobals *kg, float U = Cx * By - Cy * Bx; float V = Ax * Cy - Ay * Cx; float W = Bx * Ay - By * Ax; + + if(U == 0.0f || V == 0.0f || W == 0.0f) { + double CxBy = (double)Cx * (double)By; + double CyBx = (double)Cy * (double)Bx; + U = (float)(CxBy - CyBx); + double AxCy = (double)Ax * (double)Cy; + double AyCx = (double)Ay * (double)Cx; + V = (float)(AxCy - AyCx); + double BxAy = (double)Bx * (double)Ay; + double ByAx = (double)By * (double)Ax; + W = (float)(BxAy - ByAx); + } + const int sign_mask = (__float_as_int(U) & 0x80000000); /* TODO(sergey): Check if multiplication plus sign check is faster * or at least same speed (but robust for endian types). diff --git a/intern/cycles/util/util_boundbox.h b/intern/cycles/util/util_boundbox.h index cef5adc..228e571 100644 --- a/intern/cycles/util/util_boundbox.h +++ b/intern/cycles/util/util_boundbox.h @@ -176,6 +176,12 @@ public: fabsf(center_diff.y) <= total_size.y && fabsf(center_diff.z) <= total_size.z; } + + __forceinline void extend(float value) + { + min = min - make_float3(value, value, value); + max = max + make_float3(value, value, value); + } }; __forceinline BoundBox merge(const BoundBox& bbox, const float3& pt) ``` However, it has two issues still: a. Consumer GPUs are really slow for double precision arithmetic b. Extending BVH node boundary might cause some slowdown But since this never really worked 100% robust it's still considered a TODO. So thanks for the report, but will look into this as a part of general improvement after 2.76 release.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles: rays miss triangles #46110