Advanced trouble shooting converting Collada files to Open 3D
As seen in the previous section of the O3D tutorial, the process of converting Collada files into the Open 3D format is usually straight forward. There are however a few caveats that tend to be effected by the 3D application being used. They all however tend to follow or need the same set-up and or prepping process in order for the conversion to work properly.
IMPORTANT NOTE: Using Googles dae2o3d converter requires the DirectX SDK be installed, which can be downloaded from Microsoft here.
Unable to Import ^
The most common error when working with the O3D conversion process is "failed to import", which is normally associated with the converter not being able to find what it's looking for - very rarely is that error due to the mesh or model being 'broken' or 'corrupted' in some way (which would also usually prevent it being viewed in any 3D application).
Check your file paths ^
Make sure all the assets to be used are in 'sensible' locations - if you're able to, store all the assets in the same folder. Additionally, make sure that the assets are using 'relative' and not 'absolute' paths. That means if you had a car in the following location;
And the textures in another;
Instead of doing the following when you load a texture assets into a material slot in your 3D app;
They have to be referenced in such a way that when exported to DAE files, the process sees the path associated with the texture as something similar to the following;
This is because the files are being looked at 'relative' to the folder the assets are sitting in (as if they were being looked at from the point of view of the folder itself), as opposed to the 'absolute' path based on the hard-drive (as if the asset was looking at itself from outside the folder, looking in). This is essential to make sure game engines don't misinterpret asset locations when deployed by looking along, or for, a path that doesn't physically exist.
Upper & lower-case file paths ^
Check your file paths. Make sure paths match in both the DAE file (it can be opened and edited in Notepad, Crimson Editor or similar) and your computers file system. This;
Is not the same as this;
Also check to make sure your forward or backward slashes are being addressed the same way. Again, this;
Is not the same as this;
The former generally refers to the actual file path of the asset in question, the latter is usually just a 'reference' or 'tag' used to pull that particular shader, material or assets onto a model when run in game.
It's also good practice to make sure that any file paths used only contain lower-case characters, as is generally the rule for game development and content creation.
Change BAT file location ^
If changing or checking the files paths still yields no results, try moving the *.bat file used to initialise the conversion process to the same folder as o3dConverter.exe, this may mean changing the command line instructions slightly to compensate for the move. For example if the bat file originally read as follows;
D:\GAMES\o3D_converter\o3dConverter.exe --base-path=F:\Models\o3d F:\Models\o3d\testmodel.dae
It may need changing to the following upon being placed in the same folder as the converter exe;
o3dConverter.exe --base-path=F:\Models\o3d F:\Models\o3d\testmodel.dae
Using *.fx shader files ^
FX or *.fx files are in effect special DirectX (Direct3D) material shaders that make direct use of a graphics card processing unit. As such, their usability is subject to the hardware's ability to process the shader instructions present in the *.fax file. With regards to Open 3D production, the same caveat as present as it is with any and all 3D production, namely making sure the hardware being used supports what you're trying to do.
With that said, when trouble-shooting *.o3d models that have *.fx shaders applied to them as part of a material the first thing to try is to remove the references and in effect export a 'flat' mesh. If that open into your O3D project then you know something is wrong with set up somewhere between the FX shaders and most likely the Collada file. It should then be a simple (but long-winded if there are a lot of FX files in use) process of elimination to find out where the problem is, loading and exporting one FX shader at a time.
3DS Max specific issues with O3D files ^
Aside from the issues mentioned above, there are a couple of additional caveats specific to using 3DS Max as a production tool for making Open 3D content.
Open 3D supports 'standard' 3DS Max material slots, i.e. "Diffuse", "Specular", "normal map" and so on, just be sure to check you don't export unnecessary slots - which may cause issues. If unsure about which slots can be used export the standard 'diffuse' slot to Collada and keep adding slots to see which work and which don't within the context of your project.
The Collada exporter for Max also supports 'Tangent' and 'Binormal' exported material settings, just be sure to have 'checked' the appropriate export option in the Collada dialogue when exporting the objects.
Make sure to download and use the Collada exporter appropriate to the version of Max being used. In addition to this, there may also be issues present when exporting to or using the "Autodesk DAE" export option instead of "Collada DAE" - as would be the case if you had more than one export script installed; there is a difference between the two that may be the source of some issues.
What you should end up with after processing a collection of assets is a special *.TGZ archive file, it's special only in that its named "o3dtgz", but for all intents and purpose its simply just an 'archive' container (a 'zip' or 'tga'). This means that what's being converted by the process are the raw assets, the *.dae model, *.dds or *.tga texture images, and any other material or shader settings files; you do not need to pack any assets up before hand into any form of archive as the converter itself does that.