Page MenuHome

Cycles Hair BSDF roughness problem
Closed, ResolvedPublic

Description

System Information
linux64
win64

Works fine in mac

Blender Version
Broken: 2.71 official for both windows and linux, also latest master on linux
Worked: mac official 2.71, win 2.70 official release

Short description of error
Here's I attach the render result from different machine

2.71 linux64 aa7f919

2.71 linux64 official

2.71 win64 buildbot 2e43617

And below the result from win64 2.70 official, which gives the correct roughness and clump result.

Exact steps for others to reproduce the error

  1. download blendfile here Cycles Hair BSDF by cgcookie
  2. press f12 (Render)

Event Timeline

Thomas Dinges (dingto) triaged this task as Normal priority.

I don't know if 2.70 was handling correctly Cycles Hair primitives.
But if you change in 2.71, primitive shape from thick to ribbons, render result seems good.

In 2.70, I don't difference between both options.

No opinion from creator of the file ?

Not sure whats going on yet, maybe https://developer.blender.org/rB0509553b5eb240b3970848a4432e0bbfcbba8690 is the issue or one of the other refactors at that time. Probably need to bisect this...

Thomas Dinges (dingto) raised the priority of this task from Normal to Confirmed, Medium.Jul 22 2014, 11:15 AM

@Thomas Dinges (dingto), no need to bisect. I'll look into it tomorrow morning if you don't fix it overnight.

Developer node:

  • There is indeed a regression caused by the rB0509553, but it is fixed in rB8641e307 (T40032)
  • There are several changes to shading and normals, like rB0f85174 and it could also be some changes from GGX/Beckmann to be involved.

Going back to investigation.

Developer note for those who're playing at home: the issue is caused by rB0f85174, all the rest bits of the changes involved in this issue are solved in the current master mow. It might either be issue in the BVH intersection or we're just hitting an old TODO about energy not being conserved. Now we're limited to a single patch to be investigated at least, what can be less trivial? :)

I'm not sure what's going on here. The rB0f85174d5 commit really should only have a very minimal effect, it was just intended to remove some fireflies, it's not supposed to have a significant effect on shading. What this was supposed to fix is that if you have a radius that changes from one curve key point to the next, that the normal direction should be slightly adjusted for that. If it has a bigger influence then that there is a problem with that commit.

Some background on the hair shading and geometry for anyone debugging this.

I couldn't find quickly find the papers about the BVH hair or intersection code, not sure what Stuart based that on. But basically you have two types of hair geometry and shading. For geometry you have either ribbons, which are flat curves oriented towards the view direction, and then you also have thick curves. The critical difference is the normal, in the case of ribbons it's going to be oriented towards the viewer, in the case of thick curves it varies around the curve.

And this is then closely related to hair shading. If you want to use a regular BSDF like diffuse or glossy you need the thick curves, because otherwise the ribbon normals are always pointing in the same direction which doesn't look very good. But since you have a varying normal on this very thin curve that can lead to significant noise. That's why you have a special hair BSDF which doesn't use the normal at all, it only uses the curve tangent. If you're far enough away from the hair you don't care about the normal variation around the hair, you can just average all normal variation that together, which is basically what the hair BSDF does.

The third thing that can be going on here is minimum pixel width for curves. The idea here is that if you have very thin curves, much smaller than a pixel, you can get significant noise. So instead the curve radius is increased to give them a certain minimum with in pixels, while at the same time being made transparent to compensate for that scaling. The transparency is not implemented as actual transparency in a shader, rather in the BVH it will randomly accept/reject ray intersections with a curve depending on how much they got scaled up.

The fourth thing is about the TODO mentioned in rB0f85174d5. The way the hair BSDF is implemented, you only need to do shading on the front side of the hair curve, on the backside it's not needed. So the trick there is to assign a transparent shader instead. The weight of that shader is nog properly adjusted for mixing with other BSDFs though, so it might lead to issues, but as far as I know that behavior did not change recently, I only added a note about it.

So anyway, to debug this issue, some things you could do to narrow it down:

  • This file has both a diffuse and hair BSDF, and only the former uses the normal. So to start you should check which these BSDFs is different. Further there is a hair reflection and transmission BSDF here, so you can check those individually as well.
  • Render a normal pass to see if the normal changed. You can also change to hair shader to render a kind of tangent pass to visualize the tangent, and check if that changed as well.
  • If you zoom in really close to the hair you might also be able to better see what's going on with the geometry and normal/tangent.
  • If hair minimum width is on, you can test turning that off.
  • Test with fewer bounces, disable transmission bounces, etc.