cas files are used for settlement, vegetation and unit models and animations in RTW, unit animations in M2TW, and strat map models and animations in both games. Cas is a proprietary format used by CA to export 3d models and animations from 3dsMax. Various modding tools exist to convert .cas files to either 3dsMax, Milkshape or Blender.
It has been traditionally thought that .cas models could only have weighting to one bone per vertex, however, both RTW battle units and M2TW strat character models actually accept limited weighting across two bones if they use the model_flexi_m setting. Cas animations can also include bone movement as well as bone rotation although there are some practical difficulties using this if the animations need to be used at different scales.
The contents and structure of .cas files vary with use (with or without animation, with or without 'mesh') and according to when they were created. They can include elements that are not used by the game, e.g. some Strat Models contain animation sequences, some models (vanilla and modder created) can contain byte by byte copies of the actual .tga texture used! Cas files containing the whole texture seem to be a side-effect of the export process from 3dsMax and not something ever intended for use in-game.
"Full" Cas Files
"Full" .cas files are uncompressed files, they start with a version number, numbers seen in the game files range from approx 2.1+ to 3.22, the version number can indicate changes to the format, but all versions appear to work in-game and are interchangeable between RTW and M2TW.
Packed/Unpacked "Cas" Files
The files that are generated by 'unpacking' the animation packs using XIDX or similar tool are named with the .cas suffix. These are not the same format as the full cas files and do not start with a version number, these files cannot be used directly by the game and have to be repacked using the same or similar tool that generated them. Animations unpacked from RTW are not the same format as M2TW ones and cannot be directly swapped. If you are allowing M2TW to re-pack animations the Full type .cas file has to be used and .evt files supplied separately.
Model Cas Files
The models for RTW battle units, and both RTW and M2TW strat characters and static models, are in .cas format. Bones and weighting are only present in the battle unit and strat character models.
Most .cas models with a skeleton only contain weighting to one bone per vertex, so each vertex will be 100% weighted to a particular bone, triangles that have vertexes weighted to different bones will stretch and contract as the bones are moved in an animation.
Mesh sections for primary and secondary weapons in RTW battle units will be weighted to one bone only, e.g. the right hand, in these type of mesh sections the bone number is given once at the top of the section and not repeated for each vertex.
Mesh sections for the body will typically have vertexes weighted to all of the available bones, but only one bone per vertex as described above.
Multi Bone Weighting
A few vanilla RTW unit models actually have elements where vertexes have shared weighting across two bones. Typically these are the shoulder pad elements as used on the officer_roman_centurion model. The early .cas to 3dsMax converters do not handle these multi-weighted sections and simply fail to import them into Max, late versions of IWTE do support this multi bone weighting see here. For these models to work properly in game they need to have the model_flexi_m setting and not just model_flexi. Model_flexi_m is described in both games descr_model_strat.txt file as:
essentially a flexi model but has a small number of weighted vertices, such as Will's high-detail carthaginian infantryman with the weighted shoulder verts
The format of sections that have the multi-bone weighting is different from the normal weapon/body mesh chunks and there do seem to be restrictions on how much they can be used. Within the .cas file these types of chunks are preceded with the indicator 3, so will now be referred to as 'type 3'.
There are limitations to where this can be usefully applied:
- Should not be used if the model will be scaled, e.g. strat characters scaled to 0.7 x original size.
- Should not be used across joints that will be moved a long way from their original position during animations.
- Can only be used between direct parent and child bones.
- Max 100 verts in affected triangles per group.
- Approx max 200 verts in affected triangles total.
See below section for more information.
Limitations of Type 3 Groups in original RTW
NB: This does not apply to Rome Remastered which uses type 3 with dual bone weighting for most of its unit mesh components.
Testing the limits in RTW has only recently become possible, as wilddog's IWTE tool now writes .cas to .dae (Blender) files and .dae to .cas for RTW units/strat characters and will handle the multi-weighting.
The number of verts/tris that can be included in type 3 sections seems limited, exceeding 100 verts/tris per group or 200 verts/tris per .cas can crash the game or create visual effects similar to having unweighted bones.
The weighting only works between parent and direct child bones, so Torso/Rupperarm works, Torso/Relbow doesn't. RThigh/LThigh combination on a vert will not work, but you can have Pelvis/RThigh and Pelvis/LThigh assigned verts in the same triangle.
The type 3 sections form separate mesh groups within the .cas file and can use the same name as an associated normal mesh group, so you can have one main section of normal 'body' that has just one bone per vert, then perhaps a type 3 'body' section with multi-weighting between Pelvis/Abs and another type 3 section again called 'body' with multi-weighting between Torso/Upperarms/Head. These extra type 3 groups do not seem to cause the same problems as having too many separately named normal groups.
Each type 3 group can only have one 'parent' bone, but if that bone has more than one direct child bone, more than one child bone can be referenced in the group.
Because of the one parent limit you cannot have a working multi-weighted triangle that has verts shared between both the Pelvis, the RThigh and the RLowerleg (as the Pelvis is the parent of the Thigh, and the Thigh would need to be a second parent to the Lowerleg). To achieve sections that are multi-weighted between the Pelvis/Thigh and also Thigh/Lowerleg, you need transition verts that are weighted 100% to the Thigh, so the two areas can be successfully separated into different type 3 groups.
Multi-weighting does not work if the MODEL is scaled by the game, e.g. strat characters using 0.7 scale... or rather it does work, but in proportion to the unscaled dimensions, so will not line up with where you want it!
Multi-weighting across joints that are MOVED a long way from their starting position versus parent does not work well, as the affected section stays in the same proportional shape as before the bone movement and simply follows the child bone.
Animation Cas Files
Both RTW and M2TW use 'cas' files for Unit, Engine and Strat Character animations. With the exception of Engine animations, these are packed for use in the game.
Bone Position Animation in Packed/Unpacked Cas Files
There is a popular misconception that RTW cas animation files cannot accept movements (translations) of the bone positions in animation frames but only rotations, this is not the case and the unpacked vanilla fs_medium_horse_run.cas shows an example format where each bone has a position per frame specified. The scripts for converting unpacked cas > 3dsMax do not handle this position data and simply ignore it. As well as actually adding the position data to the file, a (re-packable type) cas file with position per frame data on multiple bones requires a bone count in the header showing how many bones have position data, and a binary 'list' of the bones involved in the footer.
If you view an unpacked cas animation file with a hex editor you will see the following at the start of the file:
Some user-made maxscript export/import tools for RTW 'hard-code' the number of bones with position data to 1, most RTW anims do use this setting and it appears not to have been understood how to add/read data for additional bones. If you have tried to include/exclude bone movements on bones other than the pelvis, checking the numbers shown at the top of the generated file will allow you to check what your export tool has actually included!
Near the end of the file you will see this:
Those three bytes are a binary bit mask indicating with 1 if the bone in sequence has position data, and 0 if it doesn't.