Question About Hair Displaying Unusual Texture Glitches

General discussion and questions about XNALara go here.

Moderators: ObscureMemories, Runa, Love2Raid

Post Reply
Schadenfreude
Posts: 5
Joined: Wed May 20, 2020 4:02 am

Question About Hair Displaying Unusual Texture Glitches

Post by Schadenfreude »

Hey,

So I'm a complete XNALara noob, just trying to get into it. I had a quick question about hair textures appearing glitched and unusual. I linked to one such image below:

https://imgur.com/a/aKmvcOt

It's not only this particular model that's having the issue; a number of models I attempted to load in had similar problems.

I'm wondering if there's some setting I could adjust that would get rid of this or compensate for it? I tried googling a solution, but failed to find anything.

Thanks in advance for any help, and sorry for the newbie question!
User avatar
Ems
Porter
Posts: 172
Joined: Tue May 19, 2015 11:16 pm
Custom Rank: Stashing stuff I like.

Re: Question About Hair Displaying Unusual Texture Glitches

Post by Ems »

Lots of models use two-sided meshes, Japanese games notoriously. Meaning whole or parts of meshes have duplicate faces, where duplicates have normals directed to the opposite side. Some engines display polygons to have only one side, one is rendered opaque and the other is transparent. Putting doubles on those and flipping normals is a workaround that makes both sides visible from every angle.

Turn on "back face culling" and "always force culling" in options to sort these out. Problem is that then you can't put models that don't require these functions on the same scene without some display oddities.
Schadenfreude
Posts: 5
Joined: Wed May 20, 2020 4:02 am

Re: Question About Hair Displaying Unusual Texture Glitches

Post by Schadenfreude »

Ems wrote:Lots of models use two-sided meshes, Japanese games notoriously. Meaning whole or parts of meshes have duplicate faces, where duplicates have normals directed to the opposite side. Some engines display polygons to have only one side, one is rendered opaque and the other is transparent. Putting doubles on those and flipping normals is a workaround that makes both sides visible from every angle.

Turn on "back face culling" and "always force culling" in options to sort these out. Problem is that then you can't put models that don't require these functions on the same scene without some display oddities.
Thanks for the info and explanation, I appreciate it!
User avatar
XNAaraL
XPS Author
Posts: 120
Joined: Fri Sep 21, 2012 9:01 am

Re: Question About Hair Displaying Unusual Texture Glitches

Post by XNAaraL »

Ems wrote:Lots of models use two-sided meshes, Japanese games notoriously. Meaning whole or parts of meshes have duplicate faces, where duplicates have normals directed to the opposite side. Some engines display polygons to have only one side, one is rendered opaque and the other is transparent. Putting doubles on those and flipping normals is a workaround that makes both sides visible from every angle.

Turn on "back face culling" and "always force culling" in options to sort these out. Problem is that then you can't put models that don't require these functions on the same scene without some display oddities.
True, turn on "back face culling" and "always force culling" (BFC/AFC) in options sort "these" out.
True, you will just replace one problem (black spots) with another problem (you can't put models that don't require these functions on the same scene without some display oddities ... except you convert the faulty model to the NGFF format )

Your explanation of what happens will be confirmed by 99.99% of all porters. However, this explanation is just a hypothetical model to describe it, like in the Atomic theory the Rutherford model is one model and the Bohr model, the Lewis model and others like the Dalton model is just a hypothetical model to describe it.

So in short:
Sure, you "model theory" can help to explain it, but is wrong in roots, if you compare it with another "true" model.
Before I will explain what really happened (next post) ... I try to list what is false:

False: "Lots of models use two-sided meshes. Meaning whole or parts of meshes have duplicate faces".
True: "Lots of models use two-sided materials. (No modeler would makes model with coplanar or coincident faces)"

False: "where duplicated faces have normals directed to the opposite side."
True: "where the polygons have the vertices (3D points) in counter-clockwise winding, and the duplicated faces have specified that the polygons have a clockwise winding ... maybe also flipped Normals"

False: "Some engines display polygons to have only one side, one is rendered opaque and the other is transparent."
True: "Is a engines display as default that polygons have only one side, then this engine have also a option to render the polygons two-sided. Even if there were an engine without this option, it wouldn't matter. The shader also has this property (CullMode = None)"

False: "Putting doubles on those and flipping normals is a workaround that makes both sides visible from every angle. Turn on "back face culling" and "always force culling" in options to sort these out."
True: "It is illogical that a visual artifact can be solved by adding additional (unnecessary) polygons and then giving the engine the command BFC/AFC to send them to the graphics card but not to draw these ployons there."

