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#26 - Artifacts rendering a cloth which has two-side textures

Attached to Project: POV-Ray
Opened by Jorge Gascon Perez (jgascon) - Wednesday, 13 May 2009, 19:30 GMT
Last edited by William F Pokorny (wfpokorny) - Monday, 24 October 2016, 15:54 GMT
Task Type Definite Bug
Category Backend → Geometric Primitives
Status Tracked on GitHub
Assigned To Chris Cason (chrisc)
Christoph Lipka (clipka)
Operating System All
Severity Low
Priority Normal
Reported Version 3.61
Due in Version Future release
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Dear PovRay maintainers and developers, congratulations for your great RayTracer!

We think that we have found a bug while we were rendering a piece of cloth.

In this piece of cloth were defined two textures, one for one side and one for the another side: 

  texture { mesh_tex0_0 }
  interior_texture { mesh_tex0_1 }
  • Please: Look at line 77414 of the attached file “test.pov” to see

these definitions in their original context.

We have found some artifacts in the final rendering, in concrete near some wrinkles,
please, look at the attached file “render_artifacts.tga”, I have painted a big green arrow
near the artifacts, maybe you’ll need to do a zoom to see them more accurately.

They are as though the texture of the other side was painted in the incorrect side.

Fortunately, we have a patch to fix this bug (thanks to Denis Steinemann, he made the
implementation for PovRay 3.5, so I have adapted these changes to release 3.6.1)

Although we have found this bug in the Windows and Linux 3.6.1 releases,
the patch was generated in Linux (using the source code release of “povray-3.6.1”).

To apply this patch, inside the parent folder of the directory “povray-3.6.1” execute:

            patch -p0 < other_side_artifacts.patch

And the “povray-3.6.1” will be patched and you will get a console output like this: 

 patching file povray-3.6.1/source/lighting.cpp
 patching file povray-3.6.1/source/mesh.cpp
 patching file povray-3.6.1/source/render.cpp

We don’t know if this “hack” is enough smart to apply in the next release,
but we think that it fixes the bug (the artifacts dissapear).

Best regards and thank you very much for your great RayTracer!

(application/octet-stream)    render_artifacts.tga (332.1 KiB)
   test.pov (1.92 MiB)
   other_side_artifacts.patch (26.7 KiB)
This task depends upon

Comment by Chris Cason (chrisc) - Saturday, 16 May 2009, 12:44 GMT

I've confirmed that the problem exists in both 3.6 and 3.7. Christoph, would you mind evaluating the patch for suitability?

Comment by Christoph Lipka (clipka) - Sunday, 17 May 2009, 21:27 GMT

Judging from both the patch and experiments with the sample scene, the described artifacts seem to be a member of the well-known "Smooth Triangle Artifact" class, caused by the discrepancy between the "unpertubed" surface normal and the true geometric surface normal.

From a first examination, it seems that the patch is a hack directly targeted at this particular variant of the Smooth Triangle Artifact only.

A complication with the patch is that it also seems to contain a few totally unrelated changes. While some deal with color clipping and gamma correction and are therefore easy to "filter out", there also seems to be at least one additional modification of the mesh code, making it difficult to tell which code changes actually constitute the fix for the reported error.

All in all, I consider this patch unsuitable, and suggest to instead tackle the underlying root cause in a more systematic fashion.

My proposal would be to generally distinguish not only between "unpertubed" and "pertubed" surface normals, but between "geometric", "smoothed" and "pertubed" surface normals (with "geometric" and "smoothed" normals being identical for most objects).

Comment by Chris Cason (chrisc) - Wednesday, 20 May 2009, 14:52 GMT

I agree with Christoph, the patch isn't suitable for the general case. However I will leave the bug open for now in case a more applicable solution becomes available.

Comment by Mike H (SharkD) - Saturday, 19 June 2010, 23:46 GMT

Wow, I had no idea there was an interior_texture statement.

Comment by William F Pokorny (wfpokorny) - Monday, 24 October 2016, 15:54 GMT
  • Field changed: Status (Assigned → Tracked on GitHub)

Now tracked on github as issue #132.

Loading...