This cloaking bug should be fixed with the latest update of the exporter. Interestingly, I found the problem to be part of the emissive map not the specular map but I did locate the problem and it should be fixed now. Head here to grab the latest version. Let me know if it's still bugging out.
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.
Put the textures in your 3dsMax\Maps directory and the script will look there by default
Setup a new maps directory for the script to look in. This can be done through the menu system: Customize->Configure User Paths...->External Paths Tab then click add to add a new directory.
The script iterates through every 'external path' looking for the bitmap file in each.
Collision has been causing quite a few problems I've noticed. As far as I know so far, collision is done through spheres only. I'd have to look closer at the Helion to see how the collision is achieved, but I get the feeling it's done through attachment points. At the moment you can't control the collision sphere for the model on export, it's automatically exported using the extents of the model. Once I get time to update the script, I'd like to add collision sphere support and I'll look into the helion and see how the altered collision in the model works.
The dark templar models have an attachment point in them that is waaaaaaaaaaaaaay out in the middle of nowhere. This is an error with the model itself. If you don't believe me, open the unit up in the previewer and highlight all the attachments. You'll notice one of the attachments is nowhere to be seen. As far as I can tell the attachment is safe to delete, however zoom to extents for the model seems to broken even after deleting the object.
The models are scaled small yes, but you can fix that by using the view perspective button in 3ds max. Looks kind of like a > with an eye in it. It allows you to zoom in on models without them clipping. Should solve all your scale problems.
The error is within the script, which I've been meaning to update. If you select 'export hidden' when you export it will export the object that holds animation data as a bone (which it shouldn't). If you attempt to import back a model that has this 'animation data' bone an error will occur. Once I have spare time and am able to update the script, this problem should be cleared up in the future.
Screenshots would be helpful here. Can you import the model and export it without making any changes without the UV maps being screwed up? The marine uses two UV map channels, one for it's standard bitmaps and an extra one for decal maps. Those factors may be playing a part in why they get screwed up.
Screenshots are always your best resource if you want people to help you your problem.
IskatuMesk is correct, each attachment essentially has a name and the bone it's attached to and takes up roughly 40 or so bytes of data depending on its string size, absolutely nothing percentage-wise. Animations and materials/bitmaps are the largest structures in M3's, animations especially. This is why it's important to export only the animations you need with your WoW models to save on file size.
It interests me what you've described zzPop about the randomised hit points on the model and I think I know where this information may be stored. It's almost certainly the fact that we are not exporting some volume (model matrix) information. There's some matrices present in all models in certain structures of M3's which I've never bothered to clearly define but which probably play a role in spell impact regions for M3's. When I get the time I'll look into this further as I have a few suspects in mind.
All of those are using the same relationships between WoW attachments and M3 attachments as are in my script. I always assumed that 'Ref_Target' was used for missile impacts. I suppose the 'Spell Impact' attachment could be converted to 'Ref_Center' instead and that should fix your problems. Of course I'm not sure the majority of M2 models have 'Spell Impact' attachment points but I don't see why they wouldn't.
A new list would have to be created then, with the M2 with attachment ID 34 being converted to 'Ref_Center'.
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 spells will be the toughest to nail, but we'll keep working on it. Thank you for testing them out and providing feedback, I'll take a look at those that aren't working correctly and see what can be done.
Particle support extends mostly to creature models for the moment, with most of them looking aesthetically as they should. We'll continue to work on the conversion until it is as close to how the original M2 is as possible. Bare in mind ribbon effects are currently not supported. I've made some progress working out the ribbon structure, so hopefully in the future ribbon effects can be converted too.
Many thanks to chuanhsing and cutevisor who are doing all the code additions.. They're working really hard updating the code and alot of effort has been put in to get it right. Thanks guys :D.
There's currently a bug in the new version that fails to export the particle textures which is resulting in the 'square' particles you guys are seeing. This the editor not being able to find the proper texture as it's not being imported into the Starcraft 2 editor due to it not being exported by WMV. This should be fixed up in the next version.
If you're impatient you can manually export the TGA through the 'Export Textures...' option. I've looked over a few models and the M3 particles are very close to how the M2 particles look. A few minor things still need work but overall the particle conversion is looking great!
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.
You shouldn't, alot of the campaign models have death animations integrated into the model (see TaurenSpaceMarine.m3 for an example of this). I'm not sure how it's achieved through the editor, but it's possible to do without having more than one model.
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.
0
@maverck: Go
This cloaking bug should be fixed with the latest update of the exporter. Interestingly, I found the problem to be part of the emissive map not the specular map but I did locate the problem and it should be fixed now. Head here to grab the latest version. Let me know if it's still bugging out.
Those arbiters look wicked by the way.
0
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
0
@Pollux710: Go
Two options:
The script iterates through every 'external path' looking for the bitmap file in each.
0
Collision has been causing quite a few problems I've noticed. As far as I know so far, collision is done through spheres only. I'd have to look closer at the Helion to see how the collision is achieved, but I get the feeling it's done through attachment points. At the moment you can't control the collision sphere for the model on export, it's automatically exported using the extents of the model. Once I get time to update the script, I'd like to add collision sphere support and I'll look into the helion and see how the altered collision in the model works.
0
@Riaction: Go
The dark templar models have an attachment point in them that is waaaaaaaaaaaaaay out in the middle of nowhere. This is an error with the model itself. If you don't believe me, open the unit up in the previewer and highlight all the attachments. You'll notice one of the attachments is nowhere to be seen. As far as I can tell the attachment is safe to delete, however zoom to extents for the model seems to broken even after deleting the object.
The models are scaled small yes, but you can fix that by using the view perspective button in 3ds max. Looks kind of like a > with an eye in it. It allows you to zoom in on models without them clipping. Should solve all your scale problems.
0
@Prlugo: Go
The error is within the script, which I've been meaning to update. If you select 'export hidden' when you export it will export the object that holds animation data as a bone (which it shouldn't). If you attempt to import back a model that has this 'animation data' bone an error will occur. Once I have spare time and am able to update the script, this problem should be cleared up in the future.
0
@Noidealol: Go
Screenshots would be helpful here. Can you import the model and export it without making any changes without the UV maps being screwed up? The marine uses two UV map channels, one for it's standard bitmaps and an extra one for decal maps. Those factors may be playing a part in why they get screwed up.
Screenshots are always your best resource if you want people to help you your problem.
0
@IskatuMesk: Go
IskatuMesk is correct, each attachment essentially has a name and the bone it's attached to and takes up roughly 40 or so bytes of data depending on its string size, absolutely nothing percentage-wise. Animations and materials/bitmaps are the largest structures in M3's, animations especially. This is why it's important to export only the animations you need with your WoW models to save on file size.
It interests me what you've described zzPop about the randomised hit points on the model and I think I know where this information may be stored. It's almost certainly the fact that we are not exporting some volume (model matrix) information. There's some matrices present in all models in certain structures of M3's which I've never bothered to clearly define but which probably play a role in spell impact regions for M3's. When I get the time I'll look into this further as I have a few suspects in mind.
0
@zzPop: Go
All of those are using the same relationships between WoW attachments and M3 attachments as are in my script. I always assumed that 'Ref_Target' was used for missile impacts. I suppose the 'Spell Impact' attachment could be converted to 'Ref_Center' instead and that should fix your problems. Of course I'm not sure the majority of M2 models have 'Spell Impact' attachment points but I don't see why they wouldn't.
A new list would have to be created then, with the M2 with attachment ID 34 being converted to 'Ref_Center'.
0
@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.
0
@HellFire0102: Go
The spells will be the toughest to nail, but we'll keep working on it. Thank you for testing them out and providing feedback, I'll take a look at those that aren't working correctly and see what can be done.
Particle support extends mostly to creature models for the moment, with most of them looking aesthetically as they should. We'll continue to work on the conversion until it is as close to how the original M2 is as possible. Bare in mind ribbon effects are currently not supported. I've made some progress working out the ribbon structure, so hopefully in the future ribbon effects can be converted too.
Many thanks to chuanhsing and cutevisor who are doing all the code additions.. They're working really hard updating the code and alot of effort has been put in to get it right. Thanks guys :D.
0
@zzPop: Go
There's currently a bug in the new version that fails to export the particle textures which is resulting in the 'square' particles you guys are seeing. This the editor not being able to find the proper texture as it's not being imported into the Starcraft 2 editor due to it not being exported by WMV. This should be fixed up in the next version.
If you're impatient you can manually export the TGA through the 'Export Textures...' option. I've looked over a few models and the M3 particles are very close to how the M2 particles look. A few minor things still need work but overall the particle conversion is looking great!
0
@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.
0
@maverck: Go
You shouldn't, alot of the campaign models have death animations integrated into the model (see TaurenSpaceMarine.m3 for an example of this). I'm not sure how it's achieved through the editor, but it's possible to do without having more than one model.
0
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.