The Last Argonaut, Маг и небольшой бонус / gamedev :: Игры :: indiedev :: сделал сам :: TheLastArgonaut :: screenshotsaturday

gamedevИгрыindiedevсделал самTheLastArgonautscreenshotsaturday

The Last Argonaut, Маг и небольшой бонус

Всем доброго утра, делюсь прогрессом
На этой недели наконец то я закончил риггинг мага. Какой же это был нудный и монотонный ад.
Так же добавил динамические волосы, думаю на счет лицевой анимации и тут вопрос, насколько это важно что бы в момент когда он начнет жарить молниями он иногда моргал и яростно скалился? :D

На следующей недели постараюсь показать какое-нибудь колдунство. И пора уже добавлять звуки, да и магия со звуками будет намного эффектнее.

и небольшой бонус.

Решил побаловаться с разрезанием мешей, забавная технология. На данном этапе не планирую ее использовать, по крайней мере не в таком виде, в начале нужно родить шейдер следов от удара, а для расчленения противников лучше подойти творчески.

Рекомендую сразу следить за оптимизацией.
Гонять профайлером, считать SetPass и Draw call. По ОЗУ игры на Юнити не шибко прожорливы, а вот оптимизация рендеринга у Юньки не очень -много приходится делать руками и доп. инструментами.

Ну и все эти фишки с физикой (Cloth например), генерацией новой геометрии - очень сильно грузят CPU. И отлавливать стоит прямо на начальном этапе - чтобы потом не пришлось профайлить огромные сцены.

