Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Unity размер Mesh данных в файле и в ram

Unity размер Mesh данных в файле и в ram

Страницы: 1 2 Следующая »
FDsagiziПостоялецwww10 окт. 201816:39#0
Занимаюсь оптимизацией ram, и был сильно удивлен что файл который в билде занимает 3 мб в рам получаеться 26 мб

к примеру меш у которого есть pos, normal, tangent, uv, skin на 5800 вершин 10000 индекосв в ram занимает 1 мб! Карл!

это примерно 150 байт на вершину. как так то...

Правка: 10 окт. 2018 16:41

Polyflow3dПостоялецwww10 окт. 201817:06#1
блендшейпов точно нет?
MiraПостоялецwww10 окт. 201818:58#2
FDsagizi
> билде занимает 3 мб
в билде это что значит? в модели?
FDsagiziПостоялецwww10 окт. 201820:09#3
Polyflow3d
Бленд Шейпы не используем, только кости

Mira
Когда делаешь билд Игры, можно посмотреть сколько Файлы занимают места в собранном проекте - у текстур сходство 1-1

Polyflow3dПостоялецwww10 окт. 201820:43#4
FDsagizi
ну я бы если бы упоролся оптимизаций создал бы пустой меш и переносил бы в него все аттрибуты по очереди, замеряя при этом размер.

Ты как размер смотришь, в профайлере?

alexzzzzПостоялецwww10 окт. 201821:49#5
Есть там что-то неочевидное с мешами. Год назад наблюдал картину:

Имеется чанк процедурного террейна. Его меш по профайлеру занимает ~50кб. После того как меш хоть раз побывал в кадре, профайлер показывает ~310кб (в редакторе) или ~260кб (в билде и если mesh.isReadable == false).

FDsagiziПостоялецwww10 окт. 201822:18#6
alexzzzz
Во во

Завтра гляну, как меняются данные гпу - те он туда тоже загонит все 26 мб?!

Polyflow3d
Да смотрю в профайлере

Правка: 10 окт. 2018 22:22

FDsagiziПостоялецwww11 окт. 201811:37#7
Итак, вот результат что удалось понять:

Есть меш 5800 вершин 10000 индекосв в ram занимает 1 мб!
Если из него удалить boneWeights, вот так:

          mesh.boneWeights = new BoneWeight[0];
          mesh.UploadMeshData(true);

то размер файла уменшаеться до ±335 кб, точно не помню...


По всей видемости, юнити создает как минимум 2 дубликата для меша
скиннинг у них работает через модификацию вершин на CPU или GPU - где возможно, видемо приходиться держать 2 копии, одна для текущего кадра, другая для след кадра.

Подумываю перевести это дело на вершинный скиннинг, и удалить boneWeights еще в редакторе. Из плюсов, память значительно уменьшим, из минусов - не оч удобно работать с материалами и шейдерами. Подумаю...

Правка: 11 окт. 2018 11:39

MiraПостоялецwww11 окт. 201812:14#8
FDsagizi
На гите есть проект с хардверным скиннингом для юнити, чето там с анимацией в текстуре. Я скачивал но не тестил.

Сам делал нативный скиннинг по принципу юнити, там один фиг оверхед.

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

MiraПостоялецwww11 окт. 201812:17#9
Правда не понятно зачем они держат в скиннед меше веса, не используют же один буфер на вход и выход) у меня работала анимация при стриминге в обычный meshfilter. Исходники не глянешь, не угадаешь точно
FDsagiziПостоялецwww11 окт. 201812:54#10
Mira
Да я на основе него и делал, только текстуры не использовал тк это очень сужает гибкость.

По сути делал обычный вершнинный скинниг, - для этого надо данные о весах перенести в меш данные, тк данные весов из вершинного шейдера на скольо я знаю нельзя получить, по этому индексы и веса записал в цвет и uv2.
а по том, в игре, брал матрицы костей, и передавал их в материал. Тоже есть ограничение, на OpenGL ES 3.0 много костей не передашь

ну и плус не очень быстро считать матрицы на CPU в C#


И еще выходит, что даже если иметь доступ к весам из шейдера, то юнити все равно будет увеличивать размер меша в 3 раза в RAM, так что запись данных весов и индексов в uv это норм практика

Правка: 11 окт. 2018 13:06

MiraПостоялецwww11 окт. 201813:10#11
FDsagizi
Да на с# матрицы перемножать как раз норм. Покомпонетно работать с ними не оч. Ну и много векторных расчетов - тоже тормоза (если не юзать эти приколы как у алекса, burst тоесть)
Там под перемножением обычный ц++ код, может уже и simd
MiraПостоялецwww11 окт. 201813:13#12
Ну логично что надо все равно держать копию данных для биндпозы, и оттуда их трансформировать в скиннедмешь.
Если все спихать в кучу и скиннинг и рендер, то стандартный графический конвеер это непрожует
Придется делать отдельные материалы урезанные для скин мешей, а это печально.

Правка: 11 окт. 2018 13:14

FDsagiziПостоялецwww11 окт. 201813:27#13
Mira
>Придется делать отдельные материалы урезанные для скин мешей, а это печально.
да это печально, вот я и думаю как быть то...

не забывай что в C# не только умножать, но и ходить по векторам приходиться...

MiraПостоялецwww11 окт. 201813:33#14
FDsagizi
Оставить стандартный скиннинг имхо.
Оверхед значительный в пределах персонажа, но игра же не из одних скиннед мешей.

Я делал не из экономии а кастомный скиннинг мутил. Смешивал вершины с симуляцией софт боди.

Страницы: 1 2 Следующая »

/ Форум / Программирование игр / Общее

2001—2018 © GameDev.ru — Разработка игр