I'm sorry to have to say, I don't believe I'll be releasing many updates in the future to the tools, if any at all at the present pace of things. I'm pretty busy with other important things in my life to the point where working on the tools is just not possible for me to do. The tools still don't do everything I'd have wanted and it's my hope in the future that someone takes an interest in developing proper tools to support creating custom M3 models. I've always provided the source code to the maxscripts so that people might learn or use the information to construct their own tools. One of these days I'll try to update libm3 to include the extra information I've learned so future developers don't have to learn the hard way, through trial and error.
It's my belief that Blizzard will not release significant tools in the future... Even if StarTools is released, it seems primarily to create doodads instead of the diverse models capable of being supported by the engine. If they do release their max plugins, they will undoubtedly be restricted to certain versions just as the tools for Warcraft 3 were. It's really up to developers present in the community to make these tools a reality. Anyone with decent knowledge of 3D graphics and programming can contribute. When I first started working on the tools, most of my knowledge was extremely basic at best, it's more about knowing what you want to achieve and realising the steps to take to achieve it.
It's been a fun hobby to indulge in and I'm very thankful for all the support you guys provided aswell as the multitude of feedback. It still frustrates me that I'm not able to fix all the problems you guys have, especially regarding shading/bone weight issues. I feel like these are basic things that should just work instead of being an obstacle to creativity and exporting. There's still alot I wanted to get done, such as a tool for transferring animations from one model to another that have similar bone hierarchies (this would be really cool, it would basically allow anyone to animate their model with professional Blizzard-like animations from WoW, WC3 or other SC2 models for instance).
I also envision a tool similar to an expanded version of WoW model viewer which allows you to do basic editing of all Blizzard models and import/export between the various Blizzard model formats. I think this would allow the community a great deal of customisation of stock models without having to own expensive software. Bare in mind Diablo 3 is also on the horizon with its plethora of models and a new modelling format to decypher. In addition, Blizzard doesn't seem to mind transferring their assets between the Blizzard games as I do remember they tweeted about the World of Warcraft custom models being used within the Starcraft 2 engine. So there's not too much concern about them interferring legally with such a tool if it were to be created.
There is a setting within the M3 that controls how a unit is selected. I haven't quite figured out how it works yet but I'll check out the cube model and see if I can figure it out. I actually never thought of looking at the cube model so cheers for the suggestion.
Aye M3's are pretty complex. There's still a huge amount of stuff I've yet to implement. IK is supported by bones in the sc2 engine for instance, so at some stage I'm going to have to provide support for that. Support for lights will be next, but there's still ribbon emitters/physics bodies/shadow boxes/cameras for portraits/global animations/etc to be done.
The egg shape won't work with bounding spheres, the script will just take the longest radius of the egg shape and use that as the basis for the sphere. The bounding sphere in M3's has essentially only two properties: position and radius. The attachment volumes are connected to bones which allow for the odd scaling/shape.
There is more complex ways to handle the unit selection but I'll have to figure out how it works with some investigating :D
I'll look into that error in 3ds Max 9. 3ds Max 9 should work fine with the scripts as far as I can tell, though you might need one of the service packs to add .dds support.
That value in the bones is pretty interesting. I'm not sure what it indicates but it does kind of strike me as a lookup of some sort. I don't think it's an internal lookup as I couldn't relate it to anything in the M3.
I was also first confused about the 'basepose' however the way animation is handled in M3's, it makes sense. Every animation reference has an 'init value' which gives the animatable property an initial value to assume if there's no key frames present. Bones are no exception as they're animatable, however it's interesting that Blizzard put them into a pose that is different from the bindpose as it seems unnecessary.
As for the UVW and normal map issues you guys have, it's way outside my expertise. If you come up with some kind of solution I'm happy to try to implement it or whatever needs to be done.
Cheers for the support guys, this update took alot of work. Particle emitters were no small task :P.
Just a note to people, light objects in models are not yet supported. The normal issues, the script isn't perfect at exporting normals which is why alot of your issues may be occuring.
Blue isle studios has graciously supported the development of the scripts and if you get the chance check them out at http://blueislestudios.com/. They will be releasing some ultra cool stuff in the future. Their support is much appreciated :).
I'll drop by later to comment on some other things that are being discussed in the thread. Just wanted to post the update before I had to head out. Cheers all.
You're doing good work Phygit, you seem to have a better grasp of the modelling fundamentals than I do. First I'll address the animation information. You're probably right about the way I'm doing the base frame, I'm going to have a good look at the code once I get the chance and see if I can use your explanation to mend any wrongs with the base pose and the animation keys imported. 3ds Max (and some 3D applications I would assume) run into some problems with the quaternion rotations found in the M3's. I've had to compare the next key quaternion with the previous one (using a dot function) to make sure Max didn't rotate in the wrong direction (instead of taking the shortest rotational path, it wanted to go in the opposite direction!).
The vertex normals are the bane of my existence. Getting them to work has been the most painful part of designing a working exporter, and they don't even work as they should. I've since fixed a minor glitch that caused incorrect normals to be generated which will be in the next released update. Converting 3ds Max smoothing groups to vertex normals and vice versa are enormous sorting tasks to which I haven't had much luck. I do most of the vertex normals through a 3ds max modifier, which is a horribly slow and inefficient method for processing them. Furthermore, it seems that smoothing groups are still not exported entirely correctly using this method. I think to calculate them based on smoothing groups and face normals for each vertex is the way to go, but I haven't come up with a valid method for doing it yet. I HAVE found a script that purports to do it properly though (Sins of a Solar Empire export script, if you're interested).
The faces problem you mentioned, the 2-sided polygons, I've noticed it in some models, particularly ones with wings. It's pretty rare on the whole from what I've seen, but I think they're far more popular in WoW models than sc2 models. Another issue, since UV's/Normals are done per-vertex, alot of extra vertices need to be generated for the faces of the geometry. This is a pretty complex issue when you consider that UV vertices used for each face may be different to the actual vertices, and even more complex as each vertex may have multiple normals depending on the smoothing of the faces (causing multiple duplicated vertices to be used for adjoined faces). If you aim to write an exporter at any stage, these are some fun issues that need to be dealt with :D.
Finally, I'm curious as to your motivation for designing an import script for the format. You don't own the game, I'll assume by choice. This presents the complex task of designing an importer based on models that aren't natively generated M3's. It means you'll have an incomplete importer that's extremely difficult to debug if people have problems importing native Starcraft 2 models, which is definitely a possibility considering the negative scaling problems I've mentioned earlier. So I'm wondering what your intentions are exactly, whether the import script is to be expanded or an export script is to be developed, or whether this is just a hobby you enjoy doing in your spare time. It's all good either way, I'm just curious :).
Cheers. I'm liking the discussion taking place and I hope we get this all figured out in the future.
Yes exactly, after alot of trial and error I found you have to work your way 'up' the chain (finger->hand->elbow->shoulder) starting from the deepest bones first. The screenshot is from the base pose of the zealot after the 'initial' translation/rotation/scale values were applied to the bindpose. I think once you are able to begin applying transformations from the deepest bone first up the hierarchy, it'll all come together and your animations/base pose will start to look fine.
Be weary of one thing I have discovered with some Blizzard models. Some of them use negative bone scales when 'mirroring' certain bones. You can find this kind of negative scaling in the Immortal and the DarkTemplar models (realising you don't have access to these models, you'll have to take my word for it :P). I don't know if Cinema 4D will be able to process the negative scaling correctly, but it's something to be weary of if you plan to create a complete importer.
Thanks for picking up on that bug in the script, I'll get it fixed for the next update. I'm glad more people are taking an interest in developing M3 tools for other programs than max.
On to your technical question, the bones gave me a great deal of problems when I first started trying to get the models into 3ds max. Infact, they're still not done entirely correct when I import them. The envelopes are incorrectly done, there should be bone geometry linking the bones too instead of using the 'show links' method I'm using on import. These things I don't know how to fix properly in max, most of the systems I tried failed and ended up causing the bones to be shown incorrectly.
The IREF chunk in the model, from what I understand, is the 'Initial Reference' inverse matrix for each bone object. That is, the matrices for each bone when the geometry (i.e. vertices of the mesh) is skinned onto them. I don't think they're meant to have a bone related axis at all. They're almost certainly processed before the bone chunk of the model, so things such as the bones parent aren't even considered at the point the IREF is processed. The IREF matrices put the bones in the correct position/orientation/scale for binding the vertices to them. I'm not sure if you can deduce a bone axis from them, I never had to deal with that problem.
I don't really think the bone systems in M3's or any of Blizzard's model formats are aligned along the bone, rather they are simply objects in 3D space that affect each other in a hierarchy, if that makes any sense. You'll notice in my script bone hierarchy is setup after the inverse matrices are applied to each bone and that all animations are done starting from the deepest bone in the hierarchy and then moving upward. If you figure out anything let me know.
Sorry I've been so absent. I just finished up with my exams so I'll have some extra free time to work on the plugins. I'm going to try and fix some of the issues people are reporting too. I'll see how I go. I'm hoping to complete particle support this time around aswell as perhaps ribbon support too.
Fixed the cloaking bug (where units turn red), also allows you to import some models that would previously fail (such as Kerrigan) and a bug where the object that stores animation information would be exported as a bone was also fixed.
Let me know any critical issues that you feel need to be addressed immediately and I'll do my best.
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.
The latest version has a massive bug in it that I've fixed and I'll be uploading shortly, once I figured out why your reaver animations are not being exported properly.
Right now I'm swamped with uni work, I just don't have time to spend on updating this for the moment. The good news is that I've made some progress with the particle stuff. I might take up Pinkhair3d on their offer and present the particles with their unknown parameters and you guys can figure out what they do, save me documenting something I know very little about :D. At the least it'll allow you to copy cool particles from other models.
I appologise to all the people PM'ing me with requests and such, I'll try to respond to you guys. I realise the cinematic models are causing problems with their materials which I'll have to look into. I've found a weird collection of settings in the bitmaps which I'm hoping you guys good with materials may be able to help explain to me. I'm calling it tint, but I don't think it's tint. I'll post up some screenshots of it when I get the chance.
Not sure whats happening with the collision sphere. Might've turned it off for some reason. When I have time to update the export script I want to add the ability to create your own collision/bounding spheres so that you don't have to use the automatically generated ones.
Particles are a massive beast. Just figuring out the M3 structure is a pain, let alone what each setting does. It's taking me a very long time to figure out what most of the LAYR chunk does and that's just bitmaps, with particles it's probably five times as complex. I do have MDX and M2 documentation as a bit of a reference, but particles and ribbons are hard to work with and I'm no expert on them. I want to add support as much as anyone but without having the necessary particle expertise I'm basically blind guessing at close to 30 or 40 particle settings with no hint as to their ultimate function.
My strategy is usually to change a setting and observe the effect but this is largely guesses when it comes to particle settings as I'm not sure what some of them even do despite having an effect. Since I can't just list a bunch of particle settings that don't have a description (how would you design your own?) I'm not sure whats going to happen here. The particle chunks are massive and while I may be able to figure out alot of the settings by cross referencing with the MDX and M2 documentation there's bound to be a whole lot more settings to which I have no idea what they ultimately are.
The butt needs to use a different material that doesn't have an alpha map assigned to it. The importer should create materials for you, and only certain materials need alpha maps added to them with the 200 cutout threshold. Since Starcraft 2 models don't use opacity maps exactly, it's the only way to mimic the way that opacity maps work in World of Warcraft models. Also I notice for the Lich King you've left the particle meshes on frostmourne. If you delete them you won't have the black textured meshes problem.
So for the spider, the hairs should be a submesh with an assigned material that has a diffuse and an alpha map with 200 cutout threshold whereas the body should have a material applied with just the diffuse map. These materials should be setup for you automatically by the importer.
You have to also set the cutout threshold to at least 1 from memory. Cutout thresholds control how much opacity you get from the alpha map. For WoW models, I used a cutout threshold of about 180-200 to mimic their opacity maps.
Looks like firebats have a light object in the model that probably causes the orange/yellow to light up the model when the attack animation is played. Light objects are not currently supported but I'd like to add support in the future.
Forgot to include exporter in the latest script bundle (thanks to WadeArcade for alerting me). It's been since fixed and 1.7 now includes the exporter script.
M3 Plugins v1.7
Smoothing groups should just work now. No need to detach faces or anything. Test it out with your simple crate model without detaching any faces and you'll see the normals are now all correct (or should be!)
Hey guys,
I'm sorry to have to say, I don't believe I'll be releasing many updates in the future to the tools, if any at all at the present pace of things. I'm pretty busy with other important things in my life to the point where working on the tools is just not possible for me to do. The tools still don't do everything I'd have wanted and it's my hope in the future that someone takes an interest in developing proper tools to support creating custom M3 models. I've always provided the source code to the maxscripts so that people might learn or use the information to construct their own tools. One of these days I'll try to update libm3 to include the extra information I've learned so future developers don't have to learn the hard way, through trial and error.
It's my belief that Blizzard will not release significant tools in the future... Even if StarTools is released, it seems primarily to create doodads instead of the diverse models capable of being supported by the engine. If they do release their max plugins, they will undoubtedly be restricted to certain versions just as the tools for Warcraft 3 were. It's really up to developers present in the community to make these tools a reality. Anyone with decent knowledge of 3D graphics and programming can contribute. When I first started working on the tools, most of my knowledge was extremely basic at best, it's more about knowing what you want to achieve and realising the steps to take to achieve it.
It's been a fun hobby to indulge in and I'm very thankful for all the support you guys provided aswell as the multitude of feedback. It still frustrates me that I'm not able to fix all the problems you guys have, especially regarding shading/bone weight issues. I feel like these are basic things that should just work instead of being an obstacle to creativity and exporting. There's still alot I wanted to get done, such as a tool for transferring animations from one model to another that have similar bone hierarchies (this would be really cool, it would basically allow anyone to animate their model with professional Blizzard-like animations from WoW, WC3 or other SC2 models for instance).
I also envision a tool similar to an expanded version of WoW model viewer which allows you to do basic editing of all Blizzard models and import/export between the various Blizzard model formats. I think this would allow the community a great deal of customisation of stock models without having to own expensive software. Bare in mind Diablo 3 is also on the horizon with its plethora of models and a new modelling format to decypher. In addition, Blizzard doesn't seem to mind transferring their assets between the Blizzard games as I do remember they tweeted about the World of Warcraft custom models being used within the Starcraft 2 engine. So there's not too much concern about them interferring legally with such a tool if it were to be created.
Cheers everyone,
- NiN
@Kalekin: Go
There is a setting within the M3 that controls how a unit is selected. I haven't quite figured out how it works yet but I'll check out the cube model and see if I can figure it out. I actually never thought of looking at the cube model so cheers for the suggestion.
@GnaReffotsirk: Go
Aye M3's are pretty complex. There's still a huge amount of stuff I've yet to implement. IK is supported by bones in the sc2 engine for instance, so at some stage I'm going to have to provide support for that. Support for lights will be next, but there's still ribbon emitters/physics bodies/shadow boxes/cameras for portraits/global animations/etc to be done.
The egg shape won't work with bounding spheres, the script will just take the longest radius of the egg shape and use that as the basis for the sphere. The bounding sphere in M3's has essentially only two properties: position and radius. The attachment volumes are connected to bones which allow for the odd scaling/shape.
There is more complex ways to handle the unit selection but I'll have to figure out how it works with some investigating :D
@maverck: Go
I'll look into that error in 3ds Max 9. 3ds Max 9 should work fine with the scripts as far as I can tell, though you might need one of the service packs to add .dds support.
@Phygit: Go
That value in the bones is pretty interesting. I'm not sure what it indicates but it does kind of strike me as a lookup of some sort. I don't think it's an internal lookup as I couldn't relate it to anything in the M3.
I was also first confused about the 'basepose' however the way animation is handled in M3's, it makes sense. Every animation reference has an 'init value' which gives the animatable property an initial value to assume if there's no key frames present. Bones are no exception as they're animatable, however it's interesting that Blizzard put them into a pose that is different from the bindpose as it seems unnecessary.
As for the UVW and normal map issues you guys have, it's way outside my expertise. If you come up with some kind of solution I'm happy to try to implement it or whatever needs to be done.
Cheers for the support guys, this update took alot of work. Particle emitters were no small task :P.
New update: M3 Plugins v1.8
Just a note to people, light objects in models are not yet supported. The normal issues, the script isn't perfect at exporting normals which is why alot of your issues may be occuring.
Blue isle studios has graciously supported the development of the scripts and if you get the chance check them out at http://blueislestudios.com/. They will be releasing some ultra cool stuff in the future. Their support is much appreciated :).
I'll drop by later to comment on some other things that are being discussed in the thread. Just wanted to post the update before I had to head out. Cheers all.
@Phygit: Go
You're doing good work Phygit, you seem to have a better grasp of the modelling fundamentals than I do. First I'll address the animation information. You're probably right about the way I'm doing the base frame, I'm going to have a good look at the code once I get the chance and see if I can use your explanation to mend any wrongs with the base pose and the animation keys imported. 3ds Max (and some 3D applications I would assume) run into some problems with the quaternion rotations found in the M3's. I've had to compare the next key quaternion with the previous one (using a dot function) to make sure Max didn't rotate in the wrong direction (instead of taking the shortest rotational path, it wanted to go in the opposite direction!).
The vertex normals are the bane of my existence. Getting them to work has been the most painful part of designing a working exporter, and they don't even work as they should. I've since fixed a minor glitch that caused incorrect normals to be generated which will be in the next released update. Converting 3ds Max smoothing groups to vertex normals and vice versa are enormous sorting tasks to which I haven't had much luck. I do most of the vertex normals through a 3ds max modifier, which is a horribly slow and inefficient method for processing them. Furthermore, it seems that smoothing groups are still not exported entirely correctly using this method. I think to calculate them based on smoothing groups and face normals for each vertex is the way to go, but I haven't come up with a valid method for doing it yet. I HAVE found a script that purports to do it properly though (Sins of a Solar Empire export script, if you're interested).
The faces problem you mentioned, the 2-sided polygons, I've noticed it in some models, particularly ones with wings. It's pretty rare on the whole from what I've seen, but I think they're far more popular in WoW models than sc2 models. Another issue, since UV's/Normals are done per-vertex, alot of extra vertices need to be generated for the faces of the geometry. This is a pretty complex issue when you consider that UV vertices used for each face may be different to the actual vertices, and even more complex as each vertex may have multiple normals depending on the smoothing of the faces (causing multiple duplicated vertices to be used for adjoined faces). If you aim to write an exporter at any stage, these are some fun issues that need to be dealt with :D.
Finally, I'm curious as to your motivation for designing an import script for the format. You don't own the game, I'll assume by choice. This presents the complex task of designing an importer based on models that aren't natively generated M3's. It means you'll have an incomplete importer that's extremely difficult to debug if people have problems importing native Starcraft 2 models, which is definitely a possibility considering the negative scaling problems I've mentioned earlier. So I'm wondering what your intentions are exactly, whether the import script is to be expanded or an export script is to be developed, or whether this is just a hobby you enjoy doing in your spare time. It's all good either way, I'm just curious :).
Cheers. I'm liking the discussion taking place and I hope we get this all figured out in the future.
@Phygit: Go
Yes exactly, after alot of trial and error I found you have to work your way 'up' the chain (finger->hand->elbow->shoulder) starting from the deepest bones first. The screenshot is from the base pose of the zealot after the 'initial' translation/rotation/scale values were applied to the bindpose. I think once you are able to begin applying transformations from the deepest bone first up the hierarchy, it'll all come together and your animations/base pose will start to look fine.
Be weary of one thing I have discovered with some Blizzard models. Some of them use negative bone scales when 'mirroring' certain bones. You can find this kind of negative scaling in the Immortal and the DarkTemplar models (realising you don't have access to these models, you'll have to take my word for it :P). I don't know if Cinema 4D will be able to process the negative scaling correctly, but it's something to be weary of if you plan to create a complete importer.
@Phygit: Go
Hey Phygit,
Thanks for picking up on that bug in the script, I'll get it fixed for the next update. I'm glad more people are taking an interest in developing M3 tools for other programs than max.
On to your technical question, the bones gave me a great deal of problems when I first started trying to get the models into 3ds max. Infact, they're still not done entirely correct when I import them. The envelopes are incorrectly done, there should be bone geometry linking the bones too instead of using the 'show links' method I'm using on import. These things I don't know how to fix properly in max, most of the systems I tried failed and ended up causing the bones to be shown incorrectly.
The IREF chunk in the model, from what I understand, is the 'Initial Reference' inverse matrix for each bone object. That is, the matrices for each bone when the geometry (i.e. vertices of the mesh) is skinned onto them. I don't think they're meant to have a bone related axis at all. They're almost certainly processed before the bone chunk of the model, so things such as the bones parent aren't even considered at the point the IREF is processed. The IREF matrices put the bones in the correct position/orientation/scale for binding the vertices to them. I'm not sure if you can deduce a bone axis from them, I never had to deal with that problem.
I don't really think the bone systems in M3's or any of Blizzard's model formats are aligned along the bone, rather they are simply objects in 3D space that affect each other in a hierarchy, if that makes any sense. You'll notice in my script bone hierarchy is setup after the inverse matrices are applied to each bone and that all animations are done starting from the deepest bone in the hierarchy and then moving upward. If you figure out anything let me know.
Hello all,
Sorry I've been so absent. I just finished up with my exams so I'll have some extra free time to work on the plugins. I'm going to try and fix some of the issues people are reporting too. I'll see how I go. I'm hoping to complete particle support this time around aswell as perhaps ribbon support too.
A small update to the plugins here
Fixed the cloaking bug (where units turn red), also allows you to import some models that would previously fail (such as Kerrigan) and a bug where the object that stores animation information would be exported as a bone was also fixed.
Let me know any critical issues that you feel need to be addressed immediately and I'll do my best.
Cheers,
- NiN
@Riaction: Go
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:
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.
@UltiDrgn: Go
The latest version has a massive bug in it that I've fixed and I'll be uploading shortly, once I figured out why your reaver animations are not being exported properly.
Right now I'm swamped with uni work, I just don't have time to spend on updating this for the moment. The good news is that I've made some progress with the particle stuff. I might take up Pinkhair3d on their offer and present the particles with their unknown parameters and you guys can figure out what they do, save me documenting something I know very little about :D. At the least it'll allow you to copy cool particles from other models.
I appologise to all the people PM'ing me with requests and such, I'll try to respond to you guys. I realise the cinematic models are causing problems with their materials which I'll have to look into. I've found a weird collection of settings in the bitmaps which I'm hoping you guys good with materials may be able to help explain to me. I'm calling it tint, but I don't think it's tint. I'll post up some screenshots of it when I get the chance.
@xcorbo: Go
Not sure whats happening with the collision sphere. Might've turned it off for some reason. When I have time to update the export script I want to add the ability to create your own collision/bounding spheres so that you don't have to use the automatically generated ones.
@tigerija: Go
Particles are a massive beast. Just figuring out the M3 structure is a pain, let alone what each setting does. It's taking me a very long time to figure out what most of the LAYR chunk does and that's just bitmaps, with particles it's probably five times as complex. I do have MDX and M2 documentation as a bit of a reference, but particles and ribbons are hard to work with and I'm no expert on them. I want to add support as much as anyone but without having the necessary particle expertise I'm basically blind guessing at close to 30 or 40 particle settings with no hint as to their ultimate function.
My strategy is usually to change a setting and observe the effect but this is largely guesses when it comes to particle settings as I'm not sure what some of them even do despite having an effect. Since I can't just list a bunch of particle settings that don't have a description (how would you design your own?) I'm not sure whats going to happen here. The particle chunks are massive and while I may be able to figure out alot of the settings by cross referencing with the MDX and M2 documentation there's bound to be a whole lot more settings to which I have no idea what they ultimately are.
@hipnos14: Go
The butt needs to use a different material that doesn't have an alpha map assigned to it. The importer should create materials for you, and only certain materials need alpha maps added to them with the 200 cutout threshold. Since Starcraft 2 models don't use opacity maps exactly, it's the only way to mimic the way that opacity maps work in World of Warcraft models. Also I notice for the Lich King you've left the particle meshes on frostmourne. If you delete them you won't have the black textured meshes problem.
So for the spider, the hairs should be a submesh with an assigned material that has a diffuse and an alpha map with 200 cutout threshold whereas the body should have a material applied with just the diffuse map. These materials should be setup for you automatically by the importer.
Hopefully that helps, good luck.
@Gadaffy2: Go
You have to also set the cutout threshold to at least 1 from memory. Cutout thresholds control how much opacity you get from the alpha map. For WoW models, I used a cutout threshold of about 180-200 to mimic their opacity maps.
@ef55515: Go
Looks like firebats have a light object in the model that probably causes the orange/yellow to light up the model when the attack animation is played. Light objects are not currently supported but I'd like to add support in the future.
Forgot to include exporter in the latest script bundle (thanks to WadeArcade for alerting me). It's been since fixed and 1.7 now includes the exporter script. M3 Plugins v1.7
@tigerija: Go
Smoothing groups should just work now. No need to detach faces or anything. Test it out with your simple crate model without detaching any faces and you'll see the normals are now all correct (or should be!)