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.
Hey Ladik, just wanted to say I'm a huge fan of your program. It's very polished, I love the interface and I love the fact that you still update it when new Blizzard games come out.
I have one problem on my end that I'd like to bring to your attention. Whenever I extract files from an MPQ to a directory and the directory already contains those files it asks me whether I would like to overwrite those files or not. If I click yes there's no problems, however, if I click cancel I will get a 'not enough disk space' error. Seems that clicking cancel is invoking the wrong course of action.
I'm running Windows 7 32-bit and the latest Cataclysm version of your MPQ editor (version 3.1.0.480), although it also used to occur in your previous versions.
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!)
It's uploaded. Can grab it here once it's approved.
Smoothing groups should now export correctly. I also found a bug with exporting emissive maps that should be fixed. The importer should no longer garble animations on import too. I've been looking into particle emitter support, and that looks tough. I don't know if I'll be able to provide that anytime soon.
What I was thinking for a future plugin, the ability to take animations from one bone system and transfer it to another. There's a tool out there that could do it for WoW models and is something I have envisioned for a long time. Let me explain the premise and then you guys can tell me whether it's already possible to do or there's already plugins that can do it.
My idea is to be able to transfer animations from a pre-existing bone structure to a new bone structure. Most models share similar bone structures to one another (bipedal models especially). The interface would be dotnet treeview style. So you'd have two models in the scene, the one you want to transfer from and the one you want to transfer to. Using the treeview interface you would assign which bones are most similar to one another in each of the models (i.e. the 'knee' bones, the 'hip' bones, the 'right shoulder' bones, etc). Then you would select a time range to take animation data from the outgoing models bones and copy it to the corresponding bones you've established in the treeview. In this way, you could make a ghost dance like a WoW character model or give the highly detailed campaign models standard run and walk animations from other models.
This doesn't just apply to Blizzard models either. Models from Doom3 or virtually any model with bone animation data that can be brought into 3ds Max that has a similar bone structure to your model could be animated with another models animations. Blizzard enjoys doing this on a more subtle level by creating meshes over old skins (in WoW, skins are reused a crazy amount).
A very old demonstration of the possibilities with a 3ds Max plugin I created roughly around BC's release:
Some of the animations are glitchy as the plugin is very ancient that I used to accomplish the task, so ignore the glitches. As you can see though, not all the animations fit properly into the golems bone system. I think it'd be a powerful way to add say a jump animation to your model for instance. Let me know what you guys think, cheers.
The problem might be that you're using an early version of the exporter. In one of the updates, it automatically adds an important sequence end event that is necessary for animations to loop properly. It sounds like you're using an old version that doesn't create the event and so the looping is bugged (i.e. animation plays once then the model freezes)
I've conjured up some fancy code to export smooth groups from 3ds Max. Trust me when I say it was no easy task. It also means if you choose to export using smooth groups there's a possibility it'll take a little longer (about an extra 3 - 4 seconds for the Zealot on my end).
I'll upload the updated script when I can, I'm still bug testing it. For those interested in how it works, the code basically introduces new vertices when multiple faces meet but don't share the same smoothing group. A new vertex is copied from the original with a new calculated normal so the end result is that you have a seperate vertex for each face using a different normal (using the face normal for those in the know). Keep in mind that while this increases the vertex count the face count remains the same and thus the performance hit due to the extra vertices is basically nothing. I'm pretty sure this is exactly how detaching faces work, just that when using this option you no longer have to detach the faces manually to introduce the new vertices as the code is doing it for you.
I'd love to use smoothing groups with the importer aswell, but I fear thats even more complex. With the way I import models at the moment, smoothing groups have little effect on the model. I think what would be best is to allow smoothing groups AND custom normals, and I think with my current code a hybrid processing of the normals shouldn't be too difficult. You'll have to choose whether to export normals through the edit normal modifier or through smoothing groups for the time being.
Smoothing groups are an absolute pain to code for aswell. There's almost no specific code I can reference to figure out a good way to calculate vertex normals based on smoothing groups. That's the exporter side of things. I've been googling the problem a fair bit and there's little information about going from vertex normals to smoothing groups and from smoothing groups to vertex normals.
Looking at Blizzard M3 models that have creased surfaces, you can see in 3ds Max they have multiple vertices where adjacent faces are meant to be creased. Smoothed surfaces only need one vertex. This is because to have a creased surface, you require a seperate vertex normal for each adjacent face and M3's only support one normal per vertex. 3ds Max, on the other hand, allows you to have multiple normals per vertex however the normals are automatically calculated based on smoothing groups. I do believe smoothing groups can be used and the extra vertices and their normals automatically generated on export (as Warcraft III tools did) but I am absolutely stumped as to how to go from the generated vertex normals back to smoothing groups with the importer.
If I do figure out some solution I think I'll have to provide an option for the exporter whether to use custom vertex normals that are assigned through the Edit Normals modifier or to use smoothing groups.
As above, 3ds Max uses multiple vertex normals per vertex yet M3's have only one vertex per normal. You'll have to detach the faces like you've been doing for the moment until a solution is reached.
Honestly the math involved is frustrating and sparsely documented. I'll keep considering a solution but for now I don't know of an easy one.
I'll step in here. The exporter isn't perfect at exporting smooth groups. Infact it's terrible at it. I've yet to code in a good smooth group algorithm so at the moment I use the edit_normals modifier present in max to grab each custom vertex normal. It's pretty slow and it's far from perfect. It works well with the importer, but I could see how you could run in to problems with custom models. The problem here is vertex normals, which M3's use, but 3ds Max hates. 3ds Max likes to calculate its vertex normals on the fly using smoothing groups, which is great, but it means you can't use custom vertex normals without a modifier. This is a problem when importing/exporting and if someone has a 3ds Max solution that bypasses using the modifier I'd love to hear it (I don't think there is one, besides designing the script to use smoothing groups instead).
My advice, add an 'edit normals' modifier to your mesh and mess around with it to try and get the correct smoothing. The script directly accesses the vertex normals through the modifier so you should be able to fix smoothing errors through experimentation with the modifier. In the future I hope to code in an algorithm to handle smoothing groups in 3ds Max properly on export, however the math behind such an algorithm is pretty complex and I've yet to see any example code of it anywhere. I'd love to have smoothing groups applied on import too, but again the math I just can't do. If anyone knows how to convert vertex normals to smoothing groups and smoothing groups to vertex normals, please enlighten me.
That looks like the keyboard texture that the engine uses when a model references an invalid texture. This must mean you have:
Not imported the textures to the map in the right path (Import them into 'Assets\Textures\' folder in the import window by default)
Haven't added the correct texture in 3ds Max so the internal filename is being saved into the M3
If the textures are being applied properly in 3ds Max, and you're resaving the textures as 32 bit in photoshop, then you must not be importing the texture into the map correctly. The default 'internal directory' set in the M3 exporter is used to define what folders you'll be placing the textures into within your map. By default it's 'Assets\Textures\' and if you don't import textures into this folder in the map the M3 will incorrectly reference the texture and you'll get the funky keyboard texture you're seeing in the screenshot.
For example, if you're trying to apply the map 'Worgen_diffuse.tga' to your model you'd first apply the texture to your model in 3ds Max so that the model exports with the path properly. Then in your map you'd import the TGA and place it in the 'Assets\Textures\' path and THEN import the model. If you import the texture first, the model should appear in the editor textured.
Bare in mind when importing some M2's there are meshes that are relevant to particles which should be removed and for characters there's meshes that are only present with certain character configurations (setup in the DBC files, if I update this further in the future I'll most likely add better support for importing characters).
I'm back at uni now and with the game released I'm leagueing quite a bit with what little spare time I have. It's doubtful I'll be able to provide any updates to the plugins for awhile but I still do have plans for them in the future.
Grab the new script bundle here. Removed all the activeX controls and replaced them with dotnet controls, so everything should work on 64-bit operating systems and 64-bit max. It was a bit of a pain to learn so much about dotnet controls so I hope the hard work is appreciated :P. I'm going to be busy with Uni work soon, so I probably won't be doing much in the way of updating the plugins.
My final goals are to add particle/ribbon support to the importers/exporters, do some tutorials on how to use the plugins and to see about coding something for Blender at some stage. I wish I could program C plus plus programs that would do straight conversions instead of having to use 3ds Max as a medium for conversion too. Doubtful I'll get around to doing that.
Hopefully I can put a tutorial up soon on how to export to the M3 format and get the models properly textured into the Starcraft 2 editor. I'll need more details about your problem to troubleshoot it. Make sure your textures render in the importer window so it confirms the Starcraft 2 editor can understand the texture file. Import textures first then models, and make sure you import textures into the 'Assets\Textures' path or whatever you set the texture path to be in 3ds Max as the internal path. If you have textures properly imported and the model still doesn't appear textured, try restarting the whole Starcraft 2 editor or closing and reloading your map as this is known to fix alot of texture problems.
I wish it wasn't so complex, I'd prefer a straight conversion myself. The problem stems from using maxscript to code the plugin as I cannot use the CPP libraries to access MPQ's. World of Warcraft models can be heavily entangled with DBC definitions, which is how alot of models have different body textures applied without having multiple model definitions. In these instances I've tried to give the bitmaps logical names, such as 'Skin1' which means Creature Skin1 and 'Items' which usually means capes and such.
The people coding WoWModelViewer think they've made the .anim files external to save on WoW memory demands as rarer animations for the model are stored in these files and only called when they're used rather than pre-loaded. The .SKIN files are external because only one of them is used at a time and it is again a waste of memory to have them all defined in the one model when only one is usually needed to be loaded.
I think it'd be alot easier and faster to execute if I coded a CPP plugin converter that can access the MPQ's. That way I could reference the DBC files without having to force the end user to extract any himself. It also means I could access all the .anim and .skin files automatically. Perhaps in the future I'll make something like that but for now I'm a little burned out on all this stuff. Uni break is almost over so my commitment to importers and exporters will not be as solid.
Edit: Sorry IskatuMesk, I didn't realise the activeX controls would create compatibility issues. I'll look into developing a solution. Compatibility errors are the devil.
Edit2: I'm reading about a possible solution here: http://blog.duber.cz/3ds-max/farewell-activex. Converting to dot.net controls instead. If it works properly should be a relatively quick fix. Seems Microsoft pulled the plug on activeX controls, so they're not being compiled in 64-bit.
Thanks, I'm trying to fix the stupid ratio now so it embeds properly. I'll try and update it properly, I have a feeling it'll make front page and I'd prefer it didn't look like crap ><
Hey guys, due to popular demand I decided to rework my old M2 Importer script for 3ds Max so that it would work with the latest World of Warcraft models (WotLK and Cataclysm). It's been designed for WotLK models but fortunately it seems Cataclysm will not introduce major changes to the model format and so the importer should work just fine once Cataclysm goes live too. You can grab the script bundled with my other M3 scripts here.
I'll need to provide a quick tutorial on how to use the importer as World of Warcraft model files are no longer standalone model files. You have .skin and .anim files in addition to the actual .m2 file. This makes importing messy (especially coding the script, believe me) but there's an easy and quick way to do it. Get a hold of an MPQ extractor, personally I recommend Ladik's MPQ Editor. You'll need to extract a file from your WoW MPQ's if you want your animations to be named. It's called 'AnimationData.dbc', it contains all the names of the animations that WoW uses, and it's located in your language MPQ's (i.e. in Patch-enUS-3.MPQ). Once you're done extracting the file, make sure you close the MPQ so it's no longer being accessed.
Next, grab the latest version of the WoWModelViewer which can be downloaded for free here. Find the model you want to import into max and load it up in the model viewer. Once it loads, go to File->Export Textures...
Now when the new dialog pops up, click on 'Export All' and 'Export All to TGA'. Make sure 'Path Preserved' is unchecked.
The exported files will be located in your WoWModelViewer directory in the 'Export' folder. I recommend cutting and pasting them to another location so they don't get mixed up with future exports. Now head into 3ds Max. When you open up the M2 Importer, you'll notice a settings button you should click on.
In the settings, you should configure the DBFilesClient path to where you extracted the AnimationData.dbc file using the browse button. This lets the script know where to find the file so it can apply the correct names to animations. Important if you plan to export to M3 later.
If you left 'Import as M3' checked in the settings, the script will automatically scale the model for you (half it's original size seems about correct for matching the size of Starcraft 2 Models) and re-orient the model to face the same way as Starcraft 2 models do. An 'm3root_bone' will be created which can be used to alter the position, rotation and scale of the model without affecting animations. Additionally, it will select to import only Attack, Stand, Death and Run animations (which you can alter on import if you wish) and automatically rename them to M3 convention. In order to control animations, you must select 'M3 - Sequences' from the Utility drop down menu in the MAXScript panel.
Attachments will also automatically be created as Starcraft 2 attachments and given appropriate ID's, but it's not perfect as alot of the attachments have ambiguous function in World of Warcraft models. Finally, Starcraft 2 materials will be setup for you based on a rough conversion of the M2 material definitions. I've tried to name the bitmaps so you know what should go where, as some World of Warcraft textures are assigned through DBC definitions and not within the M2 itself.
Hard-coded M2 textures should be automatically applied if they are in DDS, TGA or PNG format and in the same folder as the model. The TGA textures exported from the WoWModelViewer should be fine in Max, but I've found they won't render in the Starcraft 2 editor without being resaved as 32 bit TGA in Photoshop.
If you follow these instructions it should be relatively easy to export any animated M2 to the M3 format to be used as a Starcraft 2 model. Here's a short video showing the power of the importer/exporter combo in-game. I'm not great with the editor but I tried my best to get the concept across. I suck with video editing which explains why the ratio is all off and such when I embed it. Go to the actual video it comes up a bit better :(.
I've updated the MDX script. I stopped it crashing on some models and improved the way it does animations in max so you no longer get weird interpolations between animations. This fixes the Archer models animations for instance. Also, I added some very basic conversion code for converting attachments and sequence names into the M3 format.
The update can be found bundled with the other M3 scripts here.
0
@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.
0
@Ladik001: Go
Hey Ladik, just wanted to say I'm a huge fan of your program. It's very polished, I love the interface and I love the fact that you still update it when new Blizzard games come out.
I have one problem on my end that I'd like to bring to your attention. Whenever I extract files from an MPQ to a directory and the directory already contains those files it asks me whether I would like to overwrite those files or not. If I click yes there's no problems, however, if I click cancel I will get a 'not enough disk space' error. Seems that clicking cancel is invoking the wrong course of action.
I'm running Windows 7 32-bit and the latest Cataclysm version of your MPQ editor (version 3.1.0.480), although it also used to occur in your previous versions.
I look forward to your future updates!
Cheers,
- NiN
0
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!)
0
It's uploaded. Can grab it here once it's approved.
Smoothing groups should now export correctly. I also found a bug with exporting emissive maps that should be fixed. The importer should no longer garble animations on import too. I've been looking into particle emitter support, and that looks tough. I don't know if I'll be able to provide that anytime soon.
What I was thinking for a future plugin, the ability to take animations from one bone system and transfer it to another. There's a tool out there that could do it for WoW models and is something I have envisioned for a long time. Let me explain the premise and then you guys can tell me whether it's already possible to do or there's already plugins that can do it.
My idea is to be able to transfer animations from a pre-existing bone structure to a new bone structure. Most models share similar bone structures to one another (bipedal models especially). The interface would be dotnet treeview style. So you'd have two models in the scene, the one you want to transfer from and the one you want to transfer to. Using the treeview interface you would assign which bones are most similar to one another in each of the models (i.e. the 'knee' bones, the 'hip' bones, the 'right shoulder' bones, etc). Then you would select a time range to take animation data from the outgoing models bones and copy it to the corresponding bones you've established in the treeview. In this way, you could make a ghost dance like a WoW character model or give the highly detailed campaign models standard run and walk animations from other models.
This doesn't just apply to Blizzard models either. Models from Doom3 or virtually any model with bone animation data that can be brought into 3ds Max that has a similar bone structure to your model could be animated with another models animations. Blizzard enjoys doing this on a more subtle level by creating meshes over old skins (in WoW, skins are reused a crazy amount).
A very old demonstration of the possibilities with a 3ds Max plugin I created roughly around BC's release:
<embed width="600" height="361" type="application/x-shockwave-flash" allowFullscreen="true" allowNetworking="all" wmode="transparent" src="http://static.photobucket.com/player.swf" flashvars="file=http%3A%2F%2Fvid6.photobucket.com%2Falbums%2Fy234%2FNiNtoxicated%2FArcGolCust02.flv">
Some of the animations are glitchy as the plugin is very ancient that I used to accomplish the task, so ignore the glitches. As you can see though, not all the animations fit properly into the golems bone system. I think it'd be a powerful way to add say a jump animation to your model for instance. Let me know what you guys think, cheers.
0
@PvtChevron: Go
The problem might be that you're using an early version of the exporter. In one of the updates, it automatically adds an important sequence end event that is necessary for animations to loop properly. It sounds like you're using an old version that doesn't create the event and so the looping is bugged (i.e. animation plays once then the model freezes)
0
I've conjured up some fancy code to export smooth groups from 3ds Max. Trust me when I say it was no easy task. It also means if you choose to export using smooth groups there's a possibility it'll take a little longer (about an extra 3 - 4 seconds for the Zealot on my end).
I'll upload the updated script when I can, I'm still bug testing it. For those interested in how it works, the code basically introduces new vertices when multiple faces meet but don't share the same smoothing group. A new vertex is copied from the original with a new calculated normal so the end result is that you have a seperate vertex for each face using a different normal (using the face normal for those in the know). Keep in mind that while this increases the vertex count the face count remains the same and thus the performance hit due to the extra vertices is basically nothing. I'm pretty sure this is exactly how detaching faces work, just that when using this option you no longer have to detach the faces manually to introduce the new vertices as the code is doing it for you.
I'd love to use smoothing groups with the importer aswell, but I fear thats even more complex. With the way I import models at the moment, smoothing groups have little effect on the model. I think what would be best is to allow smoothing groups AND custom normals, and I think with my current code a hybrid processing of the normals shouldn't be too difficult. You'll have to choose whether to export normals through the edit normal modifier or through smoothing groups for the time being.
0
@ef55515: Go
Damn, that's a bug put in there by me. I could've swore I fixed that problem. Looking into it now.
I've come up with a way to export based on smoothing groups, now it's just coding it which is a major pain. Might have something to show soon.
EDIT: Ok I found the problem with the import script and have corrected it. It will be included with the next release.
0
@Triceron: Go
Smoothing groups are an absolute pain to code for aswell. There's almost no specific code I can reference to figure out a good way to calculate vertex normals based on smoothing groups. That's the exporter side of things. I've been googling the problem a fair bit and there's little information about going from vertex normals to smoothing groups and from smoothing groups to vertex normals.
Looking at Blizzard M3 models that have creased surfaces, you can see in 3ds Max they have multiple vertices where adjacent faces are meant to be creased. Smoothed surfaces only need one vertex. This is because to have a creased surface, you require a seperate vertex normal for each adjacent face and M3's only support one normal per vertex. 3ds Max, on the other hand, allows you to have multiple normals per vertex however the normals are automatically calculated based on smoothing groups. I do believe smoothing groups can be used and the extra vertices and their normals automatically generated on export (as Warcraft III tools did) but I am absolutely stumped as to how to go from the generated vertex normals back to smoothing groups with the importer.
If I do figure out some solution I think I'll have to provide an option for the exporter whether to use custom vertex normals that are assigned through the Edit Normals modifier or to use smoothing groups.
@tigerija: Go
As above, 3ds Max uses multiple vertex normals per vertex yet M3's have only one vertex per normal. You'll have to detach the faces like you've been doing for the moment until a solution is reached.
Honestly the math involved is frustrating and sparsely documented. I'll keep considering a solution but for now I don't know of an easy one.
0
@tigerija: Go
I'll step in here. The exporter isn't perfect at exporting smooth groups. Infact it's terrible at it. I've yet to code in a good smooth group algorithm so at the moment I use the edit_normals modifier present in max to grab each custom vertex normal. It's pretty slow and it's far from perfect. It works well with the importer, but I could see how you could run in to problems with custom models. The problem here is vertex normals, which M3's use, but 3ds Max hates. 3ds Max likes to calculate its vertex normals on the fly using smoothing groups, which is great, but it means you can't use custom vertex normals without a modifier. This is a problem when importing/exporting and if someone has a 3ds Max solution that bypasses using the modifier I'd love to hear it (I don't think there is one, besides designing the script to use smoothing groups instead).
My advice, add an 'edit normals' modifier to your mesh and mess around with it to try and get the correct smoothing. The script directly accesses the vertex normals through the modifier so you should be able to fix smoothing errors through experimentation with the modifier. In the future I hope to code in an algorithm to handle smoothing groups in 3ds Max properly on export, however the math behind such an algorithm is pretty complex and I've yet to see any example code of it anywhere. I'd love to have smoothing groups applied on import too, but again the math I just can't do. If anyone knows how to convert vertex normals to smoothing groups and smoothing groups to vertex normals, please enlighten me.
0
@MangledMind: Go
That looks like the keyboard texture that the engine uses when a model references an invalid texture. This must mean you have:
If the textures are being applied properly in 3ds Max, and you're resaving the textures as 32 bit in photoshop, then you must not be importing the texture into the map correctly. The default 'internal directory' set in the M3 exporter is used to define what folders you'll be placing the textures into within your map. By default it's 'Assets\Textures\' and if you don't import textures into this folder in the map the M3 will incorrectly reference the texture and you'll get the funky keyboard texture you're seeing in the screenshot.
For example, if you're trying to apply the map 'Worgen_diffuse.tga' to your model you'd first apply the texture to your model in 3ds Max so that the model exports with the path properly. Then in your map you'd import the TGA and place it in the 'Assets\Textures\' path and THEN import the model. If you import the texture first, the model should appear in the editor textured.
Bare in mind when importing some M2's there are meshes that are relevant to particles which should be removed and for characters there's meshes that are only present with certain character configurations (setup in the DBC files, if I update this further in the future I'll most likely add better support for importing characters).
I'm back at uni now and with the game released I'm leagueing quite a bit with what little spare time I have. It's doubtful I'll be able to provide any updates to the plugins for awhile but I still do have plans for them in the future.
0
@IskatuMesk: Go
Grab the new script bundle here. Removed all the activeX controls and replaced them with dotnet controls, so everything should work on 64-bit operating systems and 64-bit max. It was a bit of a pain to learn so much about dotnet controls so I hope the hard work is appreciated :P. I'm going to be busy with Uni work soon, so I probably won't be doing much in the way of updating the plugins.
My final goals are to add particle/ribbon support to the importers/exporters, do some tutorials on how to use the plugins and to see about coding something for Blender at some stage. I wish I could program C plus plus programs that would do straight conversions instead of having to use 3ds Max as a medium for conversion too. Doubtful I'll get around to doing that.
@jakpe: Go
Hopefully I can put a tutorial up soon on how to export to the M3 format and get the models properly textured into the Starcraft 2 editor. I'll need more details about your problem to troubleshoot it. Make sure your textures render in the importer window so it confirms the Starcraft 2 editor can understand the texture file. Import textures first then models, and make sure you import textures into the 'Assets\Textures' path or whatever you set the texture path to be in 3ds Max as the internal path. If you have textures properly imported and the model still doesn't appear textured, try restarting the whole Starcraft 2 editor or closing and reloading your map as this is known to fix alot of texture problems.
0
@IskatuMesk: Go
Looking into the problem now...
I wish it wasn't so complex, I'd prefer a straight conversion myself. The problem stems from using maxscript to code the plugin as I cannot use the CPP libraries to access MPQ's. World of Warcraft models can be heavily entangled with DBC definitions, which is how alot of models have different body textures applied without having multiple model definitions. In these instances I've tried to give the bitmaps logical names, such as 'Skin1' which means Creature Skin1 and 'Items' which usually means capes and such.
The people coding WoWModelViewer think they've made the .anim files external to save on WoW memory demands as rarer animations for the model are stored in these files and only called when they're used rather than pre-loaded. The .SKIN files are external because only one of them is used at a time and it is again a waste of memory to have them all defined in the one model when only one is usually needed to be loaded.
I think it'd be alot easier and faster to execute if I coded a CPP plugin converter that can access the MPQ's. That way I could reference the DBC files without having to force the end user to extract any himself. It also means I could access all the .anim and .skin files automatically. Perhaps in the future I'll make something like that but for now I'm a little burned out on all this stuff. Uni break is almost over so my commitment to importers and exporters will not be as solid.
Edit: Sorry IskatuMesk, I didn't realise the activeX controls would create compatibility issues. I'll look into developing a solution. Compatibility errors are the devil.
Edit2: I'm reading about a possible solution here: http://blog.duber.cz/3ds-max/farewell-activex. Converting to dot.net controls instead. If it works properly should be a relatively quick fix. Seems Microsoft pulled the plug on activeX controls, so they're not being compiled in 64-bit.
0
@acidragoon: Go
Thanks, I'm trying to fix the stupid ratio now so it embeds properly. I'll try and update it properly, I have a feeling it'll make front page and I'd prefer it didn't look like crap ><
0
Hey guys, due to popular demand I decided to rework my old M2 Importer script for 3ds Max so that it would work with the latest World of Warcraft models (WotLK and Cataclysm). It's been designed for WotLK models but fortunately it seems Cataclysm will not introduce major changes to the model format and so the importer should work just fine once Cataclysm goes live too. You can grab the script bundled with my other M3 scripts here.
I'll need to provide a quick tutorial on how to use the importer as World of Warcraft model files are no longer standalone model files. You have .skin and .anim files in addition to the actual .m2 file. This makes importing messy (especially coding the script, believe me) but there's an easy and quick way to do it. Get a hold of an MPQ extractor, personally I recommend Ladik's MPQ Editor. You'll need to extract a file from your WoW MPQ's if you want your animations to be named. It's called 'AnimationData.dbc', it contains all the names of the animations that WoW uses, and it's located in your language MPQ's (i.e. in Patch-enUS-3.MPQ). Once you're done extracting the file, make sure you close the MPQ so it's no longer being accessed.
Next, grab the latest version of the WoWModelViewer which can be downloaded for free here. Find the model you want to import into max and load it up in the model viewer. Once it loads, go to File->Export Textures...
Now when the new dialog pops up, click on 'Export All' and 'Export All to TGA'. Make sure 'Path Preserved' is unchecked.
The exported files will be located in your WoWModelViewer directory in the 'Export' folder. I recommend cutting and pasting them to another location so they don't get mixed up with future exports. Now head into 3ds Max. When you open up the M2 Importer, you'll notice a settings button you should click on.
In the settings, you should configure the DBFilesClient path to where you extracted the AnimationData.dbc file using the browse button. This lets the script know where to find the file so it can apply the correct names to animations. Important if you plan to export to M3 later.
If you left 'Import as M3' checked in the settings, the script will automatically scale the model for you (half it's original size seems about correct for matching the size of Starcraft 2 Models) and re-orient the model to face the same way as Starcraft 2 models do. An 'm3root_bone' will be created which can be used to alter the position, rotation and scale of the model without affecting animations. Additionally, it will select to import only Attack, Stand, Death and Run animations (which you can alter on import if you wish) and automatically rename them to M3 convention. In order to control animations, you must select 'M3 - Sequences' from the Utility drop down menu in the MAXScript panel.
Attachments will also automatically be created as Starcraft 2 attachments and given appropriate ID's, but it's not perfect as alot of the attachments have ambiguous function in World of Warcraft models. Finally, Starcraft 2 materials will be setup for you based on a rough conversion of the M2 material definitions. I've tried to name the bitmaps so you know what should go where, as some World of Warcraft textures are assigned through DBC definitions and not within the M2 itself.
Hard-coded M2 textures should be automatically applied if they are in DDS, TGA or PNG format and in the same folder as the model. The TGA textures exported from the WoWModelViewer should be fine in Max, but I've found they won't render in the Starcraft 2 editor without being resaved as 32 bit TGA in Photoshop.
If you follow these instructions it should be relatively easy to export any animated M2 to the M3 format to be used as a Starcraft 2 model. Here's a short video showing the power of the importer/exporter combo in-game. I'm not great with the editor but I tried my best to get the concept across. I suck with video editing which explains why the ratio is all off and such when I embed it. Go to the actual video it comes up a bit better :(.
Cheers,
- NiN
0
I've updated the MDX script. I stopped it crashing on some models and improved the way it does animations in max so you no longer get weird interpolations between animations. This fixes the Archer models animations for instance. Also, I added some very basic conversion code for converting attachments and sequence names into the M3 format.
The update can be found bundled with the other M3 scripts here.