Degenerate index buffer and vertex buffer issue

Hi, I've just seen a couple of warnings in the log that I haven't noticed before. Yet they could there, I'm now trying to figure out why FPS on my mobile RTX2060 drops below 10 no matter of resolution (from 1920x1080 to 2560x1080), and watching the logs, I run to these, about spline objects of mine:


? <kuid2:933064:350000:1> : MeshResource::LoadResource> <kuid2:933064:350000:1> | arc:fld:$(local)/hash-98||kuid2 933064 350000 1.tzarc|
? <NULL> : Loading mesh t01s-plain-st02-cgr-gr-block-v1-lod0n.trainzmesh
! <kuid2:933064:350000:1> : Index buffer contains degenerate triangles
! <kuid2:933064:350000:1> : Vertex buffer contains NaN elements (normal)


I guess I've seen the vertex buffer thingy some time ago, but could not recall what it actually meant, and the other about the degenerate tris is brand new to me. If anyone experienced it and has a tip or guess, please share it with me.

Probably it's nothing to do with FPS, but I wonder what this is and whether I can fix it or not.

Hi, if I remember correctly degenerate triangles means the asset isn't UV unwrapped properly and that vertex points are occupying the same space. If you have the source file check for vertex points at 0,0 to begin with.

John

That very well could be the case, what's more, an intentional decision. This is a set of fences, parts of which share the same regions in the UV map to give it more variations -- one version of wooden fence face is laid over on another, but a bit shifted to one direction, another piece is turned upside down, so that I can have differently looking wood patterns using just percents of extra UV space. Do you think it may cause any issues other than generating log entries when logging is on?

Hi Gusztavj,

You can have multiple vertex sharing the same space that's ok. The error refers to the vertex points of a face, example a square will have 4 vertex points, but if it isn't unwrapped properly then those 4 vertex points may occupy the same space and therefore triangles cannot be drawn.

In Trainz 22 (and I think 19) this will fail the validation in Content Manager.

If you are using an earlier version on Trainz it maybe that the problem isn't caught by CM and therefore it may impact performance, but I'm guessing.

John

A rather large mesh library.
Not failed validation as such in TRS22 Beta and no mention of vertex or index errors however it's listing as warnings all the meshes as not used, 2172 of them! Need to include the actual meshes in the mesh table in the config now.

See <kuid2:124060:60090:1> as an example, first mesh library I came across.

Not sure having that many meshes in a library is actually a good idea but I stand to be corrected!

I think degenerate triangles are primarily a mesh geometry problem, not a UV mapping problem. The vertices do not need to be coincident - a triangle in which the 3 vertices are separate, but in a straight line, is also degenerate. I’ve heard it expressed as the “zero area triangle” problem. This is why welding of coincident vertices does not always eliminate degeneracy.

gusztavj said:

...
! <kuid2:933064:350000:1> : Index buffer contains degenerate triangles
! <kuid2:933064:350000:1> : Vertex buffer contains NaN elements (normal)
...

Click to expand...

My current guess is that the first problem is a malformed triangle much as Johnarran described. These, I believe, were picked up by the old Blender XML exporter as "faceless faces". In other words a face that cannot be rendered. I've been trying to make an addon that might detect that but without any success so far.

The second issue is more obscure. NaN is "not a number" and perhaps means a number that isn't realistic. My guess is that it is a normal vector (direction) with an improbable value.

I doubt if this is your FPS problem though. In the first case I imagine Trainz wouldn't bother trying to render the triangles, and in the second, it probably substitutes a default vector. The FPS problem might be related to assets using scripts with obsolete function calls.

My best guess at present.

It's a mesh library not an asset though and has 2172 meshes......... that might not help FPS?

clam1952 said:

It's a mesh library not an asset though and has 2172 meshes......... that might not help FPS?

Click to expand...

The WiKi doesn't say anything about mesh limits and I assume Trainz would only load the referenced mesh files and their textures rather than the entire library. Gus has used just a few (PBR) textures for a lot of meshes. I thought the theory was that this approach was supposed to make Trainz more efficient.

Thanks for all the valuable answers, guesses and ideas, guys! Yepp, Paul is right, Trainz only loads the meshes from a lib when referenced by a visible asset, and having this many in a lib only causes some delay during import. Probably when it needs to first load a mesh from a directory of 500 files is somewhat lower than from a smaller dir, but I hope it's not remarkable delay and stuff gets cached over time.

As per the face issue, I'll check them. This stuff was one of the first of mine when I had almost zero experience, so it could happen that somehow I made faceless faces, probably when decimating for lods. I think there's a little chance that fixing the vertex issue will solve the other, too, probably no matter what's in the normal map at the problematic point if the face cannot be rendered: the normal values will probably be wrong whatever they are.