Should gltfpack or meshoptimizer be used before or after generating normals and tangents?

[GasimGasimzada]

I have a GLTF importer that converst GLTF scenes into my engine's internal format. GLTF files do not have strict restrictions on whether a mesh has indices, normals, tangents, or even uv coordinates. The only requirement is that they have positions. So, within my engine, instead of handling all these cases at "runtime", I want to manage them at a single point -- the import.

I want to do the following operations:

• If a mesh does not have indices, generate them -- meshoptimizer
• If a mesh does not have normals, generate normals -- custom implementation
• If a mesh does not have tangents, generate tangents -- mikktspace (depends on normals)
• Vertex cache optimization -- gltfpack
• Overdraw optimization -- gltfpack
• Vertex fetch optimization -- gltfpack

As I am new to these optimizations and mesh generation algorithms in general, I would like to ask in what order should the normal be generated -- after mesh optimizations or before? What if I add quantization to the mix as well -- should it happen before or after normals are generated?

[zeux]

Normally you'd give gltfpack and/or meshoptimizer a fully ready-to-render mesh - so in this case, after you use mikktspace et al to generate TBN data.

[GasimGasimzada]

One additional question regarding this process. If a mesh is not indexed, will meshopt_remapVertex/IndexBuffer generate a new vertex buffer with shared vertices replaced by indices. Or will it just add indices based on the index of a vertex in the vertex buffer? Let's say that there is an indexed quad that is defined like this:

v0, v1, v2
v1, v2, v3

Will calling the vertex remapper the mesh to:

v0, v1, v2, v3

i0, i1, i2
i1, i2, i3

Or something like this:

v0, v1, v2
v1, v2, v3

i0, i1, i2
i3, i4, i5

Note that in this case we only have an unindexed vertex buffer; the remap table is generated based on binary equivalence of the input vertices, so the resulting mesh will render the same way. Binary equivalence considers all input bytes, including padding which should be zero-initialized if the vertex structure has gaps.

Does this mean that vertex data won't be modified at all?

What if I have a vertex/index data like this:

v0, v1, v2
v1, v2, v3

i0, i1, i2
i3, i4, i5

Will the meshopt_remapVertex/IndexBuffer reindex vertex buffer and index buffer to be more optimized.

Since I want optimizer to be the last step of my import "pipeline," I want to fake generate indices, then let the optimizer reindex my vertices in an optimized way.

[zeux]

If a mesh is not indexed, will meshopt_remapVertex/IndexBuffer generate a new vertex buffer with shared vertices replaced by indices

For unindexed meshes, meshopt_generateVertexRemap will generate a remap where shared vertices get replaced by indices, and meshopt_remap* functions will apply that to vertex/index data. So vertex data will be modified.