FaceForward And AverageNormal4 issue

[jdelauney]

Your functionnal test for faceforward is right :

FaceForward returns a normal as-is if a vertex's eye-space position vector points in the opposite direction of a geometric normal, otherwise return the negated version of the normal

Self = Peturbed normal vector.
A = Incidence vector (typically a direction vector from the eye to a vertex).
B = Geometric normal vector (for some facet the peturbed normal belongs). 

see http://developer.download.nvidia.com/cg/faceforward.html (also for step, smoothstep....)

For averagenormal4 i have : "AverageNormal4:Sub3 Z failed " expected: <1> but was: <0>

[dicepd]

I tested avn4 in unix64 for all configs and is green for me, what win64 config did it fail in?

[dicepd]

So it is basically for backface viewing. Allowing the face to be rendered all the time. I think I can mod the test for this, I see why it fails, test is wrong.

[jdelauney]

for facefoward can change the andps by assign cOneMinusVector and instead xorps by a mulps xmm0, xmm2

I tested avn4 in unix64 for all configs and is green for me, what win64 config did it fail in?

I'll check tomorrow but something is break in my lazarus ide and i'll compare Unix64 sse code with mine

[dicepd]

I am not testing assembler when I write these tests, just the pascal, I have not even tested any of these in other modes than native

[dicepd]

for smoothstep I think you changed a - to a *

    float t = saturate((x - a)/(b - a));
    return t*t*(3.0 - (2.0*t));

[dicepd]

So it is basically for backface viewing. Allowing the face to be rendered all the time. I think I can mod the test for this, I see why it fails, test is wrong.

Right so this is where I am having to learn new stuff. So basically this function is about shaders and per pixel normals when bump mapping. The geom norm is the underlying geometry normal and the perturbed normal is the resultant normal after applying the bump map, this function then decides if the new normal is visible or not, but has to flip the geom normal in order to get displayed. Is my understanding correct here.

[jdelauney]

Right so this is where I am having to learn new stuff. So basically this function is about shaders and per pixel

Yes those functions are often use in GLSL or HSL Shader scripts :)

[jdelauney]

I don't understand why FaceNormal fails. I don't understand why Y is the only negate and others set to 0

cmpps xmm2, xmm3, cSSE_OPERATOR_NOT_LESS

 andps xmm2, [RIP+cOneMinusVector4f]
 mulps xmm0, xmm2
  movaps   [RDX], xmm0   

"FaceForward:Sub1 X failed (X: 0,00000 ,Y: -1,00000 ,Z: 0,00000 ,W: 0,00000)" expected: <-1> but was: <0>

And with

  andps  xmm2, [RIP+cSSE_MASK_NEGATE] //xmm4 // Yes: $80000000, No: $00000000
  xorps    xmm0, xmm2   // Flip sign >= 0

i've : "FaceForward:Sub1 X failed (X: 1,00000 ,Y: -1,00000 ,Z: 1,00000 ,W: 0,00000)" expected: <-1> but was: <1>

[jdelauney]

For AverageNormal4 i suspect a param over the stack surely need movups instead movaps

"AverageNormal4:Sub3 Z failed " expected: <1> but was: <0>

[dicepd]

Sure you don't have nostackframe enabled?

[jdelauney]

It's ok now, i've also fixed FaceForward :) and all tests are green 👍

Thank for average. So if i understand well. When we have too many Params in function or if the size of these params are to big. They're push out the stack so, for have access, we pass the pointer adress of param in RAX (mov rax, [PARAM] and finally mov to aligned (movaps xmm0, [RAX]) i'm right ?

[dicepd]

return tt(3.0 - (2.0*t));

SmoothStep now uses the formula as shown on the website and passes functional tests. I have fixed pascal and win64 and unix64. See comments in functional test. Pascal is not very efficient, we do not have an overload for single - vector so have to introduce a +negative and a negate in the pascal which is not in the assembler.

This could be one example of where you have to negate stuff to make it work, re LHR v RHR when you mix hands. Obviously this has nothing to do with LHR v RHR, but this is what tends to happen when you 'get things working' in one system where the algo was developed in the other, without going back to first principles and reworking the whole algo from scratch to suit your handing. performance goes through the floor. One of the reasons MS had to allow RHR for physics, they could not do physics efficiently in LHR, in early days GL used to trounce DX, because DX had to do more transforms and negates. Then DX grew up a bit.

An old adage we had was 'view transforms are cheap. Whatever it is, it has to be applied once, algo transforms are expensive as more algos are applied to the model in general than the one view transform.'