I've been pretty busy actually but thanks for your concern! A fair bit of house keeping in this update. I've added support for custom maps in 3ds Max, so you can practically have any kind of bitmap. This means you can use .OGV's as textures however keep in mind that Max itself does not support the format, so it won't be rendered. However the filepath will be exported within the M3 so you can later import the file into your map for the M3 to reference. Just be aware that not all maps are supported by the Starcraft 2 engine. I haven't tried AVI or anything but I discovered they've pulled the plug on .png support, which is strange.
I've added some extra bitmap options too, for UV tiling and a bitmap brightness multiplier. I patched up some bugs that people have been telling me about and I've provided support for exporting hidden or frozen scene objects if you want.
I've also updated the MDX Importer so that it no longer crashes on certain models and I've improved how the animations look in 3ds Max so that they no longer interpolate incorrectly. I've also coded some incredibly simple conversion into the importer so that it converts attachments to M3 better and corrects some of the sequence names to fit the M3 format more properly.
For the importer, I've managed to finally conquer gimbal lock and the animations will no longer suffer from it in 3ds max. However I had to change the rotation controller to achieve the affect and this may upset people, I'll see how feedback goes on that.
I've hit a bit of a roadblock on the M2 importer, but I hope to get passed it soon. Models partially import correctly, but most animations are garbled. The processing times are also huge! 20 seconds for the murloc. Not sure how I'm going to bring that down with maxscript being so slow.
Make sure you're using the same texture paths as you export the model with. When you export there's an option for 'Internal Texture Path', make sure it's checked. Let's say you decided to use the default texture path of 'Assets/Textures/' then when you import the texture into the map, you'll have to make sure it's in that exact path.
For example, say you're using a texture on your custom model called 'diffuse.dds'. In the import manager, you would import the dds file into your map and set its path to 'Assets\Textures\' and you'll see the import manager will adjust to show folders and in the last folder Textures you should have 'diffuse.dds' sitting there. Now it's important to save the map so the texture is imported into the map properly with that exact path. Now, import your model into the map or add the model through the previewer and the texture should appear on the model properly.
I just pretty much did exactly that and it worked fine. You no longer need to reopen the map it seems, that bug must've been patched. However you can no longer use external paths for textures (applies a generic keyboard texture if you try this now, it seems) and some image formats appear to no longer be supported, such as .png. Why they'd choose to strip the editor of image formats it originally supported baffles me, but there you go.
When I first read the blue post, my stomach turned. I guess the time bomb was always ticking. Perhaps to some people this isn't a big deal at all but to me, it's the message that Blizzard is now sending. It's about respect for your end users and their privacy. Control over my privacy should not be determined by a company, especially one that is profitting from its end users. I'm paying this company for its product and my privacy should be under my control, this isn't the government or the police. The internet can be used in such evil ways. It's never clear who could be sitting on the other side of the monitor and I don't think this is an unrealistic paranoia to have.
To all of you that are saying 'simple, just don't use the forums!' well it's true, I won't use them, but that's not even the point. It's that Blizzard has now extended its power to do something immoral. It's the fact that they've gone too far once and I don't believe it will stop there. I don't know if it's Activision pulling the strings here, that's just speculation, but power moves such as this seem to come from companies that grow too powerful. Ones that have such a customer following they can do no wrong in their eyes, regardless of the consequences to the end user.
What baffles me is that there are reasonable solutions to trolling without having to resort to such extreme measures. People that blame trolls are misdirecting the blame, which lies in how Blizzard moderate their forums. With proper commitment to forum moderation, trollers could be eliminated efficiently without the need for breaching any privacy. It's clear they've opted for the easy way out that absolves them of having to commit any extra resources to forum moderation with very little consideration to the end user, the users that made the company as filthy rich as it is today. I hope Blizzard will reconsider this absurd decision but I find little reason to believe they will. I've always enjoyed the quality of game and the philosophy of Blizzards design team, but for the first time I feel my loyalty wavering.
The 'Use internal path' checkbox controls whether the texture referenced in the M3 is internal to the map/mpq or whether it will use your hard disk drive path for the texture bitmaps. If you want to distribute your maps, using internal paths is a must so you can Import new textures or use Blizzards existing textures and when other people play your map they will be able to see them.
The reason this option even exists is strictly for testing purposes only. With this option off (use HDD path), you can import a model in the previewer and it will be textured properly. If you were using internal paths, it requires that you import every texture into your map, save the map then reload the map. A tedious process if all you want to do is preview how a model looks with its textures.
As of the latest version, you no longer need to merge meshes into one object. This applies to materials aswell, you can apply as many materials to as many different meshes in your scene as you'd like. You can even use the same material for multiple meshes, there's no longer a need to use Multi/sub-object materials and I'd advise against them as it's alot of extra overhead for the exporter to process. I find this is a vast improvement over the old method of jamming everything together but the old method is still supported for backward compatibility (which I hope people appreciate, that was a drain to code!)
For animations, all sequence information is managed by the Sequences UI. You'll find it in the utilities drop down menu as 'M3 - Sequences'. Through this UI you can add/delete animations and manage various settings such as whether it loops, the ranges of the animation, its rarity and its name. Starcraft II models use a naming convention for animations and it must be followed if you want your models to animate correctly. I won't provide examples here, but check out the names of other model animations to get a grasp on the convention. It's fairly logical and common sense, but can cause confusion if you have a misnamed animation.
I just downloaded Blender recently for the first time. Definitely way different to 3ds Max, but I've been looking at some video tutorials and it seems pretty damn good for freeware model software. I've always used 3ds Max and found it does almost anything you'd want, and I find the maxscript language very comfortable to code in. The language is a big thing, as I can whip up code pretty quickly in it.
The downside: 3ds Max is expensive and is mammoth in size for people grabbing the trial version. This alienates alot of people from having access to the software. It frustrates me that the plugins being native to 3ds Max forces people to have access to the program which they may not be able to have. Ideally I would prefer to use a stand alone editor for importing and exporting Starcraft II models, but I do not have the capabilities to code such a program and even if it were possible, it would be extremely primitive compared to well developed modelling software.
So here's what I want to know. Do you think I should code the plugins in Blender instead of 3ds Max due to Blender being freeware and relatively advanced modelling software? Before you scream your approval, keep in mind a few things. I'm only one man, and the 3ds Max plugins have alot of momentum. Converting to python will hinder me considerably and thus all future plugin releases will consequently be delayed. Blender also may not support some of the cool things like custom materials and such which I rely on heavily in 3ds Max, but Blender may also allow me to do better things (like render more M3 effects) than 3ds Max. I don't know the software well enough yet.
I may or may not change to Blender depending on your opinions, but I'd like to hear the fors and againsts for the idea. Thank you all for your time on the matter.
Love your nick. Out of curiousity, are you looking to get into biophysics?
For your problem, texture paths are hardcoded into M3's. Most texture paths I've come across point to the 'Assets/Textures/' MPQ path. You can load up models in the Previewer and load up the appropriate model. You'll see a group of folders off to the right, open up the materials and look for the one that seems to be the main material for the body of the model. Be aware that some materials are for things such as particles and so forth which may not specifically need to be replaced.
I'll use the High Templar as an example. The High Templar's second material has the Diffuse as Templar_Diffuse.dds, the Emissive as Templar_Emissive.dds, etc. These are the main texture files for the model. To replace them, you need to import files into your map and have them occupy the same path as the original files. The original files will exist in the 'Assets/Textures/' MPQ path. So the full diffuse map path will be 'Assets/Textures/Templar_Diffuse.dds'. To replace them, import texture files into the exact same path with the exact same name, then save and reload your map. All textures that were using the original Templar_Diffuse.dds will now be replaced with your new texture. Bare in mind you'll be replacing all instances where the Templar_Diffuse.dds texture is used. To avoid this, you'll have to do some minor model editing to change the internal texture path present in the M3 which I think is outside the scope of what you want to achieve.
Yes they are. Add them through the 'Create' panel under the 'Helpers' tab under the 'Starcraft 2 Objects' group in the drop down list (usually has 'Standard' in it). See the attached screenshot for clarification.
EDIT: Keep in mind, attachments have a naming convention that you must use. The most common ones are supplied in the drop down menu you can see. I think all of them allow you to add numbers to them so you can have more than one. i.e. Ref_Weapon 01, Ref_Hardpoint 02, etc. Check out the names of attachments in other models in the previewer for more examples.
I figured out the problem from the scene file you sent me Triceron, thanks for that. The problem is that you have zero weights included for some vertices and the script is handling them incorrectly. You'll have to zero the weights for now, but in the next update I'll make it so zero weights aren't included when exporting as M3. Check the attached screenshot to see how to zero the weights in max.
The newest version supports multiple meshes/skins. The updated importer infact imports Starcraft II models as multiple meshes with skins now. Check it out here.
If you can send me any max scene files via PM that cause errors with the export script it would make debugging the problem much easier. Otherwise indicate .mdx models that are causing you grief so I can try them and figure out the problem.
More details would be great. What model is causing the problem?
Basically, if you send me your problem max scene file if you're comfortable with that I can debug the problem and include a fix in the next update. Either that or indicate the MDX so I can look into it. I'll have a look at the archer model and see if I can figure out what's up there.
Hey Triceron. If you could send me the max scene file of the mesh it'd be helpful for debugging the problem and figuring out where the script is going wrong. I've seen this issue in xcorbo's Link mesh so I can look at that too. Perhaps check to see if you have zero weights in max? You can clear them through menu's. Either way I'll look into the issue and see if I can figure out a solution. Cheers.
Import with the M3 option and use the M3 Sequences menu to navigate the animations (it copies the MDX sequence information into the M3 Animation UI). I've noticed the odd interpolations too, I have a solution for that. They need base poses either side of each animation to prevent crazy interpolations in 3ds Max. If I update the script in the future I'll add that in. Hrm, what you're talking about is a FPS issue. Currently the MDX's import at 1000 FPS. I can add a quick update sometime to the script that allows you to change the FPS on import. Otherwise I know of no method to alter animation keyframes based on a new FPS, but if anyone does I'd like to know about it.
I may put up a tutorial soonish on how to do this. It involves importing a Warcraft III model (MDX) into 3ds Max and after tweaking some settings exporting it as a Starcraft 2 model (M3). This thread has links to the updated import script for Warcraft III models. Stay tuned for a tutorial for 3ds Max.
A converter from MDX->M3 may be possible as a batch utility. I don't have the CPP programming knowledge to design it though. At the moment, you're stuck with using 3ds Max as the middle man until either someone else starts making apps in a different language or I find time to make some myself. The latter is highly unlikely at this stage. I realise the majority of people don't have access to 3ds Max or knowledge on how to use it properly, but tutorials should be coming along shortly.
Exactly, you can't hide any part of the rig. I forgot to mention that the exporter purposely ignores hidden/frozen objects. This means if you have an object in the rig that has a parent that is hidden, it's going to crash because the script won't add the hidden object into the bone list to be sorted and linked together. I'm going to make the ignore hidden/frozen objects a selectable option in future releases. I can also provide an error message or have the script take a different course of action now that I know what causes that error.
Hrm, not sure tigerija. Maybe I can send you a modified version of the script so I can debug it. I'll PM it to ya. I'll just need a screenshot of the section of code that seems to be causing the fault.
Run the script from the maxscript part. You mustn't have put the script in the Startup folder. It needs to be loaded by 3ds Max first before the export option will appear in the drop down menu.
I've updated the MDX Import/Export script for 3ds Max originally created by Philip Laing in 2002. Just as I thought, it works really well with the M3 exporter update. I corrected a few serious errors in the script so it should work on all versions of 3ds Max now. Animations now work properly too thanks to borrowed code from the M3 Importer. You can grab the updated script here.
If you leave the Import as M3 option ticked, it'll automatically scale the model down (to 1/100 if you're curious, Warcraft III models are roughly 100 times larger in size than SC2 models), add attachment objects and update with M3 sequence information aslong as you have the right version of sc2objects.ms already loaded. You'll find you still have to tweak the model a little, such as removing unneccesary meshes/bones/lights. Additionally, you'll have to apply materials to the model manually. The script doesn't actually grab the material data properly and even if it did, Warcraft III models use .blp textures and have a slightly different material setup to M3's. So the script leaves the material settings up to you.
I've only updated the importer side of the script, the exporter side may not work at all I have no idea. The main purpose of the script is to convert MDX to M3's with 3ds Max acting as an intermediate. I suppose it could be useful for Warcraft III modders too but I imagine they will use Magos' awesome editor or some other means of importing/exporting MDX's.
A major thanks to Philip Laing for providing the original open source code for the importer/exporter for me to work with. Without it, this would have been alot of trouble to create myself and I don't know if I'd have done it. I want to thank BlinkBoy (known as BlinkHawk around mapster) from the hive workshop also, as his advice on MDX animation was helpful for getting the rotation animations correct.
You can now have multiple meshes in a scene and they will be exported as submeshes. For bones to be exported you no longer need to add them all to a skin modifer on the main mesh. I really think the update will clear up alot of the errors people have been getting. M3's will now import in the new format, with a seperate mesh for each submesh and with skin modifiers that only contain the bones that affect the vertices of the mesh. I've really striven for backward compatibility with old models imported or created with the old plugin versions so please let me know if anyone encounters severe problems working with older models.
I've updated the way materials are handled, there are different 'types' which I'll expand on in the future. At the moment you can only have 'Terrain (Null)' and 'Normal'. Terrain works just as it sounds, rendering terrain for that particular material instead of a specified material. You won't see that render in 3ds max though, I was thinking about bundling a dirt terrain texture with the plugins but the dds file is a bit too big. It's still an experimental material at the moment anyhow.
Decals are now supported. The way decals work, they're applied through different UV channels. I've hardcoded diffuse/spec/emissive/etc. to all work through UV channel 1 at the moment. Decals can be customly set to a different UV channel, but just be aware to map decals on to a mesh you'll have to work in a different UV channel than 1. Attachments are now supported as custom objects too. They can be found in the Create panel, under the Helpers tab. You'll see a drop down list (has 'Standard' in it by default) that you can select 'Starcraft 2 Objects' from. You'll find attachments in there. When I finally get around to doing particle and ribbon emitters I'll be placing these kind of custom objects under this group too.
Also xcorbo I updated the code so you can now use any animation range for animations. i.e. you can have Stand and Walk use the same animation ranges.
I'll see about doing some tutorials for this update as it's moving in the direction I want it to go. The MDX importer works really good with it too so it won't be too long before I'll be able to release that aswell :D. Cheers guys.
0
New update guys! Update can be found here.
I've been pretty busy actually but thanks for your concern! A fair bit of house keeping in this update. I've added support for custom maps in 3ds Max, so you can practically have any kind of bitmap. This means you can use .OGV's as textures however keep in mind that Max itself does not support the format, so it won't be rendered. However the filepath will be exported within the M3 so you can later import the file into your map for the M3 to reference. Just be aware that not all maps are supported by the Starcraft 2 engine. I haven't tried AVI or anything but I discovered they've pulled the plug on .png support, which is strange.
I've added some extra bitmap options too, for UV tiling and a bitmap brightness multiplier. I patched up some bugs that people have been telling me about and I've provided support for exporting hidden or frozen scene objects if you want.
I've also updated the MDX Importer so that it no longer crashes on certain models and I've improved how the animations look in 3ds Max so that they no longer interpolate incorrectly. I've also coded some incredibly simple conversion into the importer so that it converts attachments to M3 better and corrects some of the sequence names to fit the M3 format more properly.
For the importer, I've managed to finally conquer gimbal lock and the animations will no longer suffer from it in 3ds max. However I had to change the rotation controller to achieve the affect and this may upset people, I'll see how feedback goes on that.
I've hit a bit of a roadblock on the M2 importer, but I hope to get passed it soon. Models partially import correctly, but most animations are garbled. The processing times are also huge! 20 seconds for the murloc. Not sure how I'm going to bring that down with maxscript being so slow.
Anyways, hope you guys enjoy the update!
0
@evildemon14: Go
Make sure you're using the same texture paths as you export the model with. When you export there's an option for 'Internal Texture Path', make sure it's checked. Let's say you decided to use the default texture path of 'Assets/Textures/' then when you import the texture into the map, you'll have to make sure it's in that exact path.
For example, say you're using a texture on your custom model called 'diffuse.dds'. In the import manager, you would import the dds file into your map and set its path to 'Assets\Textures\' and you'll see the import manager will adjust to show folders and in the last folder Textures you should have 'diffuse.dds' sitting there. Now it's important to save the map so the texture is imported into the map properly with that exact path. Now, import your model into the map or add the model through the previewer and the texture should appear on the model properly.
I just pretty much did exactly that and it worked fine. You no longer need to reopen the map it seems, that bug must've been patched. However you can no longer use external paths for textures (applies a generic keyboard texture if you try this now, it seems) and some image formats appear to no longer be supported, such as .png. Why they'd choose to strip the editor of image formats it originally supported baffles me, but there you go.
0
When I first read the blue post, my stomach turned. I guess the time bomb was always ticking. Perhaps to some people this isn't a big deal at all but to me, it's the message that Blizzard is now sending. It's about respect for your end users and their privacy. Control over my privacy should not be determined by a company, especially one that is profitting from its end users. I'm paying this company for its product and my privacy should be under my control, this isn't the government or the police. The internet can be used in such evil ways. It's never clear who could be sitting on the other side of the monitor and I don't think this is an unrealistic paranoia to have.
To all of you that are saying 'simple, just don't use the forums!' well it's true, I won't use them, but that's not even the point. It's that Blizzard has now extended its power to do something immoral. It's the fact that they've gone too far once and I don't believe it will stop there. I don't know if it's Activision pulling the strings here, that's just speculation, but power moves such as this seem to come from companies that grow too powerful. Ones that have such a customer following they can do no wrong in their eyes, regardless of the consequences to the end user.
What baffles me is that there are reasonable solutions to trolling without having to resort to such extreme measures. People that blame trolls are misdirecting the blame, which lies in how Blizzard moderate their forums. With proper commitment to forum moderation, trollers could be eliminated efficiently without the need for breaching any privacy. It's clear they've opted for the easy way out that absolves them of having to commit any extra resources to forum moderation with very little consideration to the end user, the users that made the company as filthy rich as it is today. I hope Blizzard will reconsider this absurd decision but I find little reason to believe they will. I've always enjoyed the quality of game and the philosophy of Blizzards design team, but for the first time I feel my loyalty wavering.
0
@Serrehsieth: Go
The 'Use internal path' checkbox controls whether the texture referenced in the M3 is internal to the map/mpq or whether it will use your hard disk drive path for the texture bitmaps. If you want to distribute your maps, using internal paths is a must so you can Import new textures or use Blizzards existing textures and when other people play your map they will be able to see them.
The reason this option even exists is strictly for testing purposes only. With this option off (use HDD path), you can import a model in the previewer and it will be textured properly. If you were using internal paths, it requires that you import every texture into your map, save the map then reload the map. A tedious process if all you want to do is preview how a model looks with its textures.
@IskatuMesk: Go
As of the latest version, you no longer need to merge meshes into one object. This applies to materials aswell, you can apply as many materials to as many different meshes in your scene as you'd like. You can even use the same material for multiple meshes, there's no longer a need to use Multi/sub-object materials and I'd advise against them as it's alot of extra overhead for the exporter to process. I find this is a vast improvement over the old method of jamming everything together but the old method is still supported for backward compatibility (which I hope people appreciate, that was a drain to code!)
For animations, all sequence information is managed by the Sequences UI. You'll find it in the utilities drop down menu as 'M3 - Sequences'. Through this UI you can add/delete animations and manage various settings such as whether it loops, the ranges of the animation, its rarity and its name. Starcraft II models use a naming convention for animations and it must be followed if you want your models to animate correctly. I won't provide examples here, but check out the names of other model animations to get a grasp on the convention. It's fairly logical and common sense, but can cause confusion if you have a misnamed animation.
0
I just downloaded Blender recently for the first time. Definitely way different to 3ds Max, but I've been looking at some video tutorials and it seems pretty damn good for freeware model software. I've always used 3ds Max and found it does almost anything you'd want, and I find the maxscript language very comfortable to code in. The language is a big thing, as I can whip up code pretty quickly in it.
The downside: 3ds Max is expensive and is mammoth in size for people grabbing the trial version. This alienates alot of people from having access to the software. It frustrates me that the plugins being native to 3ds Max forces people to have access to the program which they may not be able to have. Ideally I would prefer to use a stand alone editor for importing and exporting Starcraft II models, but I do not have the capabilities to code such a program and even if it were possible, it would be extremely primitive compared to well developed modelling software.
So here's what I want to know. Do you think I should code the plugins in Blender instead of 3ds Max due to Blender being freeware and relatively advanced modelling software? Before you scream your approval, keep in mind a few things. I'm only one man, and the 3ds Max plugins have alot of momentum. Converting to python will hinder me considerably and thus all future plugin releases will consequently be delayed. Blender also may not support some of the cool things like custom materials and such which I rely on heavily in 3ds Max, but Blender may also allow me to do better things (like render more M3 effects) than 3ds Max. I don't know the software well enough yet.
I may or may not change to Blender depending on your opinions, but I'd like to hear the fors and againsts for the idea. Thank you all for your time on the matter.
Cheers,
NiN
0
@Biophysicist: Go
Love your nick. Out of curiousity, are you looking to get into biophysics?
For your problem, texture paths are hardcoded into M3's. Most texture paths I've come across point to the 'Assets/Textures/' MPQ path. You can load up models in the Previewer and load up the appropriate model. You'll see a group of folders off to the right, open up the materials and look for the one that seems to be the main material for the body of the model. Be aware that some materials are for things such as particles and so forth which may not specifically need to be replaced.
I'll use the High Templar as an example. The High Templar's second material has the Diffuse as Templar_Diffuse.dds, the Emissive as Templar_Emissive.dds, etc. These are the main texture files for the model. To replace them, you need to import files into your map and have them occupy the same path as the original files. The original files will exist in the 'Assets/Textures/' MPQ path. So the full diffuse map path will be 'Assets/Textures/Templar_Diffuse.dds'. To replace them, import texture files into the exact same path with the exact same name, then save and reload your map. All textures that were using the original Templar_Diffuse.dds will now be replaced with your new texture. Bare in mind you'll be replacing all instances where the Templar_Diffuse.dds texture is used. To avoid this, you'll have to do some minor model editing to change the internal texture path present in the M3 which I think is outside the scope of what you want to achieve.
Hopefully that answers your question.
Cheers,
NiN
0
@tigerija: Go
Yes they are. Add them through the 'Create' panel under the 'Helpers' tab under the 'Starcraft 2 Objects' group in the drop down list (usually has 'Standard' in it). See the attached screenshot for clarification.
EDIT: Keep in mind, attachments have a naming convention that you must use. The most common ones are supplied in the drop down menu you can see. I think all of them allow you to add numbers to them so you can have more than one. i.e. Ref_Weapon 01, Ref_Hardpoint 02, etc. Check out the names of attachments in other models in the previewer for more examples.
@Triceron: Go
I figured out the problem from the scene file you sent me Triceron, thanks for that. The problem is that you have zero weights included for some vertices and the script is handling them incorrectly. You'll have to zero the weights for now, but in the next update I'll make it so zero weights aren't included when exporting as M3. Check the attached screenshot to see how to zero the weights in max.
0
@Cyb3rD3lux3: Go
The newest version supports multiple meshes/skins. The updated importer infact imports Starcraft II models as multiple meshes with skins now. Check it out here.
@Bouda456: Go & @IskatuMesk: Go
If you can send me any max scene files via PM that cause errors with the export script it would make debugging the problem much easier. Otherwise indicate .mdx models that are causing you grief so I can try them and figure out the problem.
@Metatr0n: Go
More details would be great. What model is causing the problem?
Basically, if you send me your problem max scene file if you're comfortable with that I can debug the problem and include a fix in the next update. Either that or indicate the MDX so I can look into it. I'll have a look at the archer model and see if I can figure out what's up there.
0
@Triceron: Go
Hey Triceron. If you could send me the max scene file of the mesh it'd be helpful for debugging the problem and figuring out where the script is going wrong. I've seen this issue in xcorbo's Link mesh so I can look at that too. Perhaps check to see if you have zero weights in max? You can clear them through menu's. Either way I'll look into the issue and see if I can figure out a solution. Cheers.
0
@IskatuMesk: Go
Import with the M3 option and use the M3 Sequences menu to navigate the animations (it copies the MDX sequence information into the M3 Animation UI). I've noticed the odd interpolations too, I have a solution for that. They need base poses either side of each animation to prevent crazy interpolations in 3ds Max. If I update the script in the future I'll add that in. Hrm, what you're talking about is a FPS issue. Currently the MDX's import at 1000 FPS. I can add a quick update sometime to the script that allows you to change the FPS on import. Otherwise I know of no method to alter animation keyframes based on a new FPS, but if anyone does I'd like to know about it.
0
@JLogan: Go
I may put up a tutorial soonish on how to do this. It involves importing a Warcraft III model (MDX) into 3ds Max and after tweaking some settings exporting it as a Starcraft 2 model (M3). This thread has links to the updated import script for Warcraft III models. Stay tuned for a tutorial for 3ds Max.
A converter from MDX->M3 may be possible as a batch utility. I don't have the CPP programming knowledge to design it though. At the moment, you're stuck with using 3ds Max as the middle man until either someone else starts making apps in a different language or I find time to make some myself. The latter is highly unlikely at this stage. I realise the majority of people don't have access to 3ds Max or knowledge on how to use it properly, but tutorials should be coming along shortly.
0
@Omnimmotus: Go
Exactly, you can't hide any part of the rig. I forgot to mention that the exporter purposely ignores hidden/frozen objects. This means if you have an object in the rig that has a parent that is hidden, it's going to crash because the script won't add the hidden object into the bone list to be sorted and linked together. I'm going to make the ignore hidden/frozen objects a selectable option in future releases. I can also provide an error message or have the script take a different course of action now that I know what causes that error.
0
@tigerija: Go
Hrm, not sure tigerija. Maybe I can send you a modified version of the script so I can debug it. I'll PM it to ya. I'll just need a screenshot of the section of code that seems to be causing the fault.
@XYZMuffin: Go
Run the script from the maxscript part. You mustn't have put the script in the Startup folder. It needs to be loaded by 3ds Max first before the export option will appear in the drop down menu.
0
I've updated the MDX Import/Export script for 3ds Max originally created by Philip Laing in 2002. Just as I thought, it works really well with the M3 exporter update. I corrected a few serious errors in the script so it should work on all versions of 3ds Max now. Animations now work properly too thanks to borrowed code from the M3 Importer. You can grab the updated script here.
If you leave the Import as M3 option ticked, it'll automatically scale the model down (to 1/100 if you're curious, Warcraft III models are roughly 100 times larger in size than SC2 models), add attachment objects and update with M3 sequence information aslong as you have the right version of sc2objects.ms already loaded. You'll find you still have to tweak the model a little, such as removing unneccesary meshes/bones/lights. Additionally, you'll have to apply materials to the model manually. The script doesn't actually grab the material data properly and even if it did, Warcraft III models use .blp textures and have a slightly different material setup to M3's. So the script leaves the material settings up to you.
I've only updated the importer side of the script, the exporter side may not work at all I have no idea. The main purpose of the script is to convert MDX to M3's with 3ds Max acting as an intermediate. I suppose it could be useful for Warcraft III modders too but I imagine they will use Magos' awesome editor or some other means of importing/exporting MDX's.
A major thanks to Philip Laing for providing the original open source code for the importer/exporter for me to work with. Without it, this would have been alot of trouble to create myself and I don't know if I'd have done it. I want to thank BlinkBoy (known as BlinkHawk around mapster) from the hive workshop also, as his advice on MDX animation was helpful for getting the rotation animations correct.
0
I've uploaded the new version here.
You can now have multiple meshes in a scene and they will be exported as submeshes. For bones to be exported you no longer need to add them all to a skin modifer on the main mesh. I really think the update will clear up alot of the errors people have been getting. M3's will now import in the new format, with a seperate mesh for each submesh and with skin modifiers that only contain the bones that affect the vertices of the mesh. I've really striven for backward compatibility with old models imported or created with the old plugin versions so please let me know if anyone encounters severe problems working with older models.
I've updated the way materials are handled, there are different 'types' which I'll expand on in the future. At the moment you can only have 'Terrain (Null)' and 'Normal'. Terrain works just as it sounds, rendering terrain for that particular material instead of a specified material. You won't see that render in 3ds max though, I was thinking about bundling a dirt terrain texture with the plugins but the dds file is a bit too big. It's still an experimental material at the moment anyhow.
Decals are now supported. The way decals work, they're applied through different UV channels. I've hardcoded diffuse/spec/emissive/etc. to all work through UV channel 1 at the moment. Decals can be customly set to a different UV channel, but just be aware to map decals on to a mesh you'll have to work in a different UV channel than 1. Attachments are now supported as custom objects too. They can be found in the Create panel, under the Helpers tab. You'll see a drop down list (has 'Standard' in it by default) that you can select 'Starcraft 2 Objects' from. You'll find attachments in there. When I finally get around to doing particle and ribbon emitters I'll be placing these kind of custom objects under this group too.
Also xcorbo I updated the code so you can now use any animation range for animations. i.e. you can have Stand and Walk use the same animation ranges.
I'll see about doing some tutorials for this update as it's moving in the direction I want it to go. The MDX importer works really good with it too so it won't be too long before I'll be able to release that aswell :D. Cheers guys.