To provocate:
False: "Lots of models use two-sided meshes, Japanese games notoriously"
True: "Models, extracted by a "daemon tool" that use the wrong file format (.smd and mesh.ascii) and now not can know how to save the "Two Sided" (cm = none) state using a file format that not support this state, will produce superfluous duplicated faces, and this polygons will caust such a trouble (if the porter not remove it)."

Before I explain my "model theory" (what really happens inside XNALara or XPS), try to use your "Backface model theory" (sometimes referred to as Daltonism) and explain:
  1. Why are some spots in black (dark)? What caust the spots? Image
  2. Why have this model display oddities for (BFC/AFC) , even the "Normals" are calculated outsided? Image
Schadenfreude
Posts: 5
Joined: Wed May 20, 2020 4:02 am

Re: Question About Hair Displaying Unusual Texture Glitches

Post by Schadenfreude »

XNAaraL wrote:
Ems wrote:Lots of models use two-sided meshes, Japanese games notoriously. Meaning whole or parts of meshes have duplicate faces, where duplicates have normals directed to the opposite side. Some engines display polygons to have only one side, one is rendered opaque and the other is transparent. Putting doubles on those and flipping normals is a workaround that makes both sides visible from every angle.

Turn on "back face culling" and "always force culling" in options to sort these out. Problem is that then you can't put models that don't require these functions on the same scene without some display oddities.
True, turn on "back face culling" and "always force culling" (BFC/AFC) in options sort "these" out.
True, you will just replace one problem (black spots) with another problem (you can't put models that don't require these functions on the same scene without some display oddities ... except you convert the faulty model to the NGFF format )

Your explanation of what happens will be confirmed by 99.99% of all porters. However, this explanation is just a hypothetical model to describe it, like in the Atomic theory the Rutherford model is one model and the Bohr model, the Lewis model and others like the Dalton model is just a hypothetical model to describe it.

So in short:
Sure, you "model theory" can help to explain it, but is wrong in roots, if you compare it with another "true" model.
Before I will explain what really happened (next post) ... I try to list what is false:

False: "Lots of models use two-sided meshes. Meaning whole or parts of meshes have duplicate faces".
True: "Lots of models use two-sided materials. (No modeler would makes model with coplanar or coincident faces)"

False: "where duplicated faces have normals directed to the opposite side."
True: "where the polygons have the vertices (3D points) in counter-clockwise winding, and the duplicated faces have specified that the polygons have a clockwise winding ... maybe also flipped Normals"

False: "Some engines display polygons to have only one side, one is rendered opaque and the other is transparent."
True: "Is a engines display as default that polygons have only one side, then this engine have also a option to render the polygons two-sided. Even if there were an engine without this option, it wouldn't matter. The shader also has this property (CullMode = None)"

False: "Putting doubles on those and flipping normals is a workaround that makes both sides visible from every angle. Turn on "back face culling" and "always force culling" in options to sort these out."
True: "It is illogical that a visual artifact can be solved by adding additional (unnecessary) polygons and then giving the engine the command BFC/AFC to send them to the graphics card but not to draw these ployons there."

To provocate:
False: "Lots of models use two-sided meshes, Japanese games notoriously"
True: "Models, extracted by a "daemon tool" that use the wrong file format (.smd and mesh.ascii) and now not can know how to save the "Two Sided" (cm = none) state using a file format that not support this state, will produce superfluous duplicated faces, and this polygons will caust such a trouble (if the porter not remove it)."

Before I explain my "model theory" (what really happens inside XNALara or XPS), try to use your "Backface model theory" (sometimes referred to as Daltonism) and explain:
  1. Why are some spots in black (dark)? What caust the spots? Image
  2. Why have this model display oddities for (BFC/AFC) , even the "Normals" are calculated outsided? Image
Thanks for the in-depth explanation, this helps a lot to explain why these texture issues exist.
User avatar
XNAaraL
XPS Author
Posts: 120
Joined: Fri Sep 21, 2012 9:01 am

Re: Question About Hair Displaying Unusual Texture Glitches

Post by XNAaraL »

