search

mmp / pbrt-v3

Source code for pbrt, the renderer described in the third edition of "Physically Based Rendering: From Theory To Implementation", by Matt Pharr, Wenzel Jakob, and Greg Humphreys.
http://pbrt.org
BSD 2-Clause "Simplified" License
4.87k stars 1.18k forks source link

Hair rendering issue (possible incorrect intersection computation) #221

Closed jlemein closed 4 years ago

jlemein commented 5 years ago

I am rendering two hair models. One using the provided hair model from PBRT (straight hair) and the other from CemYuksel (wavy model), converted by using the cy2pbrt tool provided from the PBRT source code. When I render both models, with a distant light source coming from behind the hair models (shining into the camera), then the hair model from PBRT renders fine, but the hair model from Cem Yuksel does not:

  1. The wavy hair model is overlit,
  2. It seems that something is going wrong with the intersection computation for the wavy model, since you would only expect the edges of the hair model to be lit (the central part is dense enough to block light light). I even added a head model between the hairs from Cem Yuksel, and such an opaque object is also not blocking the light.

I attached two renderings with a scene description file.

wavy-straight-lit-from-back wavy-straight-lit-from-right

scene.txt

jlemein commented 5 years ago

After building PBRT with the lastest sources I managed to get a correct output. I tried different builds: debug and release, and single precision floating point vs. double precision floating point. The correct result I get with single precision floating point.

If I build PBRT with double precision floating point (-DPBRT_FLOAT_AS_DOUBLE=1), then the rendered output is still incorrect. Moreover, the output for the PBRT hair model is now incorrect as well. See attachments.

I don't know why this happens. Maybe any of you has a clue what has changed in the last couple of weeks/months that could result in this behavior?

For what it's worth: My OS: Linux Mint 18.3 (Sylvia) My compiler: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) Thread model: posix latest_singleprecision latest_doubleprecision

mmp commented 4 years ago

Sorry for not getting to this sooner (and when I did, it took a while to chase down.)

It boiled down to an Unfortunate Interaction between extra ray origin slop being added in the Float==Double case and the large initial ray origin slop that's necessary with curves..

Fixed now.