Loading a .x file with the d3dxof functions is not trivial. Essentially, the file has several sections that have data structured according to "templates" identified by GUIDs. The loader would enumerate through all sections and parse sections of interest (such as vertex data section) according to the template type.
The default template types are documented in the SDK. The most important ones for this case (loading static geometry) have names starting with Mesh*. The individual templates tend to be simple but can form potentially complex hierarchies. Add to that, .x files can be either binary, text or compressed text. And that for robust file handling, you have to understand custom templates too.
Because of this complexity, most real-world developers either:
1: use D3DX Mesh for prototyping or simple demo/poc or
2: write their own custom (often simpler than .x) mesh format and corresponding container + serializer to gain flexibility and precisely solve their needs or
3: use a simpler public format to begin with, and write a custom loader.
I used to write an (incomplete) "raw" .x loader some ten years ago just for fun, but I believe that it has been eaten by the sands of time (or something). Writing a new one would require considerable amount of effort, and would not be very useful to most people anyway.
Show differencesHistory of post edits
#1Nik02
Posted 02 April 2012 - 05:44 AM
Loading a .x file with the d3dxof functions is not trivial. Essentially, the file has several sections that have data structured according to "templates" identified by GUIDs. The loader would enumerate through all sections and parse sections of interest (such as vertex data section) according to the template type.
The default template types are documented in the SDK. The most important ones for this case (loading static geometry) have names starting with Mesh*. The individual templates tend to be simple but can form potentially complex hierarchies. Add to that, .x files can be either binary, text or compressed text. And that for robust file handling, you have to understand custom templates too.
Because of this complexity, most real-world developers either:
1: use D3DX Mesh for prototyping or simple demo/poc or
2: write their own custom (often simpler than .x) mesh format and corresponding container + serializer to gain flexibility and precisely solve their needs.
I used to write an (incomplete) "raw" .x loader some ten years ago just for fun, but I believe that it has been eaten by the sands of time (or something). Writing a new one would require considerable amount of effort, and would not be very useful to most people anyway.
The default template types are documented in the SDK. The most important ones for this case (loading static geometry) have names starting with Mesh*. The individual templates tend to be simple but can form potentially complex hierarchies. Add to that, .x files can be either binary, text or compressed text. And that for robust file handling, you have to understand custom templates too.
Because of this complexity, most real-world developers either:
1: use D3DX Mesh for prototyping or simple demo/poc or
2: write their own custom (often simpler than .x) mesh format and corresponding container + serializer to gain flexibility and precisely solve their needs.
I used to write an (incomplete) "raw" .x loader some ten years ago just for fun, but I believe that it has been eaten by the sands of time (or something). Writing a new one would require considerable amount of effort, and would not be very useful to most people anyway.