-
-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for black and white Bump Maps to compute normals PR #559
Conversation
Thanks - this is easier to understand. I think it's best to look at how normal mapping is handled in the path tracer and use similar code. A bump map is basically a normal map - you just have to compute the normals from a notional "height" computed from the black and white values. |
You'll also want to make sure that tangents are generated when bump maps are present instead of just when normal maps are: |
@gkjohnson i miss that... I'll check tangents I use only bumpMap at mesh and I can't get tangent attributes normally at shader |
I'm pretty new in glsl or graphics so i don't have a idea how to do dFdx and dFdy manually can i get a hint? This is as far as I understand it at this point. surf_pos (- vViewPosition) that input of perturbNormalArb(in my pr and three.js bumpMap function) from vertex shader so its value has no effected pathTracing sampling but dFdx, dFdy (surf_pos) has effected right? then should I get a near vertex position in screen space and add by uniform and use it in glsl? ** I also check blender cycles osl codes(node_bump.osl)
I think it's same in three.js codes |
Of course! Feel free to ask questions. I'm happy to have some help adding additional features to the project. Regarding the dFdX and dFdY functions - they compute the apparent change in a variable from pixel to pixel in screen space. It does this by checking sibling pixels and computing the difference between the variable value. This great for traditional rasterization but of course because all of these path tracing operations occur as a light ray bounces around a scene it's not appropriate to compute the change in texture value in screen space. Likewise the idea of using a "view position" or "direction" (which is based on the view ray from the original camera position) doesn't make sense since the rays can hit a surface from any direction after bouncing around. This is why the So on to how to compute the derivative (dFdX, dFdY) of the texture without using the built in functions - the derivative is the change in a variable over time along some dimension. So, instead, to manually compute the change along the X axis, for example, you can sample the value at the point hit and one pixel to the left and right and compute the derivative from those values. Since a bump map is basically a height map the derivative of a pixel represents the slope of the surface represented in the bump map which you can use to compute the normal. Hopefully this was helpful - let me know if you need me to elaborate on anything. |
then approach would simple with conversion of bump to normal... I'm going to find a solution of it |
related : #558
also this pr has a problem(I write a details in related issue #558 )
bumpMap applied not fully success(especially plane)