Quite a few of you have downloaded my Max 9 SMD exporter now and thanks to everyone who did and helped by reporting bugs and giving feedback – it was a great help indeed. Two subjects I’ve recieved a lot of feeback on are “Are you going to convert your exporter for other Max versions?” and “Are you going to make and SMD importer too?”.
I figured I’d answer both of these question in detail as some of the more technically inclined users might find the information interesting…
To answer the first question, when I feel the exporter is as refined as possible and I take it out of beta then yes, I may compile it for Max 8 as well. The only difficulty is if the 3DXI interface in the Max 8 API is missing features that Max 9 has. I don’t think I used any exotic commands when I wrote it so it should just be a case of a straight re-compile in Visual Studio 2003.
Of course the question comes up, “why bother?”, after all Cannonfodder’s exporter works perfectly well. True, but as CF seems to of quit the modding scene (hearsay states that he had quit to due to Valve’s engine updates always breaking his apps) it leaves the issue of his being un-supported. I figure as long as I’m alive, I’ll continue to maintain my code. It also guarantees consistency across tools if the same plug-in is available for several platforms.
Regarding an importer, it is something I want to do, but it’s incredibly more time consuming than the exporter was. Sadly time is something I’m constantly short of with all the projects I’m working on. I barely have time to do them all and eat, sleep and have rewarding social contact with the rest of the planet!
One of the big hurdles to writing an importer is in fact the SMD format itself – it just plane sucks. Seriously, it’s a throwback to Half-Life 1, heck it might even of been used in Quake it’s that bad. Valve seriously need to ditch it and use Collada DAE format or work some more with the mystery MRM format that the compiler appears to support.
The main problem with SMD format is the way it exports the mesh – everything is defined as individual triangles using vertex normals. This means massive vertex duplication and no easy way to recreate surface smoothing groups.
In just about every sane 3D file format (and internally in most 3D applications) you define where a vertex is in space and give it a unique ID number, then for each face in your model you simple state the three ID numbers of the vertices that are connected to make it. This is good because it allows you to share a vertex between multiple faces and easily generate a seamless flowing surface. However, SMD format complicates this by not using vertex lists and ID number but instead listing the vertex co-ordinates for the three points in the triangle. What this means is that effectively each triangle is unique and isn’t joined to any other.
This is what causes problems with and importer – to create a continuous welded surface you need to load in every triangle, analyse all the vertices for them, figure out if the vertices it uses are in fact unique or are shared with another. If it it does share a vertex with a neighbor, use that one instead. It’s a major fugging pain…
Ironically, when you compile a model StudioMDL actually does this – it makes all the vertices unique so that it can better make strips and fans which begs the question, why break your 3D model apart only to glue it all back together in the compiler? SMD really is clumsy and Valve would be wise to ditch it for something better as far as I’m concerned.
So that’s some of the issues I’m facing but I hope to be able to over come them eventually. In the mean time you’ll just to hang on while I figure it all out.
Responses to “Of SMD Importers/Exporters…”
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.