1. Ты делаешь игру, твой репозиторий всё равно будет жирным.
2. Обычно суть тестирования в том что тебе не нужно их менять когда меняется твой код. То есть твои прототипы описывают то, как твоя штука должна выглядеть.
3. Я бы просто сравнивал картинки сцен снятых с определённого угла. Библиотеки для приблизительного сравнения изображений есть.

Тогда тем более нет смысла менять прототипы.

так если сознательно что-то меняется в результатах работы рендера, то как без обновления эталонных снимков?

Ребята, подскажите, пожалуйста, есть ли какие-то best practices для "юнит" тестирования графических ассетов в инфраструктуре Раста? То есть, грубо говоря, тулза производит выходную картинку какого-то специфичного аспекта рендеринга, хотелось бы сравнивать её с ожидаемым прототипом.

Тут сразу возникает несколько проблем:

1) Где и как хранить прототипы? Если в самом репозитории, он очень быстро разрастется, и устаревшие протопы потом не выковыришь из старых коммитов.
2) Как прототипы сравнительно оперативно обновлять, когда меняется аутпут?
3) Может быть есть около-готовые библиотеки для этого всего?

у гитхаба судя по докам с git-lfs все очень так себе, тебя биллят за то что кто то у тебя что то скачивает с lfs, и квота очень маленькая.

Я до сих пор в офигении от такой ценовой политики и отсутствия общественного давления сменить еë

cargo insta?

Не знаю насколько в тему, но вот небольшое видео о том как можно параметрически завадать модели.
https://youtu.be/8--5LwHRhjk

Про git lfs. А чем это принципиально лучше git submodules? Создаешь дополнительный репозиторий на гитхабе, в котором будут прототипы ассетов. И привязываешь его к основному через сабмодули. Тестирование картинок, соответственно, можно ограничить cargo-фичей. Если программист хочет, он выставляет эту фичу и резолвит сабмодуль с прототипами. Если нет, то просто не резолвит. А сам сабмодуль можно, думаю, и на гитхабе хранить.