Особенно если используешь сторонние ассеты (даже со стора) - люди с оптимизацией вообще не парятся (

13.03.2021, 08:02

+7,4

>>Рекомендую сразу следить за оптимизацией.
>>Гонять профайлером
Отличный совет начинать с оптимизации несуществующий проект и профайлить пустые сцены.

>>считать SetPass и Draw call.
Снова мимо.
Существует инстансинг, батчинг и directx12. Drawcalls давно уже не узкое место.

>>Ну и все эти фишки с физикой (Cloth например) очень сильно грузят CPU
Тряпки на персонаже будут работать даже на древней мобилке. В эпоху многоядерности и подавно.

>>И отлавливать стоит прямо на начальном этапе - чтобы потом не пришлось профайлить огромные сцены.
Это инди проект, а не гта5. Хватит раздавать упоротые советы из разряда "брейншторми на Agile, обмазывайся ECS и наследованиями и профайли профайли профайли"

Для инди проекта почти нет ресурсов, а ты предлагаешь последние ещё и потратить на оптимизацию спичек.

13.03.2021, 09:20

+2,1

Поэтому каждая вторая демка на всяких унрилах весит в среднем по 10 гиг и жрёт ресурсы как ГТА 5, при том что на экране пустая сцена с парой болванчиков.
Ты, конечно, дело говоришь, в приоритете оптимизации быть не должно, но полностью её отбрасывать тоже не стоит.

13.03.2021, 11:47

+1,0

>>Поэтому каждая вторая демка на всяких унрилах весит в среднем по 10 гиг и жрёт ресурсы как ГТА >>5, при том что на экране пустая сцена с парой болванчиков.
>>Ты, конечно, дело говоришь, в приоритете оптимизации быть не должно, но полностью её >>отбрасывать тоже не стоит.
Я говорю про ранюю оптимизацию. Естественно к релизу размер и ресурсы имеют значение.
Потому что пока ты тратишь время на оптимизацию на ранней стадии создания игры, ты 100 раз можешь поменять планы и удалить/изменить/модели/код/сцены и т.д.

13.03.2021, 13:37

-0,4

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

Не путай рефакторинг и оптимизацию.

Твои рассуждения отдают знакомством с темой на уровне: "игрок, который что-то там по диагонали прочел".

13.03.2021, 13:49

+0,1

Вообще чувак выше полностью прав.
4/5 инди проектов имеют просто отвратительную оптимизацию и зачастую люди с компами ниже хай класса просто физически не имеют возможности поиграть (а при некоторых особо упоротых случаях, даже с компами хай класса) из за отвратительной оптимизации, так как ассеты взяты, а на сколько эти ассеты оптимизированны со всеми финтиплюшками игры, никто не думал...

+кстати хочу дополнить мелочью, но многие ютуберы скажут автору спасибо, это актуально и для юнити и для анриала...ОТКЛЮЧИ БЛЯТЬ ПОДДЕРЖКУ ВИАРА! Эта херня стандартно почему то включена и если на компе есть стим виар, игра автоматически начинает запускаться через него создавая лишние проблемы с записью (а иногда и с запуском)

13.03.2021, 11:50

+1,7

>>ОТКЛЮЧИ БЛЯТЬ ПОДДЕРЖКУ ВИАРА! Эта херня стандартно почему то включена и если на компе >>есть стим виар
Нет, не включена. В unity XR рендеринг не работает без VR и требует отдельно установленной галочки и плагинов. Так что ты несёшь ничем не подкрепленный бред. У меня есть VR очки, я работаю как с обычным рендерингом, так и с VR, и никогда запуск обычной демки не запускает стим VR.

13.03.2021, 13:40

-0,3

Воу воу воу, без агрессии дружище.
Я говорю со стороны потребителя, и поверь со мной в этом плане мало кто может сравниться. Я за год играю в несколько сотен инди хорроров и уж на что, а на их проблемы я уже насмотрелся.
Так что я не просто говорю что это либо стандартная функция, либо идет с каким то основным плагином. Даже самые паршивые тестовые проекты где чуть ли не просто одна сцена реализована, все равно пытаются запустить стим виар и открыться через него, что заставляет лишний раз перепроверять какое именно окно захвается, как пишется игровой звук и прочие ютуберские условности.
И только если написать об этой проблеме напрямую разрабу, то да, "ой, сейчас исправлю" и тут же выходит версия где виара нет, и все работает нормально...

13.03.2021, 15:03

-0,2

Скорее всего проблема не в движке (Unity \ UE) а в SteamworksAPI. Ты сам косвенно это подтверждаешь упоминая стим виар.

Без SteamworksAPI ты не сможешь распространять игру через Стим. А уж какие функции он накручивает - это не факт что все разбираются.

13.03.2021, 21:40

0,0

9/10 индюшек что я записываю к стиму никакого отношения не имеют и учитывая их качество иметь не будут.
Так что тут явно не стимовский апи виноват

13.03.2021, 23:22

0,0

Дефолтные инстансинг и батчинг работаю мягко говоря не идеально. Пример - в статику заношу порядка 1600 объектов использующих 4ре материала с атласами. Юнити делает из них 250 Set pass и 600 DrawCalls Проц в сцене грузится на 40%, GPU на 99% время на рендеринг вдвое больше чем на апдейт всех скриптов. Отрубаешь рендеринг 1600 объектов - рендеринг ускоряется вдвое. Но DrawCalls конечно же не "узкое место".
Да-да.
Много опыта в оптимизации?

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

13.03.2021, 12:47

-0,1

>>Дефолтные инстансинг и батчинг работаю мягко говоря не идеально.
Никто и не говорил что они должны работать идеально и сделать за тебя всю работу. Ты должен понимать как работает статик батчинг и occlusion culling. Юнити запекает все объекты в один большой кусок, поэтому модели которые ты не видишь всё равно будут отрисовываться в вершинном шейдере. В таких случаях следует использовать инстансинг.

>>Но DrawCalls конечно же не "узкое место".
В твоём случае уж точно нет. 1600 drawcalls это смех для дектопа. В skyrim 2011 года drawcalls в разы больше. Ты начал оптимизировать то, что не являлось узким местом, и жалуешься что у тебя теперь это является узким местом.

>>Много опыта в оптимизации?
Достаточно.

>>Похоже ты не имеешь понятия что такое оптимизировать игру сложнее тетриса, хотя бы на >>уровне альфы.
Я не разрабатываю игры, но мои сцены и эффекты запускаются на любом бюджетном пк.

Если бы ты знал что и как оптимизировать, то наверное пошел бы и почитал про статик батчинг.
Кроме оптимизации drawcalls, что ты можешь ещё рассказать? Использовал и знаешь ли ты проблемы проекторов, grabpass, fallback shadow pass и буфера глубины, material property инстасинг и render queue, OnRenderImage на мобильных платформах, msaa и рендер текстуры, discard/cutout и тайловый рендеринг, дальше продолжать?
А бездумно нажать "isStatic" на объектах и жаловаться, ну это не оптимизация.

13.03.2021, 14:04

+0,7

>Я не разрабатываю игры,
>>Много опыта в оптимизации?
>Достаточно.

Ну да. Оно и видно что "достаточно". Только ты даже не понимаешь смысла терминов, которыми тут швыряешься.
>Ты должен понимать как работает статик батчинг и occlusion culling.

Я как раз понимаю. А вот ты - судя по всему нет.
У тебя каша даже в терминах.
grabpass - причем тут он? Единственное его "применение" - при рендеринге в текстуру. С хуя ли ты решил что это - обязательно используемая технология?
fallback shadow pass - это что за херь? Shadow pass - знаю. Отрисовка теней - отдельный разговор ибо очень разная вещь в зависимости от deferred \ forward rendering и от платформы.
Fallback - относится к шейдерам. Каким боком в твоей голове слиплись две эти сущности?
Давай расскажи мне про "проблемы" render queue.)
grabpass\ рендер текстуры - это вообще-то одно и то же.
А OnRenderImage - это имя метода вызываемого при итоговой отрисовке кадра. И какие с ним проблемы? Что ты \ кто-то в него дохера насовал и завалил всю отрисовку?
Проекторы я зарекся использовать еще года три назад.
material property инстасинг (это ты так MaterialPropertyBlock обозвал? Так там как раз исключается инстансинг для этого и сделана технология) - использую постоянно.
occlusion culling - вообще нихуя не панацея. А эффективна в основном для "коридорных" сцен. Например для лесной локации - никакой ощутимой выгоды не дает.
Ну и расскажи мне, каким же хуем соединение "Юнити запекает все объекты в один большой кусок, поэтому модели которые ты не видишь всё равно будут отрисовываться в вершинном шейдере." (кстати почему именно в вершинном? А в surface? А во фрагментном?) - соединяется с occlusion culling по твоему?

