Photo-mode poses

Maturity: Draft. This page covers how Cyberpunk 2077 lists and plays V's photo-mode poses, how mods add them, what a pose clip holds, and what the game does to the body's helper joints under a pose. It was consolidated on 27 September 2026 from the installed 2.31 game (the REDmod TweakDB sources, the compiled TweakDB, photo-mode resources), the WolvenKit, ArchiveXL and TweakXL sources, and the installed pose packs and pose tools on the reference MO2 profile. Sections 6–8 (the rig for posing, the graph after the pose clip, and changing a pose at runtime) come from the pose editor study of the same day: the photo-mode body graph's node tree, the decompiled 2.31 scripts, RED4ext.SDK's animation layouts, and the Red Hot Tools, ArchiveXL and AMM sources. Nothing here has runtime evidence of its own. Grades follow the knowledge rules: source engine, framework or tool source or decompiled scripts, resource extracted game or mod resources, wiki Modding Docs, runtime running game, [offline] our own tool runs, hypothesis not yet established. Hashes, versions and counts are in the pose library design and the pose editor design, which also hold the Studio's designs built on these facts.

Photo-mode faces (expressions) are a separate chain, covered in facial expressions. How to drive the photo-mode menu from script is in photo mode.

1. The chain

2. The pose record

No field names an icon, an .anims file or a workspot resource: the menu is a text list.

3. What a pose clip holds