Schadenfreude wrote:Thanks for the in-depth explanation, this helps a lot to explain why these texture issues exist.
? :?: :shock: :? :?:
I haven't explained anything yet! :!:
Read again:
XNAaraL wrote:...
Before I will explain what really happened (next post) ... I try to list what is false:
...
...
I have not yet written this next post because Ems has not yet answered the questions for the first post. :roll:
XNAaraL wrote: Before I explain my "model theory" (what really happens inside XNALara or XPS), try to use your "Backface model theory" (sometimes referred to as Daltonism) and explain:
  1. Why are some spots in black (dark)? What caust the spots? https://i.imgur.com/kqSlRVL.jpg
  2. Why have this model display oddities for (BFC/AFC) , even the "Normals" are calculated outsided? https://images-wixmp-ed30a86b8c4ca88777 ... y2yYDXTwSI
User avatar
Ems
Porter
Posts: 172
Joined: Tue May 19, 2015 11:16 pm
Custom Rank: Stashing stuff I like.

Post by Ems »

So, @OP, on topic - yeah, XNAaraL knows way more than me and wrote this program, so while trying to keep the explanation short, I probably used wrong terms for things, thus the roast, I'm a hobbyist just like you. But honestly, I dunno, what the heck.

off the topic though:

1. mesh has duplicates, each set has front facing and back facing triangles. Culling renders them properly, by, well, literally culling back-faces that are not facing the camera, without it we get those "pretty" checkers, because everything is visible at once as I get it, and light is not rendered on the "back side", thus colour.

2. face normals are turned away from the camera. In other words, model is made of back-faces. No doubles like in the upper case, culling is unnecessary for this particular one, but face normals need to be flipped to front to be displayed correctly. I am aware of vertex normals and face normals, just btw.


Sometimes, besides the issue of mixing models that require/not require culling, removing doubles is impossible to keep things simple, because the back faces have their own UV piece, like the inside of a jacket having a different colour than the outside. But honestly, I'm not interested in all this, as long as I know how to fix those issues visually, and as long as we don't have an option to control the use of culling, whether would that be via .xps or ngff.


Ok, now that's all I will bite on, because I don't have more energy to spare, and because I'd rather turn your attention to what is happening in 11.8.9, which I haven't noticed until now: https://streamable.com/scc3nj

I dunno how to describe it. Normal maps are lightened incorrectly at the UV seams. Model matters not.
User avatar
XNAaraL
XPS Author
Posts: 120
Joined: Fri Sep 21, 2012 9:01 am

Re:

Post by XNAaraL »

Ems wrote:So, @OP, on topic
Between the lines I read that my comment is off topic. That is correct. My contribution belongs in the section "Tutorials, which nobody want to read". So I'll be brief.
Ems wrote:2. face normals are turned away from the camera. In other words, model is made of back-faces. No doubles like in the upper case, culling is unnecessary for this particular one, but face normals need to be flipped to front to be displayed correctly. I am aware of vertex normals and face normals, just btw.
This note contains parts that are true ... and parts that are false.

Image
  • False: The face normals are NOT turned away from the camera.
  • False: face normals need NOT to be flipped
  • True: The model is made of back-faces
btw, model formats holds ONLY vertex normals. A face normal is just the interpolation of the three vertex Normals of a triangle.

In computer graphics, back-face culling determines whether a polygon of a graphical object is visible. It is a step in the graphical pipeline on the video card, that tests whether the points in the polygon appear in clockwise or counter-clockwise order when projected onto the screen.
So the vertex order of the face determine if a face is a back face (face away from the camera) or a front face.
Image
vs
Image
So:
  • True: The vertex order must be changed
In XPS:
Image
Ems wrote:1. mesh has duplicates, each set has front facing and back facing triangles. Culling renders them properly, by, well, literally culling back-faces that are not facing the camera, without it we get those "pretty" checkers, because everything is visible at once as I get it, and light is not rendered on the "back side", thus colour.

Some engines display polygons to have only one side, one is rendered opaque and the other is transparent. Putting doubles on those and flipping normals is a workaround that makes both sides visible from every angle.
This note contains parts that are true ... and parts that are false.
  • True: light is NOT rendered CORRECT on the "back side"
  • False: Everthing else
To make the shading, XNALara calculate the cosinus of the angle between the INVERTED Light direction eq shadow direction (b) and the direction of the Normal (a), using a dot product (|b| cos alpha)
Image
If the projection points to the same direction as the other vector, dot product is positive. If it has opposite direction, dot product is negative (XNALara clamp negative values to zero).
If now the shadow points to the opposite direction as the Normal vector the shading is bright. If light and Normal has the same direction the shading is dark.
Image
Image
Image
Image