И кроме "запекает все объекты в один большой кусок" - что еще по твоему делает статический батчинг? И почему он называется БАТЧИНГ? Ну давай - жги напалмом.) Я послушаю очередную порцию дичи.)

Чувак, я вижу что ты просто насобирал терминов (и не только) - свалил их в кучу но ни капли не врубился как оно работает и зачем вообще надо.

Я постоянно пишу про SetPass, но ты игноришь ибо не в курсе, что есть "дешевые" DrawCalls а есть "дорогие".
Но хуле тебе расписывать если ты сам себе противоречишь:

Сначала пишешь "да ничего оптимизировать не надо, Существует инстансинг, батчинг и directx12. Drawcalls давно уже не узкое место."

Затем: "Никто и не говорил что они должны работать идеально и сделать за тебя всю работу."
А дальше - валишь кучей технологий и инструментов, большинство которых ПРЕДНАЗНАЧЕНО - СОКРАЩАТЬ КОЛИЧЕСТВО DRAW CALLS.

Ты хоть сам-то врубаешься, что твоя заява "Drawcalls давно уже не узкое место." - как бы тупо звучит?

13.03.2021, 15:04

-0,1

>>grabpass - причем тут он? Единственное его "применение" - при рендеринге в текстуру
Каждое использование шейдера с grabpass и разной очередью вызывает копирование текущего буфера и заставляет поток ждать. Поэтому в urp/hdrp от этого отказались.
Это влияет на производительность.

>>fallback shadow pass - это что за херь? Shadow pass - знаю. Отрисовка теней - отдельный >>разговор ибо очень разная вещь в зависимости от deferred \ forward rendering и от >>платформы.
>>Fallback - относится к шейдерам. Каким боком в твоей голове слиплись две эти сущности?
В любом surface шейдере и кастомных шейдерах с конструкцией fallback копируется "shadow pass" проход, который даже без использования теней всегда пишет в буфер глубины. Если шейдер не нуждается в тенях, и даже если это кастомный шейдер, то всё равно объект будет отрисован дважды. Это опять же влияет на производительность и твои любимые drawcalls.

>>Давай расскажи мне про "проблемы" render queue.)
Инстансинг не работает при queue > 2049

>>А OnRenderImage - это имя метода вызываемого при итоговой отрисовке кадра. И какие с >>ним проблемы? Что ты \ кто-то в него дохера насовал и завалил всю отрисовку?
На мобильных платформах он копирует back buffer и блокирует основной поток рендера. Это всегда медленно. Поэтому кастомный blit в текстуру будет быстрее. Это влияет на производительность.

>>material property инстасинг (это ты так MaterialPropertyBlock обозвал? Так там как раз >>исключается инстансинг для этого и сделана технология) - использую постоянно.
Как я уже писал выше, он работает только в определенных условиях. Это так же влияет на производительность.

>>occlusion culling - вообще нихуя не панацея. А эффективна в основном для "коридорных" >>сцен. Например для лесной локации - никакой ощутимой выгоды не дает.
Occlusion culling у любой камеры работает по дефолту. Все объекты позади камеры не отрисовываются. В пруф можешь попробовать взять модель и вручную уменьшить её aabb box через "Mesh.bounds" и ты увидишь как отбрасывается рендеринг модели.

