GSOC 26: keep bump map slopes correct at image edges - #9095
Conversation
| * <a href="#/p5/sphere">`sphere()`</a>, the two edges of the image meet. The | ||
| * image has to tile for them to line up. Because a bump map is read by | ||
| * comparing neighbouring pixels, also call | ||
| * <a href="#/p5/textureWrap">`textureWrap(REPEAT)`</a> so those comparisons |
There was a problem hiding this comment.
Does this apply to other textures like bump maps? Also I think for shapes like sphere() it won't end up mattering because there aren't faces that go past 1 in texture coordinates, so it's probably sufficient to leave out the textureWrap bit
There was a problem hiding this comment.
the tiling half applies to any texture wrapped around a sphere, plain texture() included, so that part isn't bump specific.
the textureWrap half is though, and i think it does still matter. you're right that no face goes past u=1, but the bump path deliberately samples one texel to each side of the current coordinate to work out the slope, so at u=1 that lookup does read past the edge even though the face doesn't.
i just tested it on this branch to be sure, same build and same map, only difference being the textureWrap(REPEAT) line: without it there's still a visible seam down the sphere, with it the surface is clean. the both-sides change in this pr made it much fainter than it was (one side still clamps instead of both), but it didn't remove it.
happy to drop the mention if you'd rather keep the docs lighter, or move it somewhere less prominent. can also post the two screenshots if it's useful to see the difference.
2 participants
closes #9091.
two parts, both from the seam discussion on #9068.
bump map slopes at the edge of an image
bumpTexture()works out the surface slope by comparing neighbouring pixels. it only looked one way, so at the far edge of the image that lookup ran past the end and read back the same pixel, which made the slope read as flat exactly there. it now compares both sides, so an edge still gets a real slope.on a sphere this shows up as a line down the seam. comparing the same sketch before and after, the line goes from obvious to faint. it doesn't disappear entirely without
textureWrap(REPEAT), since at the very edge one of the two lookups still stops at the end of the image, but the shader no longer flattens the slope on its own. the same fix is in the webgpu shader.docs
added a note to
normalTexture()andbumpTexture()explaining that a shape likesphere()wraps its texture coordinates all the way around, so the two edges of the image meet and the image has to tile for them to line up. thebumpTexture()note also mentionstextureWrap(REPEAT), since the slope comparison needs to carry across the join.as discussed, this stays a property of the texture rather than something forced on all maps, since on a plane u=0 and u=1 shouldn't be the same.
full webgl and webgpu suites pass, including the existing normal and bump map visual tests.
note: stacked on #9089, so that one goes in first.