2

I have a shader i wrote, using the normal map generated by 3ds max. I get seamless results on windows, but i've seen seams on macs. Is this something that could be related to the directon i develop my normal map, (but then again i believe that i am running chrome in opengl mode), or some kind of precision issue? Is there any way of debugging this without a mac?

Per gmans answer below, i've added

gl.pixelStorei(gl.UNPACK_COLORSPACE_CONVERSION_WEBGL, gl.NONE);

The link is here.

webgl normal map seam

pailhead
  • 5,162
  • 2
  • 25
  • 46
  • On OSX using Safari 7.0.2 I see no seams. On OSX using Chrome 33.0.1750 I see an almost-invisible seam in the corner of the seat only. Try `MeshPhongMaterial` as an experiment. It uses derivative tangents -- not attribute tangents. Where did you get your tangents from? They do not look right. Try `VertexTangentsHelper`. – WestLangley Mar 27 '14 at 07:58
  • Hi West. By the sounds of it, even what you are seeing is not as harsh as the image on the left? I am obtaining tangents from 3ds max - the whole point is syncinc the normal maps. Could it be something related to gamma? – pailhead Mar 27 '14 at 08:21
  • First, did you try my suggestion(s)? – WestLangley Mar 27 '14 at 08:24
  • The information is somewhat overwhelming, what am i supposed to be looking at with 'VertexTangentsHelper'? Is this preferred over outputting the tangent as vertex color to the fragment shader? MeshPhongMaterial will most likely cause different artifacts (seams almost inevitably) because it's using a different function to unpack the normals. – pailhead Mar 27 '14 at 08:29
  • @gman's suggestion appears to have worked. No visible seams on OSX. – WestLangley Mar 27 '14 at 18:52
  • I did suspect gamma but i had no idea it was set like this by default. I hope it fixed it for good. – pailhead Mar 27 '14 at 19:00
  • Many of your tangents do not appear to be even close to "tangent" to the faces. I am still surprised that your rendering looks as well as it does. `MeshPhongMaterial` does not rely on tangents, and seams can be less visible -- sometimes. In any event, I like your work. +1 – WestLangley Mar 27 '14 at 19:01
  • It's voodoo :) [Here's a comparison](http://dusanbosnjak.com/test/webGL/new/importer/meshImporter04.html) of my method and default three.js. The shader should differ only in the rim term in terms of lighting. It's using the same normal map generated from max (it's without the colorspace fix). Not to dis on three.js, but i do think that there is a better tangent space solution than from Lengyel's book, and it's mikktspace used in blender and xnormal. The guy wrote a phd on the subject, and xnormal is a very popular baker. – pailhead Mar 27 '14 at 19:12
  • Do you mind redoing your example and NOT recomputing vertex normals -- so both shaders use the same geometry? Also, the Phong shader does not require tangents. – WestLangley Mar 27 '14 at 19:32
  • Not at all. I do remember having some issues at some point, the vertex normals wouldnt come in. For testing purposes, will it suffice if i just clone all the mesh info omitting tangents/binormals that i've added? What do you mean when you say that Phong does not require tangents, how does it develop the normal map? – pailhead Mar 27 '14 at 19:49
  • 1. Yes. 2. http://hacksoflife.blogspot.ch/2009/11/per-pixel-tangent-space-normal-mapping.html. – WestLangley Mar 27 '14 at 20:02
  • I did not know about this, was this around in r61 or r59? ill redo the example – pailhead Mar 27 '14 at 20:07
  • i can still see isues with this though, if it's purely based on sampling the UVs, it's very hard to get a proper bake based just on that, for tiled 'relief' maps without many discontinuities yes. Do you use bakers? – pailhead Mar 27 '14 at 20:14
  • [Does this make any sense?](http://dusanbosnjak.com/test/webGL/new/importer/meshImporter03_samemesh.html) – pailhead Mar 27 '14 at 20:32
  • We are cross-typing... :-) No, it doesn't. I am focused on getting the math as compatible as possible... You UV map on the sphere is has a lot of discontinuities. Your sphere does not have duplicate vertices on UV seams, but I do not think that matters. I thought the Phong shader using screen-space derivatives would work better in this case. There is something I don't get... – WestLangley Mar 27 '14 at 20:35
  • It must be something about the way you are baking the normals. I have not used those baking tools, so it is hard for me to know exactly the math behind them. In any event, you are better off with a consistent pipeline, and you seem to have one -- You just have to write your own `ShaderMaterial`s. – WestLangley Mar 27 '14 at 20:39
  • It's the way the normal map is encoded, and each baker has it's own way of doing it. I purposly made so many discontinuities to try to make a worst case scenario. Even the shadermaterial is showing some seams but they are less noticable. It shouldnt be hard at all to add this as a shader chunk and use it within three.js pipeline, but i struggled much with marying the content. [Going back to this](http://stackoverflow.com/questions/20262349/three-js-custom-tangent-attribute-how-do-i-load-it) you'll remember how miserably i failed at explaining the issue :) – pailhead Mar 27 '14 at 20:55
  • Not duplicating the vertices on seams took some time figuring out. Initially i would break them manually within 3ds max, but this posed some limits. I dont understand how to assign custom attributes with this discrepancy though, so i went in and basically copied the typed buffer used to set up the tangents, and just used the bitangent data. My format currently has indecis for each and every channel, i got a bit lost with all of that. If i shuffle things around though, i could bring it down to just the face indecis, maybe it would be easier to just assign attributes through the material then. – pailhead Mar 27 '14 at 20:58
  • Yes, I do remember. :-) ... So the conclusion, as I understand it, is if you had saved your normal map in sRGB format, then the seam would have been less visible -- if at all. Sound right to you? – WestLangley Mar 27 '14 at 21:35
  • I get somewhat lost with color space conversion. I have some experience from compositing. I understand the benefits of say, post processing in linear space, but i must admit that im not sure where it applies here. In my scope, what renders correctly with a cg shader, should more or less render the same in glsl. The normal map itself should always be linear, any conversion offsets the mid gray? – pailhead Mar 27 '14 at 22:01
  • Yes. Your normal map was in PNG format. I think WebGL by default converts PNG textures to linear space, which is a mistake if the image data is already linear. I just don't know enough about your baking tools to know if other formats are available -- or if three.js should have an option to not convert. Maybe @gman can help clear this up... – WestLangley Mar 27 '14 at 22:11

1 Answers1

5

Is it possible it's a color space conversion issue?

By default some browsers apply colorspace conversions when they load images. That's fine if you're just displaying an <img> tag but no so good for normal maps.

To tell WebGL to not allow to the browser to apply colorspace conversions you call

gl.pixelStorei(gl.UNPACK_COLORSPACE_CONVERSION_WEBGL, gl.NONE);

The default is that colorspace conversions are allowed (as in browser specific).

See the WebGL spec

gman
  • 100,619
  • 31
  • 269
  • 393
  • Hi gman, I think its very possible, in fact I would bet on it. I didnt know about this method. I am updating the question with another link with this set to none. I hope its as trivial as this :) Thanks! – pailhead Mar 27 '14 at 18:37
  • Thank you so much, this seems to have solved the issue! – pailhead Mar 27 '14 at 19:13