So all back sides (Normals points away from the camera) has a wrong shading. To bright for back lights and to dark for front lights, since XNALara version 1.0 :ohn: But honestly, XNALara / XPS users are not interested in all this, as long as there know how to fix those issues visually :mrgreen:
Culling do NOT renders them properly. Culling do just NOT RENDER the back faces, so it does not make any sense to add (or not remove) "back faces" ;)

It is just NOT true that we don't have an option to control the use of culling, whether would that be via .xps or ngff.
We can choose between "counter clock wise" culling (Microsoft XNA framework default setting) and "clock wise" culling for every single mesh part of every single model ... and we can save it in every supported format (.xps, .mesh, .mesh.ascii, .obj and in NGFF):
Image

We can choose between "counter clock wise" culling, "clock wise" culling and "no culling" via NGFF
Image
On this way, you can have a model with some meshes rendered with "back face culling" (cm ccw) and other meshes rendered without back face culling (cm none) ... and even some meshes rendered with "front face culling" (cm cw); or changing the winding without reorder the vertices.

It is just not true that "some engines display polygons to have only one side, one is rendered opaque and the other is transparent". Every game engine that i know (and I know as software developer a lot of engines) has a option to toggle BFC on or off. Even the simple XNA framework (game engine) can do it. Otherwise XPS would not have a option BFC/AC to make it. Even if there is such a engine (lets say Unity 4), it does not matter. Back face culling is done on your video card. The small program running on you video card is called "shader". And every shader since 2001 allows to toggle backface culling on or off. It is a single line of code.
In HLSL it is "CullMode = CCW;" to toggle BFC to ON, and "CullMode = NONE;" to toggle BFC to OFF.
In OpenGL, BFC is disabled by default. It is "glDisable" to toggle it OFF and "glEnable(GL_CULL_FACE);" to toggle it ON

It is false that "putting doubles on those and flipping normals is a workaround that makes both sides visible from every angle". "flipping normals" affect only the shading. You have also change the "Winding order" (vertex order for the face).

Why should a model maker "putting doubles on those"? A simple attribute to render it "double sided" by apply an two-sided shader to it; even "double sided textured" with different UV-Sets (layer) on both sides it's enough.
I cannot believe that a professional modler will make a model with coincident faces without any needs to do it. A professional will allways Avoiding Coincident Faces ... especially if the face is transparent. You know also, nobody want to order so much semi transparent faces ;)

It is mostly a matter of a wrong tool to extract the game data. Just make a easy test. Create a sphere (in Blender) ... port it to XPS ... invoke a (Cel) outline shader ... grap it with "3D Ripper DX" ... examine the result in Blender: You have now 2 spheres. One with back faces (In other words, mesh is made of back-faces) surrounding the original sphere with front facing.

Ems wrote:Ok, now that's all I will bite on, because I don't have more energy to spare, and because I'd rather turn your attention to what is happening in 11.8.9, which I haven't noticed until now: https://streamable.com/scc3nj

I dunno how to describe it. Normal maps are lightened incorrectly at the UV seams. Model matters not.
I cannot reproduce it. I need the model and the .scene file.

BTW: If you use google and search for "Normal maps are lightened incorrectly at the UV seams", you will get a lot of hits ;)

Perhaps on the pipeline to port the model, you have used a tool which make the misstake and save the Normal map as "unsigned integer" .tga ? If so, you will allways get seams on the UV border.
Just comparing (127,127,255) versus (128,128,255) versus 0.0,0.0,1.0 ... because the middle of 0..255 is 127.5 ... and 127.5 cannot saved as integer value, you get a seam. None of this values are a "flat Normal map".
Anx had written a shader to "correct such wrong values" ... or more precice to try it. https://www.deviantart.com/xnafreak/art ... -732363486 ... try it. (- Correct "Tangent Space Normal" mapping solved )

Read more:
https://community.khronos.org/t/normal- ... tion/74245
https://paroj.github.io/gltut/apas02.html

Most developer of such extract tools do not care about the difference between a image format and a texture. Google about "color of a flat Normal map", "normal map seams problem" or "Why normal map baking break at UV seams" to understand what I means. A normal map is not as a colour map. A normal map is a texture holding 3D data (XYZ coords of the Normals), coded as fake colors.

