引用自 EL MAPACHE：

- Since I want to use my animations in GMod the MDL files have to be bellow a certain file size. -

Can you compile different animations (or groups of animations) as separate MDL files, and have the "main" animation MDL use $IncludeModel to load the other MDLs?

(This is not a "solution", only a workaround.)

引用自 Zappy：

Can you compile different animations as separate MDL files, and have the "main" animation MDL use $IncludeModel to load the other MDLs?

Thank you for answering.
This doesn't work if the model is streamed through Outfitter or PAC3. The size of the whole package must be below a certain threshold.

The following is from memory, and most of this is from working on the model decompiler within Crowbar. Some of it might be a little inaccurate, but should at least give you some ideas to research. I would give more info, but life is messy for me right now.

1. There are two main ways that the animation data is stored within MDL and related ANI files, using a model compiler that compiles to MDL 49 format. You will have to check if Garry's Mod's model compiler (studiomdl.exe) compiles to MDL 49 format. If it does not, then another game's model compiler might work.
   
2. Using an ANI file (via the $animblocksize QC command) might compress the animation data more than without it, but I think the compiler stores a copy of the first frame of each animation in the MDL file and all frames in the ANI file.
   
3. There might be other interpolations you can use to reduce the size of some animations.
   
4. Try out different options for each animation to see which compress more.
   
5. The compile log might show exact byte sizes of the animation data.

What I have in my head is that the compiler does indeed create transforms for each bone for each frame, regardless of the input data. Perhaps that is no longer true, though? Or perhaps I am just remembering this wrong...

One exporter optimisation that already exists is not writing a keyframe if a bone hasn't moved this frame (I did this to reduce export times and file sizes). So you could test your theory by exporting two animations from the same armature: one with a single moving bone, and another many moving bones. Then compare the size of the compiled output.

In terms of how to approach this, I would add a pre-processing step that finds keyframes with linear interpolation and for each one records the target bone and time range to the next keyframe. Then areas these can be easily skipped during the export loop (see export_smd.py line 2047).

Thanks to everyone for answering, I will have time to test the theory next week. If I will manage to reduce the size, I will write back and make a PR.