I'm sorry to have to say, I don't believe I'll be releasing many updates in the future to the tools, if any at all at the present pace of things. I'm pretty busy with other important things in my life to the point where working on the tools is just not possible for me to do. The tools still don't do everything I'd have wanted and it's my hope in the future that someone takes an interest in developing proper tools to support creating custom M3 models. I've always provided the source code to the maxscripts so that people might learn or use the information to construct their own tools. One of these days I'll try to update libm3 to include the extra information I've learned so future developers don't have to learn the hard way, through trial and error.
It's my belief that Blizzard will not release significant tools in the future... Even if StarTools is released, it seems primarily to create doodads instead of the diverse models capable of being supported by the engine. If they do release their max plugins, they will undoubtedly be restricted to certain versions just as the tools for Warcraft 3 were. It's really up to developers present in the community to make these tools a reality. Anyone with decent knowledge of 3D graphics and programming can contribute. When I first started working on the tools, most of my knowledge was extremely basic at best, it's more about knowing what you want to achieve and realising the steps to take to achieve it.
It's been a fun hobby to indulge in and I'm very thankful for all the support you guys provided aswell as the multitude of feedback. It still frustrates me that I'm not able to fix all the problems you guys have, especially regarding shading/bone weight issues. I feel like these are basic things that should just work instead of being an obstacle to creativity and exporting. There's still alot I wanted to get done, such as a tool for transferring animations from one model to another that have similar bone hierarchies (this would be really cool, it would basically allow anyone to animate their model with professional Blizzard-like animations from WoW, WC3 or other SC2 models for instance).
I also envision a tool similar to an expanded version of WoW model viewer which allows you to do basic editing of all Blizzard models and import/export between the various Blizzard model formats. I think this would allow the community a great deal of customisation of stock models without having to own expensive software. Bare in mind Diablo 3 is also on the horizon with its plethora of models and a new modelling format to decypher. In addition, Blizzard doesn't seem to mind transferring their assets between the Blizzard games as I do remember they tweeted about the World of Warcraft custom models being used within the Starcraft 2 engine. So there's not too much concern about them interferring legally with such a tool if it were to be created.
There is a setting within the M3 that controls how a unit is selected. I haven't quite figured out how it works yet but I'll check out the cube model and see if I can figure it out. I actually never thought of looking at the cube model so cheers for the suggestion.
Aye M3's are pretty complex. There's still a huge amount of stuff I've yet to implement. IK is supported by bones in the sc2 engine for instance, so at some stage I'm going to have to provide support for that. Support for lights will be next, but there's still ribbon emitters/physics bodies/shadow boxes/cameras for portraits/global animations/etc to be done.
The egg shape won't work with bounding spheres, the script will just take the longest radius of the egg shape and use that as the basis for the sphere. The bounding sphere in M3's has essentially only two properties: position and radius. The attachment volumes are connected to bones which allow for the odd scaling/shape.
There is more complex ways to handle the unit selection but I'll have to figure out how it works with some investigating :D
I'll look into that error in 3ds Max 9. 3ds Max 9 should work fine with the scripts as far as I can tell, though you might need one of the service packs to add .dds support.
That value in the bones is pretty interesting. I'm not sure what it indicates but it does kind of strike me as a lookup of some sort. I don't think it's an internal lookup as I couldn't relate it to anything in the M3.
I was also first confused about the 'basepose' however the way animation is handled in M3's, it makes sense. Every animation reference has an 'init value' which gives the animatable property an initial value to assume if there's no key frames present. Bones are no exception as they're animatable, however it's interesting that Blizzard put them into a pose that is different from the bindpose as it seems unnecessary.
As for the UVW and normal map issues you guys have, it's way outside my expertise. If you come up with some kind of solution I'm happy to try to implement it or whatever needs to be done.
Cheers for the support guys, this update took alot of work. Particle emitters were no small task :P.
Just a note to people, light objects in models are not yet supported. The normal issues, the script isn't perfect at exporting normals which is why alot of your issues may be occuring.
Blue isle studios has graciously supported the development of the scripts and if you get the chance check them out at http://blueislestudios.com/. They will be releasing some ultra cool stuff in the future. Their support is much appreciated :).
I'll drop by later to comment on some other things that are being discussed in the thread. Just wanted to post the update before I had to head out. Cheers all.
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!).
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).
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.
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.
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.
Be weary of one thing I have discovered with some Blizzard models. Some of them use negative bone scales when 'mirroring' certain bones. You can find this kind of negative scaling in the Immortal and the DarkTemplar models (realising you don't have access to these models, you'll have to take my word for it :P). I don't know if Cinema 4D will be able to process the negative scaling correctly, but it's something to be weary of if you plan to create a complete importer.
Thanks for picking up on that bug in the script, I'll get it fixed for the next update. I'm glad more people are taking an interest in developing M3 tools for other programs than max.
On to your technical question, the bones gave me a great deal of problems when I first started trying to get the models into 3ds max. Infact, they're still not done entirely correct when I import them. The envelopes are incorrectly done, there should be bone geometry linking the bones too instead of using the 'show links' method I'm using on import. These things I don't know how to fix properly in max, most of the systems I tried failed and ended up causing the bones to be shown incorrectly.
The IREF chunk in the model, from what I understand, is the 'Initial Reference' inverse matrix for each bone object. That is, the matrices for each bone when the geometry (i.e. vertices of the mesh) is skinned onto them. I don't think they're meant to have a bone related axis at all. They're almost certainly processed before the bone chunk of the model, so things such as the bones parent aren't even considered at the point the IREF is processed. The IREF matrices put the bones in the correct position/orientation/scale for binding the vertices to them. I'm not sure if you can deduce a bone axis from them, I never had to deal with that problem.
I don't really think the bone systems in M3's or any of Blizzard's model formats are aligned along the bone, rather they are simply objects in 3D space that affect each other in a hierarchy, if that makes any sense. You'll notice in my script bone hierarchy is setup after the inverse matrices are applied to each bone and that all animations are done starting from the deepest bone in the hierarchy and then moving upward. If you figure out anything let me know.
Hoping to release it this week! I know you're waiting on the attachment volume stuff tFighterPilot. The reason the update is taking so long is that I'm having to iron out alot of the new features that are being added with the next update. Thanks for the patience.
The next release of the M3 plugins will support particle emitters, which should be released soon. I'm not sure why this problem is occuring but I can maybe do some tests and attempt to narrow down the crash in the future.
Very well done with the investigation. This kind of documentation of a problem really helps.
The tools I've developed so far do not support physics bodies. I've known about them for some time but I think their implementation will be quite complex to do. At the moment I'm focusing on other areas. In the future these will be supported for the importer/exporter, but right now other model objects such as particle/ribbon emitters are taking priority.
ZealNaga is correct, the only working import/export script so far is for 3ds max. The obj converter you're using was almost certainly designed for the old beta M3 format which is why your obj file comes out garbled. No obj converters have been updated to handle the new format. I could probably update one of them myself, but the obj format can't handle most of the M3 data and so it would only be useful in a restricted set of circumstances, such as when someone would like to make use of the geometry of a model such as yourself.
I realise 3ds max is expensive and not accessible to most people. Some work was being done on blender import/export scripts but the work was abandoned, as have many projects based on the M3 format. I'm hoping more interest develops around designing freeware tools to handle the format for blender or other 3D modelling software, however I don't believe anything will be done in the near future. This leaves 3ds max as your only immediate option unfortunately.
Ah I see, you've done it to render them transparent with team colours. Very cool. Here was my solution for all those curious, in a PM to ezbeats:
I've noticed that M3 materials don't have an opacity setting exactly, none that I could discover anyway. This is strange as you would think a standalone opacity setting would be important to have.
All opacity seems to be controlled through maps alone. I'm not exactly sure on how alpha maps work, but I've noticed some trends in the M3 models that do use alpha maps. I recommend taking a look at the DarkTemplar.m3 cape as it is a really good example of how a transparency gradient is achieved through an alpha map in an M3. Another example is the warp blades in Zealot.m3. They are made transparent through their diffuse map alpha channel I believe. Practically every setting you can see in the previewer can be toggled in the custom Starcraft 2 shader in 3ds max.
So what I have observed is that this kind of transparency appears to be achieved through the 'Add' or 'Alpha Blend' kind of Layer Blend Mode, depending on how you're rendering your alpha. A cutout threshold of at least 1 seems to be needed aswell, which seems to control the degree that the alpha map affects transparency. If you import the Zealot.m3 with the correct materials and export it right back out, you'll notice the warp blades maintain their transparency. Not useful for what you want (a gradual fade out) however so I recommend you check out the DarkTemplar.m3 cape.
I'll attach some images that provide an example I did real quick with the DarkTemplar cape to illustrate how it's done. Hopefully they explain it.
Not sure if you managed to solve this problem yet xcorbo, but the Dark Templar's cape is your standard alpha map transparency you're probably looking for. I did a solid tutorial up for someone perhaps in PM's on how to do alpha maps properly for transparency. It does involve the alpha map and having a cutout threshold of at least 1 IIRC. I'll do some digging around and see if I can find it.
Not sure what could be causing your problem... no one else seems to be having this problem. Perhaps send me the model via PM so I can take a look, or send me screenshots describing the problem. Not too sure what could be causing it.
I have this problem fixed now. The problem was that some attachments have a 'volume' entry in the model files. As far as I can tell, these volumes are only used for the attachments 'Ref_Target' and 'Ref_Shield'. This volume is defined as a radius or 'spread' around the attachment point. I've fixed the exporter to support this now whenever you create a Ref_Target or Ref_Shield attachment and it'll be included in the next update. At the moment, the radius will have to be a number rather than a visual element (I envision a 'sphere' around the attachment would do the job if I were to make it a visual element) but that may change in future updates if I figure something out.
I've tested this out on the zealot as it has two hit regions, shield hit region and once shields are depleted a 'chassis' hit region. It works well. The next update to the tools will add this feature and should fix up your issue tFighterPilot.
0
Hey guys,
I'm sorry to have to say, I don't believe I'll be releasing many updates in the future to the tools, if any at all at the present pace of things. I'm pretty busy with other important things in my life to the point where working on the tools is just not possible for me to do. The tools still don't do everything I'd have wanted and it's my hope in the future that someone takes an interest in developing proper tools to support creating custom M3 models. I've always provided the source code to the maxscripts so that people might learn or use the information to construct their own tools. One of these days I'll try to update libm3 to include the extra information I've learned so future developers don't have to learn the hard way, through trial and error.
It's my belief that Blizzard will not release significant tools in the future... Even if StarTools is released, it seems primarily to create doodads instead of the diverse models capable of being supported by the engine. If they do release their max plugins, they will undoubtedly be restricted to certain versions just as the tools for Warcraft 3 were. It's really up to developers present in the community to make these tools a reality. Anyone with decent knowledge of 3D graphics and programming can contribute. When I first started working on the tools, most of my knowledge was extremely basic at best, it's more about knowing what you want to achieve and realising the steps to take to achieve it.
It's been a fun hobby to indulge in and I'm very thankful for all the support you guys provided aswell as the multitude of feedback. It still frustrates me that I'm not able to fix all the problems you guys have, especially regarding shading/bone weight issues. I feel like these are basic things that should just work instead of being an obstacle to creativity and exporting. There's still alot I wanted to get done, such as a tool for transferring animations from one model to another that have similar bone hierarchies (this would be really cool, it would basically allow anyone to animate their model with professional Blizzard-like animations from WoW, WC3 or other SC2 models for instance).
I also envision a tool similar to an expanded version of WoW model viewer which allows you to do basic editing of all Blizzard models and import/export between the various Blizzard model formats. I think this would allow the community a great deal of customisation of stock models without having to own expensive software. Bare in mind Diablo 3 is also on the horizon with its plethora of models and a new modelling format to decypher. In addition, Blizzard doesn't seem to mind transferring their assets between the Blizzard games as I do remember they tweeted about the World of Warcraft custom models being used within the Starcraft 2 engine. So there's not too much concern about them interferring legally with such a tool if it were to be created.
Cheers everyone,
- NiN
0
@Kalekin: Go
There is a setting within the M3 that controls how a unit is selected. I haven't quite figured out how it works yet but I'll check out the cube model and see if I can figure it out. I actually never thought of looking at the cube model so cheers for the suggestion.
@GnaReffotsirk: Go
Aye M3's are pretty complex. There's still a huge amount of stuff I've yet to implement. IK is supported by bones in the sc2 engine for instance, so at some stage I'm going to have to provide support for that. Support for lights will be next, but there's still ribbon emitters/physics bodies/shadow boxes/cameras for portraits/global animations/etc to be done.
The egg shape won't work with bounding spheres, the script will just take the longest radius of the egg shape and use that as the basis for the sphere. The bounding sphere in M3's has essentially only two properties: position and radius. The attachment volumes are connected to bones which allow for the odd scaling/shape.
There is more complex ways to handle the unit selection but I'll have to figure out how it works with some investigating :D
@maverck: Go
I'll look into that error in 3ds Max 9. 3ds Max 9 should work fine with the scripts as far as I can tell, though you might need one of the service packs to add .dds support.
@Phygit: Go
That value in the bones is pretty interesting. I'm not sure what it indicates but it does kind of strike me as a lookup of some sort. I don't think it's an internal lookup as I couldn't relate it to anything in the M3.
I was also first confused about the 'basepose' however the way animation is handled in M3's, it makes sense. Every animation reference has an 'init value' which gives the animatable property an initial value to assume if there's no key frames present. Bones are no exception as they're animatable, however it's interesting that Blizzard put them into a pose that is different from the bindpose as it seems unnecessary.
As for the UVW and normal map issues you guys have, it's way outside my expertise. If you come up with some kind of solution I'm happy to try to implement it or whatever needs to be done.
Cheers for the support guys, this update took alot of work. Particle emitters were no small task :P.
0
New update: M3 Plugins v1.8
Just a note to people, light objects in models are not yet supported. The normal issues, the script isn't perfect at exporting normals which is why alot of your issues may be occuring.
Blue isle studios has graciously supported the development of the scripts and if you get the chance check them out at http://blueislestudios.com/. They will be releasing some ultra cool stuff in the future. Their support is much appreciated :).
I'll drop by later to comment on some other things that are being discussed in the thread. Just wanted to post the update before I had to head out. Cheers all.
0
@Phygit: Go
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!).
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).
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.
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.
0
@Phygit: Go
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.
Be weary of one thing I have discovered with some Blizzard models. Some of them use negative bone scales when 'mirroring' certain bones. You can find this kind of negative scaling in the Immortal and the DarkTemplar models (realising you don't have access to these models, you'll have to take my word for it :P). I don't know if Cinema 4D will be able to process the negative scaling correctly, but it's something to be weary of if you plan to create a complete importer.
0
@Phygit: Go
Hey Phygit,
Thanks for picking up on that bug in the script, I'll get it fixed for the next update. I'm glad more people are taking an interest in developing M3 tools for other programs than max.
On to your technical question, the bones gave me a great deal of problems when I first started trying to get the models into 3ds max. Infact, they're still not done entirely correct when I import them. The envelopes are incorrectly done, there should be bone geometry linking the bones too instead of using the 'show links' method I'm using on import. These things I don't know how to fix properly in max, most of the systems I tried failed and ended up causing the bones to be shown incorrectly.
The IREF chunk in the model, from what I understand, is the 'Initial Reference' inverse matrix for each bone object. That is, the matrices for each bone when the geometry (i.e. vertices of the mesh) is skinned onto them. I don't think they're meant to have a bone related axis at all. They're almost certainly processed before the bone chunk of the model, so things such as the bones parent aren't even considered at the point the IREF is processed. The IREF matrices put the bones in the correct position/orientation/scale for binding the vertices to them. I'm not sure if you can deduce a bone axis from them, I never had to deal with that problem.
I don't really think the bone systems in M3's or any of Blizzard's model formats are aligned along the bone, rather they are simply objects in 3D space that affect each other in a hierarchy, if that makes any sense. You'll notice in my script bone hierarchy is setup after the inverse matrices are applied to each bone and that all animations are done starting from the deepest bone in the hierarchy and then moving upward. If you figure out anything let me know.
0
@tFighterPilot: Go
Hoping to release it this week! I know you're waiting on the attachment volume stuff tFighterPilot. The reason the update is taking so long is that I'm having to iron out alot of the new features that are being added with the next update. Thanks for the patience.
0
@Darkyvm: Go
The next release of the M3 plugins will support particle emitters, which should be released soon. I'm not sure why this problem is occuring but I can maybe do some tests and attempt to narrow down the crash in the future.
0
@desiderius1: Go
Very well done with the investigation. This kind of documentation of a problem really helps.
The tools I've developed so far do not support physics bodies. I've known about them for some time but I think their implementation will be quite complex to do. At the moment I'm focusing on other areas. In the future these will be supported for the importer/exporter, but right now other model objects such as particle/ribbon emitters are taking priority.
0
@Shortyg78: Go
ZealNaga is correct, the only working import/export script so far is for 3ds max. The obj converter you're using was almost certainly designed for the old beta M3 format which is why your obj file comes out garbled. No obj converters have been updated to handle the new format. I could probably update one of them myself, but the obj format can't handle most of the M3 data and so it would only be useful in a restricted set of circumstances, such as when someone would like to make use of the geometry of a model such as yourself.
I realise 3ds max is expensive and not accessible to most people. Some work was being done on blender import/export scripts but the work was abandoned, as have many projects based on the M3 format. I'm hoping more interest develops around designing freeware tools to handle the format for blender or other 3D modelling software, however I don't believe anything will be done in the near future. This leaves 3ds max as your only immediate option unfortunately.
0
@xcorbo: Go
Ah I see, you've done it to render them transparent with team colours. Very cool. Here was my solution for all those curious, in a PM to ezbeats:
I've noticed that M3 materials don't have an opacity setting exactly, none that I could discover anyway. This is strange as you would think a standalone opacity setting would be important to have.
All opacity seems to be controlled through maps alone. I'm not exactly sure on how alpha maps work, but I've noticed some trends in the M3 models that do use alpha maps. I recommend taking a look at the DarkTemplar.m3 cape as it is a really good example of how a transparency gradient is achieved through an alpha map in an M3. Another example is the warp blades in Zealot.m3. They are made transparent through their diffuse map alpha channel I believe. Practically every setting you can see in the previewer can be toggled in the custom Starcraft 2 shader in 3ds max.
So what I have observed is that this kind of transparency appears to be achieved through the 'Add' or 'Alpha Blend' kind of Layer Blend Mode, depending on how you're rendering your alpha. A cutout threshold of at least 1 seems to be needed aswell, which seems to control the degree that the alpha map affects transparency. If you import the Zealot.m3 with the correct materials and export it right back out, you'll notice the warp blades maintain their transparency. Not useful for what you want (a gradual fade out) however so I recommend you check out the DarkTemplar.m3 cape.
I'll attach some images that provide an example I did real quick with the DarkTemplar cape to illustrate how it's done. Hopefully they explain it.
0
@xcorbo: Go
Not sure if you managed to solve this problem yet xcorbo, but the Dark Templar's cape is your standard alpha map transparency you're probably looking for. I did a solid tutorial up for someone perhaps in PM's on how to do alpha maps properly for transparency. It does involve the alpha map and having a cutout threshold of at least 1 IIRC. I'll do some digging around and see if I can find it.
0
@Alrik1989: Go
Not sure what could be causing your problem... no one else seems to be having this problem. Perhaps send me the model via PM so I can take a look, or send me screenshots describing the problem. Not too sure what could be causing it.
0
I have this problem fixed now. The problem was that some attachments have a 'volume' entry in the model files. As far as I can tell, these volumes are only used for the attachments 'Ref_Target' and 'Ref_Shield'. This volume is defined as a radius or 'spread' around the attachment point. I've fixed the exporter to support this now whenever you create a Ref_Target or Ref_Shield attachment and it'll be included in the next update. At the moment, the radius will have to be a number rather than a visual element (I envision a 'sphere' around the attachment would do the job if I were to make it a visual element) but that may change in future updates if I figure something out.
I've tested this out on the zealot as it has two hit regions, shield hit region and once shields are depleted a 'chassis' hit region. It works well. The next update to the tools will add this feature and should fix up your issue tFighterPilot.
0
@tFighterPilot: Go
Going to be looking into this problem shortly. I have a fair idea where the problem is.