>>Ну и расскажи мне, каким же хуем соединение "Юнити запекает все объекты в один >>большой кусок, поэтому модели которые ты не видишь всё равно будут отрисовываться в >>вершинном шейдере." (кстати почему именно в вершинном? А в surface? А во >>фрагментном?) - соединяется с occlusion culling по твоему?
>>И кроме "запекает все объекты в один большой кусок" - что еще по твоему делает >>статический батчинг? И почему он называется БАТЧИНГ? Ну давай - жги напалмом.) Я >>послушаю очередную порцию дичи.)
Моя ошибка, признаю, в настоящее время юнити изменили отбраковку статики и теперь пересчитывают её каждый раз когда область видимости меняется.
Раньше юнити запекал меши в один большой (или несколько больших) и не перестраивал геометрию если bounce не попадал в камеру, и отрисовывалась вся геометрия, даже если был виден только один объект из группы.

>>Сначала пишешь "да ничего оптимизировать не надо,
Я такого не писал. Я написал что не надо оптимизировать проекты на ранних стадиях, тем более пытаться оптимизировать то, что не является узким местом и экономить на спичках. Для инди важно вообще хотя бы выпустить проект, а не экономить drawcalls.

>>Затем: "Никто и не говорил что они должны работать идеально и сделать за тебя всю >>работу."
И что не так? Как я и сказал, drawcalls часто не бутылочное горлышко, но если это так, то должен использовать все статик/динамик батчинг и инстансинг с умом и понимать их слабые места.

>>А дальше - валишь кучей технологий и инструментов, большинство которых >>ПРЕДНАЗНАЧЕНО - СОКРАЩАТЬ КОЛИЧЕСТВО DRAW CALLS.
Прям уже большинство, лол.
Из всего списка (7 вещей) только material property block предназначен для уменьшения drawcalls. Проекторы и shadow pass множат геометрию, увеличение drawcalls это следствие. Если у тебя вся сцена из 10 млн треугольников батчится до 1 drawcall, то огромный проектор сделает тебе 20 млн треугольников и 2 drawcall. И тут проблема будет не в drawcalls.

>>Ты хоть сам-то врубаешься, что твоя заява "Drawcalls давно уже не узкое место." - как бы >>тупо звучит?
Я правильно понимаю, что все инди игры лагают потому что у них узкое место это drawcalls, а не количество треугольников, пиксельный овердрав, сложность шейдеров и т.д.?

13.03.2021, 16:25

-0,5

>Каждое использование шейдера с grabpass и разной очередью вызывает копирование текущего буфера и заставляет поток ждать.

А с какого ты решил что ВСЕ используют шейдеры с grabpass ? Случайно не из-за того что ты сам рендеринг в текстуру в своих поделках суешь напропалую?

>В любом surface шейдере и кастомных шейдерах с конструкцией fallback копируется "shadow pass" проход, который даже без использования теней всегда пишет в буфер глубины.
Шта млять?
"shadow pass" проход генерируется ТОЛЬКО если шейдер использует опциональный параметр addshadow. В таком случае на тень повлияет работа вершинного шейдера. Обычно же шейдеры используют УЖЕ готовый "shadow pass" проход из fallback шейдера.

Т.е. все чуть ли не необорот.
Читай что ли документацию: https://docs.unity3d.com/ru/2019.4/Manual/SL-SurfaceShaders.html

>Инстансинг не работает при queue > 2049
Эм... А это ты откель взял? Сам придумал или кто другой сочинил? Откуда вообще такая цифра 2049?

Инстансинг может прерываться очередью отрисовки, но величина очереди никак не влияет на его применимость. Ты какую-то дичь продолжаешь писать.

>На мобильных платформах он копирует back buffer и блокирует основной поток рендера.
Он это делает на любой платформе. В этом как бы его суть - даже по названию метода понятно. Чтобы что-то добавить в кадр на моменте его отрисовки - ЛОГИЧНО что отрисовку надо остановить. Или у тебя с логикой - затруднения?

>Как я уже писал выше, он работает только в определенных условиях. Это так же влияет на производительность.
Эм... Во-первых, ты даже название написал неверно. Во-вторых, ЛЮБОЙ батчинг - работает в определенных условиях. И да, ЛЮБОЙ батчинг влияет на производительность СНИЖЕНИЕМ кол-ва draw calls.
Ты хоть условия для MaterialPropertyBlock знаешь? Или опять херню пороть будешь?

