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.
Opened by Jorge Gascon Perez - 2009-05-13
Last edited by William F Pokorny - 2016-10-24
FS#26 - Artifacts rendering a cloth which has two-side textures
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!
I've confirmed that the problem exists in both 3.6 and 3.7. Christoph, would you mind evaluating the patch for suitability?
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).
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.
Wow, I had no idea there was an interior_texture statement.
Now tracked on github as issue #132.