• Rig. base\characters\base_entities\woman_base\woman_base.rig: 71 joints (Root, Trajectory, Hips, reference_joint, Spine…) and 13 float tracks: headBodyPartVis, leftArmBodyPartVis, rightArmBodyPartVis, legsBodyPartVis, predictiveLookAtDirectionX/Y/Z, allowFeetIk, enableLeftFootIk, enableRightFootIk, footStepOffsetX/Y/Z. There are no face tracks, in vanilla or in any inspected pack. The male rig is man_base.rig, with the same layout resource.
• The compressed buffer is not ACL [source: WolvenKit WolvenKit.RED4/Types/ClassesExt/CustomData/animAnimationBufferCompressed.cs at 11720772, read as documentation] [resource: XF Studio's native decoder, whose keys equal WolvenKit's export (§9)]. It is a flat key list, little-endian, in five runs whose lengths the buffer declares (numAnimKeys, numAnimKeysRaw, numConstAnimKeys, numTrackKeys, numConstTrackKeys):
  • Animated keys, 10 bytes: time normalised to 16 bits over the buffer's duration, then 16 bits holding the joint index (bits 0–12), the channel (bits 13–14: position, rotation, scale) and the rotation's w sign (bit 15), then three values quantised to 16 bits over [−1, 1] (v / 65535 · 2 − 1). An earlier reading said 12 bytes; the key blocks only add up at 10.
  • Raw keys, 16 bytes: the same 4-byte head, then three float32.
  • Constant keys, 16 bytes: the 16 joint, channel and sign bits first, then a 16-bit time, then three float32. There is one per joint channel that doesn't change; an animated channel's keys take precedence.
  • Float-track keys, 8 bytes (16-bit time, 16-bit track, float32) and constant track keys, 8 bytes (16-bit track, 16-bit time, float32).
  • Rotations store (x, y, z) = q.xyz / √(2 − d) with d = 1 − |w|. They are rebuilt as xyz · √(2 − d) and w = 1 − d with d = x² + y² + z², negated when the sign bit is set: a unit quaternion by construction. Raw and constant rotations use the same mapping.
  • The key block is in the set's animationDataChunks[unkIndex] (a deferred buffer) at fsetInBytes, zeInBytes long (dataAddress; omitted fields mean none), or inline in inplaceCompressedBuffer (possibly a KARK Oodle stream) or defferedBuffer.
  • idle_stand_01 is 132 animated, 4 raw and 108 constant keys, plus 4 track and 12 constant track keys: 3,240 bytes. The 133-clip idle set is 159 KB. Mod pose clips key all three channels of all 71 joints (213 channels), mostly as constants resource.
  • The rig (animRig) keeps its bone table after its properties: one i16 parent index per bone, then one reference transform per bone (translation xyzw, rotation xyzw, scale xyzw) resource [source: WolvenKit's rig appendix reader, as documentation].
• SIMD. The other format, animAnimationBufferSimd, appears in a few face clips (three in ui_female_face.anims, 5 of 444 in the Mega Pack) and in three of the character-preview body idles. No body pose clip surveyed uses it resource. The native decoder reads it too (every frame of every joint; layout in archive formats §11), so a pack's SIMD pose plays like any other [source: the Studio].
• Longer clips. Some packs ship multi-frame poses with motion extraction, e.g. Photo Mode Unlocker XL's wp_hg_silver_*: 141 to 361 frames, some with a motion-extraction block resource. Photo Mode Pose Selector's per-character "freeze pose animation" shows that such poses play over time in photo mode source.
• Most multi-frame mod clips hold still. On the reference profile 562 of the 1,641 female poses with a clip have more than 3 frames, but 371 of those have no animated keys at all (every channel constant): only 191 move [resource: the buffers' key counts].

4. How photo mode plays a pose

• Selection is native. The menu's attributes 5 (category) and 6 (pose) hold option data. PhotoModePose_Record is script-readable (AnimationName(), AnimationTime(), PositionOffset()…), but no script starts a clip [source: 2.31 decompiled orphans.script].

• The body graph player_photomode.animgraph has:

  • one MixerSlot (two normal, two additive and two override entries);
  • a WORKSPOT graph slot with a WorkspotHub;
  • the features PhotomodePoseCategory (an IntInput poseCategoryIndex driving a switch over the head and chest rotation nodes) and six AnimFeature_PhotomodeBodyPartRotate (head and chest X/Y/Z);
  • FreezeFrame, foot IK request nodes and look-at controllers;
  • 85 SkAnim nodes (weapon idles, a default standing idle) resource.

  Which slot plays the chosen clip is not traced [hypothesis: the mixer slot].

• Photo mode has no body idle: static pose clips hold. Only look-at and the gaze-triggered blinks move. Community tools freeze even those with SetIndividualTimeDilation resource (facial expressions §4).

• The helper joints are a second graph. The puppet also has an animated component deformations with woman_base_deformations.rig and base\characters\base_entities\woman_base\deformations_rigs\woman_base_deformations.animgraph resource. It drives 114 named muscle, twist and corrective joints from the main skeleton, which is why body meshes carry joints the pose clip doesn't key: deltoids, l_Wrist_0_JNT…, knuckles, the latissimus, buttocks, knees and calves. The graph has these nodes:

  Node	Count
  PointConstraint_WeightedTransform	94
  SimpleBounce	90
  AimConstraint_ObjectUp	78
  SetBoneTransform	72
  OrientConstraint_WeightedTransform	62
  PointConstraint	46
  SimpleSpline	44
  OrientConstraint	31
  AimConstraint_ObjectRotationUp	14
  TwistConstraint	10
  TranslationLimit	8

  The shadow component has its own rig (shadow_rig_wa) resource. The graph is one linear chain of 420 nodes over woman_base_deformations.rig (181 joints); the Studio evaluates it from the game's files with inferred semantics that reproduce the rig's A pose for 179 of 181 joints (body animation §3).

5. How mods add poses

On the reference profile (920 enabled mods) resource:

• 44 packs add 1,907 pose records and 87 category records. They append about 1,510 entries to femalePoses, 324 to malePoses and 86 to poseCategories. Every record uses $base: PhotoModePoses.idle_stand_01.
• 45 mods' animations: entries reach V's photo-mode entity.
• 23 mods ship AMM custom-pose files. Four are AMM-only; their 24 files list 656 "Woman Average" clips.
• 150 animation names are used by more than one mod record.
• A female V's menu would offer about 1,650 poses in about 90 categories. The Studio's catalogue, read the game's way, lists 1,642 in 90 categories (1,641 with an installed clip) and 477 for a male V [offline, 27 September 2026]. The rest of the list is counted, not shown: 6 entries name no record (one pack writes PhotoModePosesv. for PhotoModePoses.), 2 poses name a category no list holds, 1 clip isn't in any set, and 8 clip names are held by more than one set.
• TweakXL property names are case-sensitive. A pose-pack generator writes CategoryName: in its category records. TweakXL derives property names from the record getters with a lower-case first letter (categoryName) [source: TweakXL Red/TweakDB/Reflection.cpp ResolvePropertyName], so the key is not a known property, and those categories inherit vanilla's categoryName through $base. Their poses still name the category record, and the packs are in wide use, which suggests the menu groups poses by the category record's name rather than by categoryName [hypothesis: G1].

Pose tools. Photo Mode Pose Selector reads the lists the native menu builds (OnSetupOptionSelector), offers search, favourites, arrow-key stepping and per-character freeze, and stores favourites in SQLite keyed by the category text plus the pose text. Its README notes that a cross-category browser would need indexing beyond the menu's list [source: its init.lua, README.md 1.2.0]. Photo Mode Unlocker XL adds 31 categories and 199 full records of its own resource.

6. The rig for posing

• Joints resource: woman_base.rig's 71 joints are Root, Trajectory, Hips, reference_joint; the spine Spine…Spine3, Neck, Neck1, Head and the two eyes; per side the shoulder, arm, forearm and hand, a weapon socket, five metacarpals (LeftInHandThumb…LeftInHandPinky), two thumb and three joints for each other finger (LeftHandIndex1–3…), and the thigh, shin, foot, heel and toe. Every left joint's twin swaps Left for Right in its name.
• No posing limits. The rig's only angle data is its ragdoll description: 22 bodies with swing and twist ranges relative to their capsules (the upper arm ±6°, the forearm −30…55° and −40…25°, the head ±20°). They are physics tuning, not anatomical limits resource.
• IK setups: the rig lists two-bone foot setups for each leg (LeftUpLeg → LeftLeg → LeftFoot, hinge Z) resource.
• What a pose can key: only these 71 joints. The 114 helper joints the body meshes are also skinned to are solved by the deformations graph (§4), so a pose never addresses them resource.

7. What the body graph does after the pose clip

The photo-mode body graph runs, from the pose source to its output [resource: its node tree]:

1. The pose source: a MixerSlot over the WORKSPOT graph slot, whose inputs are a looping idle_stand and a WorkspotHub. Which of the two plays a chosen pose is not traced hypothesis.
2. PoseCorrection.
3. Head and chest rotation: six RotateBone nodes on Head and Spine (X, Y, Z; ±90°), each fed by a float input RotateHeadX…RotateChestZ / rotateDegree; the graph declares them as six AnimFeature_PhotomodeBodyPartRotate features (one float, rotateDegree) resource [source: RED4ext.SDK generated type].
4. Terrain foot IK: an AddSnapToTerrainIkRequest whose hips request uses the ikLeftLeg and ikRightLeg chains. Clips switch it with the float tracks allowFeetIk, enableLeftFootIk and enableRightFootIk resource. The community documents that it glues feet to the floor, and removes it per pose in WolvenKit when a pose's feet should leave the ground [wiki: "Removing Foot Snap IK from Poses/Animations"].
5. Look-at: two LookAtControllers, with inputs for Eyes, Head, Chest, LeftHand and RightHand (isEnabled, target, mode, suppress) resource.
6. Limb IK: AddIkRequest for the four chains, then Ik2 for each arm (LeftArm → LeftForeArm → LeftHand, hinge Z, at most 165° left and 180° right) and Ik2Constraint for each leg, with inputs per chain: isEnabled, position, rotation (a quaternion), poleVector, weightPosition, weightRotation and poleVectorOverideWeight resource.
7. An override blend for the eyes, then the output.

So head, chest, gaze, feet and all four limbs can be bent on top of any pose. Whether the external IK requests reach the branch that plays poses is untested hypothesis.

8. Changing a pose at runtime

How the Studio plans to use these levers is in the pose editor design.

9. Where this lives in XF Studio

Open questions

1. How does the native menu start a pose clip (mixer slot or workspot), and is animationTime a start or a hold time? Do static 2-frame poses loop?
2. Which set wins when two sets hold the same clip name: priority, component order, ArchiveXL append order?
3. Is a pose whose filterOutForGarmentTags matches V's outfit hidden from the menu, or only disabled? The Studio hides it by default, with "Show them" (decision Q4), matching the worn garments' visual tags.
4. In which axes and space do positionOffset and rotation apply?
5. Does a game without Phantom Liberty use the base player_wa_photomode.ent for V, and does a pack that targets only one of the two entities show in the other?
6. What does the deformation graph compute for each helper joint? Mostly answered [offline]: each node kind's semantics, checked at the A pose (body animation §3). Still open: the same checked against the game in strong poses.
7. Does the engine sample a loaded clip's constant keys every frame, so that writing them changes a held pose live, or does it copy or cache them per selection or per load?
8. Do IKTargetAddEvent targets and LookAtAddEvent hand targets act on the photo-mode puppet while it holds a pose?
9. After a hot reload, does re-selecting a pose pick up a reloaded set, or only a newly created puppet?
10. Does individual time dilation 0 on the puppet stop its graph from evaluating?
11. Does the menu group poses by the category record's name or by its categoryName (§5)?
12. Do the animation-setup extension components' sets join the root component's clip lookup, as the Studio assumes? The vanilla pose sets are listed there.

The prepared in-game checks for 1–6 are G1–G7 in the pose library design; 7–10 are steps LP1–LP9 of the pose editor design.

Related pages

Photo mode · Facial expressions · Body rendering · Mod loading · Archive format · Pose library design · Pose editor design