Clarification on Endianness Used in Ogre3D Mesh Files

[vincentdoan86]

I hope this message finds you well. I'm currently working on parsing Ogre3D mesh files and have encountered an issue that I believe may be related to endianness. Additionally, I would appreciate guidance as I navigate this process using C#.

Issue Description:

While reading a .mesh file, I noticed that the chunkSize value extracted from the file exceeds the total file length, resulting in validation errors. Here's a snippet of the hexadecimal data around the problematic area:

Code: Select all

00 10 5B 4D 65 73 68 53 65 72 69 61 6C 69 7A 65 72 5F 76 31 2E 34 30 5D 0A 00 30 F6 0D 00 00 00 00 40 88 04 00 00 42 61 73 65 57 68 69 74 65 0A...

Chunk ID: 0x3000
Chunk Size: 0x00000DF6 (Little Endian) = 3,574 bytes
Total File Length: 3,556 bytes
This discrepancy suggests that either the chunkSize is being read incorrectly or there's an underlying issue with how the file is structured.

Steps Taken So Far:

Endianness Check:

Interpreted the chunk size as Little Endian (0x00000DF6 = 3,574) and Big Endian (0xF60D0000 = 4,060,647,680).
The Little Endian interpretation seems more plausible, but chunkSize still exceeds the total file length.
Header Analysis:

The file starts with [MeshSerializer_v1.40]\n followed by the chunk header:

Code: Select all

00 30 F6 0D 00 00

Header ID: 0x3000
Chunk Size: 3,574 bytes
Code Adjustments:

The chunkSize immediately after the header is F6 0D 00 00, which translates to 0x00000DF6 (3,574 bytes) in Little Endian.
The total file length is reported as 3,556 bytes, which is less than the chunkSize.

Modified the condition to check if chunkSize exceeds the remaining bytes in the file.
Ensured that the chunk size is read correctly based on Little Endian format.
Despite these adjustments, the issue persists, indicating that chunkSize might be incorrectly defined or there's potential file corruption.

I do not have a background in C++ and am attempting to develop a software tool to convert Ogre3D mesh files to XML using C# in a WPF application. My lack of experience with C++ has limited my ability to troubleshoot deeper into Ogre3D's internal implementations.

Does Ogre3D use Little Endian or Big Endian byte ordering for its .mesh files? Understanding this is crucial for correctly parsing the chunk sizes and other multi-byte values in my C# application.

Is the chunkSize field in Ogre3D .mesh files inclusive of the chunk header bytes (ID + Size), or does it represent only the size of the data within the chunk? Clarifying this will help in accurately calculating data offsets in my converter.

Is it common for Ogre3D mesh files to have discrepancies between chunkSize and total file length? Could this indicate file corruption, or might there be another underlying issue?
Are there any best practices or recommended methods for parsing Ogre3D .mesh files using C# to avoid such issues? Any sample code, libraries, or references would be highly appreciated.

Your assistance in resolving this issue would be immensely valuable. Looking forward to your insights and suggestions.

Best regards,

[rpgplayerrobin]

You should take a look here:
https://github.com/ehsan/ogre/blob/mast ... alizer.cpp
It seems the endianness is checked and loaded with the endianness of the mesh file itself.
That is shown in the first line in the importMesh function there, but if I were you I would also go through all the steps in that code to be able to see how it actually loads something, and check how it loads it specifically from the mesh version that you are using (1.40).

Other than that:

1. Where did you get the mesh from? Does it happen for more meshes, and in that case where did you get them from?
2. Does this happen for meshes that you export yourself using the same mesh version (1.40)?

If meshes your export yourself is easier for you to import, while the meshes you have gained from somewhere else is still impossible to import, it probably means that the meshes that you gained from somewhere else are using a custom import/export function adjusted from Ogres version, which makes it very hard to know how to actually import it.