Quote:Original post by FReY
Well, the phenomenon you have on your screenshot is edge-creasing. The only way this would happen is if you have a different TBN per vertex (even if it is a wrong TBN, it will be the same and yield the same result with all faces that are using it) which means you probably have split normals/tangents at those points on the model.
i can assure you this is not the case as i visually checked all normals. at the neck and the shoulder all normals are shared (hence faces sharing the same vertex have also the same normal)
Quote:There is NO other way that this phenomenon can occur.
i still think it is not the normal playing dull there, maybe the TBN or the shader but the normals are ok.
Quote:Please, post another screenshot with your normals used in conventional lighting (ie. no vertex shader, no normal mapping, no TBN, just straight fixed-function lighting.)
this i can not do as my graphic-module is hard-wired to shaders (i have no TLN module yet). but i messed with the shader to not transform the normal and not apply the normal map, hence lighting like always just without TBN and normal-maps.
NOTE: i disabled shadow-volumes in this one to see lighting better.
Quote:So *ARE* you using this 'edge creasing' on your model? If you are, it will yield the same results as smoothing groups (it's just another method of splitting normals on your faces)
kind of. i use it to make an edge which is hard (ergo an edge of a box for example) to be lit 'hard' with separate normals and all other edges have smoothed normals. it is much easier to work with edge creasing than smoothing groups, especially since blender has separate edge selection and handling mode.
Quote:I suggest you run a function like this on your models to make sure (if a face shares a vert with another face it makes sure that the normal is the same)
*** Source Snippet Removed ***
no-go. like i mentioned above there are edges which have to be hard to be lit properly. those are located at places with sharp angles like the mouth or horns and claws. the parts having problems with lighting all have no hard edges and hence all the normals there are shared. that code will hence bounce out on every model i have.
Quote:Just to clarify something. The inverse of the TBN will be the transpose of the TBN if the TBN is orthonormal. This simply means the TBN rows and columns are swapped. There is no dire need to invert the matrix by using it's determinant, so there is no need to negate any values when simply a transpose will do.
sounds logical to me. still there has to be something wrong with the TBN or the fragment program. if you pay attention to the hind feet in both screenshots you will notice that in the normal only both hind feet are totally unlit, because they are outside the light range. in the TBN version though they receive utterly muich light which can not be correct. as in both cases i use the very same VBOs (hence the same normals and tangents) i assume that those are not incorrect as otherwise in both screens it should look wrong.
EDIT: i'm not sure about it but maybe the lighting with normals only is not fully correct too. if i am not mistaken then the edges of the faces have correct lighting but the pixels inside the triangle not. this would mean the interpolated normal (lightPos - inPos) is off somehow. as far as my math goes using a shorter normal inside the triangle should result in less light intensity. maybe it is effectivly not the TBN but the fragment shader having an error somewhere (if i'm correct).
still doesn't give me a hint why with TBN it is totally off.
EDIT: EDIT: made a mistake in the quickly changed shader for showing normal lighting only, i forgot the normalizing. updated the second screenshot with the corrected one. here you see that normals do work well. there are some spots i am not sure what's up there but in general it is looking ok.
EDIT: EDIT: EDIT: i played around with the scripts as i have a suspect. i set attenuation fix to 0.5 instead of calculating it per-vertex. in this setup the model is properly lit like in the normal-only screenshot, just with a normal-map applied like it should. this result means that the fragement program is working well but that the normal spit out by the TBN is utterly wrong. as i have only ommited the TBN compared to the normal-only version of my script it is clear that the TBN calculation has to be buggy and misshaping my light normals. now what can i do against that?
[Edited by - RPTD on October 13, 2005 1:23:35 PM]