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.
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.
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'.
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):
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.
Would it not be possible to just generate an entirely new point in the relative center of the model and then call that center? Can the viewer even guess such a location? Perhaps it could look for a chest or torso bone if they exist or not.
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 :)
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.