POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Tasklist

FS#324 - 3.7 mesh2 rendering artifact, regression from 3.6

Attached to Project: POV-Ray
Opened by H. S. Teoh (quickfur) - Friday, 30 May 2014, 17:53 GMT
Last edited by William F Pokorny (wfpokorny) - Saturday, 15 October 2016, 18:29 GMT
Task Type Definite Bug
Category Backend → Geometric Primitives
Status Tracked on GitHub
Assigned To No-one
Operating System All
Severity High
Priority Normal
Reported Version 3.70 release
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Povray 3.7 has rendering artifact in meshes with polygons that meet at shallow angles. Please see the attached file.

The part of concern is the mesh2, which produces the partly-transparent faces of a shallow pyramid. The file result-3_6.png shows the output of povray-3.6, and the file result-3_7.png shows the output of povray-3.7. In 3.7, you can see a thin light-colored margin all around the base of the pyramid, especially thick under the top cylinder. In 3.6, this artifact is absent. For comparison purposes, I have inserted a “#version 3.6;” directive at the top of the file so that the output images are as close to each other as possible. However, the artifact is still present in 3.7 without this directive.

The attached scene file is only a small part of a much larger scene, where this artifact shows up in numerous very obvious places, where it doesn’t in 3.6. I have hunted in the documentation and online for ways to solve this problem, but haven’t found anything. Because of this, I am forced to stay with 3.6 for production use, which is quite unfortunate since I’d like to take advantage of the new features of 3.7.

This task depends upon

Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 31 May 2014, 21:04 GMT

it seems tied to transparency (transmit 0.5 in scene) and triangles (or surface ?). Mesh/Mesh2 is irrelevant: it also occurs with union of triangles.

Alpha in rendered picture seems irrelevant: putting a background plane keep the problem of dual tone near the edge.

The resulting color seems to be the one that is encountered when only one surface instead of two are encountered. (but two are really crossed!)

Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 31 May 2014, 21:13 GMT

The +UA is not needed either, in the problem.

Reduced scene for the problem in 3.7;

#version 3.7;

global_settings {
  assumed_gamma 1.0
	max_trace_level 30
}

#local lookat = <0,0,0>;
#local base_lookfrom = <0.1, 0.2, -0.8>;
#local lookfrom = base_lookfrom*.6;

camera {
	location lookfrom
	look_at lookat
	right x*1.0/1.0
}

#declare P1=		<0.03249196962329062993, -0.05257311121191336062, -0.19021130325903071179>;//,
#declare P2=		<0.08792183440801312755, -0.05433868201739210785, -0.17584366881602625510>;//,
#declare P3=		<0.05433868201739210785, 0.00000000000000000000, -0.19659919844279735712>;//,
#declare P4=		<0.03429496250085656284, -0.08978537747014557480, -0.17957075494029114959>;//,
#declare P5=	<0.00000000000000000000, -0.03429496250085656284, -0.20076620740872361259>;//,
#declare T1=texture { pigment { rgb<1,0,0> transmit 0.5 } finish { ambient 0.5 } }
union{
triangle { P1, P2, P3 texture {T1} }
//triangle { P1, P2, P4 texture {T1} }
//triangle { P1, P3, P5 texture {T1} }
//triangle { P1, P4, P5 texture {T1} }
//
triangle { P2, P3, P5 texture {T1} }
triangle { P2, P5, P4 texture {T1} }
	transform { rotate z*60 scale 1.3 }
no_shadow
}

Render with height/width ratio of 1 (+Hxxx +Wxxx)

The top border should be homogeneous. It is not so far.

Comment by Grimbert Jérôme (Le_Forgeron) - Sunday, 01 June 2014, 11:11 GMT

Even shorter

#version 3.6;
global_settings { assumed_gamma 1.0 max_trace_level 30 }

#local Lookfrom = <0.1, 0.2, -0.8>;

#declare P1=		<0.03249196962329062993, -0.05257311121191336062, -0.19021130325903071179>;
#declare P2=		<0.08792183440801312755, -0.05433868201739210785, -0.17584366881602625510>;
#declare P3=		<0.05433868201739210785, 0.00000000000000000000, -0.19659919844279735712>;
#declare P4=	<0.00000000000000000000, -0.03429496250085656284, -0.20076620740872361259>;
#declare C=(P1+P2+P3+P4)/4;
camera {
	location Lookfrom
	look_at C
	right x*image_width/image_height
  angle 10
}

