Well, I had a guy originally try to prepare/export it and it took him 3 or so hours to give up. But I couldn't open his max file because he's using 2011 and I'm using 2009, so he sent me an FBX which I then imported and made a quick default sc2 material for. However, my max starts new scenes with a bunch of random design materials. Obviously these are not applied to the model, but if the exporter sorts through them when it wants to export, it could explain why it takes forever.
Winamp froze windows again (don't ask, it's a weird bug) and I had to force a restart. At 13 hours elapsed the export had still not finished but definitely hadn't locked, it was still regularly fluctuating in CPU usage. Something really weird is going on. There's no way it should take that long, the scene was like 160k poly vs the Jugg's 100k poly with only 1 diffuse texture being used vs the Jugg's 7-8 mass of huge, fully configged textures.
I had a bit of a look over the code and it appears that it only looks at materials that are applied to the objects you are exporting. Everything else should just be ignored as far as I can see. However not being the original author, I could have missed something and may be incorrect in saying that.
Maxscript is generally speaking a very slow language in terms of how long it takes to process things. Physical scale wouldn't have any real affect on the export. I suspect the reason its taking so long and possibly crashing is simply because of the number of tris involved. The script needs to essentially read out every single polygon / vertex / material id etc etc and then work out how that fits into the new file format. The more information you try to feed it, the longer it will take.
There is only so much optimization that can be done to maxscript to handle models like you are trying to. It eventually gets to the point where using a maxscript is not really economic and the only way to get it to process things in a reasonable time is to make it a C plugin for max, essentially rewriting it all. Using a C plugin instead gets past most of the bottlenecks of maxscript and allows for much better processing of larger models.
Also a bit of a disclaimer, I'm not the best coder, so if someone with better knowledge says otherwise, listen to them :-p
Sorry guys, pretty busy here so I haven't had time to reply. Riaction is absolutely correct on all points, maxscript has some serious performance issues. Creating a C plugin would circumvent the problems, or even just creating C functions for the script bottlenecks, but that would then force the script to only work on one version of 3ds Max as I'd only have access to one SDK version for compiling. So, while I love the maxscript language, the processing times disappoint me immensely and I'm left scratching my head on what to do about it.
A couple of things to note about process times:
Materials are only processed if they're used by a mesh. In general materials aren't a great deal of processing time and I wouldn't worry about them.
Tris, or really vertices, are your biggest enemy, with texture vertices and smoothing groups (vertex normals) causing the greatest amount of processing time.
Animations are the second biggest enemy, taking up the second greatest amount of processing time.
Now for the internal mechanics:
Vertices are the biggest bottleneck in the script for multiple reasons. Firstly, M3's use one uv coordinate (generally) and one normal per vertex. This is a huge huge problem in 3ds Max, as 3ds Max has different systems for handling each of these. The mesh faces are always the same, but the vertex normal used by each face and the texture vertex used can be very different. Additionally, with smoothing groups, multiple vertex normals are required if you want to make a hard edge.
Now since M3's can't have multiple vertex normals per vertex, you must generate new vertices that are at the some location but that have the different normals and have them used by each adjoining face of the hard edge. Ontop of this, texture vertices don't line up one to one with mesh vertices (there's a good reason for this too detailed to explain here) and this means some extra M3 vertices need to be generated to handle these extra texture vertices.
I think you can start to appreciate the complexity of exporting a single textured mesh with applied smoothing groups. Not only was it difficult for me to code but it means there's an intense amount of processing overhead required on the part of maxscript to scan through all the mesh vertices, the texture vertices and work out the proper vertex normals and if extra vertices need to be generated. I would love a more elegant solution to the problem, but when it comes to 3ds Max there isn't one that I could find and believe me I looked just about everywhere. The tragedy is that in the C environment, this kind of processing would be lightning quick, it's just that it's occuring in the maxscript language that the bottlenecks occur. Infact if I could handle three or four functions outside of maxscript in CPP instead the whole script processing time would be reduced to a few seconds where it might normally take thirty.
I'm really busy at the moment which is preventing me from updating the script. We have pretty much figured out the particle structure and so adding particle support should be relatively easy for the next update. Thanks for the patience and I understand your dissatisfaction IskatuMesk, I wish I could make the script more efficient in some way and I'm constantly trying to figure out ways to make it a little bit faster. The problem will always be the sluggish nature of maxscript. Perhaps when the Blender exporter plugin is encoded in python, processing times will be much better and it will be a better medium for exporting to M3.
Gathering scene objects...
Gathering used materials...
Unknown property: "materialType" in 09 - Default:Standard**
Any ideas how to resolve this? I changed the 09 - Material to a starcraft 2 material and even copied over an existing/working material into that slot and I still get the error and am unable to export my model w/ it's new animations. Thanks for any help in advance!
I don't blame you at all, I was just wondering if there was something left that might have been able to squeeze out a bit of performance. I appreciate the work you've done, all this means is that I'll need to cut apart the geometry mesh and export it in pieces, probably overnight each. It isn't a huge problem because it isn't an animated mesh; once I have it looking the way I want I will probably never need to export it again.
I'm curious though, can you explain the enormous time differences between exports? When I did my initial two exports of the Juggernaut, they were around 3 hours a piece. Exports after those were 11-16 minutes a piece. Is it because of the materials, if you change the mesh's materials or textures that screws with the render times?
Honestly if the Blender plugin can squeeze out faster export times I think it will be the only time I ever consider using blender for anything, which would be exporting these huge static meshes :P
Ok, I have another issue and this time I have no clue what I'm doing really. I'm trying to create a model w/ several variations, each one having slightly different geometry but similar animations. I tried to create an attachment helper from the sc2 objects and then attach that to the geometry I want to use as an attachment. I'm not exactly sure how I should be doing this, much less setting it up in the galaxy editor to support those variations. Any ideas on this one? Worst case scenario I create 10 different models, but I figured that this would probably end up requiring the user to use up a ton of unnecessary memory when running my map. So I'd like to avoid that route if at all possible.
One more thing. I think you are probably already aware of this, but smoothing groups don't seem to play very nice with multi-object materials. I have a large number of animated models dependent on multi-object materials for their textures, but the smoothing groups don't seem to apply to them. Currently the only way I can think of getting around this is unifying the textures into one UV for each and every single one of the models. Which will be a substantial amount of work I hope to avoid if you think you know what the cause of this is and could potentially fix it sometime in a later update.
Actually now that I look closer I think the smoothing groups are applying, but only to the first texture in the set.
Great News, Anyways I think some problems arent that annoying so far i have no problems with the M3 exporting tools works perfectly.
Only thing what is annoying is sometimes the Normal gives a flipped normal but can be easily fixed by adding new object and attach it.
Iam not sure if this is a issue, But there seems a problem with the Materials "Shader", Models without Emissive materials will be cloaked fine.
But when i add a emissive material the cloak effect all become red.
In 3dsmax i get this error when i import a model previously exported with m3 plugin:
ERROR# Bone animation failed!
No ""findItem"" function for undefined
Set up bones bindpose
Set up bones base pose
With sc2 original models it doesn't happen, only with exported one.
My 3dsmax 2010 is updated to last hotfix.
In 3dsmax i get this error when i import a model previously exported with m3 plugin: Transforming bones... ERROR# Bone animation failed! No ""findItem"" function for undefined Set up bones bindpose Set up bones base pose
With sc2 original models it doesn't happen, only with exported one. My 3dsmax 2010 is updated to last hotfix.
He is using Windows XP, service pack 1 btw. Problem is Local, not with exporter itself, or the problem is related with windows xp not correctly supporting exporter.