FPS Animations
Pages: 12
| James Parsons wrote: |
|---|
| im just saying that your game could be modified through the xml file to make it "easier" |
You shouldn't protect someone from not doing things the way you want them to.
You should protect people from doing things that could be harmful to themselves.
OBJ files are for static meshes only. Like I said, they support vertices, UVsets, normals, primitive lists (index arrays for the vertices), and references to the textures and material used.
I've found that, for exporting from the 3D modeling software, a good choice may be COLLADA (.dae), and FBX. COLLADA is ASCII and has XML syntax, and FBX can be in either binary or ASCII. I think the best way to go is to export in an easily readable ASCII format like COLLADA or ASCII FBX and then write a converter to make a binary version of your files in a custom file format that best suits your engine and project, since loading ASCII files as your final import will be burdensome, and loading binary files will impede development due to their content being harder to read.
Both COLLADA and FBX aim to support a full scene export, including skeletal animation, as well as lights, materials etc. .
Yes, rastertek has less material for OpenGL at the moment, I just linked the section where OpenGL initialization and static mesh rendering are covered, as asked by lmsmi1.
Well, there are plenty of good sources for 3D modeling, although -- especially when first starting out -- , it may be helpful to decide on a software that's convenient for you, because there are several differences in the user interface between 3ds Max, Blender, Maya, XSI, Lightwave, etc . Once you settle on your software, you can start learning about modeling based on that program (and you can always migrate on a different one later on). Also, 3D modeling for games has a few differences in the fact that you have to pay much closer attention to your number of primitives (due to real-time rendering), and that youy'll most likely want to export triangulated meshes.
I've found The Gnomon Workshop's material invaluable over the years, I am more familiar with Autodesk Maya and am getting increasingly familiar with 3ds Max at the moment. For free tutorials, I don't have some available off the top of my head although there's some great stuff on youtube etc. (and it'll help finding them so long as you search for techniques for your software of choice, rather than generally). How about this, from a brief search:
http://www.youtube.com/watch?v=o_27q1Iyufg
I've found that, for exporting from the 3D modeling software, a good choice may be COLLADA (.dae), and FBX. COLLADA is ASCII and has XML syntax, and FBX can be in either binary or ASCII. I think the best way to go is to export in an easily readable ASCII format like COLLADA or ASCII FBX and then write a converter to make a binary version of your files in a custom file format that best suits your engine and project, since loading ASCII files as your final import will be burdensome, and loading binary files will impede development due to their content being harder to read.
Both COLLADA and FBX aim to support a full scene export, including skeletal animation, as well as lights, materials etc. .
Yes, rastertek has less material for OpenGL at the moment, I just linked the section where OpenGL initialization and static mesh rendering are covered, as asked by lmsmi1.
Well, there are plenty of good sources for 3D modeling, although -- especially when first starting out -- , it may be helpful to decide on a software that's convenient for you, because there are several differences in the user interface between 3ds Max, Blender, Maya, XSI, Lightwave, etc . Once you settle on your software, you can start learning about modeling based on that program (and you can always migrate on a different one later on). Also, 3D modeling for games has a few differences in the fact that you have to pay much closer attention to your number of primitives (due to real-time rendering), and that youy'll most likely want to export triangulated meshes.
I've found The Gnomon Workshop's material invaluable over the years, I am more familiar with Autodesk Maya and am getting increasingly familiar with 3ds Max at the moment. For free tutorials, I don't have some available off the top of my head although there's some great stuff on youtube etc. (and it'll help finding them so long as you search for techniques for your software of choice, rather than generally). How about this, from a brief search:
http://www.youtube.com/watch?v=o_27q1Iyufg
Last edited on
Well, I've decided to use Blender for 3D matters. I'll look into FBX and COLLADA for models. Thanks.
Oh and, does anyone have any REALLY good Blender tutorials for guns?
Oh and, does anyone have any REALLY good Blender tutorials for guns?
Okay, how the heck do I give the gun a reload ability? Don't I have to use something called hierarchy or something?
You're welcome.
You need to animate part of your model by setting keyframes etc. . The specifics depend on how you want to work with this. Do you model an arm holding a gun and have it follow camera movement? It's possible you can achieve a quite rough result with no skeletal animation (an alternative is using skeletal with rigid bind -- which means that whole meshes are applied to each bone, like the first "Tomb Raider" etc but it's not a great idea and you'll still have to parse the skeletal data from your file). Do you model a character with skeletal animation and simply look through the character's viewpoint, not rendering the head as you do and play your animation clips?
In the first case, you do not necessarilly need a skeletal animation although it would greatly improve the effect, since you could animate the arm too (using smooth binding and skin weights). In the second case you have to do skeletal animation and export that, then read it from the file. I strongly suggest you implement reading and rendering static meshes prior to working with animation though. It will also get your file parser to a good starting point prior to having to incorporate the animation data to the static mesh structures and classes.
For good results, you'll have to implement skeletal animation and parented objects to the character (the objects transformations are relative to the character, or a bone of the character), so that the gun gets reloaded as a seperate object with no skeletal animation (while following the character's arm) and the arm, along with the rest of the character, gets animated using skeletal animation with smooth bind.
You need to animate part of your model by setting keyframes etc. . The specifics depend on how you want to work with this. Do you model an arm holding a gun and have it follow camera movement? It's possible you can achieve a quite rough result with no skeletal animation (an alternative is using skeletal with rigid bind -- which means that whole meshes are applied to each bone, like the first "Tomb Raider" etc but it's not a great idea and you'll still have to parse the skeletal data from your file). Do you model a character with skeletal animation and simply look through the character's viewpoint, not rendering the head as you do and play your animation clips?
In the first case, you do not necessarilly need a skeletal animation although it would greatly improve the effect, since you could animate the arm too (using smooth binding and skin weights). In the second case you have to do skeletal animation and export that, then read it from the file. I strongly suggest you implement reading and rendering static meshes prior to working with animation though. It will also get your file parser to a good starting point prior to having to incorporate the animation data to the static mesh structures and classes.
For good results, you'll have to implement skeletal animation and parented objects to the character (the objects transformations are relative to the character, or a bone of the character), so that the gun gets reloaded as a seperate object with no skeletal animation (while following the character's arm) and the arm, along with the rest of the character, gets animated using skeletal animation with smooth bind.
Last edited on
Sure, that would not need skeletal animation. You could do something like animate the whole gun moving downwards and out of screen, play the "reload" sound, and then bring it back into view (or something in those lines).
Still, your NPCs will almost certainly use skeletal animation anyway.
Still, your NPCs will almost certainly use skeletal animation anyway.
So is there a specific word for this "animation" of the gun reloading, or is it just called an animation? (If there is a specific word for the animation, I would like to know it for looking up tutorials for Blender.)
And about the NPCs:
What if I have a body model, then have a separate model of it's arms and legs? That way I can move the arms and legs alone, w/o the body. Could that work? Or will I have to use skeletal animation for the AI?
And about the NPCs:
What if I have a body model, then have a separate model of it's arms and legs? That way I can move the arms and legs alone, w/o the body. Could that work? Or will I have to use skeletal animation for the AI?
This type of animation is simply a world-space transformation applied to the object (although for an FPS, your gun will likely be parented to the camera position, so that the animation will have to be converted to a coordinate system whose origin coincides with the position of the camera. In other words, you are rotating your gun relative to that position/origin). So, in Blender terms, it doesn't really have a name other than "rotation" keyframe animation, which you will then have to convert to that coordinate system in your engine.
In case parts of your weapon animate independently of other parts, like a switch going on or off etc, in 3D programming terms that might be "world transformations" (moving, rotating or scaling) of different parts of the gun that you have specified as seperate objects/meshes. In Blender terms that again is "move, rotate, scale" animations using keyframes.
Yes, you could have a body model composed of different parts, and avoid skeletal animation by specifying rotations of the arms and legs as simple rotations in local coordinate systems, much like the gun that I discussed. The effect will probably come out looking fairly bad though, unless your character is composed of boxes or has disconnected arms and legs to begin with. Implementing it properly so that it looks good will essentially involve skeletal animation with rigid binding, like I discussed above about Tomb Raider 1 style character animation. That's essentially a collection of seperate meshes, one for the forearm, one for the upper arm, etc, which are modelled so that they snugly fit in one another at the joints. A rotation value at a local coordinate system controls each one (in Blender terms: each joint is parented to it's preceding joint. The forearm is parented to the upper arm, the upper arm to the shoulder etc, and the pivot point of the forearm is at the elbow, the pivot point of the upper arm is at the shoulder, etc. This setup is the concept behind rigid bind skeletal animation).
It will also be severely limiting for smooth animation, and implementing it would not be all that different from implementing bones with smoot bind, but without the advantages of smooth bind. The reason this was done in early 3D games was a matter of the incapability of the hardware to perform the real-time calculations required by smooth bind. Since that is no longer an issue, I think that character animation with rigid bind is certainly not a good idea.
No, bones would have no effect relating to AI. The only thing that you might get exclusively with bones is things like characters turning their head to look at objects as they pass by, etc. . However, they are extremely useful for your actual animation clips. Take a look at something like this:
http://content.gpwiki.org/index.php/OpenGL:Tutorials:Basic_Bones_System
In case parts of your weapon animate independently of other parts, like a switch going on or off etc, in 3D programming terms that might be "world transformations" (moving, rotating or scaling) of different parts of the gun that you have specified as seperate objects/meshes. In Blender terms that again is "move, rotate, scale" animations using keyframes.
Yes, you could have a body model composed of different parts, and avoid skeletal animation by specifying rotations of the arms and legs as simple rotations in local coordinate systems, much like the gun that I discussed. The effect will probably come out looking fairly bad though, unless your character is composed of boxes or has disconnected arms and legs to begin with. Implementing it properly so that it looks good will essentially involve skeletal animation with rigid binding, like I discussed above about Tomb Raider 1 style character animation. That's essentially a collection of seperate meshes, one for the forearm, one for the upper arm, etc, which are modelled so that they snugly fit in one another at the joints. A rotation value at a local coordinate system controls each one (in Blender terms: each joint is parented to it's preceding joint. The forearm is parented to the upper arm, the upper arm to the shoulder etc, and the pivot point of the forearm is at the elbow, the pivot point of the upper arm is at the shoulder, etc. This setup is the concept behind rigid bind skeletal animation).
It will also be severely limiting for smooth animation, and implementing it would not be all that different from implementing bones with smoot bind, but without the advantages of smooth bind. The reason this was done in early 3D games was a matter of the incapability of the hardware to perform the real-time calculations required by smooth bind. Since that is no longer an issue, I think that character animation with rigid bind is certainly not a good idea.
No, bones would have no effect relating to AI. The only thing that you might get exclusively with bones is things like characters turning their head to look at objects as they pass by, etc. . However, they are extremely useful for your actual animation clips. Take a look at something like this:
http://content.gpwiki.org/index.php/OpenGL:Tutorials:Basic_Bones_System
Last edited on
Sure. As far as the placement and non-interactive part is concerned, all of it can be (and should be) done there. However there's a lot to be done later, inside the engine, to put all those animations together so that they are placed in an interactive context. The notion of your real-time OpenGL camera position will have to be connected with your gun and it's "idle", "reload" and other possible animation clips. This is done in your code. The animation clips themselves, as well as the bone hierarchy, skeletal structure, etc, are all done and exported from your 3D modeling package.
Last edited on
So about .dae and .fbx:
Which is best for animations and bones in OpenGL? I've got a fully functional, rigged AK-47, and don't know which I should export it to? Which is better IYO?
Which is best for animations and bones in OpenGL? I've got a fully functional, rigged AK-47, and don't know which I should export it to? Which is better IYO?
Great. Well, like I said, both can export your animations: .dae is in ASCII format, and .fbx can be either ASCII or binary. .dae intends to be an intermediary format for transferring your 3D data between applications, and ASCII .fbx would follow pretty much the same mentality. .dae is in XML format, while the ASCII .fbx has it's own specifix format of storing the information. So if you know XML, you could easily read the content of a .dae, and thus easily write a parser for it.
I haven't had to use ASCII .fbx, but I have used binary .fbx and (ASCII) .dae. I use .fbx for transferring data between 3D design programs (3ds Max, Maya etc), and I have been using .dae for some real-time application projects I am working on. (I haven't looked around for binary .fbx parsers. If such a thing was available and reliable at the same time, it might be worthwhile to consider as a choice, since it would achieve compactness of size and completeness of data simultaneously, in a way ASCII .fbx or .dae would not. The advantage of ASCII .fbx and .dae is readability and the ease with which you can write your own parser for them, and transfer your 3D data around as you work on your project. They take much more space than a binary file -- .fbx or otherwise -- but are more user-friendly and easier to work with while in development).
So, so long as you know where I come from and what my take on the subject is, based on what I've seen I would recommend .dae , as it's very readable and probably even parsable by XML-parsing libraries you may find around (even though the COLLADA documentation has all the information you need to simply parse the content yourself, which is very easy to do). But it's important to stress that .dae does not intend to be a final file-type for your 3D data. It intends to be a readable intermediate format. So my suggestion would be to use what is easiest to parse in order to get your data in your engine, test it, finetune it along with the engine etc, and then eventually save your data again in a format that suits your needs -- probably binary. You could go for writing a binary .fbx parser(provided the .fbx documentation covers it -- I haven't checked to verify this), or save the data in a format of your own.
To some extent, you will probably have to string your content in a file-type of your own design, since each game and engine can have peculiarities that need to be explicitly stated in a file, and which are not understood by a generic 3D data file (such as the difference between collision meshes and renderable meshes, or information about the placement and behavior of level sectors, their loading order, etc. etc. -- every game probably has some notions particular to itself about how the input 3D data is represented and handled at run-time).
So -- I would recommend something readable and easily parsable in development, and I know .dae can do that. ASCII .fbx would be equally good but I haven't used it personally.
Hope this helps you somewhat,
Ogoyant
I haven't had to use ASCII .fbx, but I have used binary .fbx and (ASCII) .dae. I use .fbx for transferring data between 3D design programs (3ds Max, Maya etc), and I have been using .dae for some real-time application projects I am working on. (I haven't looked around for binary .fbx parsers. If such a thing was available and reliable at the same time, it might be worthwhile to consider as a choice, since it would achieve compactness of size and completeness of data simultaneously, in a way ASCII .fbx or .dae would not. The advantage of ASCII .fbx and .dae is readability and the ease with which you can write your own parser for them, and transfer your 3D data around as you work on your project. They take much more space than a binary file -- .fbx or otherwise -- but are more user-friendly and easier to work with while in development).
So, so long as you know where I come from and what my take on the subject is, based on what I've seen I would recommend .dae , as it's very readable and probably even parsable by XML-parsing libraries you may find around (even though the COLLADA documentation has all the information you need to simply parse the content yourself, which is very easy to do). But it's important to stress that .dae does not intend to be a final file-type for your 3D data. It intends to be a readable intermediate format. So my suggestion would be to use what is easiest to parse in order to get your data in your engine, test it, finetune it along with the engine etc, and then eventually save your data again in a format that suits your needs -- probably binary. You could go for writing a binary .fbx parser(provided the .fbx documentation covers it -- I haven't checked to verify this), or save the data in a format of your own.
To some extent, you will probably have to string your content in a file-type of your own design, since each game and engine can have peculiarities that need to be explicitly stated in a file, and which are not understood by a generic 3D data file (such as the difference between collision meshes and renderable meshes, or information about the placement and behavior of level sectors, their loading order, etc. etc. -- every game probably has some notions particular to itself about how the input 3D data is represented and handled at run-time).
So -- I would recommend something readable and easily parsable in development, and I know .dae can do that. ASCII .fbx would be equally good but I haven't used it personally.
Hope this helps you somewhat,
Ogoyant
Last edited on
I think FBX is an Autodesk proprietary format, could be wrong. There is a high level FBX library out there, so you don't have to parse anything (pretty sure it works directly with DirectX). DAE is totally open, no one is going to ever tell you what you can and can't do. If you're using OpenGL and Blender because these are open source options, then stick with the DAE.
Could very well be the case LowestOne, I have the sense that it is proprietary and that's why I said I am not sure, although it's been some time since I last looked into the subject of 3D file formats that are handy for my purposes and workflow (and I personally chose DAE). I have only had to open (not parse) ASCII FBX files on occassion and they were fairly readable, although I have never used them apart from transferring data from one 3D design program to another.
Yes, DAE is totally open and the documentation is very good -- plus it's in XML format. So I would definitely recommend it.
EDIT:
http://xbox.create.msdn.com/en-US/education/catalog/sample/skinned_model
Yes, DAE is totally open and the documentation is very good -- plus it's in XML format. So I would definitely recommend it.
EDIT:
| Out of the box, the XNA Framework provides only partial support for animation. It defines an intermediate object model for storing animation data inside the Content Pipeline, and can import data into this object model from FBX and X formats. The built-in ModelProcessor also converts vertex channels of BoneWeightCollection data into pairs of channels with VertexElementUsage BlendIndices and BlendWeight, suitable for skinned rendering on the GPU. However, the framework doesn't include any runtime animation classes. That functionality is implemented by this sample. |
http://xbox.create.msdn.com/en-US/education/catalog/sample/skinned_model
Last edited on
Also, a short internet search got me this relevant paragraph from the wikipedia FBX entry:
And also see:
http://openendedgroup.com/field/LoadingFBXFiles
That's what I vaguely remembered regarding FBX, but wasn't sure earlier. I got to choose DAE for the clarity of the format and the good documentation.
http://www.khronos.org/collada/
| Autodesk provides a C++ FBX SDK that can read, write, and convert to/from FBX files. The FBX file format is proprietary, however, the format description is exposed in the FBX Extensions SDK which provides header files for the FBX readers and writers. Currently there are 2 FBX SDK bindings: one for C++ and Python supplied by Autodesk. Blender includes a Python export script for FBX, written without using the FBX SDK[1] and OpenEndedGroup's Field includes a Java based library for loading and extracting interesting parts from a FBX file. |
And also see:
http://openendedgroup.com/field/LoadingFBXFiles
That's what I vaguely remembered regarding FBX, but wasn't sure earlier. I got to choose DAE for the clarity of the format and the good documentation.
http://www.khronos.org/collada/
Topic archived. No new replies allowed.
Pages: 12