STEAM GROUP
Blender Source Tools BleST
STEAM GROUP
Blender Source Tools BleST
276
IN-GAME
1,660
ONLINE
Founded
8 November, 2013
All Discussions > Help > Topic Details
[PR?] Reducing file sizes by improving animation compression when linear interpolation is used.
Hello, Tom, how are you?

Due to Source's limitations I had to make a bunch of DMX models with a lot of repeating animations. Since I want to use my animations in GMod the MDL files have to be bellow a certain file size. And I think that I know how to reduce it.

Since we don't see choppy animations in Source games, I assume they use linear interpolation between animation frames.

Proposal:
I guess that skipping the frames that can be achieved by linear interpolation would decrease the file size of the final MDL. If the bone transformation is set to local space this should not cause any issues.

Questions (If you don't know, I can test them myself):
  • Is such behavior possible? If yes, then I can make a PR. If you don't know, I can try making a prototype.
  • Do you have any automated tests, so I could quickly check the implementation?
  • Is there some sort of documentation about DMX keys and values? It would save me time.
  • Should I try implementing similar behavior for SMD?
  • May this cause issues with different versions of Source?
  • Does MDL compiler forcefully saves every frame during compilation? If so, it would make this feature useless.
  • Are there any other quirks with Source Engine or MDL compiler that I should take into consideration?
  • There are two possible ways of implementing this. Which one is better? I'm leaning towards the second one.
    1. Iterate over bone's keyframes and write interframe transformations if necessary. This approach would be clean, but it probably would cause a rewrite of animation handling and this might cause issues when using constraints.
    2. Iterate over the frames and see if last n frames can be achieved through linear interpolation, if so, skip until new keyframe is found. This would not require any serious rewrite and would be very generalized. For example: we could skip some frames if sine interpolation is used, but the keyframes are arranged in a way that let's us achieve the motion through linear interpolation with small enough error.
Last edited by Zabawna ⁧⁧Klaczka; 10 Feb, 2022 @ 9:05am
< >
Showing 1-5 of 5 comments
Zappy 10 Feb, 2022 @ 9:30am 
Originally posted by 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.)
Originally posted by 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.
ZeqMacaw 10 Feb, 2022 @ 11:34am 
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.
Last edited by ZeqMacaw; 10 Feb, 2022 @ 11:36am
Artfunkel 10 Feb, 2022 @ 12:20pm 
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.
< >
Showing 1-5 of 5 comments
Per page: 1530 50

All Discussions > Help > Topic Details