Вот только такие ответы я нахожу)

Следуя простой логике, фрагментов будет создаваться для упрощенного шейдера примерно столько же. Уменьшится только количество вызовов вершинного шейдера и фиксированных функций растеризации.

По идее упрощение меша при сохранении занимаемой им площади на фреймбуффере не приведет к увеличению производительности после определенного количества треугольников. Нужно только это количество найти.
Сделать это можно лишь экспериментальным путем. Ведь это число будет зависить и от самих шейдеров, и от того что еще рендерится, и от разрешения, и от конкретного железа.
Автоматизировать такой эксперимент было бы интересной задачей я думаю.
Приложить такой автобенч к утилите для сжимания меша было бы киллерфичей.

Вот этим и занимаюсь сейчас.
Ещё, я так понимаю, на тайловой архитектуре кол-во треугольников сильнее влияет на производительность.

Там скорее влияет сколько тайлов пересекает треугольник. А среднее число тайлов на которые попадает каждый треугольник может расти с упрощением модельки

Я вот было сунулся в Bevy, чисто попробовать, но оказалось что пока рано. Сразу же упёрся в то что нет нормального решения для State Management (как это в аметисте называется). Какой-то задел на будущее вроде бы есть в виде "Сцен", но судя по их роадмапу - всё ещё впереди. А сейчас не получится нормально, модульно реализовать разделение игры на разные состояния (меню, настройки, раунд игры, пауза и др.)

да, тоже стейт менеджера не нашел, пока через костыли в виде ресурса

автор говорит что должно быть скоро

В целом задумка интересная. По сравнению с Аметистом сильно проще для новичков. Не надо задумываться над разными типами контейнеров для компонентов. Не надо имплементить трейтов что бы структуру превратить в компонент. Системы - это почти простые функции, а не трейт поверх структуры.

А сейчас я решил попробовать Аметист, пока в Bevy не допилят сцены.

Интересно, насколько беви с аметистом в итоге будут либы переиспользовать?

https://github.com/bevyengine/bevy/issues/708

Кстати в Bevy немного смутила работа с текстурами. Я не очень понял как это так работает. Я могу просто внутри "системы" взять и поменять "байтики" в текстуре и она изменится на изображении без каких либо действий с моей стороны. Не понятно как изменения попадают в видео карту.
Разве что Bevy отслеживает момент, что я запросил мутабельную ссылку на текстуру, и сразу же помечает её изменённой и потом сам отправляет её в видео-карту.

Для новичков в чем? В расте? Заимплементить трейт для системы вроде как несложно. Аметист разве уже не на легионе? Там не надо выбирать тип контейнера.

Вот сейчас изучаю аметист - всё делается через структуры + трейты на них. И компоненты и системы. Для компонентов надо указывать тип контейнера.

Значит спекс еще

Совсем разработка аметиста заглохла

Так что отвечая на вопрос @ozkriff . Имхо, пересечения в виде libc и rand не считая, не будут переиспользовать вообще

эээ я наоборот начал читать доку аметиста, потом мне скинули беви, я посмотрел на ecs и подумал "ну его нах этот аметист"

Кстати на Bevy у меня CLion с Rust плагином просто "завывает" всеми ядами процессора, когда вношу какие-то изменения в код. С ggez такого не было. Причём это именно сам процесс Java начинает  нагружать процессор, а не какой-нить Clippy.

Ну у меня есть наработки на ggez и наличие "стейтов" было первое что я полез проверять в Bevy после того как научился менять текстуру в спрайте. Понял что там этого нет и опечалился. А ECS и в аметисте есть, просто он более многословный.

https://github.com/intellij-rust/intellij-rust/issues/new ;)