no probs, it’s code I had knocking around and was creating a modifier for artists to check how their model will be in game when exported, the vert counts can get unexpectedly high with mesh “splits” from normals, vertex colour, vertex alpha, 4 uv channels, vert data etc… I’m sure there is more efficient code if you are just handling extra verts just for normals. If you ever need to generate tangent vectorsthis is very useful and works really well on the optimized verts and indices from my routines (better than the igame when you have uv seams)
other useful stuff in the sdk is their implementation of autoptr which in this case could be used like this…
MaxSDK::ArrayAutoPtr<vertex> rawverts = CollectRawVerts(*mesh, rawcount);
if(rawverts.IsNull())
return;
MaxSDK::ArrayAutoPtr<vertex> optverts = CreateOptimizeVertexList(rawverts.Get(), rawcount, optcount);
if(optverts.IsNull())
return ; // forces previous mem alloc to be released
MaxSDK::ArrayAutoPtr<unsigned int> indices = CreateOptimizeFaceIndices(rawverts.Get(), rawcount, optverts.Get(), optcount);
if(indices.IsNull())
return; // forces previous mem alloc to be released
then in my case is access the pointer like so…
BuildMesh(tobj->GetMesh(),optverts.Get(),optcount,indices.Get(),mesh->numFaces);
it seems like extra coding but it doesn’t require any memory clean up as it’s handle automatically once the autoptr goes out of scope, which is very useful if at any stage an error is thrown (memory allocation fail for example) and the stack is unwound (forcing our autoptr to release it’s memory).