#declare T1=texture { pigment { rgb<1,0,0> transmit 0.5 } finish { ambient 0.5 } }
triangle { P1, P2, P3 texture {T1} no_shadow }
triangle { P2, P3, P4 texture {T1} no_shadow  }

   demo.png (10.7 KiB)
Comment by Grimbert Jérôme (Le_Forgeron) - Sunday, 01 June 2014, 11:30 GMT

It seems the bug occurs when the second surface is at less than 0.002 from the first intersection.

#version 3.6;
global_settings { assumed_gamma 1.0 max_trace_level 30 }

#local Lookfrom = <0.1, 0.2, -0.8>;

#declare P1=	<0.03249196962329062993, -0.05257311121191336062, -0.19021130325903071179>;
#declare P5=	<0.00000000000000000000, -0.03429496250085656284, -0.20076620740872361259>;
#declare P2=	<0.08792183440801312755, -0.05433868201739210785, -0.17584366881602625510>;
#declare P3=	<0.05433868201739210785, 0.00000000000000000000, -0.19659919844279735712>;
#declare P4= P1+(P5-P1)/19;
#declare C=(P1+P2+P3+P4)/4;
camera {
	location Lookfrom
	look_at C
	right x*image_width/image_height
  angle 10
}

#declare T1=texture { pigment { rgbt<1,1,0,0.5>  } finish { ambient 0.5 } }
#declare T2=texture { pigment { rgbt<1,0,1,0.5>  } finish { ambient 0.5 } }
triangle { P2, P3, P1 texture {T1} no_shadow }
triangle { P2, P3, P4 texture {T2} no_shadow }
#debug concat(str(vlength(P1-P4),3,5),"\n")
Comment by Grimbert Jérôme (Le_Forgeron) - Sunday, 01 June 2014, 11:43 GMT

Testing code... the issue is tied to MIN_ISECT_DEPTH (changing it from 1e-4 to 1e-5, in source/backend/configbackend.h, reduces by 10 the size of the issue).

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 02 June 2014, 19:10 GMT

Updated to definite bug, all platforms.

History diving: MIN_ISECT_DEPTH was introduced with change #4117, 2006-04-03, from an issue with balcony.pov which did not render the liquid. SMALL_TOLERANCE (as 1e-3) was used in the previous code. The value of MIN_ISECT_DEPTH is just a tenth of it, pure magic.
It has not been adjusted since that time.

The previous code tested for > SMALL_TOLERANCE. The new code tests for >= MIN_ISECT_DEPTH. (backend/scene/objects.cpp & backend/render/trace.cpp ;places are noted for [cjc] )

The value also replaced the tolerance for detecting the intersection of bounding boxes. (backend/scene/objects.cpp)

From my understanding, the tests for additional intersection (avoiding perfect hit) would be also fine with > MIN_ISECT_DEPTH, and MIN_ISECT_DEPTH to 0.0; Yet the bounding box need a fuzzy factor, so maybe SMALL_TOLERANCE should be back there (loosing a bit of performance, not even sure the noise of bounding box is that bad).

From looking at 3.6.1, the test to check that the distance was at least > SMALL_TOLERANCE was not even there.

Opinions are welcome.

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 02 June 2014, 20:53 GMT

Using imagemagick to compare the balcony scene ( compare -metric AE -fuzz 5% B36.png Bpatch.png -compose Src Delta_36_patch.png ), the sea is different (that's known and expectable, IIRC tied to noise generator; render done with +A0.01), and the glass is more similar to 3.6 with the previously suggested patch.

In 3.6, the shadow of the top of the glass is darker (in 3.7 the inside is white/clear), and the base of the shadow of the glass shows less the caustic (?) of the base of glass (or in 3.7, the base of the shadow of glass+liquid is brighter, unrealistic white).

Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 07 June 2014, 16:52 GMT

Proposal of correction in file delta. (diff)

   delta (5.8 KiB)
Comment by William F Pokorny (wfpokorny) - Saturday, 15 October 2016, 18:29 GMT
  • Field changed: Status (New → Tracked on GitHub)

Now tracked on GitHub as #121.

Loading...