Jump to content
Hash, Inc. Forums

Obsidian Games

A:M Users 2019
  • Content Count

    145
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Obsidian Games

  • Rank
    Journeyman

Contact Methods

  • Website URL
    http://www.obsidiangames.com
  • ICQ
    0

Profile Information

  • Name
    Chris Roy

Previous Fields

  • Hardware Platform
    Mac/Win
  • System Description
    P4 2.66, 768MB RAM, GeForce 6200 - Win2k Mac Mini 1.42 w/ 1GB RAM - Panther/Tiger Dual Boot
  1. Hi everyone, I'm very sorry for essentially falling off the face of the earth these last 6 months. Days became weeks, and weeks became months, and here we are. It has been a crazy year (*good* crazy, any day now I'm going to be a dad for the first time!), but that's really no excuse. I've received some very nice emails from people, and a more than generous offer regarding my work. It's great to see the Hash community still doing well, and hopefully, I can come back with a bit of good news. I've cleaned up the AMXtex source code a bit, and have published it on my website -- Obsidian Games. It's now available for anyone to use, play around with, or base other exporters off of. Hash is more than welcome to include the source or exporter in any future release, and if it can find a good home, I'd be very happy. Please be nice with it, and if anyone improves upon it, please release it back out to the public. Also, since this will be the first time anyone has seen the code besides me, I'll apologize in advance for the horrible coding standards. AMXtex definitely started on a hope and a dream, and I have a feeling the code will definitely show that! I've also uploaded some free public release registration codes for those of you with a version of AMXtex or AMXdtsPlus that contains the registration requirement. I'm still not sure what to do with the source code for AMXdtsPlus, as the Torque license prohibits public posting of code, and don't have a lot of time at the moment to sort this one out. If anyone has some contacts at Garage Games and would like to find out if they can host it in their repository, I'd be happy to do the same and publish that code as well. That's all for now. It still amazes me what people are doing with Hash, both on the straight render and animation side, as well as on the gaming/programming side. Best of luck to everyone!
  2. To the Animation:Master community: Almost six years ago to the day, I posted a message to the Animation:Master mailing list with the following header: From: Chris Roy To: animaster@hash.com Sent: Saturday, March 03, 2001 8:31 PM Subject: Interest in a DirectX .X export plugin? What started as a simple request to gauge interest in an A:M exporter turned out to be quite a bit more than I expected. From that email, I began programming AMXtex, a DirectX .X model and animation exporter for A:M. Four years later, in 2005, I began working on AMXdtsPlus, a Torque DTS/DSQ model and animation exporter. Lately though, the combination of my personal and professional life has left me with very little time to pursue my work with Animation:Master, and it's with a heavy heart that I am announcing that effective immediately, Obsidian Games will be closing its doors. AMXtex and AMXdtsPlus, while I made them available for sale, were always more a labor of love than a profitable venture. I have always been, and continue to be, amazed at the work that people have done with the assistance of these tools. The creativity that I've seen, and for some, the dreams realized, are truly why I loved working on the exporters. While my work on the exporters is coming to a close, I do not intend at all for this to be the end for the tools themselves. I will be spending the next few weeks packaging up the code for release, and hope to find good homes for them. Compiled versions of each exporter, minus the registration requirement, will be made available on the Obsidian Games website, and if I don't have another home for it by then, so will the AMXtex source code package itself. Due to some of the code and Torque file changes that are part of AMXdtsPlus, I will need to work with Garage Games to find a suitable home for that source code. As soon as I know more, I will make it known. I want to thank everyone who I've worked with over the years, both at Hash and in the A:M community. While Animation:Master is an amazing product on its own, the supportive community and the tireless dedication from the Hash team have really made it what it is. I'm proud to have been a part of it. Thank you for six great years! Sincerely, Chris Roy Obsidian Games
  3. Unfortunately, I'm still not seeing the problem. I created a new action for Jason using the v13 final release, and the eyeballs moved with the rest of the model. What options are you using to export? If you want to send me a zip of the model/action that you're using, along with a screenshot of the options that you're using, I'd be happy to take a look.
  4. That's great to hear, I'm glad it's working for you! As for the Jason model, I did a simple move where he bends to the side, and the eyes moved with the model as I would expect. Did you mean that the eyes don't move within their sockets, or that when the model moves, the eyes pop out of his head?
  5. Arthur, I got your email on this issue as well, but since you've posted on the boards, and since it might be beneficial to other users, I figured I would respond here. I'm not sure exactly what the problem is, and if you'd like to email me a zip of the model/animation/.x files that are not working for you, I'd be happy to take a look. One question I have though, is what .X file viewer are you using? There is an issue with the new DirectX SDK viewers that causes animation issues. I'm not sure if this is the problem you're having, but it's covered in the AMXtex help doc under the FAQ question "Why does my model look/animate wrong when using the 2005+ versions of the DirectX 9 SDK Mesh Viewer?" If that's not the issue, please send me the files, and I'll see what I can find.
  6. I believe others have reported similar issues exporting models that use the 2001 skeleton. While it's a great skeleton for animating in A:M, some of the contraints/bones/etc (sorry, I'm not a rig person) export slightly off, which seems to be what you're describing. The options that I've seen for fixing this are to either use a different rig, or to re-bone the affected areas until they export properly. I hope this helps!
  7. I just tried exporting the GALA cd model from V13 beta1 and beta2, and it exported properly without an error. Which version of V13 are you running? Also, is anyone else having problems with this version of the V13 exporter?
  8. I've replied in the other thread about this. Basically, it's possible to use .X files exported from A:M in this, but the full workflow will rely more on the programmer rather than the artist.
  9. I've been looking into the ParallaxOcclusionMapping material in the 4/06 DirectX SDK, and here's what I found. Basically, there's some good news and some bad news with respect to how it works. All of the work being done to simulate the displacement seems to be happening outside of the .X file, so there's nothing I can really do to the exporter to help this process. If you look at the .X file that they use for this example, (\Samples\C++\Direct3D\ParallaxOcclusionMapping\Media\Disc.x), you can see that it's just a plain disc. There is nothing added to the .x file to do the occlusion work, and in fact, there are actually pieces missing from the .X file, namely the material list and texture filenames. However, it does contain normal texture coordinates, which I think is key for the example to work. It appears to take that X file, and then loads in the appropriate textures and occlusion maps by way of the project code and .fx files. I added in a material section to the .X file so that I could see what it looked like, and it loads up the textures just fine (I used stones.bmp), only without the occlusion mapping. So, in order for this to work with A:M, it looks like you'll need to create your .X files with a single texture and export it like normal. The material section (starting with "MeshMaterialList" and ending with "} // End MeshMaterialList") should then be stripped out. After that, it's up to whoever is doing the programming to take it from there. I don't know if A:M can create the occlusion maps or not, but perhaps someone else can comment on that. I'm sure this wasn't the answer people were hoping for, but I hope this helps explain it a bit. It does look like a cool technology, though.
  10. I'll continue to update the V12 exporter along side V13 as much as possible. However, the V12 version of the A:M SDK does not support weight export, so in this case, it wasn't possible.
  11. No worries about the questions, I'm always happy to try and answer them the best I can. I will try to take a look at the "ParallaxOcclusionMapping" example and see if/how it works with .X files. As for making an identical size normal map and having the programmer load it, that may well be possible. To be honest, I don't know enough about how normal maps are used with DirectX to give a good answer. If I can find out more, I'll post back here.
  12. DWARVEN_KING - I also got your email on this, but figured I'd reply here. The A:M-generated texture maps, which are an option with AMXtex, may not suit your purposes. Most DirectX viewers want texture maps to be powers of 2 (64x64, 512x256, etc), and the auto-generated maps don't fit this sizing. However, if you start by creating all of your textures with this sizing (either one large map or multiple smaller maps), you can use those with .X models just fine. As you noted, AMXtex only exports a single texture per polygon, which should be the color texture. It does not handle normal maps, though. I've browsed through the DirectX 9 docs, and while I found mention of normal maps, I can't find where .X files use them. The list of supported .X templates does not appear to include anything for normal maps. Can you point me to the documentation that you found, so I can investigate further? Thanks,
  13. I've just released a new version of AMXdtsPlus (Torque Model exporter), Beta-6, which is available for Animation:Master version 13 on Windows and OSX Tiger. This version of AMXdtsPlus introduces vertex/cp weight export, and is available to registered users only. I have also updated the AMXdtsPlus help file to add information on this, and other, features. Both the exporter and help file can be downloaded from the Obsidian Games website. As always, if there are any issues or questions with this new release, please let me know.
  14. I've just released a new version of AMXtex (DirectX Model exporter), version 3.0, which is available for Animation:Master version 13 on Windows. This version of AMXtex introduces vertex/cp weight export, and is available to registered users only. I have also updated the AMXtex help file to add information on this new feature. Both the exporter and help file can be downloaded from the Obsidian Games website. There is one limitation to this new feature to keep in mind. DirectX limits the number of bones that can control an individual vertex to 4. The export process will enforce this limit, so if a cp has more than 4 weights, the extra weights will be removed and the remaining 4 weights will be normalized so that the vertex maintains 100% weighting. As always, if there are any issues or questions with this new release, please let me know.
  15. Dennis, one thing that I noticed immediately is that your model is nearly 70 meters tall in Torque (each cm in A:M = 1 meter in Torque). It's possible that the large size is causing an issue with some of the math somewhere (maybe in Torque), which could account for the slight offset. If it's not that, then it may have something to do with the specific rig. I have seen issues like this in the past, and sometimes it required re-setting up bones. As a test, I shrunk your model to normal Torque size, and created a new (quick and easy) skeleton, and was able to get Herbie to animate properly. This is a screenshot of what I got (Herbie is now only ~4ft tall): *Update* I just did an export test using Hash's PLY (model) and KFM (action) exporter, and it does look like it's a rig issue. When you open the exported PLY & KFM in the AMViewer utility, the same issue comes up (the shoulders are just a bit off). My guess is that it has to do with the conversion of the contrained bones to standard bones. You may need to re-rig your model (either with another rig or just with a basic bone hierarchy). I hope this helps.
×
×
  • Create New...