KhronosGroup / KhronosGroup/UnityGLTF
Vertex reordering after import
- Dominant language
- C#
- Stars
- 2.2k
- Forks
- 536
- PR merge metrics
- No merged PRs in 30d
Description
### Describe the bug 💬
### How to **disable** vertex re-ordering on import?
similar to on fbx import settings:
### Why?
I tried to bake additional vertices information (for a cloth simulation, a float weight 0 - 1 ) inside another uv-map (channel 2) for my model.
I exported out of blender for unity. Once as .fbx and once as .glb
When I imported my model and ran my script to extract the value per vertex, both models were simulating wrong.
```
using UnityEngine;
[RequireComponent(typeof(Cloth))]
[RequireComponent(typeof(SkinnedMeshRenderer))]
public class CreateClothFromUVData : MonoBehaviour
{
public float maxDistDynamic = 0.1f;
public void Start()
{
var cloth = GetComponent();
var smr = GetComponent();
var mesh = smr.sharedMesh;
if (!mesh.isReadable)
{
Debug.LogError("Mesh is not readable.");
return;
}
Vector3[] renderVertices = mesh.vertices;
Vector2[] uv3 = mesh.uv3;
ClothSkinningCoefficient[] coefficients = cloth.coefficients;
if (uv3.Length == 0)
{
uv3 = mesh.uv2;
}
if (uv3 == null || uv3.Length != renderVertices.Length)
{
Debug.LogError("UV3 channel missing or length mismatch with vertices.");
return;
}
for (int i = 0; i < coefficients.Length; i++)
{
float weight = uv3[i].x;
coefficients[i].maxDistance = maxDistDynamic * weight;
}
cloth.coefficients = coefficients;
}
}
```
I took a deeper look and saw, that unity (or the import plugins) reordered the vertices (for better performance I guess) on import.
But then my custom created uv channel did not correctly map to vertex indices anymore (textures do btw, I don't know why my channels did not get remapped like normal map too..)
So I disabled "Vertex Order" on fbx import settings and it behaved correctly for the fbx model.
UnityGLTF _is missing this option_, so it still behaves wrong.
### Fixes:
Is there any chance you will add this Option? - Or at least:
Could anyone show me the spot to where to patch it or how to get the right post-import index-mapping-dictionary - or something else?
I took a look inside the source but could not find the script where it reorders the vertices.
Thanks in advance!
### Steps to reproduce 🔢
0. Create a new Unity 6.0 Project, Install UnityGLTF and DracoMesh Compression as package:
```
{
"dependencies": {
...
"com.unity.cloud.draco": "5.1.8",
"org.khronos.unitygltf": "https://github.com/KhronosGroup/UnityGLTF.git"
...
}
}
```
1. Download the unity package: [unitygltfissue.zip](https://github.com/user-attachments/files/22465981/unitygltfissue.zip)
2. Import the Package
3. Open Scene, see for yourself
Optionally you can import the meshes (.glb/.fbx) yourself
### Files to reproduce the issue ♻
_No response_
### Editor Version 🎲
6000.0
### Render Pipeline and version
URP/HDR/SRP
### UnityGLTF Version
2.17
### Operating System 👩💻
Windows
### When does this problem happen?
- [x] Editor Import
- [x] Runtime Import
- [ ] Editor Export
- [ ] Runtime Export
### Additional Info 📜
_No response_
### Validations 🩹
- [x] I have [searched existing issues](https://github.com/KhronosGroup/UnityGLTF/issues): no issue already exist that reports the same problem.
- [x] I follow the [Code of Conduct](https://www.khronos.org/about/code-of-conduct)
- [x] I provided a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example), including files when necessary.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by importing the attached unitygltfissue.zip in the stated Unity 6.0 environment and compare the FBX and GLB mesh vertex data during editor and runtime import. Trace the UnityGLTF mesh import path to find where vertex reordering occurs; done means the importer exposes an equivalent setting or preserves the custom UV-to-vertex mapping, with the reproduction scene behaving correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, unity
- Domain
- game-dev
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100