[Всем пофиг] [LWJGL] Скелетная Анимация
- Автор темы Oldestkon
- Дата начала
- 808
- 3
- 129
Фордж вообще разрабатывают люди с весьма специфическим отношением к производительности 
.obj у них грузился с использованием регулярок и рендерился в immediate-режиме, теперь вот добавили поддержку b3d - так там скелетная анимация мало того что в immediate-режиме рисуется, так ещё и тонны мусора каждый кадр генерирует.
У меня один забавный случай был. Когда в кадре было много анимированных персонажей, потребление оперативки начинало скакать с бешеной скоростью. Дело оказалось в том, что я в коде построения скелета использовал foreach цикл (for SomeClass foo : bar) для итерации листа. А foreach-цикл для листов - это синтаксический сахар над someIterable.iterator(). Тонны генерируемого мусора оказались просто-напросто итераторами...
Так вот: эти странные люди, которые пилят фордж, каждый раз, перед тем как отрендерить анимированную модель, создают временный объект со всеми треугольниками и вершинами модели... Сборщик мусора - это хорошо, но отсутствие мусора - существенно лучше. Да, в современной JVM очень хорошо собирается young generation мусор, но вот обилие этого мусора приводит к фрагментации памяти, а для дефрагментации приходится "вешать" приложение. И после этого они говорят:
.obj у них грузился с использованием регулярок и рендерился в immediate-режиме, теперь вот добавили поддержку b3d - так там скелетная анимация мало того что в immediate-режиме рисуется, так ещё и тонны мусора каждый кадр генерирует.
У меня один забавный случай был. Когда в кадре было много анимированных персонажей, потребление оперативки начинало скакать с бешеной скоростью. Дело оказалось в том, что я в коде построения скелета использовал foreach цикл (for SomeClass foo : bar) для итерации листа. А foreach-цикл для листов - это синтаксический сахар над someIterable.iterator(). Тонны генерируемого мусора оказались просто-напросто итераторами...
Так вот: эти странные люди, которые пилят фордж, каждый раз, перед тем как отрендерить анимированную модель, создают временный объект со всеми треугольниками и вершинами модели... Сборщик мусора - это хорошо, но отсутствие мусора - существенно лучше. Да, в современной JVM очень хорошо собирается young generation мусор, но вот обилие этого мусора приводит к фрагментации памяти, а для дефрагментации приходится "вешать" приложение. И после этого они говорят:
Да, всё верно - чтобы отрендерить трубу петабайты оперативки не нужны. Но речь не дошла до анимированной трубы...
- 1,990
- 18
- 109
Мягко говоря, люди, колдующие над форджем сейчас - упоротые. Судя по слухам. Я пока наслышан об одном: Лексе (в соседнем топике обсуждали), недавно его в скайпоконфе грязью поливали.
Насчёт cpw ничего не знаю, но о нём вроде хорошо отзывались, правда он свалил куда-то вдруг...
Погуглил тут по ключевым словам, ладно, он хоть сам признаётся
Насчёт cpw ничего не знаю, но о нём вроде хорошо отзывались, правда он свалил куда-то вдруг...
Погуглил тут по ключевым словам, ладно, он хоть сам признаётся
- 2,955
- 12
Cpw уходил, да, но уже вернулся. И он довольно неплохой человек. А еще, Лекс (по тем же слухам) решил совсем обезуметь и обрезать прямой доступ к GL'y и сказал, что Тесселятор доведен до совершенства. В той же теме его пытались убедить в обратном ЧикенБоунс и Иммибис, но он все равно отпирается.
- 808
- 3
- 129
Ну, опять-таки, по слухам, моджанги собираются полностью перенести майн с FFP на рендеринг через шейдеры. Для этого в 1.8 они ввели класс, который является оберткой над большинством GL-функций. Проблема заключается в том, что если майн и часть модов используют этот класс, а некоторые - нет, то всё сломается. Из этих соображений было бы вполне логично запретить доступ к тем функциям GL, над которыми есть обёртка.
- 2,955
- 12
А если обертки НЕТ?
- 808
- 3
- 129
Если обертки нет, то ничего и не сломается. Ломается из-за того, что обёртка кеширует предыдущие значения и не вызывает функции OpenGL, если значение не поменялось. Естественно, если сменить что-то не через обёртку, то она сработает неправильно. Обёртку эту придумали не авторы форджа, а моджанги, так что как-то с ней считаться надо. По уму запретить прямой доступ к тем функциям openGL, для которых есть обертка - вполне себе решение.
Вон System.exit() и System.halt() запретили (через секьюрити менеджер) и даже сделали красивое предупреждение "мод пытается использовать System.exit(), а нужно юзать фоджевскую обертку". Не разбирался, как сделали предупреждение, но наверняка сканированием байткода модов. А раз уж на то пошло, то можно при запуске заменять вызовы функций OpenGL из модов на нужные вызовы оберточных методов. Секьюрити менеджером для блокировки OpenGL не воспользоваться всё равно (можно, конечно, нагородить велосипед на входе в нативные методы, но это убьет производительность).
Мне, пожалуй, нравится, куда двигается фордж, но с производительностью надо что-то делать. Куча трансформеров на запуске применяется до ужаса долго, а использование секьюрити-менеджера совсем не улучшает производительность в игре. Скорость запуска можно сильно увеличить за счет "препроцессинга" классов. Я сейчас применяю все трансформеры (включая форджевские) заранее, а в клиенте лежат уже трансформированные классы. Ещё для ускорения запуска можно попробовать вынести список главных классов модов в отдельный файл, потому что сейчас оные ищутся тоже через сканирование байткода.
Вон System.exit() и System.halt() запретили (через секьюрити менеджер) и даже сделали красивое предупреждение "мод пытается использовать System.exit(), а нужно юзать фоджевскую обертку". Не разбирался, как сделали предупреждение, но наверняка сканированием байткода модов. А раз уж на то пошло, то можно при запуске заменять вызовы функций OpenGL из модов на нужные вызовы оберточных методов. Секьюрити менеджером для блокировки OpenGL не воспользоваться всё равно (можно, конечно, нагородить велосипед на входе в нативные методы, но это убьет производительность).
Мне, пожалуй, нравится, куда двигается фордж, но с производительностью надо что-то делать. Куча трансформеров на запуске применяется до ужаса долго, а использование секьюрити-менеджера совсем не улучшает производительность в игре. Скорость запуска можно сильно увеличить за счет "препроцессинга" классов. Я сейчас применяю все трансформеры (включая форджевские) заранее, а в клиенте лежат уже трансформированные классы. Ещё для ускорения запуска можно попробовать вынести список главных классов модов в отдельный файл, потому что сейчас оные ищутся тоже через сканирование байткода.
- 808
- 3
- 129
Запускаешь с применением трансформеров, дампишь трансформированные классы, суешь их в клиент, запускаешь без применения трансформеров.
- 2,955
- 12
В фордже почти все работает за счёт сканирования байт-кода. А если избавиться от @Mod (Или спонджевского @Plugin), то пропадает простота (Баккитовский plugin.yml - шикарный пример того, как не надо делать).
- 808
- 3
- 129
Я не предлагаю от них избавляться, я предлагаю вынести всё сканирование байткода из запуска игры. Понятно, что этот метод не подойдет большинству пользователей форджа, но для серверов с лаунчерами - самое то.
- 808
- 3
- 129
ЛолDrovosek написал(а):