The Last Argonaut, Маг и небольшой бонус
Всем доброго утра, делюсь прогрессомНа этой недели наконец то я закончил риггинг мага. Какой же это был нудный и монотонный ад.
Так же добавил динамические волосы, думаю на счет лицевой анимации и тут вопрос, насколько это важно что бы в момент когда он начнет жарить молниями он иногда моргал и яростно скалился? :D
На следующей недели постараюсь показать какое-нибудь колдунство. И пора уже добавлять звуки, да и магия со звуками будет намного эффектнее.
и небольшой бонус.
Решил побаловаться с разрезанием мешей, забавная технология. На данном этапе не планирую ее использовать, по крайней мере не в таком виде, в начале нужно родить шейдер следов от удара, а для расчленения противников лучше подойти творчески.
Подробнее
The Last Argonaut - Mage,Entertainment,,
The Last Argonaut - Cut!,Entertainment,unity,meshcut,indiedev,gamedev,rpg,https://vk.com/revearto_games - VK https://twitter.com/Revearto - Twitter I'm not planing to use it, just test for fun)
gamedev,Игры,indiedev,сделал сам,нарисовал сам, сфоткал сам, написал сам, придумал сам, перевел сам,TheLastArgonaut,screenshotsaturday
Еще на тему
Гонять профайлером, считать SetPass и Draw call. По ОЗУ игры на Юнити не шибко прожорливы, а вот оптимизация рендеринга у Юньки не очень -много приходится делать руками и доп. инструментами.
Ну и все эти фишки с физикой (Cloth например), генерацией новой геометрии - очень сильно грузят CPU. И отлавливать стоит прямо на начальном этапе - чтобы потом не пришлось профайлить огромные сцены.
Особенно если используешь сторонние ассеты (даже со стора) - люди с оптимизацией вообще не парятся (
>>Гонять профайлером
Отличный совет начинать с оптимизации несуществующий проект и профайлить пустые сцены.
>>считать SetPass и Draw call.
Снова мимо.
Существует инстансинг, батчинг и directx12. Drawcalls давно уже не узкое место.
>>Ну и все эти фишки с физикой (Cloth например) очень сильно грузят CPU
Тряпки на персонаже будут работать даже на древней мобилке. В эпоху многоядерности и подавно.
>>И отлавливать стоит прямо на начальном этапе - чтобы потом не пришлось профайлить огромные сцены.
Это инди проект, а не гта5. Хватит раздавать упоротые советы из разряда "брейншторми на Agile, обмазывайся ECS и наследованиями и профайли профайли профайли"
Для инди проекта почти нет ресурсов, а ты предлагаешь последние ещё и потратить на оптимизацию спичек.
Ты, конечно, дело говоришь, в приоритете оптимизации быть не должно, но полностью её отбрасывать тоже не стоит.
>>Ты, конечно, дело говоришь, в приоритете оптимизации быть не должно, но полностью её >>отбрасывать тоже не стоит.
Я говорю про ранюю оптимизацию. Естественно к релизу размер и ресурсы имеют значение.
Потому что пока ты тратишь время на оптимизацию на ранней стадии создания игры, ты 100 раз можешь поменять планы и удалить/изменить/модели/код/сцены и т.д.
Оптимизировать надо каждый атомарный функционал \ фичу. Сразу - при создании надо думать сколько оно сожрет и ограничивать. А для этого - профайлить и профайлить.
В идеале надо сразу писать оптимальный код и строить архитектуру, поддерживающую основные методы оптимизации.
Не путай рефакторинг и оптимизацию.
Твои рассуждения отдают знакомством с темой на уровне: "игрок, который что-то там по диагонали прочел".
4/5 инди проектов имеют просто отвратительную оптимизацию и зачастую люди с компами ниже хай класса просто физически не имеют возможности поиграть (а при некоторых особо упоротых случаях, даже с компами хай класса) из за отвратительной оптимизации, так как ассеты взяты, а на сколько эти ассеты оптимизированны со всеми финтиплюшками игры, никто не думал...
+кстати хочу дополнить мелочью, но многие ютуберы скажут автору спасибо, это актуально и для юнити и для анриала...ОТКЛЮЧИ БЛЯТЬ ПОДДЕРЖКУ ВИАРА! Эта херня стандартно почему то включена и если на компе есть стим виар, игра автоматически начинает запускаться через него создавая лишние проблемы с записью (а иногда и с запуском)
Нет, не включена. В unity XR рендеринг не работает без VR и требует отдельно установленной галочки и плагинов. Так что ты несёшь ничем не подкрепленный бред. У меня есть VR очки, я работаю как с обычным рендерингом, так и с VR, и никогда запуск обычной демки не запускает стим VR.
Я говорю со стороны потребителя, и поверь со мной в этом плане мало кто может сравниться. Я за год играю в несколько сотен инди хорроров и уж на что, а на их проблемы я уже насмотрелся.
Так что я не просто говорю что это либо стандартная функция, либо идет с каким то основным плагином. Даже самые паршивые тестовые проекты где чуть ли не просто одна сцена реализована, все равно пытаются запустить стим виар и открыться через него, что заставляет лишний раз перепроверять какое именно окно захвается, как пишется игровой звук и прочие ютуберские условности.
И только если написать об этой проблеме напрямую разрабу, то да, "ой, сейчас исправлю" и тут же выходит версия где виара нет, и все работает нормально...
Без SteamworksAPI ты не сможешь распространять игру через Стим. А уж какие функции он накручивает - это не факт что все разбираются.
Так что тут явно не стимовский апи виноват
При том, что я как разраб Юнити точно уверен - никакого VR по дефолту не включено.
Стимовский виар и стимовский апи никак не связаны...вообще никак...даже близко не стояли...
Ладно, в общем я не вижу смысла продолжать спор, я как потребитель инди хорроров на 100% уверен что эта дичь по дефолту включена так как виар подтягивается даже на самых паршивых проектах никакого отношения ни к стиму, ни к виару не имеющих (и заранее предвидя предьяву, нет, ни у меня одного, спрашивал у многих потребителей виара записывающих инди, та же самая беда).
Идти качать юнити что бы найти эту злоебучую галочку мне откровенно лень, так что смысла продолжать спор не вижу...
Да-да.
Много опыта в оптимизации?
Похоже ты не имеешь понятия что такое оптимизировать игру сложнее тетриса, хотя бы на уровне альфы.
Никто и не говорил что они должны работать идеально и сделать за тебя всю работу. Ты должен понимать как работает статик батчинг и occlusion culling. Юнити запекает все объекты в один большой кусок, поэтому модели которые ты не видишь всё равно будут отрисовываться в вершинном шейдере. В таких случаях следует использовать инстансинг.
>>Но DrawCalls конечно же не "узкое место".
В твоём случае уж точно нет. 1600 drawcalls это смех для дектопа. В skyrim 2011 года drawcalls в разы больше. Ты начал оптимизировать то, что не являлось узким местом, и жалуешься что у тебя теперь это является узким местом.
>>Много опыта в оптимизации?
Достаточно.
>>Похоже ты не имеешь понятия что такое оптимизировать игру сложнее тетриса, хотя бы на >>уровне альфы.
Я не разрабатываю игры, но мои сцены и эффекты запускаются на любом бюджетном пк.
Если бы ты знал что и как оптимизировать, то наверное пошел бы и почитал про статик батчинг.
Кроме оптимизации drawcalls, что ты можешь ещё рассказать? Использовал и знаешь ли ты проблемы проекторов, grabpass, fallback shadow pass и буфера глубины, material property инстасинг и render queue, OnRenderImage на мобильных платформах, msaa и рендер текстуры, discard/cutout и тайловый рендеринг, дальше продолжать?
А бездумно нажать "isStatic" на объектах и жаловаться, ну это не оптимизация.
>>Много опыта в оптимизации?
>Достаточно.
Ну да. Оно и видно что "достаточно". Только ты даже не понимаешь смысла терминов, которыми тут швыряешься.
>Ты должен понимать как работает статик батчинг и 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 давно уже не узкое место." - как бы тупо звучит?
Каждое использование шейдера с 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, а не количество треугольников, пиксельный овердрав, сложность шейдеров и т.д.?
А с какого ты решил что ВСЕ используют шейдеры с 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
как ни странно - не лагают, а прекрасно оптимизированы.
Завязывай уже портить воздух, а то тебе дышать скоро будет нечем.)
Особенно понравился такой отзыв:
"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."
Вкратце: "нихуя не работает "из коробки", все выглядит забись, но сделано неоптимально и в игре невозможно использовать. Автор "изделия" игнорит вопросы и замечания, считая покупателя - идиотом"
Так держать - нам явно нужно равняться на тебя.)
Он купил пак для VR, решил все эффекты инстансировать с позиции руки и жаловался что они не работают должным образом. Ему показалось не логичным что для эффекта торнадо, метеора с неба или аое бафа надо указывать разную позицию и они не должны появляться в позиции рук.
Для своей демо сцены, для каждой демонстрации эффекта я создаю свой префаб с одним персонажем, но разными настройками позиций, анимаций, и т.д.
Он хотел что бы был всего 1 префаб с персонажем и с разными эффектами, он подсчитал это неоптимальным. Где по его мнению я должен хранить настройки позиций/анимаций для меня загадка.
Так же он не знал как использовать animation events и как с помощью одной анимации использовать разные эффекты по выбору. Несмотря на всё это, я ему сделал несколько демок со скриптами, которые ему были нужны (что бы по нажатию на кнопку была одна анимация но с разными эффектами, в зависимости от кнопки).
Когда я сделал замечание, что демки имеют лишь ознакомительный характер, и я продаю эффекты, а не демо, он вылил на меня поток мата и оскорблений и пошел жаловаться на стор.
А почему ты проигнорил другую сотню отзывов? Ах да, селективное восприятие оно такое.
Каков процент этих людей относительно остальных?
На какие скрипты/просадки/код они жалуются? Можешь мне процитировать мне эти комментарии и уточнить где они правы на 100%? Там половина недовольных писали отзыв когда добавили urp/hdrp рендеринг, из-за которого не работали 90% проектов на сторе. Другая часть отзывов это где люди не открывают ридми и не могут прочесть первой строчкой "импортируйте hdrp/urp патч для urp/hdrp рендеринга".
Готов обосновать любой комментарий.
>>Вкратце: "нихуя не работает "из коробки", все выглядит забись, но сделано >>неоптимально и в игре невозможно использовать. Автор "изделия" игнорит вопросы и >>замечания, считая покупателя - идиотом"
Это мнение одного человека, который не разбирается в разработке от слова совсем, при этом ты игнорируешь мнение остальных нескольких сотен человек у которых всё работает.
Стоит ли говорить что этот разработчик ставит почти всем пакам 1 звезду и вероятно в этом есть какая-то связь?
И раз уж пошла такая пьянка и ты доказываешь что ты профессионал в оптимизациях, могу я увидеть твою игру/проект и оценить твои навыки?
>И раз уж пошла такая пьянка и ты доказываешь что ты профессионал в оптимизациях, могу я увидеть твою игру/проект и оценить твои навыки?
Ну ты точно дурак или читать не умеешь?
http://joyreactor.cc/post/4720479#comment22635141
И про свой профессионализм я ни слова не писал - не надо мне приписывать свои какие-то фантазии.
Просто я знаю больше тебя и понимаю - тоже получше. И не люблю когда пишут херню, изображая из себя "специалиста".
Специалист не использует в коде "под ключ" такие перлы как Instantiate(), а потом рассуждает про "оптимизацию cutout рендеринга".
>>Вот не надо заливать - там среди "остальных" - достаточно недовольных. Так что не >>один он там такой.
Ну так ты расскажи чем они не довольны? Я тебе расскажу есть ли там объективная сторона или нет. Или тоже проигноришь?
>>Ну ты точно дурак или читать не умеешь?
Твои посты разбросаны по всей странице, да я не умею читать ублюдское цитирование джоя.
>>Просто я знаю больше тебя и понимаю - тоже получше. И не люблю когда пишут >>херню, изображая из себя "специалиста".
Ты опять же проигнорил большинство моих вопросов, тебе неугодных и просто дальше гнёшь свою линию про специалиста. Вот не убедил вообще ни разу что ты экспертнее.
>>Специалист не использует в коде "под ключ" такие перлы как Instantiate(), а потом >>рассуждает про "оптимизацию cutout рендеринга".
Что за хуйню ты несёшь? Как по твоему создавать эффект в рантайме, если не instantiate(effect, position, rotation)?
>>Там среди этой сотни - на каждые три "положительных" - которые не парятся с >>оптимизацией как ты - находится один негативный, где люди вдумчиво >>применяют купленное.
Так ты мне уже покажешь эти комментирии вдумчивых людей?
>>Само наличие людей, которые недовольны оптимизацией твоих "эффектов" - оно >>как бы намекает.
Во-первых не надо ехидничать и брать в кавычки слово "эффекты", глядя вот на это
Ок, мои эффекты не оптимизированы. Расскажешь где и как? Ах да, ведь ты мельком прочёл коммент и не стал разбираться о чём там говорится?
>>Ну и ты там расписывал людям про 2-3 мс процессорного времени. Эм...
>>И ты заявляешь что эффект который жрет 3мс - это дохуя оптимизированный? Иди >>таблетки прими что ли.
Это ты иди прими таблетки. Я нигде не заявлял что 1 эффект жрёт 3мс.
Все 33 эффекта на экране
http://kripto289.com/Shared/Effects4%28Test%29.jpg
Shuriken particles работают на cpu. Нагрузка по экспоненте, где 1 эффект с 10к частиц потребляет 0.2мс, там 10 эффектов будут потреблять уже больше 2 мс.
Именно поэтому я добавил в пак фичу для оптимизации количества частиц в зависимости от количества эффектов на сцене, что бы не превышать определенный порог. И на скриншоте я как раз вырубил эту оптимизацию, что бы показать что даже в таком случае выходит 0.12 мс на эффект. в 99% проектов никто не использует сразу кучу эффектов, поэтому я могу ориентироваться на создание одного эффекта и бюджет для него, а не для всех сразу.
Покажешь мне игру где на экране сразу 33 эффекта используется?
А ничего, чувак, что ты обосрался с той самой половиной "аргументов и вопросов"?
Ты даже офф. документацию не смог осилить - понапридумывал всякой дичи, которую взялся тут впаривать населению.
>Ну так ты расскажи чем они не довольны?
Т.е. я еще должен поработать для тебя PR-менеджером? Да ты в край охуевший. Я уж не говорю что твои ассеты переоцены по стоимости.
Например вот эти ребята https://assetstore.unity.com/packages/tools/terrain/r-a-m-river-auto-material-101205 предлагают гораздо более качественные и оптимизированные (я проверял их ассеты - могу утверждать) вещи, а ценник сравним с твоим.
Но пытаться припрячь меня еще и для разборок фидбека по твоим поделкам - шел бы ты нахуй.
>Твои посты разбросаны по всей странице, да я не умею читать ублюдское цитирование джоя.
А т.е. опять кто-то (но не ты) виноват в твоей невнимательности (уведомления об ответах на почту приходят вообще-то)?
>Ты опять же проигнорил большинство моих вопросов, тебе неугодных
Каких? Я тебя что обязан учить Юнити? Я тебе и так расписал больше чем ты способен уяснить. Дальше читай документацию, и не выдумывай бредней. Я уж задолбался их развенчивать. Кто ж тебе доктор, что ты даже смысла применяемых терминов не понимаешь.
>Что за хуйню ты несёшь? Как по твоему создавать эффект в рантайме, если не instantiate(effect, position, rotation)?
Пиздец... И этот человек мне что-то про оптимизацию пишет.
Про пулы реиспользуемых объектов ты конечно же не слышал. Хотя может и слышал - как все остальное - краем уха. Ну и о том что instantiate - одна из самых тормозных функций ты тоже - ни ухом, ни рылом.
>Во-первых не надо ехидничать и брать в кавычки слово "эффекты", глядя вот на это
А что тебя не устраивает? То что тут нет десятков тысяч партиклов? И оно не жрет миллисекунды на отработку?
>Ок, мои эффекты не оптимизированы. Расскажешь где и как?
Да запросто - комменты на сторе (в картинке к комменту).
Падение производительности с 60 фпс до 30 фпс на 10(!) эффектах.
У чела кадр считался за 16,5 мс. Стал считаться за 33 мс. Разница в 16,5 мс. Делим на 10 - получаем по 1,65 мс на эффект.
Скажешь - 10 эффектов одновременно - это слишком дохера? А может просто - нахуй такие эффекты?
Ну как же, смотрим еще один скриншот прямо с первой же страницы стора - приаттаченный к комменту.
Где ты расписываешь как на "low end" девайсах у тебя стабильные 60+ фпс.
И где ты расписываешь что 20 тысяч партиклов сожрут 1 мс а 40 тысяч уж 3 мс.
Правда ты нигде не указываешь от какого CPU, хотя сам же заявляешь что
>Shuriken particles работают на cpu.
Но отчего-то упоминаешь только gtx 1060. ты всегда такой гнилой, да? С подтасовкой фактов, данных и т.д.?
При том что выше я указал скрин где у человека всего лишь 10 твоих эффектов сожрали половину производительности, а из простой арифметики следует что с "выходит 0.12 мс на эффект" ты напиздел примерно на порядок.
Запизделся ты дружок.
>Покажешь мне игру где на экране сразу 33 эффекта используется?
Навскидку - Magicka 1\2. Там в коопе и больше 33 бывает одномоментно. И (что удивительно) ) - реально работает на платформах слабее gtx 1060.
http://kripto289.com/Shared/Effects4%28Test%29.jpg
Пиздец.
SetPass 232 Batches 342, Saved by Batch 5. И это всего лишь - 33 эффекта без всего остального. Это пиздец товарищи. И этот "кадр" что-то втирает про оптимизацию. Эффективный "оптимизатор", мля.
Ты тупо выезжаешь на многоядерном проце и довольно сильной видеокарте. И то...
У тебя в кадре менее 300 тысяч треугольников, а кадров 150. У меня в сцене 1,3 млн треугольников и на Xeon 1220V3 + GTX 570 - 100 кадров. При этом в кадре - несколько систем частиц, кучка Skinned mesh и пара полноэкранных постэффектов с твоими "проблемными" OnRenderImage.
Причем загруженность проца - менее 50%, а вот видеокарта - 99%. Причем прямая зависимость - уменьшаю draw calls, растут fps.
>>Да ты в край охуевший
>> по твоим поделкам
>> шел бы ты нахуй.
>>ты всегда такой гнилой
>>ты напиздел примерно на порядок.
>>Запизделся ты дружок.
На этой ноте заканчиваю.
Ну а чего ты хотел? Ты хуйню пишешь, аргументы игноришь, пиздишь, сам себе противоречишь, в теме не волочешь - тебя надо было погладить по головке и дать конфетку, чтобы ненароком не порушить твою тонкую душевную организацию пиздабола?
Слился наконец-то. Ну и хуй с тобой.
Ну считай что я "слился" спорить с неадекватом. Достаточно лишь того факта, что ты сравниваешь пака эффектов с паком воды и считаешь крутость эффетов по количеству drawcalls. Ps, кстати уточнение, на скрине 43 префаба с эффектами, не 33.
ну и плюс в паке не только вода и инструменты для работы с ней.
>Ps, кстати уточнение, на скрине 43 префаба с эффектами, не 33.
А отчего не 143 сразу? Ты не понимаешь что - пофигу совершенно? У тебя просто эффекты жрут столько - сколько у людей полная сцена в готовой игре.
Что ж ты не комментируешь игру с большим кол-вом одновременных эффектов? Я ж тебе назвал.)
Что ж ты давно заткнулся по поводу своих "технологий"? Что-то завалил хлеборезку про Occlusion culling и т.д.
Надеюсь не огребу своим комментом :D
1. донести до всех, кому интересно, что оптимизация - сложный методичный и трудоемкий процесс, окупающийся лишь постоянным контролем и в отдаленном будущем (ближе к релизу)
2. пояснить, что нехер слушать долбойобов, не делавших ничего, кроме тормозных "эффектов" - ибо знать кучу терминов и названий не значит - разбираться в вопросе.
3. На примере особо упертого (или упоротого) создателя ассетов, показать к чему приводит - забивать болт на оптимизацию каждой отдельной фичи сразу. Собственно как пример "инди" которому главное - "выпустить", а не "выпустить качественно".
Причем под качеством я понимаю не только "красиво", но еще и "стабильно", "производительно", "удобно", "применимо".
>>пояснить, что нехер слушать долбойобов, не делавших ничего,
>>кроме тормозных "эффектов"
>>показать к чему приводит - забивать болт на оптимизацию каждой
>>отдельной фичи сразу
Агресивный неадекват, делающий выводы об оптимизации не видя в глаза ни проекта, ни демки.
>>Причем под качеством я понимаю не только "красиво",
>>но еще и "стабильно", "производительно", "удобно", "применимо".
К твоему проекту относится только "производительно" и то благодаря тому, что графика уровня 20-и летней давности.
Интересно с твоим подходом хуесосить и оскорблять без причины, много ли ты добьёшься в геймдевелопменте? Ну кроме 3-х продаж в стиме?
Явно сработаться ты ни с кем не сможешь, с таким-то подходом.
Да ты достаточно скринов и всего остального выложил "похваляясь" - чтобы делать выводы понимая суть темы.
>Интересно с твоим подходом хуесосить и оскорблять без причины
Положим причин тут вагон.
Про твой подход "лишь бы продать" - я уже написал.
Ну и это - ты же вроде как слился. Или пукан пригорает?
Целый один скрин, где в среднем 8 dc на эффект у тебя вызывают приступы истерии.
>>Положим причин тут вагон.
Причина - ты неадекват.
>>Про твой подход "лишь бы продать" - я уже написал.
Да. Я продал свои навыки VFX артиста и благодаря этому в моём портфолио есть несколько проектов, включая от крупных ААА студий.
>>Ну и это - ты же вроде как слился. Или пукан пригорает?
Да слился. Для меня не зазорно "слиться" при общении с неадекватом.
Пукан вообще не пригорает. Это ведь не у меня пена из рта брызжит от слов "frustrum/occlusion".
Впрочем, ретируюсь. Лучше в дотку сыграю, там хотя бы комьюнити менее агрессивное.
До тебя, дауна так и не доходит что кроме DC есть другие параметры, о которых я писал, но ты продолжаешь их игнорировать, т.к. они наносят непоправимый ущерб твоему ЧСВ.
>Причина - ты неадекват.
А что сделать? Приходится с тобой на твоем уровне общаться.
>Да. Я продал свои навыки VFX артиста и благодаря этому в моём портфолио есть несколько проектов, включая от крупных ААА студий.
Да про твое ЧСВ я уже написал. Только что ж ты продолжаешь игнорить скрины которые я с твоих страниц в сторе наделал, а? Случайно не потому что они противоречат твоему образу "непогрешимого специалиста"?
И что ж ты замолчал со своими "знаниями" технологий и тулзов Юнити, после того как тебя натыкали в твои обсеры в понимании того как оно работает?
>Да слился. Для меня не зазорно "слиться" при общении с неадекватом.
Пукан вообще не пригорает.
Себе почаще об этом рассказывай - может и поверишь.
Ты обосрался что с frustrum, что с occlusion. Но никак не можешь об этом заткнуться.
>Впрочем, ретируюсь.
Свежо предание да верится с трудом. В очередной раз: проследуй уже наконец нахуй.
Который инди разраб не сможешь провести, если займется им сразу, только код изговнит и добавит лишние часы работы там, где это не особо то и нужно. Оптимизировать нужно лишь тогда, когда нельзя не оптимизировать. Ну либо когда точно знаешь, где конкретно понадобится оптимизация.
>Собственно как пример "инди" которому главное - "выпустить", а не "выпустить качественно".
Но это ложная дихотомия. Обычно выбор - он между "выпустить" и "невыпустить, т.к. хотел качественно".
>"красиво", но еще и "стабильно", "производительно", "удобно", "применимо".
Как говорится, выберете 1 из 4. Спойлер: выбирать нужно "красиво".
Почему совет - стараться писать оптимальный код изначально (не использовать LINQ, всякие foreach, строковые операции, всякие GetComponent \ FindComponent и т.д.), профайлить получающиеся классы - чтобы научиться и без профайлера ориентироваться сколько и чего "жрет", обязательно проверять на ресурсоемкость "тяжелые" алгоритмы - где реализован перебор либо обработка крупных массивов, изучать корректную применимость тех или иных компонент и решений - это прямо таки что-то запредельное для большинства?
Заниматься такой оптимизацией - это НОРМАЛЬНЫЙ процесс разработки.
Он не занимает дохера времени и почти всегда идет параллельно основной разработке + позволяет снизить вероятность создания тучи боттлнеков "на пустом месте" и прокачать скиллы кодинга в принципе.
Как бы неслабая разница - при полишинге игры вылавливать двадцать боттлнеков или пару.
Я понимаю, что гораздо проще забить на нормальную разработку, на оптимизацию, на юнит тесты, на тестирование вообще, а нахапать "красивых" ассетов, к ним - наговнять какой-то там код, зато "супер быстро" и "выпустил".
«Отложенная игра в конечном счете будет хорошей, но игра, выпущенная в спешке — всегда плохая.»
- Сигэру Миямото
Создатель Mario, Donkey Kong, & Zelda
Ну и насчет "дефицита ресурсов у инди":
"Если бы у меня был неограниченный доступ к ресурсам — это был бы полный бардак. На протяжении игровой истории очень редко кому-то удавалось справиться без ограничений. Даже Blizzard с их проектом "Титан". Неограниченные деньги, неограниченные ресурсы, неограниченное время. И они не смогли заставить это работать.
Но в конечном счёте, когда они упёрлись в стену, появилась Overwatch. Фантастическая игра, но путь к ней лежал через ограничения. Рамки принципиально необходимы нам. Когда я был намного моложе, я думал: "Как бы я хотел не связываться со всеми этими людьми, иметь ресурсы и делать всё, что захочу". Но по мере того, как я рос, набирался опыта, много ошибался и порой достигал успеха, я понял важную вещь. То, что сделало меня хорошим геймдизайнером — это постоянная необходимость думать об этих проблемах."
© Дэниел МакЛарен, геймдизайнер Vanguard: Saga of Heroes и Star Wars: Galaxy of Heroes
А потом еще удивляться: "а почему от инди так плюются?"
>Спойлер: выбирать нужно "красиво".
а вот нихуя. особенно в случае выбора ассета для своего проекта нужно выбирать так что первом месте - "удобно и " "применимо", иначе ты просто не сможешь интегрировать этот ассет в свой проект, либо потратишь столько ресурсов, что проще было сделать самому.
На втором месте - "стабильно", ибо нахрен нужен ассет, который рушит весь твой проект. Конечно всегда можешь взять на себя труд по багфиксу чужого ассета, за который ты отдал деньги.
И только на третьем - баланс между "красиво" и "производительно".
Те кто ведутся только на "красиво" - обычно остаются с красивой пустышкой.
И ты обосрался уже с первым советом. Мало того, что LINQ, foreach и всякий другой синтаксический сахар компилятором во многих простых случаях разворачивается в более быстрый код, чем если все это делать в лоб, так и еще в остальных 98% сценариев, где не разворачивается - это вообще ни на что не влияет, кроме как на читаемость кода.
>Заниматься такой оптимизацией - это НОРМАЛЬНЫЙ процесс разработки.
Нет, заниматься такой оптимизаций - это хз, в каком-нибудь НИИ работать нужно за 40 тысяч. Труд программиста - достаточно дорог, программист должен создавать ценность, а не долбиться в сраку байтоеблей там, где эта байтоебля не нужна и, вполне вероятно, вообще выкинется из проекта, не дойдя до продакшена. Ты сначала пишешь, чтобы было лаконично и понятно, а потом уже, где требуется, оптимизируешь.
>Как бы неслабая разница - при полишинге игры вылавливать двадцать боттлнеков или пару.
Да, разница действительно нехилая - выловить 20 батлнеков в конце или замедлить проект в 3 раза, чтобы в конце пришлось вылавливать только пару.
>«Отложенная игра в конечном счете будет хорошей, но игра, выпущенная в спешке — всегда плохая.»
Выпущенная игра - это выпущенная игра, а отложенная игра - очень может быть, что невыпущенная.
>Если бы у меня был неограниченный доступ к ресурсам
>Дэниел МакЛарен, геймдизайнер Vanguard: Saga of Heroes и Star Wars: Galaxy of Heroes
Ну ты бы сразу и бюджеты дал бы, чтобы понимать, что тут подразумевается под ограниченным доступом к ресурсам.
ты б в свои штаны заглянул что ли...
Сами Юнитеки рекомендуют НЕ использовать "LINQ, foreach и всякий другой синтаксический сахар". Во всех статьях по оптимизации кода под Юнити - только ленивый не писал что нехер эти конструкции использовать - ибо каким хреном они могут дать "более быстрый код", если тот же foreach выделяет память на создаваемый итератор, а выделение памяти - такая "быстрая" операция что нахер-нахер.
Ты может почитал бы что на эту тему, что ли... А то очередной "специалист" пишет очередную НИЧЕМ не обоснованную дичь.
Просвещайся, мне не жалко:
https://stackoverflow.com/questions/365615/in-net-which-loop-runs-faster-for-or-foreach
и на русском (если с английским не дружишь)
https://habr.com/ru/post/210616/
Все наглядно с картинками и таблицами доказывает как ты пи... сильно ошибаешься.)
А что же про LINQ?
"Unity Technologies and Microsoft, among others, recommend to avoid LINQ where performance is a concern.
Unity Technologies said:
Both LINQ and Regular Expressions generate garbage due to boxing that occurs behind the scenes. It is best practice to avoid using these altogether where performance is a concern
https://learn.unity.com/tutorial/fixing-performance-problems
Microsoft said:
Avoid use of LINQ. Although LINQ can be very clean and easy to read and write, it generally requires much more computation and particularly more memory allocation than writing the algorithm out manually.
https://docs.microsoft.com/en-us/windows/mixed-reality/performance-recommendations-for-unity"
Надо же - мои утверждения подкреплены доказательствами. А твои?
>Труд программиста - достаточно дорог, программист должен создавать ценность, а не долбиться в сраку байтоеблей там, где эта байтоебля не нужна и, вполне вероятно, вообще выкинется из проекта, не дойдя до продакшена.
О как. Да ты прямо - Ванга. Знаешь что и когда выкинется, где что нужно - не видя ни кода, ни проекта. Научи такому фокусу, а?
>или замедлить проект в 3 раза
Откуда цифра? Почему именно в 3? Почему не в 3,145? Или не в 2,995?
Чувак, завязывай свои фантазии выдавать за какую-то там истину.
Твое знание материальной базы как бы намекает что конкретно вот твой труд как программиста не стоит вообще нихера. И прислушиваться к твоему ахуенно неверному мнению - наверное себе дороже.
>отложенная игра - очень может быть, что невыпущенная.
Харе уж себе славу Ванги загребать. Да и на слепую старушку ты никак не похож.)
В общем смотрю тут прямо началась перепись говнокодеров, которые прямо по шаблону: "ну ща мы тяп ляп и в продакшен! Главное - выпустить, а там мы на игроках потестим!"
Нахуй им пайплайны, оптимизации, итерационная разработка, чтение документации... они заняты - создают "ценности". Им некогда отлавливать баги, боттлнеки и т.д.
Нахуй им пайплайны, оптимизации, итерационная разработка, чтение документации... они заняты - создают "ценности". Им некогда отлавливать баги, боттлнеки и т.д."
Забавно, ты делаешь выводы об оптимизации и говнокоде даже не видев ни одной строчки кода, лол. Агрессивный теоретик.
Как пример в моём проекте все шейдера самописные и оптимизированные, и что я использую собственную систему освещения без доп пассов? Или что я годами поддерживал самописные быстрые постэффекты для мобилок, как например hdr bloom на opengles 2.0 без поддержки hdr?
Знаешь какая между нами разница? В оплате наших знаний и умений.
Какими бы охуительными не были твои знания, судя по всему результат твоей деятельности нахуй никому не впёрся, кроме тебя и твоего чсв.
Да куда уж мне, ага. Это ведь НЕ Я использую в продакшене Instantiate(), а потом делаю круглые глаза "а как по другому?"
Не Я тут пишу "нахуй оптимизацией заниматься - есть БАТЧИНГ. Нахуй считать draw call'ы - это не узкое место. Нахуй профайлер."
И НЕ Я - не читаю ОФИЦИАЛЬНУЮ документацию, в которой черным по белому написано: "не используйте долбойобы foreach \ linq и другую такую херню, ибо пишете вы ее от лени и для "красоты", а потом понять не можете куда же делась производительность".
Никаким боком НЕ Я взялся тут спорить с элементарными советами (причем опять же - сопровождаемыми ссылками и подтверждениями) по оптимизации.
Это не у меня люди в отзывах пишут: "производительность упала вдвое, хотя было обещано "даже на low end устройствах", а в реальности..."
Или
"Код очень отвратительно составлен, классы дублируются, отличаясь несколькими строчками"
Или ты такие отзывы к своим ассетам СЕЛЕКТИВНО не замечаешь?
Вы дебилы, тут на пару уже столько про свой "индус-стайл" кодинга нарассказали - пару книг написать можно под заголовком "Так делают долбойобы".
Про свои "оптимизированные" шейдера это ты смешно написал, да.)
Разница между нами в том, что я не втюхиваю лохам и неграмотным свои поделки наобещав с три короба. И не втираю с важным видом народу кучу малосвязанных терминов, даже не понимая их сути.
Не гну пальцы про "участие в ААА-проектах", и не делаю проекции своего ЧСВ на других. И не сравниваю чужие доходы со своими.
Да и еще - если я говорю что сваливаю, то - держу свое слово, а не болтаюсь как ты - словно говно в проруби с полыхающим пердаком.
Боже, какой ты неадекватный, ей богу. Я префабы продаю, а не код в продакшене.
>>Это не у меня люди в отзывах пишут
Про тебя тут тоже 2 отзыва написали. Ты или ты СЕЛЕКТИВНО не замечаешь?
>>"производительность упала вдвое, хотя было обещано "даже на low end устройствах", а в реальности..."
Демка для мобилок есть? Есть.
На скрине 43 эффекта показывают 150фпс? 1 эффект не может потреблять половину ресурсов. Но тебе то зачем разбираться в чём проблема, раз написали значит это 100% так? Даже несмотря на то, что я либо в комментах, либо по почте всем помогаю?
>>"Код очень отвратительно составлен, классы дублируются, отличаясь несколькими строчками"
В каждом паке уникальные имена классов, хотя могут иметь общий код. А могут и не иметь. Расскажешь как и зачем мне нужно использовать общие скрипты для разных версий проектов, как мне править эти скрипты и как гарантировать что все проекты будут работать после этого?
>>Разница между нами в том, что я не втюхиваю лохам и неграмотным >>свои поделки наобещав с три короба
Я до сих пор не вижу ни единого пруфа твоим словам. По полочкам, какие проблемы с оптимизацией в моём коде и эффектах? Что я наобещал и что из этого не работает?
Желательно с замерами производительности и разбором кода, а не гаданием на кофейной гуще и двум отзывам.
>>Да и еще - если я говорю что сваливаю, то - держу свое слово,
И? Какая мне разница до того, что и для кого ты там держишь?
Поражаюсь твоему лицемерию. Ты бьёшь себя в грудь и доказываешь как для тебя важно проявить уважение к людям и оптимизировать для них за спасибо, но при этом готов хуесосить и оскорблять любого.
>> а не болтаюсь как ты - словно говно в проруби с полыхающим пердаком.
Да почему ты взял что у меня полыхает? Мне оборот приятно, что у человека (с огромным чсв и поведением агрессивного школьника) и на 14 лет старше меня вершиной достижений является количество drawcalls в хобби-игре.
Меня прям забавляет как контрастирует твоё чсв с тем чего ты добился.
>Боже, какой ты неадекватный, ей богу. Я префабы продаю, а не код в продакшене.
Ага, а без скриптов (т.е. без кода) твои эффекты работают как заявлено? Или ты делаешь не "под ключ", и надо - "дорабатывать напильником"?
Или ты сейчас будешь изворачиваться, что скрипты не часть твоих ассетов?
>Про тебя тут тоже 2 отзыва написали.
Шта? Ты больной или как? Ты отзывами считаешь писанину двух некомпетентных демагогов, которые тупо обиделись, что им указали на полнейшее незнание предмета? Да, такие "отзывы" двух обиженок я замечать не собираюсь.
>Демка для мобилок есть? Есть.
На скрине 43 эффекта показывают 150фпс?
Вот только мне не надо тут по ушам кататься. Ты уже несколько комментариев никак не можешь указать конфигурацию, на которой эти 15 фпс получены.
И собственно если ты считаешь, что это прямо дохрена, то я тебе еще раз напишу - 300 тыс. треугольников, ничего кроме 43х эффектов в кадре, судя по gtx 1060 - комп выше среднего по мощности и ВСЕГО ЛИШЬ 150 фпс.
Повторюсь еще раз - это пиздец.
>я либо в комментах, либо по почте всем помогаю?
Пиздеть не надо - в тех же комментах люди пишут что ты неделями не отвечаешь. И предваряя твое : "где? да нет такого" - я тебя уже тыкал носом в скрины, ты - язык в жопу засунул. Больше я бисер перед тобой метать не буду. Если ты - тупой баран, который доказательства игнорит - хуле мне ими мозги греть?
>Расскажешь как и зачем мне нужно использовать общие скрипты для разных версий проектов, как мне править эти скрипты и как гарантировать что все проекты будут работать после этого?
Т.е. нагрузить меня PR-возней с твоими клиентами не вышло. Теперь я должен тебя еще и кодингу учить? Повторюсь - ты охуевший от жадности пиздабол.
>Я до сих пор не вижу ни единого пруфа твоим словам. По полочкам, какие проблемы с оптимизацией в моём коде и эффектах? Что я наобещал и что из этого не работает?
Ну не видишь - сходи к окулисту. Я двадцать раз одно и тоже писать \ приводить не буду. Ты ж все равно не увидишь - неспособен просто видеть что-то что рушит твою розовую картинку мира, где ты весь такой "добившийся" (хуй знает чего и где) и "непогрешимый".
>Ты бьёшь себя в грудь и доказываешь как для тебя важно проявить уважение к людям
Наркоман штоле? Где я писал про "уважение к людям", мудло?
Ты уж настолько заипался высасывать из пальцев чушь, что опустился до прямого вранья?
>при этом готов хуесосить и оскорблять любого
Опять пиздишь. Далеко не "любого". Если посмотреть даже комменты этого поста - напросились на грубость тут лишь двое. И то - даже тебя хуесосить я начал не сразу, а только после твоего неоднократного заносчивого пиздабольства по теме в которой, как выяснилось ты - ни ухом, ни рылом.
А вся твоя аргументация в итоге свелась к тому, что ты заткнулся обсуждать средства и области оптимизации, а талдычишь лишь, что ты там чего-то "добился". Даже про какой-то ААА-проект насочинял, да что-то боишься его назвать - наверное потому что опять напиздел.)
>Да почему ты взял что у меня полыхает?
Потому что ты , бедная зверушка, уже дважды "уходил с гордым видом", но что-то ты нихуя не хозяин своему слову - возвращаешься как прилипчивое гавно. И вместо технической аргументации, ответов на вопросы которые были заданы уже сутки с гаком как - ты все пытаешься достать меня одним аргументом про "добился". Да вопрос чсв тебе покоя не дает. Боишься что у кого-то больше?)
Обратил бы внимание - тут только ты чем-то хвалишься. Причем начал когда по технической стороне сел в лужу.
Этим и отличаются программисты от говнокодеров: первые думают своей головой, а не читают статьи других говнокодеров.
>если тот же foreach выделяет память на создаваемый итератор
Что ты несешь, сумасшедший?
>Просвещайся, мне не жалко:
>In .NET,
>Asked 12 years, 3 months ago
Я никаким боком к геймдеву отношения не имею, но даже я знаю, что Unity - это не .NET, а про 12 лет назад я вообще промолчу.
>Надо же - мои утверждения подкреплены доказательствами. А твои?
А мои - отсутствием у меня слабоумия. Иди другим аутистам расскажи, как foreach замедляет код потому, что так в статье 50-летней давности было написано.
>Твое знание материальной базы как бы намекает что конкретно вот твой труд как программиста не стоит вообще нихера.
Сказал человек, который вместо работы заменяет foreach на for.
>Нахуй им пайплайны, оптимизации, итерационная разработка, чтение документации...
Но это ты себя описываешь, посылая нахуй пайплайны, итерационную разработку, документацию и здаравый смысл, занимаясь байтоеблей и понижением качества кода вместо работы.
Оно и видно, говнокодеры типа тебя не только советы профессионалов не читают, но и официальной документации. Зато очень "думают" - межушным ганглием, в полной уверенности, что это и есть - "мыслительный процесс".
Все что ты смог - напиздел кучу текста без единого доказательства.
Тебе, дебилу, который нихуя к кодингу отношения не имеет, ссылка на АКТУАЛЬНУЮ Юнити-документацию ни о чем не говорит, да?
Хуле, ты ж вместо того чтобы ЧИТАТЬ - "надумал своей головой" кучку говна, вместо которой можно было написать, что ты нихуя не знаешь, нихуя не читаешь, в геймдеве не разбираешься, но все тебе должны почему-то поверить.
Вся твоя писанина - в одной фразе.
>>Fosgen Тебе, дебилу, который нихуя к кодингу отношения не имеет
>>Мамкин Бродяга Я никаким боком к геймдеву отношения не имею
Просвещайся
https://www.jacksondunstan.com/articles/4573
"This is exactly the same assembly code! Every single character of every single line is the same, even down to the registers that local variables occupy. This means we can very easily state what a foreach loop looks like on an array: it’s the same as a for loop"
Ill2CPP оптимизирует for и foreach до идентичного кода.
Ill2CPP оптимизирует весь код, местами даже в несколько раз.
https://www.jacksondunstan.com/articles/3001
Или ты мастер оптимизации используешь моно и оптимизируешь foreach? Лол.
Яркий пример с моим скриншотом. Я тебе черным по белому написал
>>Именно поэтому я добавил в пак фичу для оптимизации количества
>>частиц в зависимости от количества эффектов на сцене,
>>И на скриншоте я как раз вырубил эту оптимизацию, что бы показать
>>что даже в таком случае выходит 0.12 мс на эффект
Для одного эффекта я использую примерно от плюс/минус 20 тыщ частиц. Даже для мобилок это несущественно. А теперь поставь на сцену хотя бы 10 таких эффектов и у тебя cpu уже начнёт захлебываться. 200 тыс частиц = 400к треугольников.
А у тебя уже жопа горит от цифры 300тыс на скрине, хотя в реальности по дефолту автоматом режется количество частиц по приоритету и дальности. И это PC версия частиц, а не мобильная, где всё ещё гораздо оптимизированнее.
Ей богу, лучше бы ты так же читал, как материшься и оскорбляешь.
Что там у тебя "режется" если указано кол-во ИТОГОВЫХ треугольников?
Ты хоть сам-то понимаешь что 200 тыс. треугольников чисто на 10 эффектов в сцене - это ПИЗДЕЦ?
Ты вообще врубаешься что если б ты хоть немного использовал тот самый батчинг и запихивал частицы в минимальное кол-во отрисовок, а часть расчетов выносил на GPU (который бывает сильно быстрее CPU) - то это и было бы оптимизацией, а не твоим любимым пиздабольством.
>И это PC версия частиц, а не мобильная, где всё ещё гораздо оптимизированнее.
И где эта легндарная "мобильная версия" и чем там "всё ещё гораздо оптимизированнее"? Тем что кол-во частиц меньше?
Все что ты смог выдавить "для оптимизации" - уменьшать кол-во частиц. Сл-но - ухудшать визуальную составляющую эффекта. Ща ты скажешь "оно не теряет в качестве".
Но если можно уменьшать без потери эффектности - почему тогда изначально не уменьшить? Зачем перенагружать CPU?
Т.е. ты, обиженка, меня обвиняешь в байтоебле, но сам все что смог "в оптимизацию" - визуально обеднять свои эффекты.
Ей богу, лучше бы ты своим бревном в глазу занимался, чем чужие соринки обмусоливать.
Бедная обиженка вылезла опять. Твое слово не значит ровным счетом нихуя.))
Ну и посмотрим что же пишет чувак с твоей ссылки:
"there is a reason to cache the array length as a local variable. It will reduce the amount of branching required in the loop when null checks are left enabled."
Но это оказывается нихуя не "байтоебля", ага, потому что прямо сейчас вам выгодно, да? "Вы нипанимаити, эта - ДРУГОЕ".
Только может ты все же не умеешь читать, а?
"This means we can very easily state what a foreach loop looks like on an array: it’s the same as a for loop that doesn’t cache the Length field and doesn’t disable null- or bounds-checks. That makes it equivalent to the slowest for loop we can write. "
Перевожу для дебилов:
""Это значит что foreach-цикл как for ДЛЯ МАССИВА. Он такой же как цикл-for, который НЕ КЕШИРУЕТ поле Length и НЕ ОТКЛЮЧИЛ null- и bounds- проверки. Что делает его эквивалентным САМОМУ МЕДЛЕННОМУ for-циклу, что мы можем написать."
С учетом что в случае foreach закешировать поле Length мы не можем в силу синтаксиса...
>Ill2CPP оптимизирует весь код, местами даже в несколько раз.
Ага, прям заебись как оптимизирует:
"The indexer, however, is quite long. It has method initializaton overhead of its own since it can throw an exception."
...
"By calling GetAt, it performs the exact same bounds check to see if it should throw an IndexOutOfRangeException, which will never happen. It might as well disable bounds-checks since it performs its own bounds check, but it doesn’t."
...
"So we’ll have to eat the function call overhead once for the cached Count getter call and every loop iteration to index into the contents of the List."
А вот это:
" List_1_GetEnumerator_m593114157 gets the enumerator, Enumerator_MoveNext_m3181700225 advances it"
подтверждает мои слова несколькими комментами ранее: "foreach выделяет память на создаваемый итератор". Так что твою ссылку стоит почитать второму моему оппоненту.) Спасибо, однако за подтверждения.)
Ну а для foreach по List он даже пишет:
"With all of this expensive work present in the C++ code, let’s look at the assembly it compiles to. This is going to be long and there’s no need to understand it all or even read it all. "
...
"Notice that this isn’t the full assembly source for the loop. "
т.е. она даже не стал запихивать в статью весь асм-код данного цикла, ибо "дохера" в отличие от for по List.
Как ты там умудрился найти "оптимизирует for и foreach до идентичного кода" , убогий разумом?
IEnumerable foreach - идентичен foreach по a List.
И в заключение чувак пишет:
"There is a clear winner here: for loops on an array with the Length field cached and the null- and bounds-checks disabled. It produces tiny, minimal assembly code for the CPU to run and should be preferred whenever we care about performance. Not disabling the null- and bounds-checks triples the number of if checks in every iteration of the loop! Unfortunately, foreach loops on an array use this very form. Even with the checks disabled, fetching the Length field every iteration cannot be avoided by caching it as a local variable (i.e. into a CPU register). They should be avoided when performance matters."
Перевожу:
"Абсолютный победитель for для массивов с отключением проверок и кешированием длины массива. Проверки втрое увеличивают время выполнения, а в циклах foreach невозможно кешировать длину массива. Поэтому их надо избегать в целях производительности."
Ты либо гнилой мудак, который перевирает аргументы, либо не читаешь даже свои "доказательства"? Вот это точно - ЛОЛ.
Давай еще таких "доказательств"!)
Просто нельзя же быть настолько непроходимо-безгранично тупым - под соусом "опровержения" приводить исследование, где прямым текстом подтверждается моя точка зрения.
Или я недооцениваю твои возможности в дебилизме?)
Я выбрал просто навскидку.
понятно что сейчас мы здесь не услышим "вторую сторону" - тех людей (а их далеко не один) которые запросили рефанд.
Само наличие людей, которые недовольны оптимизацией твоих "эффектов" - оно как бы намекает.
Ну и ты там расписывал людям про 2-3 мс процессорного времени. Эм... У меня в игре вся отрисовка сцены занимает 2,4 мс - и это МНОГО. Один цикл апдейта 3,5 мс.
И ты заявляешь что эффект который жрет 3мс - это дохуя оптимизированный? Иди таблетки прими что ли.
Любой функционал \ фичу игры надо сразу укладывать в определенные рамки по затратам CPU, RAM, GPU, VRAM и после - контролировать чтобы при масштабировании затраты росли адекватно.
В противном случае будет результат на который только крайне ленивый не жаловался - отвратительно оптимизированная игра, дальнейшее "причесывание" которой приводит к лавинообразному появлению багов.
Мы про инди-разработку говорим. Жалуются - это уже успех.
А вот производительность просадить можно следующими аспектами:
1. Физика - большое кол-во коллизий \ слишком сложная форма коллайдера (MeshCollider convex) \ неверные настройки Rigidbody \ коллизии частиц \ пересекающиеся коллайдеры
2. Значительное кол-во вызовов Update() в скриптах наследованных от MonoBehaviour.
3. Большое кол-во SkinnedMeshes в кадре \ использование компонента Animator там где можно было использовать Animation \ больше кол-во костей в SkinnedMeshes.
раньше я не замечал, что недели пролетают так быстро
а теперь каждую субботу ощущаю
так что не
Конечно, если не предполагается активное взаимодействие с НПС, чьи лица будут показаны крупным планом в диалогах - тогда тут нужно мне кажется однозначно запариваться т.к. если тебе рассказывают какой тот волчара плохой и злой и сожрал у непися почти всех овец и при этом с каменным рылом, не выражающим даже лёгкого раздражения, это уже плохо)
А вот разрезание мешей штука не часто встречающаяся в играх. Она и смотрится эффектно и часть механик оригинальных можно с ней запилить. Её бы я добавил.
Про лицевую анимацию соглашусь, на данном этапе наверно не стоит запариваться над этим)
Древковое оружие рубить.
Декапитация.
Если у тебя боевка "камерная" - т.е. в замкнутых локациях-аренах, то можно ввести разрушаемые препятствия.
В плане физики взаимодействий - я делал привязку к физическим материалам:
как для VFX, так и для SFX
Но там надо учитывать что при обращении к материалу напрямую - создается его инстсанс что во-первых не очень рационально, а во-вторых блокирует прямое сравнение материалов.
https://thegamedev.guru/unity-performance/draw-call-optimization/#batches-vs-setpasses