>Occlusion culling у любой камеры работает по дефолту. Все объекты позади камеры не отрисовываются. В пруф можешь попробовать взять модель и вручную уменьшить её aabb box через "Mesh.bounds" и ты увидишь как отбрасывается рендеринг модели.

Очередной пук в лужу. Occlusion culling работает, только если ее "запечь". И включить на камере. По дефолту оно как раз выключено - иди проспись.
Ты перепутал (как обычно) Frustum culling и Occlusion. Occlusion culling кстати требует доп. ресурсов CPU, в отличие от Frustum culling которая делается на GPU.

>Моя ошибка, признаю, в настоящее время юнити изменили отбраковку статики и теперь пересчитывают её каждый раз когда область видимости меняется.

Ты бы свою ошибку в ДНК признал. Причем тут отбраковка статики? Ты, как выяснилось не знаешь что такое Occlusion culling и как оно работает, так как ты можешь судить взаимодействие со статической геометрией?
Они одинаково взаимодйствуют и в Юнити 4.Х и в 2018.4 LTS (я ее использую). Так что ты в очередной раз испортил воздух.

>Как я и сказал, drawcalls часто не бутылочное горлышко,
Нет чувак ты написал (цитирую): "Drawcalls давно уже не узкое место".
Никаких "часто не" - не звучало. А звучало - безапелляционное одновариантное мнение.
Так что нехуй елозить на жопе - ты обосрался.
Если код пишет не такой криворукий как ты, то основная проблема потерь при рендеринге - именно количество вызовов на отрисовку. Причем особо "дорогими" являются draw calls предваряемые сменой стейта - Set Pass. Если б ты разбирался хотя бы вполовину как ты тут изображаешь, то знал бы что одни из самых "тяжелых" операций - биндинг текстуры \ перезагрузка шейдера, что почти всегда и происходит при смене стейта. Смена материала = смена текстуры, смена шейдера - приводит к смене стейта. Чем больше таких переключений - тем больше Set Pass и тем больше итоговых Draw calls.
Поэтому может быть много дешевых отрисовок (когда стейт не меняется) и это не убивает fps, а можно просадить все за счет "лишних" 400-500 Set Pass.

>Для инди важно вообще хотя бы выпустить проект, а не экономить drawcalls.
Оно и видно. Для тебя важно - накидать поделок в стор и срубить бабла и похеру что реализовано херово.
Толку-то от инди-проекта если он нормально ни у кого не работает? Жаль что твой принцип "срубить по быстрому" - чрезвычайно популярен и потому народ и жалуется что 4 из 5ти "инди" - дико тормозят почти у всех.

>то должен использовать все статик/динамик батчинг и инстансинг с умом и понимать их слабые места.
Вот еще бы ты не писал в чем не смыслишь ничего - была бы просто сказка.)

>Прям уже большинство, лол.
Из всего списка (7 вещей) только material property block предназначен для уменьшения drawcalls. Проекторы и shadow pass множат геометрию, увеличение drawcalls это следствие.

Дядя, ты дурак или как? Просто честно - вот признай и разойдемся по-хорошему.
Оказывается ты вообще НЕ понимаешь значения слова "батчинг" и его задачи.

Внезапно - ЛЮБОЙ батчинг именно для этого и предназначен - снижать кол-во вызовов на отрисовку (draw calls) путем ОБЪЕДИНЕНИЯ "раздельной" геометрии по признаку единого материала \ шейдера и пытаясь отрисовать каждую такую группу за ОДИН draw call. То что оно в реальности с этим нихера не справляется и потому был добавлен Material property block - вот о том и речь. Что интересно, Mesh Baker - вполне справляется с данной задачей, но путем доп. манипуляций в design-time.

А так, все технологии батчинга - для снижения draw calls.

Material property block - это РУЧНОЙ ДИНАМИЧЕСКИЙ батчинг, когда ты сам объединяешь рендеринг нескольких объктов с одним материалом.
Occlusion culling - отсечение геометрии "заслоненной" другими объектами ВНУТРИ поля зрения камеры. Тем самым мы опять же - уменьшаем кол-во РИСУЕМЫХ объектов - уменьшаем кол-во и set pass и draw calls.

Про проекторы я тебе уже написал - использовать их - себе дороже. А уж для теней - полное безумие.
Про shadow pass - иди почитай когда он и кому нужен. Ссылку я тебе дал, уж коли ты не в курсе официальной документации.

