<cat>Dev.Model</cat> <title>Citizen</title>  The Citizen character is the default player model provided by Facepunch. # Source files All source files of the Citizen model come with the game. You can find them right in the game folder, under **"addons/citizen/models/citizen"**. These files are effectively always synced straight with the official sources; when new animation files are added on our end, they'll show up in that folder for you too! If you don't have access to the game yet, you can find the FBX file and textures here: [citizen.fbx](https://files.facepunch.com/maxlebled/1b2011b1/citizen_2021-05-20.fbx) [citizen_textures.zip](https://files.facepunch.com/Taylor/1b2011b1/citizen_textures.zip) If you don't have access to the game yet, you can find the FBX file and textures here: [citizen.fbx](https://files.facepunch.com/maxlebled/1b0611b1/citizen_2022-06-06.fbx) [citizen_textures.zip](https://files.facepunch.com/Taylor/1b2011b1/citizen_textures.zip) ⤶ ([Updated 2022-06-06](https://files.facepunch.com/maxlebled/1b0611b1/citizen_v2_june22update.gif) with skinning and triangulation improvements around the wrists, elbows, and kneecaps, along with extremely minor weight edits in other places.)⤶ # Creating a new player model...? Before you do anything with the sources, ask yourself: do you just want to add a new model on top of the existing animations (like in Gmod), **OR** do you want to add new animations and effectively "fork" the model? ⤶ ## Fork it...⤶ If you create a new "forked" VMDL, you may have keep up with any changes and updates that we make to citizen.vmdl yourself. However, this is largely (if not wholly) automated by simply using the *.vmdl_prefab files, and doing your changes right besides them: that is to say, you don't touch the contents of the prefab at all, while your new nodes go under the prefab nodes. These prefab files can be thought of as the Source 2 equivalent of .qci (QC includes) files. ⤶ This isn't the Source 1 "$includemodel" feature, but it's the next best thing available for the time being. If you don't do anything too off the beaten path, it means you'll only need to recompile your model every so often. The animgraph equivalent of this system is being worked on. ⤶ Now, on the other hand, if what you're trying to do is "create a new player model", in the sense of Gmod 13, that is to say, a character model that references an existing animation set, you should not "fork" citizen.vmdl! Your gamemode should instead use citizen.vmdl as is, but hide all its meshes, and then bonemerge your custom meshes on top. Think of it like bonemerging a hat in Team Fortress 2, except you're doing that with the entire body.⤶ ⤶ If you don't do anything too off the beaten path, it means you may be prompted to recompile your model every so often when we update the prefab files, but you may not even *need* to actually do it. The implementation of an animgraph equivalent for something like this is being worked on. ⤶ ## ... or show a new thing on top⤶ ⤶ Now, on the other hand, if what you're trying to do is "create a new player model", in the sense of Gmod 13—that is to say, a character model that references an existing animation set—you should **not** "fork" citizen.vmdl! Your gamemode should instead use citizen.vmdl as is, but hide all its meshes, and then bonemerge your custom meshes on top. Think of it like bonemerging a hat in Team Fortress 2, except you're doing that with the entire body.⤶ If you want to create a model that differs radically from the proportions and look of the Citizen, though, it'll be up to you to provide your own skeleton, animations, and animgraph... but at this point, you're creating something entirely new, and that's outside the scope of this page. ⤶ ## Extending the model as-is with new animations⤶ ⤶ If you only need to add a few animations to the VMDL, you can try using the "Base Model" feature. This is somewhat similar to the Source 1 "$includemodel" feature. You can only add animations to an existing model using this feature; you can't do anything else. You only need to reference the official citizen.vmdl file in the "Base Model" field, above the "Add" button in ModelDoc.⤶ # Scale Note that the model is provided in centimeters; we've chosen to let the engine take care of scaling it down into inches. The conversion takes place using the global **ScaleAndMirror** modifier in ModelDoc. We're NOT doing it at the import level on the mesh node, though that might have been a nicer choice for a couple reasons. (The global modifier isn't actually consistently global, it's kind of weird.) So if you want to fit something onto the character as it exists in-game (compiled and all that), you should work against the source as it exists in centimeters, then in ModelDoc, you can perform the scaling down to inches either at the import level (on the mesh node), or using the global ScaleAndMirror modifier, **using a value of 0.3937.** (Only 4 decimals; this is an arbitrary choice.) You should ideally NOT be doing any scaling on your 3D app's side. ## Animating with the SFM There is, however, one downside to this: when you're animating the character in the SFM, you are effectively animating on something that is already scaled. Therefore, if you try to export animation out of the SFM to be used in the VMDL, things will look very wrong because the scaling will effectively be applied again on that. The workaround is to create your own copy of the VMDL with the global scaling node disabled, and use that to animate. # Procedural helper bones These bones are set up to be procedural helpers driven entirely by constraints configured in ModelDoc. Feel free to open up citizen.vmdl and look at the constraint folders to see what makes them tick! * arm_upper_*_twist (from shoulder to biceps) * arm_elbow_helper_* (better deformation for extreme bend angles on the elbow) * arm_lower_*_twist (from forearm to wrist) * leg_upper_*_twist (from pelvis to thigh) * leg_knee_helper_* (better deformation for extreme bend angles on the kneecap) * leg_lower_*_twist (from calf to foot) Animation data doesn't need to be exported from your 3D program for these (it's, in fact, set up to be ignored). Our own animation FBX files usually don't have them. It's just not needed! If you're making a model (e.g. clothing) to be bonemerged on top of the citizen, you don't actually *need* to skin your mesh to these bones... but it's better if you do! ## Animation compositing with helpers If you're using an animgraph to animate a character, it's best not to touch the helper bones at all, or to reset them to the bindPose state right before the end of the graph. Otherwise, you might see some jitter! However, if you're using old-school Source1-style direct sequence playback, and if you're doing any compositing (in ModelDoc), your weightlists should include the helpers when relevant. # IK bones These bones are used to drive IK constraints in-engine. They need animated data.  root_IK is the parent to all *_IK_target bones. These are effectively "model-space" IK targets. Why are we doing it this way? Because the position of these targets needs to be kept in a different space that won't be affected by any layers, weightlists, etc. that animation compositing is touching, otherwise we can't restore the positions through IK afterwards! Think of them as a way to keep the pos/rot data of hands and feet intact, separately. root_IK is, in the control rig, constrained to follow X and Y of the pelvis, but with Z (height) forced to 0. It also needs to always point forwards (zero rotation), otherwise funky things can happen. Similarly, the hand/feet target bones are pos/rot constrained to their respective hand/feet bones in the control rig. Additionally, there are two special IK bones, which are an attempt at reproducing the "ikrule touch" feature from Source 1. * hand_L_to_R_ikrule (child of right hand, constrained to the left hand) * hand_R_to_L_ikrule (child of left hand, constrained to the right hand) These are used as a way to keep the position and orientation of hands the same *relative to each other*, even after applying layers, weightlists etc. and they are pos/rot constrained in the control rig. In the animgraph, this is most often how the left hand is made to stick to a two-handed weapon that's driven by the right hand: in a way, it's not sticking to the gun itself, it's made to stick back to its original position relative to the right hand, even after all the aim matrices, breathing additive motion, etc. has been applied.