@IskatuMesk: Go
Theoretically, yes (with a bit of vector math). Though I don't think its necessary, especially since the center attachment point already exists in the WoW models.
The way it is being done now (at least from what I can see from a cursory glance of the source code), is by just mapping specific WoW attachment id's to their respective SC2 names. This really is the best way to do it. It is simple and doesn't require math (making the overall process much faster).
The only thing we are missing is knowing which specific WoW attachment id maps to the SC2 center one, e.g. we know the WoW attachment called "Base" is the SC2 attachment "Ref_Origin". I'm sure that we will eventually find out what the WoW attachment is that maps to "Ref_Center" (my money is on either "Belly" or "Spell Impact", though I would have to investigate it further to be sure).
For now, we can just use a temporary WoW attachment that we know maps to a similar region in the model (middle-ish) and use that as our Center, which is why I proposed we can use the "Front Hit Region", since we don't need 2 Ref_Target attachments in SC2.
What I have started thinking about now is about all those extra "Ref_Hardpoint" attachments that are getting sent through as well. I wonder how much space we can save on filesize if we thin out the ones we don't really need. Does anyone know what kind of % of final filesize the attachment data for a single attachment takes? Who knows, maybe if we thin out the number of attachments the file is trying to store, we might be able to reduce the final filesize of a single m3 export.
Though I guess optimization of the exporter process is still a long way away :)
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.
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.
@IskatuMesk: Go Theoretically, yes (with a bit of vector math). Though I don't think its necessary, especially since the center attachment point already exists in the WoW models.
The way it is being done now (at least from what I can see from a cursory glance of the source code), is by just mapping specific WoW attachment id's to their respective SC2 names. This really is the best way to do it. It is simple and doesn't require math (making the overall process much faster).
The only thing we are missing is knowing which specific WoW attachment id maps to the SC2 center one, e.g. we know the WoW attachment called "Base" is the SC2 attachment "Ref_Origin". I'm sure that we will eventually find out what the WoW attachment is that maps to "Ref_Center" (my money is on either "Belly" or "Spell Impact", though I would have to investigate it further to be sure).
For now, we can just use a temporary WoW attachment that we know maps to a similar region in the model (middle-ish) and use that as our Center, which is why I proposed we can use the "Front Hit Region", since we don't need 2 Ref_Target attachments in SC2.
What I have started thinking about now is about all those extra "Ref_Hardpoint" attachments that are getting sent through as well. I wonder how much space we can save on filesize if we thin out the ones we don't really need. Does anyone know what kind of % of final filesize the attachment data for a single attachment takes? Who knows, maybe if we thin out the number of attachments the file is trying to store, we might be able to reduce the final filesize of a single m3 export.
Though I guess optimization of the exporter process is still a long way away :)
@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):
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.
@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.
@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.
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.
@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.
@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?
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
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 :)
@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.