sprockets Shelton's new Char: Hans It's just donuts by ItsJustMe 3D Printing Free model: USS Midnight Rodger Reynolds' 1950s Street Car Madfox's Pink Floyd Video Tinkering Gnome's Elephant
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

Emilio Le Roux

Hash Fellow
  • Posts

    532
  • Joined

  • Last visited

Posts posted by Emilio Le Roux

  1. "It's better that you UV-MAP (decal) the patches before duplicating. This way you'll get both the front and back patches textured correctly. And most .x importing apps (fragmotion, 3dgs...) will be able to weld the duplicate CPs (vertex) into one, still preserving the backfaces, so the number of final vertices will not be doubled. The faces will be doubled, tho - but that's the way it works: one polygon for front, another for back."

     

    I'm using the AMTEX util to export to X file. And there are no settings to use to weld the CP's is this something that will occur automatically if the CP's are close enough to each other?

    Or even in the exact same spot as the original CP's?

     

    When you mentioned importing, Im a bit concerned, as we have a modified X file viewer based on the AMtex viewer, but it is a custom build, and inside our game the engine is a custom build, do I need to get my programmer to make changes to accomidate welding the CP's?

     

     

    Thank you for your input this has already helped imensely. :)

     

     

    Well, I'm no expert in .X format details, but I talk about my experience. I use AMXtex to export .X models, and import them into MED (Model editorm, from the 3DGS engine), or in Fragmotion, which is a multi purpose model editor and converter, from www.fragmosoft.com

     

    I can only tell you the following tips:

     

    1) Fragmotion has a Weld All command, that will weld Vertices that share same positions into one

    -

    2) Exporting models with AMXtex, if not checking Ignore Duplicate Normals, often will lead to fragmented models (polys that are separated from their neighbors. ) You can fix it with Weld All, but you can prevent it by always checking Ignore Duplicate Normals. Also, you could export models without exporting normals at all - this sometimes gives me better results.

  2. I once needed to do this. You don't need 'double sided normals', but 'double sided faces'.

     

    In poly (game) world, polys are almost always one-sided. I think back-face culling is always ON in game engines, so there's no use for turning it off in A:M (default key: shift-6 will show backfaces on/off).

     

    You are mostly right on your method. But it should be used to specific parts of a model and not the whole model. Your models should be always closed-meshes, with no backfaces.

     

    But, say you are modeling a tree with foliage. In this case, the tree trunk should be a closed 'mesh', and the foliage, just some flat 'patches'. Then, you want to duplicate all the foliage patches and FLIP the normals. But - DO NOT move the CPs, nor slightly. Leave them on the same place.

     

    It's better that you UV-MAP (decal) the patches before duplicating. This way you'll get both the front and back patches textured correctly. And most .x importing apps (fragmotion, 3dgs...) will be able to weld the duplicate CPs (vertex) into one, still preserving the backfaces, so the number of final vertices will not be doubled. The faces will be doubled, tho - but that's the way it works: one polygon for front, another for back.

     

    Always turn OFF 'show backfaces' in A:M to model for games. This way you can check how your real 'backfaces' are working. Otherwise you'll see weird overlapping patches.

  3. I just tried it with the final release of v13 and still the same problems... The eyeballs do not move with the rest of the model on export. Any idea on what is causing this?

     

    Arthur Walasek

    arthurwalasek@comcast.net

     

     

    Arthur: maybe you are exporting at 4 polys per patch (or more) and Chris is using 1 poly per patch? I got some small issues when exporting more than 1 poly per patch, since AMXTex (or the AM sdk?) tries to guess to which bone it will attach the newly-created intermediary Vertices. Well, it's not very probable that this is the problem, but it's a chance.

     

    Second tip: I strongly recommend you to download FRAGMOTION from www.fragmosoft.com. I used the trial as a model-viewer and multi format converter, and it's far better than any MS viewer. Even from opening the .X models and saving them again as .X

     

    Fragmotion opens .X models very well, and often files that open bad in Meshview or such, open OK in fragmotion. I ended up paying the small registration fee.

     

    Third tip: If you export normals, always check 'Ignore duplicate normals' in AMXtex. Otherwise your mesh will be segmented at export. (flat, separated faces instead of smoothing group). If this is the case, you can use the simple command 'WELD ALL' in fragmotion. The problem with MeshView is that it directly starts on the animation (there's no 'STILL' frame), and you have to weld the vertices in a STILL frame so the animation doesnt distort the fragmented mesh.

  4. I'm with Dennis about the design document. You may not use all that crazy template - but it's very useful to write things down in a paper, which most useful feature will be the Version number and the Version History track.

     

    The document could start as simple as:

     

    1) "My game", version 0.2

     

    2) Version History

    Version 0.2 - added some more general features

    Version 0.1 - just started with the document, and added 'general features'

     

    3) General Features

    "Winki Country

    Cows grazing in a meadow.

    People in town interact (Well just the ones that are present witch isn’t going to be a lot)

    Shot of Woot waving to his Momma ..."

     

     

    Otherwise it soon turns into a chaos...

  5. I like games a lot, and I like lots of games... so where to start?

     

    I don't like FPS and platform games very much. I like games with a good story and environment.

     

    The POV, for example, is a matter of choice, but this choice isn't totally arbitrary: there's not much sense on first person if you are playing famous characters, like Neo, Bugs Bunny or even Lara Croft. I think this applies to the OZ characters.

     

    I like my character to grow in the game, but I dislike cyphers and numbers, like Thac0, AC, Courage Extra Points, MMORPGHSLP and RRTSPG. I think sometimes game developers are too involved in a BOX way of thinking ("I am making a MMRTS") instead of thinking in a more abstract way, what is driving the players in.

     

    Of course that is a personal opinion. There should be some people who loves looking at their characters' RPG attribute numbers, like, my dwarf has a strength of 19.5, which is a little better than my elf... but what is really addicting for me is the characters earning new strengths and powers, jumping higher, etc. independent of cyphers.

     

    I like adventure and puzzles - but I don't like lateral math puzzles and such. Just played star wars Kotor and I hated the 'math problems'. In a minute you are swinging your lightsaber and the other you are at a damaged computer console trying to find the numbers missing in this sequence: "2, 22, *, 46, 81, *". This is just an example of lateral puzzles that are completely detached from the story line. But they are always abused.

     

    I like action-adventure 3d games, since the first Alone in the Dark versions.

    Sadly it seems to be a faint genre nowadays, if compared with the big mainstream shoot and fight games. It's like comparing '24' or 'six feet under' with Baywatch. Still, my favorite project would be an action-adventure game.

  6. I feel I am coming late to this thread...

     

    I'd love to participate on the game.

     

    I didnt participate on the TWO film because I was afraid I wouldn't have the time. But currently, game developing is one of the priorities among my personal projects, more than films and animation.

     

    I have a little experience with game creation, via the 3d gamestudio engine, but I think I would be able to create levels using quark. I know the C++ basics although I never used it for games - and I can model and animate well, in my opinion.

     

    I'd like to learn more about using Torque, and this is one of the reasons I would be interested in participating. I learn quick, but I am not sure where I would fit in the project, so it will be up to you - I usually do a bit of everything.

  7. emilio-

    I tried to take .x models from am to fragmotion and then a6 as a mdl7 file and seems for me i get a bad mdl file error in wed. Being a newbie i am probably doing something wrong but is there any tricks or things to be extra careful that you have figured out. I have found am as .x to med and to wed much more easier but I do like some of fragmotions toolsets.

     

     

    I KNOW THAT ONE! I KNOW THAT ONE!

     

    It's a simple problem: this error happens when there aren't any animations on the model. You could add an empty animation in fragmotion, but as MED always saves an 'empty' animation or scene with any model, the easiest solution is to open the model in MED just to save it again.

  8. Thank you for the update, Chris! It works great.

     

    By the way - I do use fragmotion to take the .X file and save it as MDL7. I find MED .X importer a bit unreliable - and fragmotion has better texture tools IMO. (Among other things, it automatically takes all textures from the .X model and creates a single MDL7 texture).

     

    Besides that, the AMXTex exported models are so clean that I can use fragmotion to turn the .X file into anything else, for instance, to go to a 3dpaint app.

  9. interesting I might try it. I have a pretty good/reliable pipeline now, betwen AM Unwrap and MED, but I guess theres always room for something new, although I may wait till they make it more user freindly.

    Oh, now that you mention it, I forgot to say that fragmotion has UV tools too.

     

    Well, the important thing is that you get your pipeline working. I almost have mine too, and I think it will involve fragmotion (and probably NOT involve MED :) ) But then, I want to texture directly into AM.

     

     

    Regards.

  10. My recent 'discovery' is this application, Fragmotion.

     

    It's a fully functional application (Just US$ 20,00! to remove the nags) with many features, ideal for translating and cleaning up models and animations from one format to another.

     

    I use it to import .X models exported from AMXtex and saving them as 3D GameStudio MDL7 files.

     

    The MDL7 is the newest GameStudio format, which includes vertex animation, bones animation, and in-file textures.

     

    Saying that fragmotion is a good replacement for the 3dgs Model Editor (MED) is like saying that Word is a replacement for Notepad.

     

    Here is the Good and Evil i have found so far in Fragmotion:

     

    GOOD:

    -Fragmotion imports .X models in the correct orientation, with no problems.

    -Imports and separates different animation sequences from the imported file.

    -Imports several materials.

    -Since MDL7 textures must be in a single image, instead of discarding textures, fragmotion JOINS the textures side to side in a single image, so you can use several small images in A:M to texture parts if you want.

    -It exports animations as named scenes in the MDL7 format.

    -It can convert bone to vertex animation while exporting MDL7 (but it can't read vertex animation from MDL7 files, see below)

    -The forum open to feature requests and suggestions. The developer's dedication is impressive, and he uses to include new features as they are requested.

    -Lots of formats.

     

    EVIL:

    -The keyframe editor is very primitive yet. Deleting chunks of frames and cleaning up sequences is a pain. The developer is working on this.

    -The alpha channels in textures are not preserved (yet).

    -Vertex animation is not supported. (Although MDL7 files can be converted from bones to vertex animation at exporting time).

     

     

     

    The greatest feature, to me is the ability to clamp textures in a single image when exporting to mdl7. This way you can have a PATCH IMAGE for a repeating group, i.e. the foliages of a tree, and another for the trunk. Both patch images will be joined side to side and correctly UV mapped in the MDL7 file.

     

    I use patch decals a lot. You can make impressive textures for walls, metal pipes, wood, leaves, everything, using this time-and-memory inexpensive method, like on these samples:

     

    predios.jpg

     

    shiptoon.jpg

     

    treehouses.jpg

     

    It's worth trying.

     

    Regards,

  11. This was started on another thread, but the posts were getting a little off-topic, so I decided to start a new thread.

     

    Some hints on working with A:M and 3DGS were post before on this thread.

     

     

    I just wanted to share some more information on this:

     

     

    1) The MED (model editor) has a simple but nice SKIN editor/painting utility. It is not any automatic UV unwrapper, but it remembers the old LithUnwrap functionallity.

     

    2) Because of this skin editor, I found out that you should NOT check the "Shift Y to 1" option. UV coords exported from AM with this option will be located OUTSIDE the image. Since skins repeat, the model will look good, but it will be hard to edit in the MED skin editor.

     

    3) I like to use AM patch images (group images) for quick decaling. For instance you could texture all the patches of a tree trunk with a single 64x64 BARK.BMP tile, with no need of complex UV techniques.

    The problem is that .X models only accept 1 skin image, so you won't be able to add other texture images for the leaves, etc.

     

    Fortunately, later in MED's skin editor, you can find all UV coordinates generated by patch decals as a single group of overlapping faces. So you can select a point of these UV triangles, then 'select connected', and scale / position the UV 'mesh', for example, to one quarter of the image.

     

    Every group that is patch-decaled in AM generates a different connected group of UV triangles in the skin editor. So it is easy to use, say, four 64x64 tiles in a single 128x128 image.

     

     

    4) One more tip, pretty obvious: If you are going to make double-faced geometry (like tree foliage, sheets of paper, wings, etc...) before exporting, you can group ALL the geometry to be double faced, then just COPY, PASTE and FLIP. (it is required to set the copy offset to 0,0,0 in am->options).

     

     

     

    -Cheers!

  12. Just walked in this old thread...

     

    So, how is the game going, Will?

     

    I just got GameStudio extra edition, and what impressed me the most is the huge community and resources. Name it, and probably you will find tutorials, scripts and resources for any style you want.

     

    For instance, I found:

     

    "how to make a diablo-style game"

     

    :)

  13. Now I feel like a complete idiot :) That only doesn't make me feel sad because all my problems were suddendly solved.

     

     

    In the manual:

     

    New features...

    MED .X import

      The .X import dialogue now has a [Transform] button that allows

      swapping or mirroring arbitrary axes. By default the Y and Z axes

      are swapped on importing a .X model.

     

     

    In MED:

     

    xdialog.gif

     

     

    I highlighted the settings you should check. I only don't know what 'shift Y to 1' does. It was checked by default.

     

    This imports the model, corrects the axii, corrects the normals, transform bones animation in vertex animations, and you don't need to rotate your model to the RIGHT view nor export as Left-handed.

     

    Duh...

  14. First of all, I wanted to say, the phrase I used 'your tips are more than welcome' doesn't make enough justice. Indeed, you are the one who has any experience on these matters. I'm just putting some things together. So, I should have rather said "you're KEY" :)

     

    I think your method of pasting all animated key frames in a single animation action is the safest. What I was doing is, creating my animation, say, with keyframes every 5 frames, and before exporting, COMPRESS the keyframes so they only use frames 1-4 or so. But be aware, there's a little bug in AMXtex that makes it crash when you have keyframes at fractional times i.e. not snapped to whole frame numbers.

     

    I was thinking about: what if we include a simple pose, like a 'construct' pose, as the first pose of the animation sequence? It would be flipped all right.

     

     

    Hmmm... wait a minute.. i'm having a thought...

     

    A-HA ! I knew it!

     

    I think i found the ONLY problem here...

     

    The 'bare model' , i.e. the construct frame with no animation, is NOT actually being exported left-handed. Want a test? Make a horn at Thom's head, only at right side. Export as left-handed and voilá! The horn is NOT at left side.

     

    The faces normals would be correct IF the model had been mirrored, but since the model wasn't mirrored, the faces are flipped!

     

    Now, the animation keyframes ARE exported left handed - that's why the flipped, unanimated object flips: because the 'construct' left hand becomes the right hand in all other frames!

     

    I guess the only workaround by now is to create a construct keyframe manually - or then just ignore the normal flip in the construct?

     

    -Emilio

  15. Emilio AKA Mosca,

     

    I don't know what you are doing different but my model IS mirrored left to right. When I move the model left in a:m and export it right handed it moves right in game studio. As far as I can tell we are doing the same thing.

    Yes, you are right - i was wrong. Thanks for noticing this.

     

    Models must be exported as left-handed indeed, and this opens a new bunch of problems.

     

    For some reason, left-handed models have all its normals flipped inwards. But animation keyframes are right.

     

    If you go to the 'construct' frame in MED and flip all normals back, then the animation keyframes will be flipped bad.

     

    I guess it has something to do with the mirrored bones animation - the same way it happens if you scale a bone -100 in some direction. I feel it would not be hard to fix this somehow in the exporter, but that's a task for Chris :)

     

     

    triath: your tips are more than welcome, as we are trying to figure out every task. Ultimate unwrap may be an easy solution if you are decided to invest a little more money, but it would also be great if there was an easy way to go from AM to gamestudio.

     

    Later!

  16. Ok, I kinda found a solution for this...

     

     

    Appending animations in gamestudio

    Importing .X files with several appended animations (As in appended in AMXtex) doesn't work in GameStudio. The best way i found so far is as follows:

     

    1. Export the model using AMXtex i.e. "Goblin.x"

     

    2. Export each animation appended to a new copy of the file. i.e. "Goblin - walk.x" "Goblin - run.x" "Goblin - jump.x"

     

    3. in Gamestudio, for every animation

    - import the file, i.e. "goblin - walk.x"

    - rename the frames i.e. 'walk 1, walk 2, walk 3...' . There's a command for that.

    - file - export - export model to ASC and tell the exporter to create frame named files only. It will then create one file for each frame, i.e. "walk1.asc, walk2.asc".

     

    4. Once you have exported all animations you want to append, open your .X model, save as MDL file, and then

    - file - import - import append frames. A dialog will open. Go to the location you saved the named frames into, and then select them and click OK.

    I suggest that you select frames from ONE animation at a time, so you append the animations in the order you want. Otherwise they will be appended in alphabetical order.

     

    Remember that gamestudio uses a frame names convention for default behaviors, like 'stand, walk, run..." . see the manual.

     

    -

  17. Now, a new problem to solve:

     

    .X files with more than 1 animation can't be imported in MED. The program freezes before the importing dialog. Any clue on why this is happening?

     

    I found no other way to have a model with all animations that the ridiculous task of making a single action with all character animations in a sequence! i.e. walk, run, crawl...

  18. I think this may help:

     

    Left-Handed: this option is only to correct importing in applications that use a slightly different coordinate system, which causes the model to be 'mirrored' left to right, but not in gamestudio. The problem is that this option (export as left-handed) also flips all the normals inside out. We should ask Chris for a way to correct this in AMXtex, but it's not necessary for gamestudio.

     

    Welding vertices: the button is grayed out when you are in animation mode. Turn animation mode off.

     

     

     

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

    Also these are some hints I collected from my little experience and several other guys' vast experience :)

    (triath among them of course!)

     

     

    1) Use right view as front.

    The easiest way is, in bone mode, select the main bone, hit ROTATE, and CTRL-rotate the bone around Y (the bone will rotate along with the geometry). To do this faster and by numbers, you can activate the Manipulator Dialog, select the main bone, hit ®otate, then type '90' in the green Y rotate field, and then, hit CTRL-ENTER. (this works if the main bone is in the default orientation used in Hash).

     

    2) exporting animation with AMXtex

    You can use any rig, but the most important issue here is that the bones that ACTUALLY drive the geometry have keyframe information at the first frame. You don't need to bake anything, and to avoid getting your action all messed up, the easiest way is: turn OFF all keyframing options from the bottom bar, leaving only the first button on ('key skeletal translates'). Use the 'key whole model' mode, and shift-click on the key button to keyframe 'all filtered channels'. This way you don't create unnecessary channels and also you avoid scrambling it all by mixing up bone rotation with constrains. Probably you are not using any bone translate in your animation, but that's all AMXtex needs to know that 'there is a bone here'.

     

    And the good news are, you don't have to worry so much about big or complex rigs and skeletons, because:

     

    3) importing animation in gamestudio

    The most efficient method in gamestudio is actually vertex animation. Bone animation is slower and it's actually a new feature, and also it is only available in commercial and pro versions of the engine. But don't worry!

    When importing, there will be a dialog with a series of checkboxes:

    (checked) MESH

    (checked) MATERIAL

    (checked) BONE

    (unchecked) POINTS ANIMATION

    You should uncheck BONE (since it is not supported in std/extra) and check POINTS animation instead. To my surprise, this converts all bones keyframes to vertex keyframes!

    Also, by unchecking BONES, you are ignoring huge unnecessary content. The importing time will be reduced dramatically. (from 15 seconds to half a second, on my 5000 patch test model!)

     

    It worked like magic so far. It's good to know that you can use A:M best animation tools the way you like, and you will obtain an equally efficient animation as with simple FK animation!

     

    I know I have repeated some tips that have been said already, but I thought it was a good idea to put them together. IF you have any other tips to add here, we can build ourselves some kind of quick manual for A:M / AMXtex / Gamestudio :)

     

    Good luck

×
×
  • Create New...