Investigate minifig head lighting

[leozide]

[leozide]

Also on heads:

3626cpx3.dat in ldrawunf.zip

[rsbx]

Looking at torso 973 and head 3626a using wireframe shading with LC_DEBUG_NORMALS enabled, it appears that the normals of the affected areas don't point where I'd expect them to. BTW, the torso also has the issue on the "neck".

[rsbx]

Hmmm; if I disable my BFC code, 3626a and the neck of 973 are fine. But, 973 still has issues where the arms go.

[rsbx]

Another OFFICIAL part with normal issues: 14769, Tile 2x2 Round with Round Underside Stud. Specifically the areas by the notches.

[rsbx]

Attached is a detail image of part 14769, Tile 2x2 Round with Round Underside Stud, showing the vertex normals in wireframe mode using orthographic projection from above. There are a number of triangles & quads with vertex normals that do match the normal of their triangle/quad in the area that I highlighted. I suspect the issue affecting minifig torsos, e,g, 973.dat, is related to what is going on here.

To get this view, I made the following changes to the code at commit b10d895:

• Defined LC_DEBUG_NORMALS to 1 in common/lc_scene.cpp
• Changed the calls to MeshLoader() in common/lc_library.cpp and pieceinf.cpp to disable vertex optimization and normal averaging
• Deleted all of the cache files via rm -rf

[leozide]

These are a pain to track down but you need to do it with smoothing enabled

[rsbx]

This is showing the _inputs_ to the smoothing and explains why the smoothed normals are wrong. But I'm not understanding why the unsmoothed normals are wrong. The area around torso, 973.dat, arm holes also has wrongly pointed unsmoothed normals so I think it's the same issue. I find it easier to see with the wireframe of the tile than the wireframe of the torso.

…

On 3/15/21 11:06 PM, Leonardo Zide wrote: These are a pain to track down but you need to do it with smoothing enabled — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#641 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAECJNARPE4O2ZM52H6N4PTTD3DMVANCNFSM4YXJ7X7A>.

[rsbx]

I'm pretty sure the bad input normals are caused by shear components in the transformation matrices in the definitions of 973 (torso) and 14769 (round tile). For example, the follow matrix, from the outer, left side, 4-4ndis.dat primitive of 973, appears to ONLY have shear and scale components.

-0.85 0 0
4.925 1 0
0 0 5

I have not investigated 3626cpx3 since it's an unofficial part and I don't have them loaded but, from the image, it appears that the normals are inverted for 1/2 the head.

[rsbx]

Here's the patch to fix the issue:

normalfix.patch.txt

For those interested: normals need to be transformed by the transpose of the inverse of the transform matrix.

[rsbx]

It looks like a couple of the shaders need to be fixed also but that's beyond me.

[leozide]

I think you're on the right track, I tried to orthonormalize instead and it looks like the Minifig torso is fixed. I don't think transposing the inverse is really needed, it may be fixing the matrix as a consequence of the inverse operation.

[ghost]

Also happen with eyes on many heads parts:

[rsbx]

No, the transpose(inverse()) is needed. Do a search using "computer graphics transform normals" as the terms for the reasons (likely in the textbooks also). Thinking about the shaders some more: they're OK as is if the world matrix is _only_ composed of rotations and _uniform_ scaling.

…

On 3/16/21 11:22 PM, Leonardo Zide wrote: I think you're on the right track, I tried to orthonormalize instead and it looks like the Minifig torso is fixed. I don't think transposing the inverse is really needed, it may be fixing the matrix as a consequence of the inverse operation. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#641 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAECJNATMXTGAVLIZEL4TQLTEAOAVANCNFSM4YXJ7X7A>.

[leozide]

Both methods are removing non uniform scaling so the results will be equivalent for orthogonal matrices.

Shaders don't need to change because the world matrices are affine transforms.

[rsbx]

Shears are _not_ orthogonal matrices. Not sure about scaling. Shears & non-uniform scaling _are_ affine transforms.

…

On 3/17/21 12:54 PM, Leonardo Zide wrote: Both methods are removing non uniform scaling so the results will be equivalent for orthogonal matrices. Shaders don't need to change because the world matrices are affine transforms. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#641 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAECJNA6WF4FARP7KJ67WJTTEDNFVANCNFSM4YXJ7X7A>.

[leozide]

Ok, the transforms are orthonormal

[rsbx]

The cost of the matrix inverse could be lessened by inverting only the top-left 3x3 matrix of the 4x4 transform matrix since the normal is a vector. But I've not noticed a performance degradation with the normal fix so it may not be worth the effort.

[rsbx]

@Symbian9 what are the part IDs for those heads you found with issues?

[ghost]

what are the part IDs for those heads you found with issues?

That was 3626bp61.dat and 3626bpa1.dat.

FTR, In latest LeoCAD b548e1f build (I use LeoCAD-Linux-b548e1f-x86_64.AppImage) it seems like issue already fixed:

[rsbx]

Great! Likely caused by the normals calculation issue that was just fixed.

I see you found the High Contrast stud style option.

[rsbx]

Can this issue be closed?

[rsbx]

The shading discontinuity with 3626cpx3 is cause by the texture coordinates not matching where the front and back textures meet. Since the compare fails, a new vertex in add and the there's no normal smoothing.

[rsbx]

That should fix 3626cpx3 & friends:
addvertex.patch.txt

[rsbx]

Improved patch:

addvertex.patch.txt