   vertex/fragment programs, strange shading
  Hi. I just completed a file importer, thanks to the forum's help. I would like to try some per pixel lighting using fragment/vertex programs. I'm going for a simple NdotL+ambient shader but I can't figure out whats causing this error.Vertex shader !!ARBvp1.0ATTRIB pos = vertex.position;ATTRIB col = vertex.color;ATTRIB norm= vertex.normal;OUTPUT col2= result.color.secondary;PARAM  mat[4] = { state.matrix.mvp };PARAM light = {0.0, 5.0, -5.0};PARAM offset = {0.5, 0.5, 0.5, 0.5};TEMP vcol;# Transform by concatenation of the# MODELVIEW and PROJECTION matrices.DP4    result.position.x, mat[0], pos;DP4    result.position.y, mat[1], pos;DP4    result.position.z, mat[2], pos;DP4    result.position.w, mat[3], pos; # Pass the primary color through w/ normal.MOV result.color.primary, norm;MOV col2, pos;MOV result.texcoord[0].xy, vertex.texcoord[0].yxzw;ENDfragment shader   !!ARBfp1.0ATTRIB tex = fragment.texcoord[0];ATTRIB norm= fragment.color.primary;ATTRIB pos1= fragment.color.secondary;#ATTRIB pos2 = fragment.position;OUTPUT outColor = result.color;PARAM light={0.5, 0.5, 0.5, 1.0};#PARAM  mat0 = {state.matrix.mvp};TEMP t0;TEMP nor;TEMP tmpCol;TEMP difCol, finalCol;TEMP s0, s1;TEMP v0, v1, v2, v3;TEMP lightV;TEMP col1, col2;#calc the the vector from the position to the lightSUB lightV.xyzw, light.xyzw, pos1.xyzw;#normalize light and normal and compute the dp3 between them#calc d^2DP3 s0, lightV, lightV;DP3 s1, norm, norm;#convert to 1/dRSQ v2, s0.r;RSQ v3, s1.r;#devide vectors by 1/d, normalize themMUL v0, lightV, v2;MUL v1, norm, v3;#MUL v0, v0, v2;#MUL v1, v1, v3;#calculate dot product between normalized vectors;DP3 difCol, v0, v1;MUL difCol, difCol, {1.0, 1.0, 1.0, 1.0};#calculate attenuation s0 = d^2ABS s0, s0.x;RCP s0, s0.x;#MAD s0, s0, {-1.0, -1.0, -1.0, 0.0}, {1.0, 1.0, 1.0, 0.0};MUL_SAT difCol, difCol, s0;TEX t0, tex, texture[0], 2D;MOV tmpCol, t0;MUL finalCol, difCol, tmpCol;#MUL outColor, tmpCol, difCol;MAD col1, pos1, {0.5, 0.5, 0.5, 0.5}, {0.5, 0.5, 0.5, 0.5};MAD col2, norm, {0.5, 0.5, 0.5, 0.5}, {0.5, 0.5, 0.5, 0.5};#add ambientADD outColor, finalCol, {0.1, 0.1, 0.15};#MUL outColor, col2, col1;#MOV outColor, difCol;#MOV outColor, tmpCol;ENDI can't see whats causing the massive difference in shading.Thankyou in advance.EDIT: I can also provide images of the normals(xyz) mapped to polygons(rgb). However, they are smooth; as they should be.[edited by - aaron_ds on February 5, 2004 3:58:01 AM]
  I''m not sure about this but I don''t think you can pass normals trough color since it gets clamped to (0..1) range. At least with RC it does. Try passing it trough one of the free texture chanels. Other than that try building FP step by step. First only N then L then NdotL and so on.   You should never let your fears become the boundaries of your dreams. ;  _DarkWIng_ is quite right.  Colour outputs are clamped to [0..1], so either pass your normal in a free texcoord slot (hint: if you''re textures are clamped you can pass the texcoords in the colour and the colour in the texcoords) or store it in the colour as (0.5 + (normal / 2)) and extract it in the fragment program with normal = ((colour - 0.5) * 2).Note that you''ll need to transform your normal by the modelview matrix in the vertex program (using DP3) as well as the position.I did''t look too closely at your fragment program because it was difficult to tell what was going on.  Code is much easier to read if you use descriptive variable names.Enigma ;quote:Original post by Enigma  Note that you''ll need to transform your normal by the modelview matrix in the vertex program (using DP3) as well as the position.Shouldn''t you transform normals by inverse transponse of modelview matrix? You should never let your fears become the boundaries of your dreams. ;  Errr <goes to check recent vertex program> probably.  If you only translate and rotate the inverse transpose is the same as the unaltered matrix though.Enigma ;  You should not transform normals using the matrix translation row.In that way, it is different when you invert it (not sure what it does anyway). For verices you should take the modelview matrix as is.   [edited by - Tree Penguin on February 5, 2004 7:48:30 AM];  http://developer.nvidia.com/object/mathematicsofperpixellighting.htmlThis paper should give you abit mathematical backgroud about the math used in PPL. And why you (sometimes) need inverse-transponse of MVM (pages 12-18 of PDF). It''s a good read for anyone starting PPL.   You should never let your fears become the boundaries of your dreams. 