Jump to content
Hash, Inc. - Animation:Master

Emilio Le Roux

Hash Fellow
  • Posts

    532
  • Joined

  • Last visited

Posts posted by Emilio Le Roux

  1. The last version I have in 14c ...12days later I have the second release of 15 alpha and the latest release part of the forum does not show that there was any release after 14c named 14d

     

    Exactly! The latest release I have is v14c. There isn't any announcement for v14d in the forums (well, they are were deleted anyway), but in the AMREPORTS site, as Rod said, there is a complete changelog. IN this changelog there is a v14d version. I wonder if/where it is available.

     

    The latest version in the ftp site is the same I have, v14c.

  2. Emilio,

    A:M Reports has a full Change Log for v14.

    You can compare the updates there.

     

     

    Thanks Rod! that was very useful.

    Now, I see there is a version v14D in the changelog, but this version doesn't seem to be in the update servers. Maybe you could show me some light? Thanks!

  3. There's a page on their website that directs older users to the ftp site, where they all are:

     

    http://www.hash.com/2007web/updates.htm

     

    The Hash site never works for me in Firefox.

     

     

    thanks, caroline. Just as john said, i found the latest v14 in the ftp server on the bottom of that page.

    But the v14 posts are gone all the same. And only the latest v14c release is on the server.

     

    Why I am looking for this? Because I am using v14, and I found out some problems in release v14c, so I

    went back to v14b, and I'd like to know what was fixed in v14C to see if I am losing somewhat important.

    (as I know what was 'broken' in v14c already).

     

    Since v14 won't be updated anymore, and it's just old history, It would be useful to know some of its release history.

     

    But, you know, there's a positive side! I think that, with this deletion of all v14 releases and updates threads, all A:M users will feel their only way out is to upgrade to A:M v15 ! I hope that works. Unfortunately, I face some technical matters that stop me from attaching to the new version, but who knows in the future.

  4. It should be up there...it isn't. I was able to find it thru the webpage (Hash.com) click on 'SUPPORT'...'UPDATES' and then you'll see an 'FTP' tab in the upper right corner...

     

    ftp://ftp.hash.com/pub/updates/windows/Am2007

     

     

    Thanks John! I'll look in there. Curious enough, I can find every version of AM where they were originally posted, since v11 to v13 and then v15, but v14 has been misteriously deleted from the forums. Maybe it was some evil hacker that wants to harm A:M's image. Anyway, I wanted to see the fix list in the latest releases, but it seems that either I upgrade to v15 or die... unless the forum moderators fix that doing of unknown intentions.

  5. I was about to suggest Fragmotion. But I see you found it already :)

     

    Have been using it for about a year.

     

    Great software, IMO. I bought it.

    Milkshape doesn't compare with Fragmotion. I am using Gamestudio A6, and ofter use Fragmotion to replace the Gamestudio Model Editor. It's a real 3D swiss army knife.

     

     

    I would like to look into other engines, but I found them overwhelming. I don't think I want to code a game from the ground using C++ or learning C#. I am some kind of programmer - but I've seen what Programming makes to the human mind (mine) and don't want that again! :) I'm too busy with the art!

     

    Emilio

  6. Emilio,

     

    I have a question about this, How are you applying the texures to the model? I only use 1 poly per patch, and can Xport them correctly, I think it may be related to the method of the application...

     

    I had the same thing happen to a guitar model I recently built, however, when I reapplied the Txture it came out just dandy.

     

    NOTE: I tested my model in AMTEXv13, from AMv13.0q. using 1 poly and also 16 poly, I chose to work with 16 polys and discovered the artifact problem you decribed in the 16 poly render, as well as my fix.

     

     

    Hey!

     

    This problem was fixed some time ago. Thanks to the Hash team.

  7. I really liked fragmotion. Even with its few glitches.

     

    Now MED is real trouble. It sometimes just refuses to import some .X files with several animations. These files import pretty well in fragmotion.

     

     

    Are there any other alternatives to go from A:M to MDL7? (that would be: from AMXTex to MDL7).

    Some people were using other pipelines. Someone mentioned Unwrap 3D?

     

     

    I'd really like some suggestions.

  8. EDIT: It seems it was more a hack issue. I hope Fragmo continues supporting his great software.

     

    Fragmotion 0.85 beta was removed from the site, as well as the forums.

     

    That would be just too bad.

     

    Let's write to Fragmo!!

     

     

    Visit www.fragmosoft.com

  9. Nice work Emilio. Thanks for such an excellent contribution!

     

     

    You're welcome! I failed to get into the TWO game, but at least I hope I can help a little with this.

     

     

     

     

    oops! The decal as rotoscope doesn't show in bones mode in an action... nevermind!

    -vern

     

    Yeah, that, and the fact it can't be transparent nor locked. I used to use decal-rotoscopes but I ended up misplacing them all the time accidentally, which can't be undone. But anyway, they are there... :)

  10. For those interested in using A:M and Gamestudio (perhaps other engines apply too), these are some of my notes. I use to write them for myself, to help keep track of how I should do things to avoid errors. So, please forgive me if using odd grammar :)

     

     

    --------------------------------

    Notes on Model Creation Workflow

    Hash, AMXTex, MED and Fragmotion

     

     

    My actual workflow involves exporting from A:M to Gamestudio via MED and/or Fragmotion. This pipeline is not hasslefree, as all of the involved tools show some kind of issue.

     

    Since there is a number of small glitches, it became a little hard to track the issues and avoid errors. So, I decided to put it together in this document, in workflow order:

     

    Animation Master:

     

    A:M, from www.hash.com, is one of the easiest modeling and animation tools. It uses patches, so models can be exported at different polygon ‘densities’. Currently, the only exporting bug I know is the UV mapping of 5-point patches and hooks, so one should be aware of the use of these. Note that this is an internal A:M small bug and not the exporter’s fault – but I believe that this issue will be solved soon.

     

    AMXTex:

     

    This plugin from www.obsidiangames.com is really great. I have exported lots of models and animations without a glitch.

     

    The only little bug I found so far is that exporting Right-Handed or Left-Handed .X models have the only effect of flipping the model’s normals. It does not “mirror” the object as expected.

     

    Be aware that AMXTex exports constrains correctly, translating them to bone keyframes. This is not a bug, but a feature: however, if you export a partial animation, it’s best to turn OFF the rigs and constrains that involve other bones you don’t want to keyframe.

     

    For instance, say you want to blend two different animations: A running animation (which keyframes all the bones) and a shooting animation (which should only keyframe the arms). If you export the Shooting animation with the leg rigs turned ON, the legs will be keyframed too. When trying to blend from one frame to another, the legs will try to blend to the standing position. The workaround is to turn OFF the rigs, and then delete any bone drivers that are automatically created after turning them off.

     

    MED

     

    Gamestudio’s Model Editor has been greatly improved in version 6.40. However, there are still some glitches you should be aware of:

     

    When importing .X animations, MED replaces the last frame of each animation with a copy of the first frame of the animation. This is often overseen when exporting a walk or run cycle scene, but it’s wrong, and will eliminate the last frame of your non-cyclic animation like shouting or jumping. As a workaround, you need to create an extra frame in A:M and delete it in MED.

     

    When an animation scene doesn’t keyframe all the bones (like in the shooting example above), the non-keyframed bones seem to inherit their positions from the previous scene. This gets even updated if you change the scene order. And this reflects badly when using the models in Gamestudio. In Fragmotion this doesn’t happen.

     

    Also, when merging your Vertices in MED can weld together undesired vertices, like welding the upper and lower lips of a model if they are too close. It’s better to weld vertices in another animation frame when the mouth is open. Fragmotion has also a better and simpler ‘Weld All’ command.

     

     

    Fragmotion

     

    This nice tool from www.fragmosoft.com has been updated to version 0.8.5.

     

    In overall, Fragmotion feels more reliable than MED. You just import the .X models and export them to MDL7, just like in MED. It works very nicely, but you should be aware of certain issues first.

     

    The good news are that Fragmotion imports animation scenes smoothly from .X model files. It doesn’t have the keyframe glitches that MED has, like importing a bad last frame of animations, or passing bone rotations from one scene to the unkeyframed bones of the next. It also has a keyframe editor, which MED lacks, so it’s easy to delete unwanted keys and clean up your animation.

     

    A small issue introduced in 0.8.5 (trying to fix another user’s request) is that now AMXTex .X files are imported mirrored left to right. This, however, might not be Fragmotion’s fault, because as I said before, AMXTex Right Handed / Left Handed model seems to do nothing. Perhaps if that got fixed it would be up to the user to export the model mirrored or not. And, on the other side, Fragmotion has a ‘Mirror All’ tool that easily fixes this.

     

    Fragmotion hasn’t a Scale Factor at importing, but it has a Scale All tool that can be used to fix model’s scale if needed.

     

    A major problem with Fragmotion is how it converts textures to Gamestudio MDL7 skins. It seems that Fragmotion only learned to save 16-bit textures, with no alpha. This can be convenient at times, but if you want your 24 or 32-bit texture back, you are forced to save the MDL7 and open it again in MED, so you can replace the texture.

     

    Another problem saving textures and materials is actually a Fragmotion’s ‘feature’. If more than one texture is used in the .X file, Fragmotion clamps the textures together one above the other in the MDL7 file (since Gamestudio MDL7 format can only have one set of UV cords). However, you have to make sure that only ONE material with the texture is imported into Fragmotion. Otherwise, even if two ‘materials’ use the same skin image, this image will be duplicated and put together in the MDL7 file, messing with your UVcoords in an irreversible way.

    Also, you must get rid of any unused materials in Frag: if not, big black squares will be generated and clamped together with the texture.

  11. Great information Emilio and nicely presented too.

     

    Just say the word and its hosted on A:M Tutes.

    It'd make a great companion piece to Dennis's Gaming tutorial too. :)

     

     

    Hey! Thanks to all for the Thanks!!

     

    Rod, let me finish a couple sections first. Then we put it on A:M Tutes. Thanks!

  12. I've been putting together some advanced tips and techniques in some kind of manual for myself.

    I decided to share it.

     

    I named the document 'Models for Games' because it also includes specific information about getting your models into a game engine. However, I think the modeling and texturing tips described there may prove useful in any situation.

    modelsforgames.pdf

  13. Thanks Zaryin!

     

     

    Too bad I had to stop for a while - the 5 point patch decaling problem holds me back.

    Actually, I have 2 unexpected problems:

     

    1) At 1 poly per patch, 5 point patches don't export properly their textures

     

    2) At 4 poly per patch, the joints don't seem to animate very well. That's probably due to 3dgs models not supporting CP weights.

     

     

    Well, at least I hope they fix the texture problem soon.

  14. I just reported this to A:M reports, because I think it's an SDK issue. Yet, I post it here because maybe Chris or Arthur could think on a solution for this, since they have experience on exporting patches to polygons.

     

     

    This is what happens with hooks:

    hooktest.jpg

     

     

    And this is a model with 5 point patches

    5ptest.jpg

     

    Both images show: the A:M wireframe, the A:M textured object, then the 1x export and the 4x export in Fragmotion.

     

     

    5 point patches get fixed at 4x or more (also tried 16x...) but hooks are troubled at any exporting resolution.

     

    I don't experience any missing or flipped (normal) polygons. Just these.. rotated, unaccurate UV coordinates.

  15. Hi Emilio,

     

    nice model ! you should add some textures. The new algorithm for building poly models seems to work much better then before. But i experienced some UV related bugs and missing [not flipped] polygons (which i reported already). Most models from the A:M 2006 & A:M Extras CDs don't export correctly independent of the format you use. Do you have any problems with exported models ?

     

     

    Fred

     

     

    uh oh... you brought me some bad news.

     

    Preliminary tests show some texturing errors in 5 point patches. However, the patches seem right when exported to 4 polys/patch. I guess (HOPE, actually) that it is a simple bug that could be fixed easily.

     

    textbad.jpg

     

    here you can see that the 5 point patches on the pecs are textured bad. But they look smooth at 4 polys per patch!

    Note that this is an unedited A:M model, not made for poly count. It's some 4700 at 1, and 20000 at 4.

     

     

    I will make some more accurate tests, to illustrate this problem better, and to see if it's an AMXtex or a Hash SDK problem, then report it.

  16. Oh, I forgot it... I am exporting to .X model using AMXtex, trying both 1 poly per patch and 4 polys per patch.

     

    I just reduced the patch count here...

    lod.jpg

     

    I also distorted the model, kinda trying the mesh for another character.

     

     

    I am not sure about polygon counts, that's why I am asking...

     

    In latest years we've been seen models with anything from 300 to 1500 patches, but nowadays patch counts seem to be far bigger than that - and not necessarily in high end engines.

    I found no cathegoric information on the net - thus I plan to make a full body model at about 2000 polygons (1 poly/patch) or some 8000 (4 polys/patch).

  17. I was very excited by new A:M exporting method, which seems to handle 5 point patches and hooks seamlessly. So I decided to start a new model freely using all A:M tools (instead of clumsyly joining uncontinuous splines together...)

     

    The modeling experiment consists in creating different 3D gamestudio LOD (Level-of-detail) models. Instead of making, texturing and animating several A:M models for different Levels of detail, my plan is to use A:M amazing spline modeling to create a model and export it at different subdivision levels.

     

    This is my work so far:

     

    The mesh in A:M

     

    ammesh.jpg

     

     

    Exported at 1 poly per patch, total 848 polygons

     

    face848.jpg

     

     

    Exported at 4 polys per patch, total 3272 polys...

     

    face3272.jpg

     

     

    Side, low and high...

     

     

    side848.jpg

     

    side3272.jpg

     

     

     

     

     

    This is a fairly complex model, even for the low poly version. What do you think on this polygon count? considering that it's only the head.

     

    Thanks!

  18. My opinion: several years ago, people used to model triangle-wise, because every triangle counted on the weak graphics cards polygon capabilities. I used to make models in 3d max using just triangles.

     

    Nowadays, not only A:M modelers, but almost any modeler using any method, trends to relax a little about that, and produce quad -based models, either polygons or patches. Every quad will be split in two triangles - and in A:M you don't have control of in which way the patch will be divided - but that's not so critical by now, and it's far less important than the time you will take to create your art and produce your game.

×
×
  • Create New...