Каким хером ты считаешь что пост-рендер или рендер в текстуру являются ВСЕОБЩИМИ проблемами оптимизации отрисовки - это лишь твоему психиатру ведомо. Как по мне применение таких решений - не является необходимым и узкоприменимым (хотя и не так уж "дорогим") в отличие от отрисовки сцены (которую никуда не денешь). Хули в вопросе общей оптимизации обсуждать узкопрофильные технологии не всеми и не всегда применямые?

Хули ты упомянул в рамках оптимизации discard/cutout и тайловый рендеринг - это даже твой психиатр не сообщит. Ибо cutout и тайлы полностью на стороне GPU делаются, причем очень быстро. Да даже альфа-блендинг сейчас не такой уж дорогой. Что там за проблемы у тебя с ними (при том что ты ничего кроме партиклов не знаешь) - мне похуй.

>Я правильно понимаю, что все инди игры лагают потому что у них узкое место это drawcalls, а не количество треугольников, пиксельный овердрав, сложность шейдеров и т.д.?

А я правильно полагаю, что ты сейчас:
1) Все инди-игры записал в лагающие?
2) Приписал всем инди-играм огромное кол-во треугольников, сложные шейдеры, при том что большинство инди-игр использует VertexLit освещение и лоу-поли модели, в силу того самого отсутствия ресурсов, о котором ты верещал с самого начала?
Так откель у них возьмутся сложные шейдеры и огромные кол-ва геометрии в сценах?
Ты опять сам себе противоречишь?

Самые сложные (по визуальному ряду) инди-игры со сложными шейдерами и высокополигональной графикой:
Subnautica
Forest
Empyrion
как ни странно - не лагают, а прекрасно оптимизированы.
Завязывай уже портить воздух, а то тебе дышать скоро будет нечем.)

13.03.2021, 17:43

+0,8

Зато судя по отзывам на сторе по твоей поделке - с оптимизацией ты знаком только в рамках "нахватался терминов". Люди жалуются на хреновые скрипты, дикие просадки фпс на твоих эффектах, отвратительную организацию кода и требуют рефанд. )

Особенно понравился такой отзыв:
"This seller tells you to look how he did in the demo instead helping you with the problem, ignore what you say, treat you as idiot. When he finds there are bugs after sending more mails he fix one bug, then other, but dont want to make the effort to fix the asset. He instantiates a different player model every time he cast a spell! which makes you need like 30 player or enemy variants, one for each spell, otherwise you have to rework the package, have been trying to fix all these with several days and i didnt finish yet. He denies making it work as it should, spells just cast by a single player or enemy, and not having 30 variants. When try to instantiate the spells dont work out of the box as is mentioned at the moment i write this in description, you find many bugs just instantiating them dont know why, its not easy to make this work out of the demo he made, which has no sense in a real game."

Вкратце: "нихуя не работает "из коробки", все выглядит забись, но сделано неоптимально и в игре невозможно использовать. Автор "изделия" игнорит вопросы и замечания, считая покупателя - идиотом"

Так держать - нам явно нужно равняться на тебя.)

13.03.2021, 15:19

+0,5

Я могу тебе отправить полную переписку с этим человеком, если уж мы начали копаться.
Он купил пак для VR, решил все эффекты инстансировать с позиции руки и жаловался что они не работают должным образом. Ему показалось не логичным что для эффекта торнадо, метеора с неба или аое бафа надо указывать разную позицию и они не должны появляться в позиции рук.
Для своей демо сцены, для каждой демонстрации эффекта я создаю свой префаб с одним персонажем, но разными настройками позиций, анимаций, и т.д.
Он хотел что бы был всего 1 префаб с персонажем и с разными эффектами, он подсчитал это неоптимальным. Где по его мнению я должен хранить настройки позиций/анимаций для меня загадка.
Так же он не знал как использовать animation events и как с помощью одной анимации использовать разные эффекты по выбору. Несмотря на всё это, я ему сделал несколько демок со скриптами, которые ему были нужны (что бы по нажатию на кнопку была одна анимация но с разными эффектами, в зависимости от кнопки).
Когда я сделал замечание, что демки имеют лишь ознакомительный характер, и я продаю эффекты, а не демо, он вылил на меня поток мата и оскорблений и пошел жаловаться на стор.
А почему ты проигнорил другую сотню отзывов? Ах да, селективное восприятие оно такое.

13.03.2021, 16:39

-0,5

