<cat>Dev.Model</cat> <title>Citizen</title>  # Download All source files of the Citizen model now come with the game. Find them right in the game folder, under "addons/citizen/models/citizen". These files are effectively always synced straight with the official sources! 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 a FBX file here: [citizen.fbx](https://files.facepunch.com/maxlebled/1b2011b1/citizen_2021-05-20.fbx)⤶ # 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? 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? If you create a new "forked" VMDL, you'll have to keep up with any changes and updates that we make to citizen.vmdl yourself. However, if all 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. (There's no equivalent to $includemodel for animations yet, hence this solution.) # Scale Note that the model is provided in centimeters; we've elected 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!) So if you want to fit something onto the character as it exists in-game (compiled and all that), it needs to be scaled by a factor of x0.3937. (no other decimals after that) You should NOT be doing any scaling on your 3D app's side. ⤶ # Importing⤶ ⤶ If you need a guide on importing the model through modeldoc, go ahead and follow the [Importing a new model](https://wiki.facepunch.com/sbox/Importing_a_new_model) guide. If you simply want to make stuff outside of modeldoc, simply just import the .fbx file to the 3D modelling program of your choice.⤶ 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. # Helpers ⤶ 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 does not need to be exported for these (it will in fact be discarded), they are procedural helpers driven entirely by constraints configured in ModelDoc. 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! ⤶ # IK bones These bones are used to drive IK constraints in-engine. They need animated data. ⤶ * root_IK * hand_*_IK_target⤶ * foot_*_IK_target⤶ root_IK is the parent to all *_IK_target bones. This is because this data needs to be kept in a different space that won't be affected by any layers, weightlists, etc. that we're doing, 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 relative to the root motion of the character. ⤶ root_IK is, in the control rig, constrained to follow X and Y of the pelvis, but with Z (height) forced to 0. ⤶ The hand IK target bones are pos/rot constrained to their respective hand bones in the control rig, same for the feet.⤶ ⤶ Additionally, there are these two special IK bones, which are an attempt at reproducing the "ikrule touch" feature from Source 1.⤶ ⤶  ⤶ 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. This 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. 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.