Obsidian Games
-
Posts
145 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Obsidian Games
-
-
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
-
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.
-
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?
-
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.
-
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!
-
the new v13 one gives me an "unhandled exception #1" wheather or not skin weights are on.
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?
-
hey Chris any word on ParallaxOcclusionMapping?
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.
-
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.
-
Is there going to be an update for the V12 exporter, or should I free up some cash on my credit card and upgrade to V13?
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.
-
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.
-
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,
-
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.
-
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.
-
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.
-
Dennis, you can have multiple texture maps in Torque but they must all conform to the power of TWO. (64x64, 128x128, 256 x256, etc. and I think you can use images with dimensions such as 128x256, 1024x512, etc.)
You can definitely use different height vs width dimension as you suggest (128x256, etc), as long as both the height and width are powers of two.
-
Okay, Chris, hopefully you will be able to take a look at the dts, dsq and dump files that I have zipped up.
Am I mistaken in thinking that AMXdtsPlus exports decals? I'm not getting any decal data in the export. I have tried changing the decals from TGA to BMP but that hasn't made any difference.
Also I am only getting a few frames of the animation coming through. You can compare the DSQ file with the QT movie, above, to see what I mean. Any suggestions would be welcome?
Thanks.
Paul -- The fact that you're not getting decal export and are only getting 5 frames of animation indicates that you're exporting using the unregistered version of AMXdtsPlus. These are both limits of the unregistered version.
-
Hmm, I haven't seen this type of problem with bone location yet. Can you email me the project file so I can take a look?
-
If I export the individual actions as dsq it comes out right. But the torque bones dont exactly match where the a:m bones are and it messes up the animation a bit. The frogs arms are off so they don't touch the frog's body and the knees are a little too high. I guess torque exporter doesn't export all the bones in the a:m model and it interprets them close to where they are but not exactly. Is there a fix for this? I tried baking the action but it made a mess.
The exporter will, by default, only export bones that have CPs attached. You can force export of other bones (ones without CPs attached) by adding them to the .cfg file (placed in the directory that you export to) under the "AlwaysExport" section. The example files should have .cfg files that you can copy and modify, and the .dmp file will tell you what cfg file names it's looking for. Just rename yours to one of those names, and it should pick it up.
Please test it out and let me know how it goes. Again, if you're still having problems, I'd be happy to take a look at the project file.
-
Are you exporting your model and action to the .dts file? Or are you exporting your model to .dts and then exporting your action(s) to .dsq? There can be issues when exporting animations to the .dts file if the actions do not start from the model's default pose, so that might be the issue. Please try exporting them separately and let me know how it goes. If it still doesn't work, I'd be happy to take a look at the project file and see what I can find.
-
Well, Hash did it again. I can't believe they thought to add this feature, but the new V13 beta has the option to set the max number of weights per vertex on export (which AMXtex needs). This is going to save me a ton of work, thanks Hash!
I do have a question to Hash in the beta announcement thread as to how I can get this to work, but as soon as I can get it working (and test the new feature), I should be able to release the new V13 AMXtex exporter.
-
Thanks everyone, I'm glad you're all as excited about this as I am. This is definitely a great addition to the export SDK, and again, I can't thank Hash enough for their work to add this feature.
Anyway, I couldn't wait -- I had to test out CP weights with AMXdtsPlus. Here is the same two boned model, exported from A:M to the DTS format using AMXdtsPlus. It's the same layout as before -- the model, the bend action without CP weight export, and the bend action with cp weight export.
I will continue to work on validating these, and will post more news as I have it.
-
I've started working on implementing the newly added CP weight export option to my exporters (AMXtex and AMXdtsPlus), and wanted to share what I've done so far. It's not available publicly yet, but I still thought it was worth sharing.
I started with AMXtex, and have had some great results. The image below shows a two-boned cylinder (exported to the .X format using AMXtex) in various stages. The first image is the model itself, the second shows a bend action without cp weight export, and the third image shows the bend action with cp weight export.
I still need to work on fully validating the cp weight additions, and make sure they comply with DirectX rules (which I think only allow a maximum of 4 bones to control any one vertex). However, it's working great so far, including multiple patch-per-poly export.
Once that's complete, I will be working on adding the option to AMXdtsPlus (Hash just released the updated OSX SDK, so I'll be able to implement it on both PC and Mac).
One more thing, just as a heads up. Since this is a new SDK export feature, it will only be available for exporters on A:M V13.
-
Does anyone know if Torque has something similar to A:M's cookie cut decals? That would be very useful for things like the crown. Adding detail without adding more polygons.
I have been able to get cookie cut / transparent decals to work with AMXdtsPlus, but I'm having issues getting it to differentiate between cookie cut and normal decals, so it's disabled on the public version. This is definitely something I'll be working on adding.
Chris, if you see this before you go on your trip could you let me know what this error message relates to?
Just for fun I attempted to export the full movie model of Tinman, without the rig, to Torque. I just gave him a single bone and attempted to export. It seemed to be going alright but then this error message popped up.
[attachmentid=15632]
Is this related to 5 point patches or is it down to the high number of polygons being generated? The model has 10,675 patches and many of them are 5 pointers.
I think I've read that the triangle stripper code (which is part of Torque) breaks down on really big models. I'm not sure of the numbers where this starts to happen, but I'm pretty sure it's below where you're currently at with that model size. Unfortunately this will be a limitation that I can do nothing about, but for Torque models, here is the recommended sizes for different models (taken from the Torque docs):
Here are the recommended maximum polygon counts (for your highest level of detail):
Characters 2250 polygons
Vehicles 1500 polygons
Weapons 500 polygons
For any other object that you would add to your scene (ie. Crates, barrels, rocks, etc.) you should not exceed 400 (it is recommended that you aim as low as possible, since there is no reason that doo-dads should be polygon intensive).
-
Chris, I look forward to you assessment of the situation once you have read your email from Hash Inc and had a look at the changes to A:M13. I didn't realise that AMXdtsPlus already had the ability to subdivide 5-point patches. The models shown here have been carefully built to ensure that no 5-point patches were included. Had I known I would have tried exporting models with 5 pointers too. I will try that later today, just to see what comes out.
So, If AMXdtsPlus already handles 5-point patches what will be different in the new A:M13 alpha? Oh. Hooks, I guess. Anything else?
Paul,
All A:M poly exporters have this ability. A:M converts all patches (including hooks and 5 point patches) into polygons before handing the data off to the exporter.
I think the issue was that a number of people did not like the way A:M converted 5 point patches and hooks into polygons (the exported polys did not look as smooth as they did in A:M). I won't know for sure without seeing the new behavior, but I would imagine that it's been changed so the exported 5-point patch/hook looks more like it does in A:M (which would be a great thing).
I will definitely check back after I get back from my trip.
Obsidian Games donates Torque Exporter
in Game Development
Posted
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!