This shows you the differences between two versions of the page.
modelling:dependenciesamongmodels [2012-04-04 11:20] Carsten [Human player models] It's the game code that bothers, not the engine |
modelling:dependenciesamongmodels [2013-01-07 12:07] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Dependencies among Models ====== | ||
- | |||
- | Although it might not be obvious at a first glance, there are several dependencies among certain models. | ||
- | It is worthwhile to have knowledge about these issues before you start making own models, | ||
- | because it helps with resource planning and prevents expensive problems later. | ||
- | |||
- | We'll describe several typical kinds of dependencies, considering the example of the Cafu DeathMatch MOD: | ||
- | In the Cafu DeathMatch MOD, mutual dependencies affect the human player models and their weapons. | ||
- | |||
- | First, lets deal with all "other" models, i.e. those that are neither player nor weapon models: | ||
- | Usually, these other models are not closely related to each other, each of them has a separate piece of | ||
- | game code associated that handles it, and thus they do not suffer from any inherent dependency problems. | ||
- | |||
- | |||
- | ===== Human player models ===== | ||
- | |||
- | Human player models are special, because they are usually intended to be 100% equivalent to each other. | ||
- | That is, if somebody makes a new human player model and offers it for download, | ||
- | you expect it to work exactly like the ones that you already know. | ||
- | In order to achieve this kind of equivalence, two assumptions must hold: | ||
- | The skeleton of the new models must basically match the skeleton of the old models, | ||
- | and the animation sequence numbers must refer to reasonably identical animations. | ||
- | |||
- | The animation sequences must match, because the game code has built-in knowledge that, for example, | ||
- | sequence number 3 refers to an "idle (waiting)" animation, and that sequence number 27 refers to an | ||
- | "aiming with a shotgun" animation. It is entirely up to you to animate your model to look at his | ||
- | wrist watch while aiming with the shotgun, or to pick his nose, but it //is// important that | ||
- | sequence number 27 corresponds to some "aiming with a shotgun" animation -- because the same is true | ||
- | for all other models, and the game code relies on it. | ||
- | |||
- | The skeletons must also match, for similar reasons: | ||
- | At least the basic hierarchical structure (starting from the pelvis to the most important bones) must be identical, | ||
- | as well as the //names//(!) of the corresponding bones. | ||
- | However, you are free to add bones to the skeleton as you like, change their sizes or lengths, change their positions relative to each other, | ||
- | and do many other interesting things. You may even omit bones if you want to create a one-armed, one-legged hero. | ||
- | What works and what works not is easiest determined by trying it out, but please do also refer to the next part | ||
- | about weapons. | ||
- | |||
- | |||
- | ===== Weapons ===== | ||
- | |||
- | Weapons do usually come as a set of three models: "world" models, "player" models, and "view" models. | ||
- | |||
- | **World** models are the models that lie around in the world, before someone picked them up. | ||
- | They are usually not animated (or do only have a single animation sequence), | ||
- | are independent from anything else, and are therefore in the same category as the "all others" models, | ||
- | so that we need not be further concerned about them. | ||
- | |||
- | **Player** models are the weapons that you see in the hands of //other// players who have picked up and are using that weapon. | ||
- | For the following discussion, we'll refer to the "player" weapon model as the "''_p'' model", | ||
- | and to the character model of a human player as the "body model". | ||
- | |||
- | First, if you consider the skeleton of a ''_p'' model in a model viewer, you will find that it resembles | ||
- | a partial body model (the bones from the pelvis to the shooting arm are there!), before it diverges into additional bones for the actual weapon. | ||
- | |||
- | Here is the crucial point: In order for the engine to compute the proper position of the ''_p'' model | ||
- | relative to the body model, it (partially) has to match the skeletons of both models! | ||
- | That is, it first computes the skeleton of the body model (depending on its current animation sequence and frame). | ||
- | Then it considers the skeleton of the ''_p'' model, starting at it's root, and tries to match it bone-by-bone | ||
- | to the previously computed body skeleton. If a match was determined, the engine simply takes the information from the body models bone also | ||
- | for the ''_p'' model bone. Only when the matching breaks for the first time, the engine resumes normal bone computing | ||
- | also for the ''_p'' model. (This way you can for example have a face-hugger (held by //another// player!) that is wagging it's tail.) | ||
- | Matches are made by comparing the //names// of the concerned bones, by the way. | ||
- | |||
- | As a consequence, if you want to make additional body models for the DeathMatch MOD, and additional weapons, | ||
- | and you want to be able to combine each body model with each weapon, | ||
- | //then you're forced to make sure that they **all** have a corresponding skeletal structure and bone names!// | ||
- | |||
- | **View** models are the models that you see in 1st persons view after you have picked up a weapon yourself. | ||
- | They are also independent from anything else, but the engine has usually special code for handling them. | ||
- | Thus, you can well make a //replacement// weapon for e.g. the shotgun | ||
- | (matching the animation sequences of the existing "view" weapon model, | ||
- | according to similar rules as indicated for making replacement human player models), | ||
- | but you cannot introduce //entirely new// weapon models without writing additional code for them. | ||
- | |||
- | |||
- | ===== Applicability to your own MOD ===== | ||
- | |||
- | If you create an own MOD, things may or may not be different, of course. | ||
- | However, please keep in mind that if you want to achieve a high degree of flexibility and ease of maintenance, | ||
- | you'll sooner or later probably experience the same rules and dependencies as described here. | ||
- | They are the - relatively cheap - price for the ability to combine every human player model with every weapon model. | ||