Some porters do also use a 2D image editor to alter the Normalmaps. That cannot works too.
Lets say "Red 0" is "Normal points to left" eq "X = -1.0" and "Red 255" is "Normal points to right" eq "X = +1.0"
Lets say you you have a Normal map with 2 texel. One Normal points to left (RGB 0/0/0 eq XYZ -1.0/0.0/0.0) and the neighbor Normal points to right (RGB 255/0/0 eq XYZ 1.0/0.0/0.0)
Scale the Normal map by 1.5. So 2 pixel in the input texture are 3 pixel in the output.
With a 2D image editor, you get for the new pixel a "color interpolation". The result is:
RGB 0/0/0 127/0/0 255/0/0
or
RGB 0/0/0 128/0/0 255/0/0
(both false)
With a 3D Normal map tool, you get the right texture values
XYZ -1.0/0.0/0.0 0.0/0.0/1.0 +1.0/0.0/0.0
saved as unsigned integer image (.tga)
RGB 0/0/0 0/0/255 255/0/0
User avatar
Ems
Porter
Posts: 172
Joined: Tue May 19, 2015 11:16 pm
Custom Rank: Stashing stuff I like.

Re: Question About Hair Displaying Unusual Texture Glitches

Post by Ems »

Will files saved on the desktop directory do? So here you go: https://mega.nz/file/GAhDhYiQ#omvcZAhEM ... 4pRPyudjS0
dxdiag just in case https://mega.nz/file/rEoBHK6J#x0uTO_dqf ... G6bLwS8R08
I doubt it's the textures - .png converted by XPS from .dds ripped by Ninja Ripper, they display fine on older versions of the program. It's more like... I really don't know how to describe it, lightning ignores swizzles on the edges of the UV islands, so they don't "fit" anymore?... Lightning is not uniform around the seams?... I dunno, because describing this blows my braincells. OR especially visible anywhere there's a deep crease drawn on the map? Here's another video of a model I haven't touched in years, you can see the moment it pops in: https://streamable.com/qw0stq

Also only rotating on x or z axis displays this?

Meanwhile, older versions of the program don't have this problem.

EDIT: If that's of any help EVE is a spaceship sim, characters appear only briefly and aren't a focus, so keep that in mind they weren't made perfect. What you see is how they were constructed. For example, there's a huge mismatch at the UV edges on the back parts of the waist, but the rest is generally fine. Don't focus on that. This model serves me as a test dummy for years now.
Last edited by Ems on Mon Jun 08, 2020 11:35 pm, edited 1 time in total.
User avatar
XNAaraL
XPS Author
Posts: 120
Joined: Fri Sep 21, 2012 9:01 am

Re: Question About Hair Displaying Unusual Texture Glitches

Post by XNAaraL »

Thx
I have download the model (only) and can now repruduce your issue.
Need time to analyse it.

First findings:
Look at the B1_n.png "map". It is "somehow" wrong.
Resolution not the power of 2 (made by combine 2 Normal maps ... side by side ... using a 2D editor)
Alpha channel.
Blue channel (not yet checked)


EDIT

The Normal map is kind of strange:
Image

That is the map of your port ofFF7R_Cloud_Strife (armor):
Image

To test it, the Normal map is loaded in the "diffuse" slot and the Render Group is a "shadless glow shader" (RG# 10)

And yes, it looks like XPS has also a BUG for the bump mapping. It calculate the binormal direction flag (W value of the Tangent) for the vertices wrong.


2nd EDIT

Sendspace link updated with 3rt patch (coredesign link soon)

Binormals (tangent.W / TangentV / Y axis / green) works now also for inverted mesh face flow over the UV map.

Old
Image

New
Image

The tangent and binormal are representing the direction of flow of the UVs. The tangent is the U of the UV, which for both OpenGL and DirectX is left to right (0.0 on the left, 1.0 on the right). The binormal (tangent.W flag) is the V of the UV, which is different in OpenGL and DirectX. OpenGL is bottom to top, and DirectX is top to bottom. This is also where the difference in many engine's and 3d tools' preference for "+Y / -Y" normal maps comes from. OpenGL standard is +Y, and XNA, XNALara, XPS or Unreal is -Y, which is the DirectX standard. Obviously XnaPosingStudio is using DirectX on Windows, so most of the time the tangent.w component is going to be negative (top to bottom). However what if the texture UVs are inverted, not because the mesh scale is inverted, but because the mesh's UVs themselves are going the opposite direction life if the textures are mirrored, then it also needs the w inverted for the half that's mirrored.
That is now fixed in XPS 11.8.9 3rd patch.

DirectX (XPS)
Image

OpenGL
Image

Shader-->Display Tangent space
Red (tangentU eq Tangent eq U) is +x direction
Green / yellow (tangentV eq Binormal eq V) is +y direction
blue (Normal) is +z direction
Post Reply