>>Зато судя по отзывам на сторе по твоей поделке - с оптимизацией ты знаком только в >>рамках "нахватался терминов". Люди жалуются на хреновые скрипты, дикие просадки >>фпс на твоих эффектах, отвратительную организацию кода и требуют рефанд. )
Каков процент этих людей относительно остальных?
На какие скрипты/просадки/код они жалуются? Можешь мне процитировать мне эти комментарии и уточнить где они правы на 100%? Там половина недовольных писали отзыв когда добавили urp/hdrp рендеринг, из-за которого не работали 90% проектов на сторе. Другая часть отзывов это где люди не открывают ридми и не могут прочесть первой строчкой "импортируйте hdrp/urp патч для urp/hdrp рендеринга".
Готов обосновать любой комментарий.

>>Вкратце: "нихуя не работает "из коробки", все выглядит забись, но сделано >>неоптимально и в игре невозможно использовать. Автор "изделия" игнорит вопросы и >>замечания, считая покупателя - идиотом"
Это мнение одного человека, который не разбирается в разработке от слова совсем, при этом ты игнорируешь мнение остальных нескольких сотен человек у которых всё работает.
Стоит ли говорить что этот разработчик ставит почти всем пакам 1 звезду и вероятно в этом есть какая-то связь?

И раз уж пошла такая пьянка и ты доказываешь что ты профессионал в оптимизациях, могу я увидеть твою игру/проект и оценить твои навыки?

13.03.2021, 17:01

-0,6

Там среди этой сотни - на каждые три "положительных" - которые не парятся с оптимизацией как ты - находится один негативный, где люди вдумчиво применяют купленное.

Я выбрал просто навскидку.

понятно что сейчас мы здесь не услышим "вторую сторону" - тех людей (а их далеко не один) которые запросили рефанд.

Само наличие людей, которые недовольны оптимизацией твоих "эффектов" - оно как бы намекает.
Ну и ты там расписывал людям про 2-3 мс процессорного времени. Эм... У меня в игре вся отрисовка сцены занимает 2,4 мс - и это МНОГО. Один цикл апдейта 3,5 мс.
И ты заявляешь что эффект который жрет 3мс - это дохуя оптимизированный? Иди таблетки прими что ли.

13.03.2021, 17:52

0,0

Про ресурсы инди-проектов ты мне не рассказывай. Прошелся бы по тегу screenshotsaturday или по моим постам, да сложил бы "два и два".

Любой функционал \ фичу игры надо сразу укладывать в определенные рамки по затратам CPU, RAM, GPU, VRAM и после - контролировать чтобы при масштабировании затраты росли адекватно.

В противном случае будет результат на который только крайне ленивый не жаловался - отвратительно оптимизированная игра, дальнейшее "причесывание" которой приводит к лавинообразному появлению багов.

13.03.2021, 13:43

+0,5

>В противном случае будет результат на который только крайне ленивый не жаловался
Мы про инди-разработку говорим. Жалуются - это уже успех.

Мамкин Бродяга

14.03.2021, 15:28

-0,6

Хм... Если тебя педик заприметил и в жопу трахнул, это получается тоже - успех. Ну по твоим критериям.

14.03.2021, 20:47

-0,6

Во многом с вами согласен, за оптимизацией я слежу с самого начала. Не допускаю утечек, и со сторонними ассетами я осторожен, в целом использую их по минимуму(если уже что то прям необходимое) но они не касаются визуального плана, моделей, анимаций, эффектов.

13.03.2021, 12:47

+1,0

Плюсую за правильный подход. Утечки - не самое большое зло, на самом то деле). Критически сожрать ОЗУ нынче - это надо Хром написать).
А вот производительность просадить можно следующими аспектами:
1. Физика - большое кол-во коллизий \ слишком сложная форма коллайдера (MeshCollider convex) \ неверные настройки Rigidbody \ коллизии частиц \ пересекающиеся коллайдеры
2. Значительное кол-во вызовов Update() в скриптах наследованных от MonoBehaviour.
3. Большое кол-во SkinnedMeshes в кадре \ использование компонента Animator там где можно было использовать Animation \ больше кол-во костей в SkinnedMeshes.

13.03.2021, 13:38

+0,5

меня от твоих постов грустно
раньше я не замечал, что недели пролетают так быстро
а теперь каждую субботу ощущаю

13.03.2021, 08:25

+2,5

Так кинь его в заблокированые и продолжай спокойно деградировать.

13.03.2021, 09:07

+1,6

у меня ни одного человека не заблочено
так что не

13.03.2021, 10:41

-0,1

воу воу, не надо так радикально решать проблему :D Я наоборот хочу радовать людей своей работой, слушать их фид бек и улучшать проект)

13.03.2021, 12:51

+0,2

