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.

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:

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).