You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MeshHandler returns raw integers for UNorm and SNorm vertex channels #387
MeshHandler.read_vertex_data unpacks every vertex channel with the struct code of its VertexFormat and stores the values as they are. For the normalized formats (UNorm8, SNorm8, UNorm16, SNorm16) that leaves the integer representation: a color stored as UNorm8 comes back as (255, 128, 0, 255) instead of (1.0, 0.502, 0.0, 1.0), and UVs stored as UNorm16 come back as 65535 and 32768, which the OBJ exporter writes as vt 65535 32768. The Python path and UnityPyBoost return the same values.
The other sources of the same attributes are normalized: compressed meshes divide packed colors by 255, and so does copy_from_mesh for m_Colors of older meshes. So m_Colors holds floats in [0, 1] or integers in [0, 255] depending on how the mesh was stored. Unity's VertexAttributeFormat describes these formats as normalized values in [0, 1] and [-1, 1], and AssetStudio's BytesToFloatArray converts them with / 255, / 65535, max(v / 127, -1) and max(v / 32767, -1).
Converting these channels to floats in read_vertex_data (or in assign_channel_vertex_data) would make all paths agree. It changes the values callers currently get for vertex colors stored as UNorm8, which is the common color format, so I am asking first: should normalized channels be returned as floats? If so, I can send a PR covering the four formats on both the Python and the UnityPyBoost path.
Tested with UnityPy 417d595 (1.25.4) and CPython 3.11.13 on Windows x86_64.
Activity