Лицевая анимация, вроде как на первый взгляд не сильно важная часть, но порой так случается, что когда нарезаешь врагов на фарш и видишь похер-фейс у протагониста или его врагов, создаётся такое ощущение, будто он не в бою участвует, а смотрит видосики на ютубе) Думаю, что парочка анимаций лишней не будет.
Конечно, если не предполагается активное взаимодействие с НПС, чьи лица будут показаны крупным планом в диалогах - тогда тут нужно мне кажется однозначно запариваться т.к. если тебе рассказывают какой тот волчара плохой и злой и сожрал у непися почти всех овец и при этом с каменным рылом, не выражающим даже лёгкого раздражения, это уже плохо)

13.03.2021, 09:34

+1,0

Поддерживаю, не каменное лицо, даже иногда - это приятная мелочь

13.03.2021, 09:38

0,0

Предлагаю просто всем персонажам ебальники закрыть шлемами и масками, да не страдать хуйней. Кого вообще ебёт анимация лиц в экшене про шинкование врагов?

13.03.2021, 10:08

+0,9

Меня. Но да, со шлемами проще, не спорю)

13.03.2021, 10:31

0,0

А магу дать широкую шляпу и его лица ты не будешь видеть, если спецом камеру не крутить

13.03.2021, 10:44

+0,6

Да в этом есть логика, по крайней мере можно попробовать передать как он старается жарить молниями :D

13.03.2021, 12:54

0,0

По названию последний аргонавт представил классическую окружающую среду из фильма битва титанов, и героев похожего типа

13.03.2021, 09:55

-0,3

нууу, сеттинг другой конечно будет) Что то ближе к концу 19 века начала 20, но с колдунством)

13.03.2021, 13:01

0,0

Маг на библиотекаря похож

13.03.2021, 10:59

0,0

дык это ж маг :D

13.03.2021, 12:41

0,0

Было бы прикольно если бы от долгого каста молнии у мага волосы бы эликтризовались, а в конце он ещё бы и матерился от обратного заряда.

13.03.2021, 11:01

0,0

да это хорошая идея, правда это было бы круто играй ты за него, на данном этапе он будет врагом, играбельным он будет ближе к демо) Но в целом реакции на отдачи от заклинаний, это довольно крутая идея.

13.03.2021, 12:40

+0,1

Не всплывает в памяти ни одного момента, когда бы я обратил внимание на выражение лица врага во время боя. Мне кажется это незначительная деталь, которую вполне можно оставить на этап полировки проекта. Лицевая анимация важна прежде всего в постановках диалогов, в катсценах.
А вот разрезание мешей штука не часто встречающаяся в играх. Она и смотрится эффектно и часть механик оригинальных можно с ней запилить. Её бы я добавил.

14.03.2021, 09:17

+0,6

По поводу разрезания, как раз в этом направление и думаю, что бы это было не просто разрезание, а использовалось гемплейно, буду думать как это реализовать)

Про лицевую анимацию соглашусь, на данном этапе наверно не стоит запариваться над этим)

15.03.2021, 02:50

+0,1

Щиты раскалывать.
Древковое оружие рубить.
Декапитация.

Если у тебя боевка "камерная" - т.е. в замкнутых локациях-аренах, то можно ввести разрушаемые препятствия.

15.03.2021, 09:15

0,0

Тут все не так просто) Если это щит, это может быть дерево или метал, и разрубаться оно должно соответствующе. Нужно много свойств создать, можно так же разрубать магию(там кусок скалы в тебя летит) и ты вжух ее разрезал парировав, или добавить сильный удар с возможностью влиять на вектор направления, но так что бы это не влияло на динамику и использовать это в битве против больших боссов, в общем много применений)

15.03.2021, 13:21

+0,1

Разработка игр вообще и геймдизайн в частности - не простые области, что бы там не говорили.)
В плане физики взаимодействий - я делал привязку к физическим материалам:

как для VFX, так и для SFX

Но там надо учитывать что при обращении к материалу напрямую - создается его инстсанс что во-первых не очень рационально, а во-вторых блокирует прямое сравнение материалов.

15.03.2021, 14:08

0,0

Статья 2020 года о том что надо следить за draw calls \ set pass. Особенно на мобилках:
https://thegamedev.guru/unity-performance/draw-call-optimization/#batches-vs-setpasses

20.03.2021, 15:54

0,0

Чтобы написать коммент, необходимо залогиниться

Похожие посты ↓↓↓

4712080, 4737446, 4753980, 4714002, 4697022, 4721241, 4770642, 4882470, 4898004, 4951869, 4737735, 4762634, 4712125, 4711889, 4770219