Hi, I'm working on a custom 3D file format for my engine, and I've run into some troubles exporting a model as .3ds format. In 3DS Max I convert my model to editable mesh, then export as a .3ds file, but if I import it back into 3DS Max the number of vertices always increases. I tried a simple cube, exported it, imported it, and it had 26 vertices! Some boxes have 26, others have 32, what's going on? The face count always remains correct, and the model itself always looks fine, but it's causing issues when I convert the .3ds file to my own format. I took a look here: http://boutin.info/2007/09/01/your-vertex-count-isnt-the-same-in-3ds-max-and-in-virtools-is-virtools-buggy/ This guy explains a similar problem, but reports cubes as having 24 vertices, and his 'fix' doesn't work for me.

Modelling tools have different needs than games in the storage of their geometry. They need to store it for efficient frequent manipulation. A cube may be stored with any number of vertices in order to allow for different materials, sharp texturing edges, deformations, et cetera.

You need to compensate by ensuring the geometry is in a certain state prior or export (for example, welding vertices) or having your exporter do this, or devise a way to cope with the variety of data.

well, 24 is 6 sides times 4 points each, it's then counting quads as if the vertices are unwelded, which may be normal. 32 is the same thing but a step further, triangles contain crease data more correctly so it is 2 * 6 * 3 even if it looks like quads. I don't know how to fix it though.

This is strange.

I wrote the file format over a year ago, and I swear everything was perfect.

Actually, while writing this, I've just remembered I was using Blender... hmm.

I'll try with Blender's 3DS exporter. But I still need a solution for MAX. Any ideas, anyone?

you could load the .3ds in blender and export to see if it works, especially since ur code works with blender.

Nope, that vertex count is actually correct.

In MAX, a vertex is actually a 'collection' of verticies that share the same location. Internally, however, some verticies have different normals or mapping coordinates. While they still share the same position, and should be moved about as one unit, there are actually several separate verticies there.

Best way to think about it is that each vertex has a position, normal and texture coordinate. If you make a cube, it's safe to say that each face will have a different normal, meaning 3 normals per vertex, but we can only really specific one normal per vertex. So instead there are 3 verticies at the same position, just with different normals. MAX simplifies this when it shows it to the user, but grouping together the 3 verticies to look like one.

Wow, this is harder to explain that I thought. Does that make any sense?

Anyway, you can expect a bit of vertex bloat when exporting meshes from most graphics packages (Although you've gotta be careful that you don't get unnecessary duplicates in there, too. A vertex with the exact same position, normals and UVs shouldn't be duplicated).

Just did some tests and it seems to be related to some UVW Coordinates weirdness (haven't tested it yet, but it seems it breaks the mesh based on UV seams). When max asks you if you want to export texture uv`s, choose no. Reimport the cube and you'll see the correct number of vertices.

You might want to try the obj format instead (here is a better obj exporter/importer than max's http://www.guruware.at/); if you wish to export more than just meshes, then I'd recommend fbx (very reliable, but I guess a bit too complicated)

See the "Understanding Texture Coordinates and Vertex Colors" in the maxScript help docs.