This is how normal attacks which have impact points are processed in with the Data Editor.
The normal attack actor class (the one which all attacks are based off of) uses two core a functions when figuring out where the impact point of a particular missile or attack will be. These functions are (by default):
AMVolumesTargets
AMVolumesWeightedPick
What these functions do, is they take all the attachment points (and volume information) of the target model, and generate a x,y,z coordinate within the volume which they return as the "attack impact location" of the target. This is somewhat randomized, which is why a normal attack (especially a missile) 'seems' to hit the target a different locations (you can see this with something like the marauder. When he attacks a target, his missile usually hits randomly within the bounding volume of the target's model).
Now, if, for whatever reason, these functions fail (which they seem to be doing for WoW imported models, probably because of something strange happening in the volume calculation, maybe because it can't find "Ref_Center"?), by default, the base attack class has a default fallback set to the "Center" attachment point.
Now true, we can change what this fallback would be, e.g. we can change it to be the "Ref_Target" that is already coming through from the export, but then we would have to change this fallback for every single attack actor that exists, which could be tedious. Which is why I proposed getting "Center" working.
The "Center" attachment point is found in every native SC2 model. The strange thing is that in some it is static, i.e. doesn't animate (e.g. the zealot model) while in others it animates (e.g. the High Templar model). However, it is always in around the same location (i.e. in the middle of the model). What I'm thinking we can do for now, is change one of the "Ref_Targets" to actually map to "Ref_Center".
Currently you have 2 ref_targets (one coming from front hit regoin and one from rear hit region). SC2 models only have 1 ref_target, which is usually close to where the ref_center is. I was thinking that while we figure out which is the real "center" attachment point on the WoW models (i.e. a static attachment point), we can use "Front Hit Region" as our temporarty "Ref_Center".
What do you think?
On a separate note,
"Head Region" should probably map to "Ref_Head"
and "Above" should probably map to "Ref_Overhead"
From looking at the arrays chuan has posted, they seem to be swapped, which is probably why I was seeing some strange Head and overhead stuff in some models.
True, the overhead is certainly a minor bug. I was more interested in getting the "Center" attachment set up, since pretty much every single missile has Center set to the default fallback as the impact location attachment point.
For some reason, the "volume calculation" query that SC2 does for missile impacts is not working with WoW models, that is why it is trying to default back to "center", however, when it can't even find center, it just breaks to origin, which makes things look weird. (i.e. missles shooting at peoples feet).
Now true, even this can be fixed in galaxy editor, but that would mean going through every single existing attack actor and changing its impact location to custom set up siteOp actors, but that just seems like a royal pain.
We should at least get the "Center" attachment working right.
Overall though, I don't think it is too hard a bug to fix.
By the way, I checked out modelexport_m3.cpp for r458.
I don't see "Ref_Center" in your wxString M3_Attach_Names array, which is prob why its not showing up :P
This maybe throwing your id iteration off when you are populating the m3 attachment name vector, which is why things seem to be off by 1 or 2 for the models. Not sure though, haven't really explored how m2 attachments are setup. Though maybe the bone flag (0x200 Animated) is not set for the "origin", "center" and "overhead" attachment bones?
Either way, hopefully this info helps in sorting out this bug.
Just some quick corrections you may want to make concerning attachments. (not very high priority but it shouldn't be too much effort to fix).
I have looked over some of the attachment points that are coming out of the export process, for the most part, everything seems to be working fine.
However, the attachment points:
Overhead
Head
Center
Don't seem to be in the right position.
The "Overhead" attachment point seems to be swapped with "Head" attachment point in some models, and in other models they both are static (nb. Overhead is a static attachment point over the top of the model's bounding vol, "Head" is the attachment that is connected to the actual model's head and it moves with model animations).
Also, the "Center" attachment point is missing. It is needed mainly for missile impact points, etc. Also note, the "Center" attachment point on existing SC2 models seems to be static as well (i.e. it doesn't move with model animations).
This is the way most existing SC2 models are set up.
From what I can tell, you are in fact exporting the required attachment points, they are just not named correctly, which is why SC2 editor is having a hard time finding them. E.g. the "Center" attachment point is usually being exported as "hardpoint_XX" where XX changes from model to model.
Hope this helps when you are debugging attachment points.
Approach: To be honest I don't see the point for this phase. You can't set it's duration thus it isn't useful for anything other than namesake.
This is not entirely accurate.
"Approach" is the phase that occurs after the unit has been given the order to perform an ability, and before he starts performing it. In essence, it is used when you give a unit an order to cast a spell but he is out of range and must "approach" a valid range in order to cast it. The reason you cannot set the duration is because, by its inherent nature, the duration of this phase is variable, e.g. if you tell a templar to cast psi storm over on the other side of the map, the approach phase will be the time it takes for him to get to a point where he can cast it. During that time, he will be in an "approach" state, which you can break by overriding his orders, or through other actor events.
The usefulness of this phase can be debated, however, from personal experience, I have found this phase to be extremely useful, especially in setting up unit specific AI and intercepting specific user orders.
Good tutorial, however, some steps are somewhat superfluous.
e.g. You don't need separate set of effects & behaviors to raise/lower a unit. A single behavior can accomplish this using the Behavior Modification+ -> unit tab -> height and height time (start/stop) fields. Using it this way gives the added benefit that you can control the setting of various different timings for raise/lower (as well as height) within the same behavior.
Secondly, you didn't mention that the increasing/decreasing of the speed of the knock-back is actually controlled by setting the minimum speed of the target unit. (which also can be done with the single behavior described above). So if you say, want to make a knockback that really punts units far, you do that by increasing the min speed, and not by increasing the force in the force effect.
Also, your use of persistent effects is somewhat convoluted (leading to additional complication that is not really needed). A single periodic effect can pretty much control all aspects of a good knockback spell, be it line, aoe, or single target.
Good to see some excellent progress on this project.
In my mind, the only critical outstanding issues are:
1. Ability to export custom models (i.e. model's you "dress up").
2. Ability to rename animations.
3. Particles.
I think if we can prioritize those three issues and get them done, this will be the tool for people to use when getting WoW model's into SC2. Then all that's left is actually creating a mod, which is the fun part :)
Good to see you finally got this working Chuanhsing. Great work.
I am still looking at creating the interface between the render output and the exporter, which (I believe) will solve your "character models not working" issue. Though given a rather crazy work schedule, I'm not sure I can get to it soon enough :(
That being said, you just made doing just that a lot easier by getting the m3 exporter to work.
No doubt NiN will be happy that this is up and running, since it essentially allows people like me (i.e. those who do not want to have to go through 3ds Max to export a model without editing the model itself) to do so in a straightforward way.
Good job.
ps. By the way, when this is finished (i.e. character exports), this will be the definitive way for people to get WoW models into SC2. All that is left to do now is:
1. Attachments
2. Characters
3. Particle effects
Those are probably the critical work items. NiN has a lot of experience getting the attachments set up just right for SC2. I'm sure he will weigh in here as soon as he can, and lend a hand with that part.
Particle effects are a somewhat different story though.
Yea. I actually went and looked at the source code they have (as well as asked around on their forums). I realized that the functionality was actually initially intended to be supported (in fact, a lot of the busywork that needs to be done for it is already in place in the source code).
I won't go into the specifics here (since this really isn't the place for it) but will say that all that really is left is to build interfaces between some of their existing modules.
I asked around on their forums (see here) about what the status was for this feature, but unfortunately, they got back to me saying that they have put it on indefinite hold since they feel it will violate WoW's TOS (which I didn't really understand) and they don't want to risk implementing a feature which will do so.
I went further and asked them if it would be ok for me to build the functionality for them (since a lot of the heavywork is already in place), but they haven't gotten back to me whether they will be able to host such a feature.
Needless to say, if a more permanent solution is required it might end up having to come from your script's end. Either that, or a whole new system would have to be built (perhaps cutting Max out of the loop) which allows us to have a simpler flow.
Given that MAXscript is a cumbersome beast as far as performance is concerned, it may end up being a worthwhile investment. I guess I'll have to start looking into it.
Skizot and Triceron are right, you'll need to uncheck 'Use material path' and use an internal path in the form of 'Assets/Textures/' and then import the maps to the correct paths through the importer within the editor.
Where do I find this "Use Material Path" checkbox? Right now I can't see any textures when I import into Galaxy (even though I import the textures first into the Assets/Textures/ path). The model and textures and all that appears perfectly in MAX. I even checked the material properties and they are set properly to SC2 specs.
In galaxy, the model shows up, so do the animations, but it is all whitish blue (i.e. no textures apply).
I think the problem is that its not reading the textures properly, but then again, I don't see the "Use material path" checkbox that I can uncheck and force it to use the Assets/Textures/ path that I set up before I export out of Max.
Or does your latest version have Use material path unchecked by default somewhere? If so, then maybe something else is the issue.
Nb. I am using .TGA for my model's textures. When I import them into galaxy it gives me warning along the lines of " (Core: invalid or unexpected object format)". Take note, its a warning, not an outright error.
Could this perhaps be the issue? Do i need to have the textures in some specific format for them to texture the model properly in galaxy?
@zzPop: Go
If you're getting extra meshes then they're defined within the model file and not an error with the importer nor WMV.
Yea its definitely not the importer. In fact, I suspected as much. Though I am surprised why WMV doesn't just export out the model that its rendering. It obviously is already plugged into the show/hide flags that you mention, all they would need to do is to pipe that info out to their exporter and voilla, you get a model with only your selected variations included. Meh, but you are right, this is not a script related thing. Maybe I will go to the WMV forums and hound them there to plug their render pipe into their exporter.
That being said, where can I find the documentation for all these filetypes (m2, m3, mdx etc). I would surmise that for people like me (who aren't really going to be using 3ds max for anything other then a middle step, i.e. we wont be doing any model editing) the best flow would come from a separate app (written in C maybe) which will not only be faster, but could be standalone.
I think that if I can get a hold of the documentation, I can at least get started on trying to make something that simplifies this flow. Or at least investigate the issue.
0
@NiNtoxicated01: Go Let me explain a bit.
This is how normal attacks which have impact points are processed in with the Data Editor.
The normal attack actor class (the one which all attacks are based off of) uses two core a functions when figuring out where the impact point of a particular missile or attack will be. These functions are (by default):
AMVolumesTargetsAMVolumesWeightedPickWhat these functions do, is they take all the attachment points (and volume information) of the target model, and generate a x,y,z coordinate within the volume which they return as the "attack impact location" of the target. This is somewhat randomized, which is why a normal attack (especially a missile) 'seems' to hit the target a different locations (you can see this with something like the marauder. When he attacks a target, his missile usually hits randomly within the bounding volume of the target's model).
Now, if, for whatever reason, these functions fail (which they seem to be doing for WoW imported models, probably because of something strange happening in the volume calculation, maybe because it can't find "Ref_Center"?), by default, the base attack class has a default fallback set to the "Center" attachment point.
Now true, we can change what this fallback would be, e.g. we can change it to be the "Ref_Target" that is already coming through from the export, but then we would have to change this fallback for every single attack actor that exists, which could be tedious. Which is why I proposed getting "Center" working.
The "Center" attachment point is found in every native SC2 model. The strange thing is that in some it is static, i.e. doesn't animate (e.g. the zealot model) while in others it animates (e.g. the High Templar model). However, it is always in around the same location (i.e. in the middle of the model). What I'm thinking we can do for now, is change one of the "Ref_Targets" to actually map to "Ref_Center".
Currently you have 2 ref_targets (one coming from front hit regoin and one from rear hit region). SC2 models only have 1 ref_target, which is usually close to where the ref_center is. I was thinking that while we figure out which is the real "center" attachment point on the WoW models (i.e. a static attachment point), we can use "Front Hit Region" as our temporarty "Ref_Center".
What do you think?
On a separate note,
"Head Region" should probably map to "Ref_Head"
and "Above" should probably map to "Ref_Overhead"
From looking at the arrays chuan has posted, they seem to be swapped, which is probably why I was seeing some strange Head and overhead stuff in some models.
0
@HellFire0102: Go
True, the overhead is certainly a minor bug. I was more interested in getting the "Center" attachment set up, since pretty much every single missile has Center set to the default fallback as the impact location attachment point.
For some reason, the "volume calculation" query that SC2 does for missile impacts is not working with WoW models, that is why it is trying to default back to "center", however, when it can't even find center, it just breaks to origin, which makes things look weird. (i.e. missles shooting at peoples feet).
Now true, even this can be fixed in galaxy editor, but that would mean going through every single existing attack actor and changing its impact location to custom set up siteOp actors, but that just seems like a royal pain.
We should at least get the "Center" attachment working right.
Overall though, I don't think it is too hard a bug to fix.
0
@zzPop: Go
By the way, I checked out modelexport_m3.cpp for r458.
I don't see "Ref_Center" in your wxString M3_Attach_Names array, which is prob why its not showing up :P
This maybe throwing your id iteration off when you are populating the m3 attachment name vector, which is why things seem to be off by 1 or 2 for the models. Not sure though, haven't really explored how m2 attachments are setup. Though maybe the bone flag (0x200 Animated) is not set for the "origin", "center" and "overhead" attachment bones?
Either way, hopefully this info helps in sorting out this bug.
0
Just a quick update on this. I have only really tested this with three models, but the results seem consistent:
Model Name: kaelthas.m3
Bugged Attachments:
--------------------------------------------Model Name: ladyalexstrasa.m3
Bugged Attachments:
--------------------------------------------Model Name: jaina.m3
Bugged Attachments:
By the way, "Center" is "Ref_Center: [e_attachCenter]" in SC2 for the other models.
0
@chuanhsing: Go
Hey Chuanhsing,
Just some quick corrections you may want to make concerning attachments. (not very high priority but it shouldn't be too much effort to fix).
I have looked over some of the attachment points that are coming out of the export process, for the most part, everything seems to be working fine.
However, the attachment points:
Don't seem to be in the right position.
The "Overhead" attachment point seems to be swapped with "Head" attachment point in some models, and in other models they both are static (nb. Overhead is a static attachment point over the top of the model's bounding vol, "Head" is the attachment that is connected to the actual model's head and it moves with model animations).
Also, the "Center" attachment point is missing. It is needed mainly for missile impact points, etc. Also note, the "Center" attachment point on existing SC2 models seems to be static as well (i.e. it doesn't move with model animations).
This is the way most existing SC2 models are set up.
From what I can tell, you are in fact exporting the required attachment points, they are just not named correctly, which is why SC2 editor is having a hard time finding them. E.g. the "Center" attachment point is usually being exported as "hardpoint_XX" where XX changes from model to model.
Hope this helps when you are debugging attachment points.
0
@chuanhsing: Go
Tested the new version, the 'square' artifacts still exist. (tested it with a few bolt spells)
Was there some change in this new version?
0
This is not entirely accurate.
"Approach" is the phase that occurs after the unit has been given the order to perform an ability, and before he starts performing it. In essence, it is used when you give a unit an order to cast a spell but he is out of range and must "approach" a valid range in order to cast it. The reason you cannot set the duration is because, by its inherent nature, the duration of this phase is variable, e.g. if you tell a templar to cast psi storm over on the other side of the map, the approach phase will be the time it takes for him to get to a point where he can cast it. During that time, he will be in an "approach" state, which you can break by overriding his orders, or through other actor events.
The usefulness of this phase can be debated, however, from personal experience, I have found this phase to be extremely useful, especially in setting up unit specific AI and intercepting specific user orders.
0
Good tutorial, however, some steps are somewhat superfluous.
e.g. You don't need separate set of effects & behaviors to raise/lower a unit. A single behavior can accomplish this using the Behavior Modification+ -> unit tab -> height and height time (start/stop) fields. Using it this way gives the added benefit that you can control the setting of various different timings for raise/lower (as well as height) within the same behavior.
Secondly, you didn't mention that the increasing/decreasing of the speed of the knock-back is actually controlled by setting the minimum speed of the target unit. (which also can be done with the single behavior described above). So if you say, want to make a knockback that really punts units far, you do that by increasing the min speed, and not by increasing the force in the force effect.
Also, your use of persistent effects is somewhat convoluted (leading to additional complication that is not really needed). A single periodic effect can pretty much control all aspects of a good knockback spell, be it line, aoe, or single target.
Other then that, this is a good basic tutorial.
0
The latest version of DEV WORK has a UI and a list that is populated with the current model's animations.
I believe it is under export options->m3
0
Good to see some excellent progress on this project.
In my mind, the only critical outstanding issues are:
1. Ability to export custom models (i.e. model's you "dress up").
2. Ability to rename animations.
3. Particles.
I think if we can prioritize those three issues and get them done, this will be the tool for people to use when getting WoW model's into SC2. Then all that's left is actually creating a mod, which is the fun part :)
0
@chuanhsing: Go
Good to see you finally got this working Chuanhsing. Great work.
I am still looking at creating the interface between the render output and the exporter, which (I believe) will solve your "character models not working" issue. Though given a rather crazy work schedule, I'm not sure I can get to it soon enough :(
That being said, you just made doing just that a lot easier by getting the m3 exporter to work.
No doubt NiN will be happy that this is up and running, since it essentially allows people like me (i.e. those who do not want to have to go through 3ds Max to export a model without editing the model itself) to do so in a straightforward way.
Good job.
ps. By the way, when this is finished (i.e. character exports), this will be the definitive way for people to get WoW models into SC2. All that is left to do now is:
1. Attachments
2. Characters
3. Particle effects
Those are probably the critical work items. NiN has a lot of experience getting the attachments set up just right for SC2. I'm sure he will weigh in here as soon as he can, and lend a hand with that part.
Particle effects are a somewhat different story though.
0
@NiNtoxicated01: Go
Yea. I actually went and looked at the source code they have (as well as asked around on their forums). I realized that the functionality was actually initially intended to be supported (in fact, a lot of the busywork that needs to be done for it is already in place in the source code).
I won't go into the specifics here (since this really isn't the place for it) but will say that all that really is left is to build interfaces between some of their existing modules.
I asked around on their forums (see here) about what the status was for this feature, but unfortunately, they got back to me saying that they have put it on indefinite hold since they feel it will violate WoW's TOS (which I didn't really understand) and they don't want to risk implementing a feature which will do so.
I went further and asked them if it would be ok for me to build the functionality for them (since a lot of the heavywork is already in place), but they haven't gotten back to me whether they will be able to host such a feature.
Needless to say, if a more permanent solution is required it might end up having to come from your script's end. Either that, or a whole new system would have to be built (perhaps cutting Max out of the loop) which allows us to have a simpler flow.
Given that MAXscript is a cumbersome beast as far as performance is concerned, it may end up being a worthwhile investment. I guess I'll have to start looking into it.
0
I'm assuming I would need photoshop to do the conversion? is there an easier way to convert from TGA to DDS?
The reason I have it as TGA is since that is the format WMV spits out when it does a combined texture dump on export.
What would I need to do the TGA to DDS conversion?
Thanks for the help.
edit:
Nvm, I used a random googled TGA to DDS converter and now it works fine.
Thanks again. :)
0
Where do I find this "Use Material Path" checkbox? Right now I can't see any textures when I import into Galaxy (even though I import the textures first into the Assets/Textures/ path). The model and textures and all that appears perfectly in MAX. I even checked the material properties and they are set properly to SC2 specs.
In galaxy, the model shows up, so do the animations, but it is all whitish blue (i.e. no textures apply).
I think the problem is that its not reading the textures properly, but then again, I don't see the "Use material path" checkbox that I can uncheck and force it to use the Assets/Textures/ path that I set up before I export out of Max.
Or does your latest version have Use material path unchecked by default somewhere? If so, then maybe something else is the issue.
Nb. I am using .TGA for my model's textures. When I import them into galaxy it gives me warning along the lines of " (Core: invalid or unexpected object format)". Take note, its a warning, not an outright error.
Could this perhaps be the issue? Do i need to have the textures in some specific format for them to texture the model properly in galaxy?
0
Yea its definitely not the importer. In fact, I suspected as much. Though I am surprised why WMV doesn't just export out the model that its rendering. It obviously is already plugged into the show/hide flags that you mention, all they would need to do is to pipe that info out to their exporter and voilla, you get a model with only your selected variations included. Meh, but you are right, this is not a script related thing. Maybe I will go to the WMV forums and hound them there to plug their render pipe into their exporter.
That being said, where can I find the documentation for all these filetypes (m2, m3, mdx etc). I would surmise that for people like me (who aren't really going to be using 3ds max for anything other then a middle step, i.e. we wont be doing any model editing) the best flow would come from a separate app (written in C maybe) which will not only be faster, but could be standalone. I think that if I can get a hold of the documentation, I can at least get started on trying to make something that simplifies this flow. Or at least investigate the issue.