I don't really know Max at all, but my guess from the image is... it looks like you have 2-sided polygons (?). Either that, or some issue with Normals.
I worked out the final (?) piece of the puzzle to get the SCII-native (well, exported from Max, not the WoW Model Viewer) .m3 files working... at least a 'workable' solution. The problem I was having was with the IREF matrices. I was using them fine to orient the bones for skinning the mesh, but I also needed to add 'that' pose/bone-positioning as a 'bind-pose' within the animation timeline (I typically do that at frame -1)... this preserves the pose in the scene, for future export purposes, or if any skinning adjustments need to be made.
The problem I was having with doing that is that when adding a pose built from the IREF matrices, that only required a translation key and a rotation key, but I was not adding any scale key... so - same problem I was running into in general with the animations - because other keyframes _did_ contain scale keys, that scaling was being carried over into my 'bind-pose-frame' and screwing up the pose. The remedy was simple enough - I just added a 1.0/1.0/1.0 scale key at the bind-pose-frame. I can now animate the document to that frame and have the bones lined up with the mesh in it's un-deformed state (ie. how it was loaded and then skinned to the bones, which were set to the IREF matrices).
So... that still leaves a bit of a question-mark surrounding the trans/rot/scale values that are part of the bones themselves... whether by design or not, in 'some' files, the pose generated by those values is definately just a frame of one of the animations of the figure (like the 'walk' animation mentioned earlier). I have no idea if the original/source .m3 files are set up like this or not. I'm currently still using that pose as somewhat of a 'base-pose' that I plug in between animations, but I wouldn't really need to (in the case where it's a mid-stride walking pose, it kinda doesn't make sense...), but it doesn't hurt anything.
With all the above in mind, I still am having some visual issues with some of the SCII-native figures (like Kerrigan), but they apear to either be a problem with the data/file (not likely, since noone else is mentioning any problems) or some issue with how Cinema 4D does the order of operations (ie. in what order it's applying the translation/rotation/scale keys). Some poses just look goofy - like her shoulder is dislocated or her hand is disconnected from her arm when it's on her hip, etc. (since noone's reporting those issues, I assume they aren't present in Max or the game). All of the WoW-converted models appear to be working pretty much exactly as expected (no visual errors in the animations at all), but they also tend not to have the same level of sporatic scaling mixed in throughout the skeletal structure as the SCII-native files do.
Anyway, I just wanted to update you on my latest progress and thoughts.
Not to interupt your guys's extremely advanced conversation about 3d modeling...
but from your guys's perspective... what program would be my best bet to start learning modeling/ texturing, and then be able to import into SC2.
With out having to buy anything?
Hi Soul,
I think that final line kinda defines the (or at least my) answer... 'Blender 3D" (free/open-source 3d modeling app). I haven't looked into the current state of it's .m3 file support, but I know that it does have 'some' sort of plugin under development (possibly only 'import' ?). As to getting files back into SCII, maybe someone else will have a more complete answer for you (maybe there's some path that takes you through additional free apps and other exportable file formats, like the WoW model viewer or something).
If you just want to re-texture, then you'll just need to be able to load the .dds files into some paint program (or convert them to a format that some paint program can load), make your changes and save them back out. You might also want to be able to 'import' the .m3 mesh file to test your new bitmaps, but if you're not changing the mesh itself, you wouldn't necessarily need to be able to re-export the .m3 file, etc.
@Phygit: Go
...
Finally, I'm curious as to your motivation for designing an import script for the format. You don't own the game, I'll assume by choice. This presents the complex task of designing an importer based on models that aren't natively generated M3's. It means you'll have an incomplete importer that's extremely difficult to debug if people have problems importing native Starcraft 2 models, which is definitely a possibility considering the negative scaling problems I've mentioned earlier. So I'm wondering what your intentions are exactly, whether the import script is to be expanded or an export script is to be developed, or whether this is just a hobby you enjoy doing in your spare time. It's all good either way, I'm just curious :).
Cheers. I'm liking the discussion taking place and I hope we get this all figured out in the future.
Let me just give you the short-version...
I have other plugin code that deals with game-oriented file formats.
I was/am in the process of developing a '.dds' bitmap file Import/Export plugin for Cinema 4D...
...that plugin handles/accounts for color/alpha channel swapping often used by games (like SCII does with it's Normal Maps)...
...when I asked the populace for examples of .dds files I could test with, someone mentioned SCII...
...which lead me to investigate SCII's .dds file usage (how/when channels were swapped around, etc)...
...which lead me to investigate the .m3 file format itself (mostly out of curiosity, but also because I wanted some meshes to test the textures on and the .m3 -> .obj converter program I found was broke and... I already had other game-oriented file format code to work with as a basis, so I just started wedging it in to that :) ).
@Phygit: Go
...
The faces problem you mentioned, the 2-sided polygons, I've noticed it in some models, particularly ones with wings. It's pretty rare on the whole from what I've seen, but I think they're far more popular in WoW models than sc2 models. Another issue, since UV's/Normals are done per-vertex, alot of extra vertices need to be generated for the faces of the geometry. This is a pretty complex issue when you consider that UV vertices used for each face may be different to the actual vertices, and even more complex as each vertex may have multiple normals depending on the smoothing of the faces (causing multiple duplicated vertices to be used for adjoined faces). If you aim to write an exporter at any stage, these are some fun issues that need to be dealt with :D.
...
Yes, I've mostly noticed the 2-sided polygons in the WoW-converted files... I have dozens of those to test with, but only a few SCII-based re-model .m3 files to test with (ie. ones exported from your script). I haven't looked closely to see if they are in the other files or not, but they are definately in the WoW models (wings, capes, some skirts, etc).
re: duplicate vertices...
Hehe.. yep! I have some other plugin code that I've written to handle those issues when exporting - so I know what a hassle it can be. For your amusement, here are the comments I wrote in the code when working on that..
//************************************************************************************// RemapMeshVerts()//// By the time this routine is called:// - All arrays (for verts, mapped verts, uvs and normals, etc.) have been// pre-allocated large enough for a unique vertex for each point of every// triangle (though we should never need that many)// - GetSubMeshInfo() has been called, which set up all the needed// Materials, as well as any needed SubMeshes that those Materials// keep track of//// ...the purpose of this routine is to determine which vertices of the mesh need// to be duplicated. The criteria is as follows://// If polyA and polyB both use vertX, a new vertex is generated for polyB if:// - polyA and polyB use different Materials, or...// - the Normals for that vertex are different, or...// - the UV coordinates for that vertex are different//// ...otherwise, they can share the vertex.//// [NOTE: this process is not currently completely optimized - if polyC also uses// vertX, it might also generate a new vertex, when it could probably// share with either polyA or polyB]////************************************************************************************
...of course after generating those new vertices, you also have to update any face/polygon indices and bone weighting and... been there, done that - it's a pain :)
...I'm going to address one paragrah per reply, so I don't lose this all again - continued in next reply....
...
The vertex normals are the bane of my existence. Getting them to work has been the most painful part of designing a working exporter, and they don't even work as they should. I've since fixed a minor glitch that caused incorrect normals to be generated which will be in the next released update. Converting 3ds Max smoothing groups to vertex normals and vice versa are enormous sorting tasks to which I haven't had much luck. I do most of the vertex normals through a 3ds max modifier, which is a horribly slow and inefficient method for processing them. Furthermore, it seems that smoothing groups are still not exported entirely correctly using this method. I think to calculate them based on smoothing groups and face normals for each vertex is the way to go, but I haven't come up with a valid method for doing it yet. I HAVE found a script that purports to do it properly though (Sins of a Solar Empire export script, if you're interested).
...
Actually, my comments and obsvervations about the WoW Model Viewer .m3 export outputting incorrect Vertex Normals was based on the idea that the ones your script is generating are 'correct' :). And/but... from the conversion that I ended up doing to them (axis-swapping, etc) to get them to work in Cinema 4D, I'm pretty confident that your script is generating them correctly (at least in general... it sounds like you may have found some cases where they may be incorrect, which may or may not be related to the next issue).
re: smoothing groups...
Yes, I think you're on the right track on that... I have been considering doing something similar with one of my other plugins, but never got around to implementing it (Cinema 4D doesn't have 'smoothing groups' per-se... but it does let you set up phong-edge-breaks on meshes, that are then handled by the C4D 'Phong Tag').
Basically, you generate Vertex Normals by averaging the Face/Polygon Normals of every face/polygon (or triangle, in this case) that shares each vertex. With smoothing-groups, you would 'exclude' any triangles that were not part of the same smoothing-group, during that averaging process. Keep in mind that this is where 2-sided polygons can mess you up... if opposite-facing polygons share the _same_ vertices, then those polygons will have opposite Face Normals, which will screw up your averaging routine.
...I'm going to address one paragrah per reply, so I don't lose this all again - continued in next reply....
Gah! I just spent about 30 mins replying to this and then lost it when I tried to post... so here goes another attempt (I think I'll break it up into smaller segments / multiple replies...)
You're doing good work Phygit, you seem to have a better grasp of the modelling fundamentals than I do. First I'll address the animation information. You're probably right about the way I'm doing the base frame, I'm going to have a good look at the code once I get the chance and see if I can use your explanation to mend any wrongs with the base pose and the animation keys imported. 3ds Max (and some 3D applications I would assume) run into some problems with the quaternion rotations found in the M3's. I've had to compare the next key quaternion with the previous one (using a dot function) to make sure Max didn't rotate in the wrong direction (instead of taking the shortest rotational path, it wanted to go in the opposite direction!).
Thanks...
re: base-pose-frame...
As you rightfully pointed out (later in the post), I don't have any original/source .m3 files to work/test with, but... given the 'available' sample files, either I'm right about this, or... there are issues with the current export script (or improper end-user settings before export). For an example of what I mean by that, IF you treat the rotation/translation/scale values from the bones exactly the same way you do any other keyframe data with the Kerrigan Ghost model you can download from the files section here, you'll see that it makes up an unmistakable (mid-stride) frame of the 'walk' animation. There's about zero chance that that data should be interpreted in any other way (coincidentally, if you DO combine that pose with the IREF parent matrices (as suggested by your script and the available documentation around the web), you DO get an 'interesting' (if not misleading) pose - but be sure to check out the feet/legs).
re: Gimble-Lock / Screwy Rotations...
Yeah, Cinema 4D has a 'GetOptimalAngle()' call in thier SDK that I use to handle that :).
...I'm going to address one paragrah per reply, so I don't lose this all again - continued in next reply....
Uhm... <thinking>... no - they are 2 separate problems. There's actually a combination of issues (particularly seen in the WoW-converted meshes, but possibly in original/source .m3 files and/or Max-exported ones - I just haven't looked into it enough yet).
the issue you brought up (mirrored geometry -> inverted Normal Map) is simply an issue of whether or not the game-engine has any mechanism to account for that. It could either impose some restrictions (ie. flipping left-right or top-bottom, but not both) and add some code like I described (in which case, there'd be nothing to add/adjust in the .m3 files) or there might possibly be some 'flag' bit set somewhere that tells the engine how to handle it and we just don't know if/how/where to set it.
the 'Bad Normals' issue with WoW-converted models seems to be at least partly an issue with the WoW Model Viewer .m3 exporting code... in the best-case, it's writing the vertex normals out incorrectly. In the worst case, that's being complicated by other issues...
...either by design, or at some point in the process, there are at least 2 (or 2.5) additional issues that I have seen (at least in the WoW-converted models)...
1. There are "two-sided polygons"... in other words, one polygon facing foward and another facing rearward, BOTH using the exact same vertex indices (just different winding-orders, so that that face opposite directions). This can cause issues when trying to 'compute' smooth vertex normals (I wrote a separate function to 'fix' vertex normals, but it's being confounded by the 2-sided polygons). And can also cause z-buffer issues, if no back-face culling is done.
1a. Even when there are no 'actual' 2-sided polygons, the affect is often mimmiced in the file with 2 separate, back-to-back polygons, that occupy the same location. This is a 'less broke' way of addressing the issue (when a cape or some other cloth needs to be seen from any direction, for example), but if the game or 3d app renders 'rear-facing' polygons, then because they are so close to each other, the z-buffer can get parts of both and cause 'shading issues' (typically black/dark splotches and/or other inverted normal issues).
2. In addition to 2-sided polygons, there are also 'degenerate' polygons... ie. polygons where more than one of the 3 points are shared (creating either a line or even a point - not a triangle). If the game-engine or 3d app doesn't account for these, they can also cause shading issues.
...you mentioned tweaking the exporter - I assume you mean the WoW Model Viewer (?) if so, I would still recommend doing that (see my notes on the Vertex Normals in that linked thread) - and possibly adding code to look for and eliminate at least the degenerate triangles (ideally, it would also generate separate vertices for any 2-sided polygons). Those fixes would solve some of the problems, but not the one you're particularly interested in (the mirrored UVs would still be an issue).
Yes exactly, after alot of trial and error I found you have to work your way 'up' the chain (finger->hand->elbow->shoulder) starting from the deepest bones first. The screenshot is from the base pose of the zealot after the 'initial' translation/rotation/scale values were applied to the bindpose. I think once you are able to begin applying transformations from the deepest bone first up the hierarchy, it'll all come together and your animations/base pose will start to look fine. ...
Hi NiN,
Ok, after thrashing around for the past week or so on this, I finally (about an hour ago) got everything 'mostly' working (there are still a few issues with some files, but it actually looks like bad data in the (those) files in at least some cases...).
Again, let me remind you that I do not have 'original' source game files to work with, so my experience is limited to the files I've been able to download from here - some of those were exported by the WoW Model Viewer app (which have issues with vertex normals), and several were apparently exported with your Max script.
Anyway, after dealing with all sorts of issues in various test files (like needing to add keyframes and adjust keyframe curve tangents to correct for 'drift' and interpolation 'between' animations, etc), I finally have extremely correct looking/working animations (yay). And... I think your suggestion/description above (and thus script coding) is actually wrong about those pos/rot/scale values that are attached to the bones...
Your suggestion (and script) 'combines' (multiplies) those values with the IREF (bind) matrices, to come up with a 'base pose'... I'm almost positive that you should not be combining them with the IREF matrices - they simply make up a 'local' bone matrix - just like any other keyframe data does. If you think about how the (your) exporter script works, you'll come to the same conclusion, I think. It simply converts 'global' bone matrices into 'local' bone matrices, by removing the parent matrix (multiplying by the inverse of the parent). If you need to convert them back to global matrices, they should be multiplied by the parent bone values (not the IREF matrices).
Anyway, you mentioned that you may still need some tweeking on the animations, so I thought I'd mention the above... also, most of the problems that I ultimately had (after a lot of false-paths and dead-ends) turned out to just be issues of interactions between the strung-together animations... in some cases a bone would have a single rotation key at the begining of an animation - with a different rotation for the next animation - and so the bone would spin for the entire animation towards the next angle, etc. By checking for similar situations, strategically adding some additional (duplicate) keys and changing some tangents from spline to stepped, I finally got everything behaiving.
While working on an .m3 import/parsing script, I have identified a problem with the Vertex Normals of these WoW-converted models (I'm guessing the problem is in whatever conversion script you're using).
To 'fix' the problem, the following adjustments would need to be done...
Currently, in the Wow-converted .m3 model files, the normal is being written out (referencing the normal[3] array as x/y/z) as...
x (normal[0]) - what's being written in here (currently) _should_ be going into y (normal[1]), instead
y (normal[1]) - what's being written in here needs to be inverted and stashed into the x (normal[0]) value, instead
z (normal[2]) - what's being written in here needs to be inverted
...note that my array indices above are zero-based (C convention), so you may need to convert those to one-based for Max-script.
The above problem is in pretty much every one of those models that I've looked at so far and would likely cause odd shading issue in the game (black/dark-fuzzy-vertical lines down the center of the model, from any angle... EDIT: actually, the game might basically be ignoring the Vertex Normals, but you might see the problem in Max or any other 3D app).
0
Hi dropz,
Thanks - I didn't know there was a demo out (I should have looked :) ).
0
I don't really know Max at all, but my guess from the image is... it looks like you have 2-sided polygons (?). Either that, or some issue with Normals.
0
Update...
I worked out the final (?) piece of the puzzle to get the SCII-native (well, exported from Max, not the WoW Model Viewer) .m3 files working... at least a 'workable' solution. The problem I was having was with the IREF matrices. I was using them fine to orient the bones for skinning the mesh, but I also needed to add 'that' pose/bone-positioning as a 'bind-pose' within the animation timeline (I typically do that at frame -1)... this preserves the pose in the scene, for future export purposes, or if any skinning adjustments need to be made.
The problem I was having with doing that is that when adding a pose built from the IREF matrices, that only required a translation key and a rotation key, but I was not adding any scale key... so - same problem I was running into in general with the animations - because other keyframes _did_ contain scale keys, that scaling was being carried over into my 'bind-pose-frame' and screwing up the pose. The remedy was simple enough - I just added a 1.0/1.0/1.0 scale key at the bind-pose-frame. I can now animate the document to that frame and have the bones lined up with the mesh in it's un-deformed state (ie. how it was loaded and then skinned to the bones, which were set to the IREF matrices).
So... that still leaves a bit of a question-mark surrounding the trans/rot/scale values that are part of the bones themselves... whether by design or not, in 'some' files, the pose generated by those values is definately just a frame of one of the animations of the figure (like the 'walk' animation mentioned earlier). I have no idea if the original/source .m3 files are set up like this or not. I'm currently still using that pose as somewhat of a 'base-pose' that I plug in between animations, but I wouldn't really need to (in the case where it's a mid-stride walking pose, it kinda doesn't make sense...), but it doesn't hurt anything.
With all the above in mind, I still am having some visual issues with some of the SCII-native figures (like Kerrigan), but they apear to either be a problem with the data/file (not likely, since noone else is mentioning any problems) or some issue with how Cinema 4D does the order of operations (ie. in what order it's applying the translation/rotation/scale keys). Some poses just look goofy - like her shoulder is dislocated or her hand is disconnected from her arm when it's on her hip, etc. (since noone's reporting those issues, I assume they aren't present in Max or the game). All of the WoW-converted models appear to be working pretty much exactly as expected (no visual errors in the animations at all), but they also tend not to have the same level of sporatic scaling mixed in throughout the skeletal structure as the SCII-native files do.
Anyway, I just wanted to update you on my latest progress and thoughts.
Cheers.
0
Hi Soul,
I think that final line kinda defines the (or at least my) answer... 'Blender 3D" (free/open-source 3d modeling app). I haven't looked into the current state of it's .m3 file support, but I know that it does have 'some' sort of plugin under development (possibly only 'import' ?). As to getting files back into SCII, maybe someone else will have a more complete answer for you (maybe there's some path that takes you through additional free apps and other exportable file formats, like the WoW model viewer or something).
If you just want to re-texture, then you'll just need to be able to load the .dds files into some paint program (or convert them to a format that some paint program can load), make your changes and save them back out. You might also want to be able to 'import' the .m3 mesh file to test your new bitmaps, but if you're not changing the mesh itself, you wouldn't necessarily need to be able to re-export the .m3 file, etc.
0
Last one :)...
Let me just give you the short-version...
...that's the short version :).
BTW, I am also enjoying the discussion... Cheers.
0
Yes, I've mostly noticed the 2-sided polygons in the WoW-converted files... I have dozens of those to test with, but only a few SCII-based re-model .m3 files to test with (ie. ones exported from your script). I haven't looked closely to see if they are in the other files or not, but they are definately in the WoW models (wings, capes, some skirts, etc).
re: duplicate vertices...
Hehe.. yep! I have some other plugin code that I've written to handle those issues when exporting - so I know what a hassle it can be. For your amusement, here are the comments I wrote in the code when working on that..
...of course after generating those new vertices, you also have to update any face/polygon indices and bone weighting and... been there, done that - it's a pain :)
...I'm going to address one paragrah per reply, so I don't lose this all again - continued in next reply....
0
Actually, my comments and obsvervations about the WoW Model Viewer .m3 export outputting incorrect Vertex Normals was based on the idea that the ones your script is generating are 'correct' :). And/but... from the conversion that I ended up doing to them (axis-swapping, etc) to get them to work in Cinema 4D, I'm pretty confident that your script is generating them correctly (at least in general... it sounds like you may have found some cases where they may be incorrect, which may or may not be related to the next issue).
re: smoothing groups...
Yes, I think you're on the right track on that... I have been considering doing something similar with one of my other plugins, but never got around to implementing it (Cinema 4D doesn't have 'smoothing groups' per-se... but it does let you set up phong-edge-breaks on meshes, that are then handled by the C4D 'Phong Tag').
Basically, you generate Vertex Normals by averaging the Face/Polygon Normals of every face/polygon (or triangle, in this case) that shares each vertex. With smoothing-groups, you would 'exclude' any triangles that were not part of the same smoothing-group, during that averaging process. Keep in mind that this is where 2-sided polygons can mess you up... if opposite-facing polygons share the _same_ vertices, then those polygons will have opposite Face Normals, which will screw up your averaging routine.
...I'm going to address one paragrah per reply, so I don't lose this all again - continued in next reply....
0
Gah! I just spent about 30 mins replying to this and then lost it when I tried to post... so here goes another attempt (I think I'll break it up into smaller segments / multiple replies...)
Thanks...
re: base-pose-frame...
As you rightfully pointed out (later in the post), I don't have any original/source .m3 files to work/test with, but... given the 'available' sample files, either I'm right about this, or... there are issues with the current export script (or improper end-user settings before export). For an example of what I mean by that, IF you treat the rotation/translation/scale values from the bones exactly the same way you do any other keyframe data with the Kerrigan Ghost model you can download from the files section here, you'll see that it makes up an unmistakable (mid-stride) frame of the 'walk' animation. There's about zero chance that that data should be interpreted in any other way (coincidentally, if you DO combine that pose with the IREF parent matrices (as suggested by your script and the available documentation around the web), you DO get an 'interesting' (if not misleading) pose - but be sure to check out the feet/legs).
re: Gimble-Lock / Screwy Rotations...
Yeah, Cinema 4D has a 'GetOptimalAngle()' call in thier SDK that I use to handle that :).
...I'm going to address one paragrah per reply, so I don't lose this all again - continued in next reply....
0
@GnaReffotsirk: Go
Uhm... <thinking>... no - they are 2 separate problems. There's actually a combination of issues (particularly seen in the WoW-converted meshes, but possibly in original/source .m3 files and/or Max-exported ones - I just haven't looked into it enough yet).
1. There are "two-sided polygons"... in other words, one polygon facing foward and another facing rearward, BOTH using the exact same vertex indices (just different winding-orders, so that that face opposite directions). This can cause issues when trying to 'compute' smooth vertex normals (I wrote a separate function to 'fix' vertex normals, but it's being confounded by the 2-sided polygons). And can also cause z-buffer issues, if no back-face culling is done.
1a. Even when there are no 'actual' 2-sided polygons, the affect is often mimmiced in the file with 2 separate, back-to-back polygons, that occupy the same location. This is a 'less broke' way of addressing the issue (when a cape or some other cloth needs to be seen from any direction, for example), but if the game or 3d app renders 'rear-facing' polygons, then because they are so close to each other, the z-buffer can get parts of both and cause 'shading issues' (typically black/dark splotches and/or other inverted normal issues).
2. In addition to 2-sided polygons, there are also 'degenerate' polygons... ie. polygons where more than one of the 3 points are shared (creating either a line or even a point - not a triangle). If the game-engine or 3d app doesn't account for these, they can also cause shading issues.
...you mentioned tweaking the exporter - I assume you mean the WoW Model Viewer (?) if so, I would still recommend doing that (see my notes on the Vertex Normals in that linked thread) - and possibly adding code to look for and eliminate at least the degenerate triangles (ideally, it would also generate separate vertices for any 2-sided polygons). Those fixes would solve some of the problems, but not the one you're particularly interested in (the mirrored UVs would still be an issue).
0
@Alrik1989: Go
I think you meant flipped Normals, but... thanks :) and/or you're welcome.
BTW, my latest thoughts on the Normals thing can be found in the WoW model viewer forum.
0
Hi NiN,
Ok, after thrashing around for the past week or so on this, I finally (about an hour ago) got everything 'mostly' working (there are still a few issues with some files, but it actually looks like bad data in the (those) files in at least some cases...).
Again, let me remind you that I do not have 'original' source game files to work with, so my experience is limited to the files I've been able to download from here - some of those were exported by the WoW Model Viewer app (which have issues with vertex normals), and several were apparently exported with your Max script.
Anyway, after dealing with all sorts of issues in various test files (like needing to add keyframes and adjust keyframe curve tangents to correct for 'drift' and interpolation 'between' animations, etc), I finally have extremely correct looking/working animations (yay). And... I think your suggestion/description above (and thus script coding) is actually wrong about those pos/rot/scale values that are attached to the bones...
Your suggestion (and script) 'combines' (multiplies) those values with the IREF (bind) matrices, to come up with a 'base pose'... I'm almost positive that you should not be combining them with the IREF matrices - they simply make up a 'local' bone matrix - just like any other keyframe data does. If you think about how the (your) exporter script works, you'll come to the same conclusion, I think. It simply converts 'global' bone matrices into 'local' bone matrices, by removing the parent matrix (multiplying by the inverse of the parent). If you need to convert them back to global matrices, they should be multiplied by the parent bone values (not the IREF matrices).
Anyway, you mentioned that you may still need some tweeking on the animations, so I thought I'd mention the above... also, most of the problems that I ultimately had (after a lot of false-paths and dead-ends) turned out to just be issues of interactions between the strung-together animations... in some cases a bone would have a single rotation key at the begining of an animation - with a different rotation for the next animation - and so the bone would spin for the entire animation towards the next angle, etc. By checking for similar situations, strategically adding some additional (duplicate) keys and changing some tangents from spline to stepped, I finally got everything behaiving.
Cheers.
0
@Domper: Go
Thanks.. I found the proper forum and posted the fix there as well.
0
...oops... the above Normal correction/fix is not right either. I'll report back if/when I figure it out.
EDIT: Ok, I was close.. just 100% inverted :). So, the fix is:
Cheers.
0
BTW, I figured out how the Vertex Normals on those WoW-converted models are broke and described a fix in this post.
0
Hey guys...
Thanks for the models!
While working on an .m3 import/parsing script, I have identified a problem with the Vertex Normals of these WoW-converted models (I'm guessing the problem is in whatever conversion script you're using).
To 'fix' the problem, the following adjustments would need to be done...
Currently, in the Wow-converted .m3 model files, the normal is being written out (referencing the normal[3] array as x/y/z) as...
...note that my array indices above are zero-based (C convention), so you may need to convert those to one-based for Max-script.
The above problem is in pretty much every one of those models that I've looked at so far and would likely cause odd shading issue in the game (black/dark-fuzzy-vertical lines down the center of the model, from any angle... EDIT: actually, the game might basically be ignoring the Vertex Normals, but you might see the problem in Max or any other 3D app).
Cheers.