POV-Ray / povray

The Persistence of Vision Raytracer (POV-Ray)
https://www.povray.org/
GNU Affero General Public License v3.0
1.38k stars 282 forks source link

Port of FS269 - Transparent Objects inside Media Cause Artefacts (OK. New feature?) #221

Open wfpokorny opened 7 years ago

wfpokorny commented 7 years ago

http://bugs.povray.org/task/269

(I think POV-Ray working OK, but perhaps herein an idea for a minmax-media-ray-length feature. Please see MediaArtefact_My* prefixed files in the attached zip as results today somewhat different than originally described)


Details:

When placing a transparent object inside another object which contains media, artefacts may occur (see attached file). They look similar to specular highlights or are just strange white spots in the image.

I discovered artefacts of that kind first in the image of which MediaArtefactDetail.png is a cropped part. The code I managed to reproduce such artefacts with contained a "cstarfield" sphere

sphere {
  <0,0,0>, 1

  pigment { rgbt 1 }

  interior {
    media {
      emission rgb 1/10
      density {
        crackle form <1,0,0>
        density_map {
          [0.0 rgb 1]
          [0.05 rgb 0]
        }
        scale 0.002
      }
    }
  }

  scale 1000

  hollow on
}

and a transparent sphere

sphere {
  <0,0,0>, 1

  pigment { rgbt 1 }

  scale 2

  hollow on
}

which is, obviously, completely inside the other sphere. So is the camera.

Since the sphere has a pigment { rgbt 1 }, it should be completely invisible, which is correctly rendered as long as the scaling factor is 1 and hollow off (MediaArtefact1.png). Changing hollow to on does not yet produce the artefact, but the right half of the output image seems to be shifted by one pixel (MediaArtefact2.png). Changing the scaling factor to 2 (as it is in the above code) produces the artefact (MediaArtefact3.png). Changing the camera location (MediaArtefact4.png) does not change anything, the artefact just "cmoves with the sphere". Changing the sphere size again, however, seems to stir up the "cstars" in the "cstarfield" sphere while not removing the artefacts (MediaArtefact5.png). Changing hollow to off again does neither (MediaArtefact6.png).

The artefacts are definitely no specular highlights. There is not even a light source in the scene that could produce any. I used POV-Ray 3.7 RC6 to render the images, but the artefact shown in MediaArtefactDetail.png already occured in POV-Ray 3.6 which I used to render that image

See the zip file: FS269.zip

wfpokorny commented 7 years ago

I believe POV-Ray is working as designed here. The star field is created with a crackle (0.002 scale) based density patten in a very large outer sphere which works due the sampling along very long rays.

When a transparent inner sphere is added - hollow or not - we get a new set of much shorter rays from the camera to the 'front' surface of the sphere. Size up by 2 and they are even shorter. Those from the back of the small sphere change - and so the star field for those rays shifts because the sampling shifts - but the overall length is still large.

I created two new files in the zip called MediaArtefact_My3_HighSample.pov and MediaArtefact_My3_Rot90HighSample.pov to show the 'artefacts' are related directly to how the crackle based density pattern exists and is sampled for the media result.

It could perhaps be useful - also for media artefacts due mathematical noise as happens with blob containers - to have a feature which lets the user specify a minimum ray length (max too probably helpful) for which they wish to calculate a media result. With the example here we'd ignore the short rays from the camera to the camera facing side of the inner sphere.

c-lipka commented 7 years ago

The bright orbs observed with the added hollow sphere are indeed not artifacts, but "anti-artifacts" if you will: They are a real feature of the media density pattern ("stars" that happen to be close to the camera), and the actual artifacts are their absence if the hollow sphere is removed.

I do not agree with the proposed solution though (not in the context of this issue report at any rate): If the user wants to suppress nearby genuine features of media, POV-Ray already offers enough mechanisms to achieve this, such as modifying the density pattern, or using a suitably shaped media container.

What the issue report does demonstrate, however, is that it might be useful to have a minimum sample density (or maximum sample distance) parameter for media sampling method 3, to force POV-Ray to properly pick up small localized features of a density pattern. While a certain minimum sample density can already be enforced by increasing the (minimum) samples parameter, the resulting minimum sample density will not be uniform, but rather depend on the total depth of the media container in that particular region of the image, and may therefore lead to excessive oversampling in regions of the image where the media container has less depth.

wfpokorny commented 6 years ago

Been looking at media quite a bit lately so reviewing this issues again too. I do like the idea of adjusting the samples to the ray lengths - we burn quite a bit of time sampling too much on short rays. I think it likely most natural for users building a scene like abyss.pov to calculate for the 'resolution' they want for the max distance and adjust actual samples. There would be exceptions - parts of a scene with larger shapes shadowing in the media and other parts with very tiny shapes so still thinking about how sample adjust-ability might be approached.

In my original response I was too focused on also fixing our long standing media speckling problem. I've chased this some in the code with problem scenes with bright and dark spotting and all so far are tangled in the apparent optical depth calculations. I can always "fix" scenes by hacking in some after the fact fix in the code.

I see in commit f814383 from December 2016 you did something similar to fix some issues with long rays and/or high densities. Is there any chance you still have the test scene(s) from this change? I'd like to have any of those in hand when trying other approaches. This post patching/fixing is relatively expensive though of course I've no idea if any other approach better... Thanks for your time.