User Tools
Differences
This shows you the differences between two versions of the page.
|
modelling:dependenciesamongmodels [2009-07-04 13:40] 127.0.0.1 external edit |
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 equivalency, 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 engine 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 engine 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. | ||
modelling/dependenciesamongmodels.txt ยท Last modified: 2013-01-07 12:07 (external edit)