Эти методы работают при точном определении параметров камер. Но как откалибровать сами камеры? Ведь в реальности картинки искажены линзами(напр. эффект fisheye), разные камеры могут иметь разные параметры, линейкой измерить положение и направление часто бывает невозможно, напр. если камера крутиться вокруг объекта и делает много снимков.
Да, как сказал soniq, тут очевидный плюс это отсутствие задержки на клиенте для действий самого пользователя. Проверки на сервере должны быть до показа результата действия другому пользователю. В шутерах(к примеру) подобный метод называется client prediction: ты стреляешь во врага и сразу видишь результат в виде брызг крови на враге, но не убиваешь его локально т.к. сервер должен подтвердить попадание, может быть что на сервере в этот момент тебя уже убили и тогда попадание не засчитывается.
Однако есть в этом минус: можно хакнуть код и понять какой ход нужно сделать чтобы рандом был более удачным. Сервер от такого не защитит.
Можно, но не всегда. Доступа к чужим классам иногда нет, а наследоваться не хочется. А еще так можно указать в параметр Актор у которого нет нужного интерфейса, т.е. даешь возможность совершить ошибку. Я точно не помню какая именно ситуация у меня была, помню что спрашивал в форумах и никто не смог мне помочь, пришлось находить другое решение, менее привлекательное. Меня печалит что эту схему можно относительно легко реализовать в движке, но этого нет, и кто не хочет может старую архитектуру использовать, т.е. никому хуже не будет.
Ну там есть компоненты. И это полезная вещь, т.к. можно из разных компонент конструировать какой-то цельный объект. Проблемы начинаются когда нужно как-то связать 2 компонента. Приведу пример: я хочу создать такой компонент который я буду кидать на объект и он будет крутиться. Т.е. есть куб, хочу чтоб он крутился и просто кидаю туда компонент RotatorComponent. И всё бы ничего, в таком виде это будет работать, но что если например я захочу менять параметр другого объекта, например цвет лампочки анимировать. В этом случае мне нужен доступ к компоненту Light а не к Actor-у. В текущей архитектуре для решения этой проблемы мне нужно указать ссылку на Actor(да, Акторы можно в поля указывать, а компоненты нельзя), и название компонента в виде строки, а в коде уже найти нужный компонент у Actor-а по названию(либо по типу, но если там несколько компонент внутри, то так не получится), что звучит очень плохо, потому что название можно поменять и всё сломается. Либо нужно создать еще один класс для конкретного объекта "лампочка с анимацией цвета". Хотя проще же просто кинуть компонент, и в любой момент удалить, либо заменить на другой тип анимации, переключение цвета по триггеру и т.д. По моему такая архитектура лучше чем хардкод с зависимостями, которые сложно потом расширять.
-По поводу "в анриле всё из коробки работает отлично", это справедливо для всего что уже там есть. Но если нужно что-то поменять или добавить, я про расширение редактора. То это забей. Ну т.е. не всегда можно отдельный плагин прикрутить, иногда сам движок нужно менять. Это занятие не из приятных, а если еще на новую версию переходить, то тяжело поддерживать. В юнити многого нет, но там на много проще расширять редактор, и это будет работать и после обновы(за редким исключением).
-Проект делать дольше в анриле. К сожалению у меня нет достаточно инфы, могу лишь предположить что для проекта на анриле, если это не демка, а полноценная игра с графоном и разнообразным геймплеем, нужно ощутимо больше времени и более крутых чуваков в команде, а на юнити можно сделать графон чуть попроще, но быстрее. Т.е. создать клон уровня АА с юнити анрил будет дольше чем с анрила на юнити, но если это ААА, то на юнити возможно придется урезать графон или чуть дольше повозиться с оптимизацией.
-Ждать пока перебилдиться код в анриле нужно вечность. Код движка менять это долго, а потом нужно закомитить чтобы другие разрабы подцепили. Да, там есть hot reload, но он у меня криво работал, частенько вылетал. В юнити с этим на много лучше. Это наверное касается именно для тех кто меняет код, а для тех кто только в редакторе что-то делает, то анрил наверное шустрее. Но опять же C++ vs C# думаю очевидно C# проще, но C++ быстрее. Писать блюпринтами думаю не серьезно. Быстрее кодом.
-Система контроля версий и анрил, это ад. Можно работать с ассетами только внутри движка. Я не могу нормально посмотреть какие изменения были в том файле того коммита. Ты просто обязан смириться с тем что есть. Да и плагин этот с багами. А нормальные не работают с анрилом. Поменял файл, и весь файл нужно комитить а не только измененный кусок, потому что бинарный. Не понимаю почему не сделают текстовый формат...
-Графон без сомнения шикарен и работает лучше чем юнити, но это на ПК. Когда мы доходим до мобилок, то все эти преимущества сразу исчезают. Приходится писать оптимизированные шейдеры/материалы всё так же как и на юнити.
-Если говорить про то что есть "из коробки": в юнити есть DOTS, а в анриле нет. Хотя и к анрилу можно что-то подобное подключить наверное. Не то чтобы DOTS это что-то незаменимое, но всё же. Есть еще ML-Agents, а в анриле нет. Так же Unity Simulations, Build Server(хотя тут не уверен может и в анриле есть готовое решение).
-В юнити на много удобнее работать со связями между объектами. К слову в анриле нельзя свойствах объекта указать ссылку на компонент(свой или чужой). Это нужно делать через код, иначе никак. Не то чтобы это критично, тут вопрос к архитектуре движка, но всё же в юнити просто перетащил компонент в нужное поле в инспекторе и радуешься, меньше зависимостей в коде, хотя и этот подход не идеален.
Unreal не идеален, к сожалению. Пользоваться готовыми решениями легко, но редко когда хватает того что там уже есть и очень часто хочется расширить редактор, но из-за того что это сложно, проще просто забить и чуть страдать в замен на плюшки в виде Nanite, Lumen,...
Если проект на ПК и готовы смириться со сложностями выше(или у вас есть специально обученный человек по решению этих проблем), то смело юзайте анрил. Но если мобилки, а еще другие платформы, или игра которая не требует крутого графона, то на юнити будет проще, удобнее и быстрее даже с учетом его минусов.
Новичку сделать демку на анриле наверное будет проще. Но поработав в юнити с разными прикольными/полезными плагинами, анрил покажется не таким удобным. Я сам после юнити страдал в анриле, потому что там не было всего того что было в юнити(в том числе мои плагины). И эти плюшки в виде быстродействия кода, красивого графона, не пересилили недостатки которые там есть по сравнению с юнити и я бросил анрил. Хотя хочется вернуться, залезть еще разок в исходники анрила и приблизить движок к идеалу :)
Думаю в статье имеется ввиду улучшение к примеру теней, освещения, детализации объектов за счёт уменьшения количества пикселей. Пиксели немного поломаются, но в сумме картинка будет лучше.
Недавно появилась мысль — выводить субтитры в котором почти всё на русском и некоторые слова на английском, либо наоборот. Чтобы учить не всё сразу а только некоторую часть, а потом увеличить процент английских слов. Мне кажется, так легче понимать контекст и неизвестное слово мозгом усвоиться легче, но это скорее для тех у кого не большой словарный запас. Но пока не придумал как правильно переводить отдельные слова.
Может стоит не блокировать ютюб, а установить плагин для отслеживания потраченного времени ютюбом? Ну т.е. чтобы появлялось сообщение «Хватит фигнёй страдать!» или звуковое сообщение чтобы даже коллеги слышали. А можно вообще не блокировать ютюб, но написать плагин, который отслеживает время и каждый день/неделю отсылает статистику коллеге/шефу. Даже если по приколу другу будешь кидать статистику, думаю это тоже поможет. А может лучше, и не сложно(вроде) на пару минут выйти прогуляться, если видишь сообщение «Хватит фигнёй страдать!».
А вы уверены, что оптимизация с if-ом действительно оптимизация? Я не эксперт, но мне когда-то сказали что в шейдерах if-ы существует не для оптимизаций и что шейдерный блок всё равно будет ждать другие блоки где условие сработало. Замеряли время рендера до и после?
Надо будет попробовать этот вариант, спасибо)
Я в полной тишине очень долго засыпаю(несколько часов). Сильно помогает включить на фоне видео с ютюба, где слышится монотонный разговор и под него засыпать. Музыка почему-то слабо помогает.
Респект за проделанную работу, всё выглядит довольно хорошо! Правда название uViLEd выглядит страшненько)
Пара вопросов:
1. Что думаете по поводу Bolt? На мой взгляд он лучше чем Playmaker и быстрее. Почему его не выбрали?
2. Почему решили перейти на Unity3d 2018.3 оставив поддержку старых версий? Учитывая что нет кодогенерации, и не используете напрямую компилятор Roslyn, вроде не проблема было писать на старой версии C#.
3. Как обстоят дела с производительностью? Как-то кешируете вызовы или каждый раз дергаете функции через Reflection?
Существует основной физический мир, который симулируется как и раньше. Там ничего не поменялось.
Но теперь при загрузке или создании сцен, можно указать параметр(LocalPhysicsMode), который позволяет создать отдельный физический мир, независимо от основного. Объекты в этом новом мире существуют отдельно от основного, т.е. шарик из новой сцены не будет взаимодействовать с основным миром.
Но есть нюансы:
Независимо от того, симулируем ли мы основной мир, у объектов/скриптов новой сцены будут вызываться FixedUpdate в такт с основным миром, с интервалом Time.fixedDeltaTime который указан в настройках
Во время вызова PhysicsScene.Simulate(float) не вызываются FixedUpdate у скриптов в этой сцене, однако вызываются события типа OnCollisionEnter
Не обязательно вызывать PhysicsScene.Simulate из FixedUpdate, можно из любого метода, напр из Update
Physics.Raycast не видит объекты в других физ. мирах, поэтому нужно использовать PhysicsScene.Raycast.
Согласен. Новая система префабав вообще топ, давно жду, фича должна облегчить работу многим.
Они еще обновили PhysX, об этом забыли упомянуть в статье. Теперь можно симулировать физику для отдельных сцен. Это тоже важное обновление для синхронизации физических объектов в мультиплеерных играх.
Visual Effect Graph тоже очень классная штука, правда работает вроде как только в HDRP.
Добавлена поддержка C# 7.3 и оптимизировали рекомпиляцию отдельных файлов(Incremental C# Compiler теперь вроде как встроен по умолчанию).
Профайлер памяти, без этого раньше было тяжело находить утечку памяти.
В общем обновлений достаточно много и это всё полезные улучшения. В статье многое не описывается, советую почитать в блоге юнитеков.
Статья якобы дает советы, а по сути советы дают автору.
Я не против туториалов и советов, но не стоит писать статью с советами после первой пробы.
Знающие люди не получили новой информации, а новички вряд ли поймут как решать эти проблемы, потому что Вы так и не написали как решить их, а просто пожаловались и предложили вариант как бы Вы хотели чтобы было удобно.
Все проблемы в статье решаемы, если почитать документацию и немного знать математику.
Не нужно ругаться на юнити, при изучении других технологий Вы наверняка тоже тратили время. Это нормально.
Кстати, недавно юнитеки сделали разделение физических сцен, чтобы симулировать не все физические объекты, а только объекты в нужных сценах. Т.е. достаточно использовать PhysicsScene.Simulate для нужной сцены, а остальной мир будет симулироваться автоматически. blogs.unity3d.com/ru/2018/11/12/physics-changes-in-unity-2018-3-beta
Не хватает превью для удобства.
У медузы битая ссылка.
Эти методы работают при точном определении параметров камер. Но как откалибровать сами камеры?
Ведь в реальности картинки искажены линзами(напр. эффект fisheye), разные камеры могут иметь разные параметры, линейкой измерить положение и направление часто бывает невозможно, напр. если камера крутиться вокруг объекта и делает много снимков.
Да, как сказал soniq, тут очевидный плюс это отсутствие задержки на клиенте для действий самого пользователя. Проверки на сервере должны быть до показа результата действия другому пользователю. В шутерах(к примеру) подобный метод называется client prediction: ты стреляешь во врага и сразу видишь результат в виде брызг крови на враге, но не убиваешь его локально т.к. сервер должен подтвердить попадание, может быть что на сервере в этот момент тебя уже убили и тогда попадание не засчитывается.
Однако есть в этом минус: можно хакнуть код и понять какой ход нужно сделать чтобы рандом был более удачным. Сервер от такого не защитит.
Можно, но не всегда. Доступа к чужим классам иногда нет, а наследоваться не хочется. А еще так можно указать в параметр Актор у которого нет нужного интерфейса, т.е. даешь возможность совершить ошибку.
Я точно не помню какая именно ситуация у меня была, помню что спрашивал в форумах и никто не смог мне помочь, пришлось находить другое решение, менее привлекательное.
Меня печалит что эту схему можно относительно легко реализовать в движке, но этого нет, и кто не хочет может старую архитектуру использовать, т.е. никому хуже не будет.
Ну там есть компоненты. И это полезная вещь, т.к. можно из разных компонент конструировать какой-то цельный объект.
Проблемы начинаются когда нужно как-то связать 2 компонента.
Приведу пример: я хочу создать такой компонент который я буду кидать на объект и он будет крутиться. Т.е. есть куб, хочу чтоб он крутился и просто кидаю туда компонент RotatorComponent. И всё бы ничего, в таком виде это будет работать, но что если например я захочу менять параметр другого объекта, например цвет лампочки анимировать. В этом случае мне нужен доступ к компоненту Light а не к Actor-у. В текущей архитектуре для решения этой проблемы мне нужно указать ссылку на Actor(да, Акторы можно в поля указывать, а компоненты нельзя), и название компонента в виде строки, а в коде уже найти нужный компонент у Actor-а по названию(либо по типу, но если там несколько компонент внутри, то так не получится), что звучит очень плохо, потому что название можно поменять и всё сломается. Либо нужно создать еще один класс для конкретного объекта "лампочка с анимацией цвета". Хотя проще же просто кинуть компонент, и в любой момент удалить, либо заменить на другой тип анимации, переключение цвета по триггеру и т.д.
По моему такая архитектура лучше чем хардкод с зависимостями, которые сложно потом расширять.
-По поводу "в анриле всё из коробки работает отлично", это справедливо для всего что уже там есть. Но если нужно что-то поменять или добавить, я про расширение редактора. То это забей. Ну т.е. не всегда можно отдельный плагин прикрутить, иногда сам движок нужно менять. Это занятие не из приятных, а если еще на новую версию переходить, то тяжело поддерживать. В юнити многого нет, но там на много проще расширять редактор, и это будет работать и после обновы(за редким исключением).
-Проект делать дольше в анриле. К сожалению у меня нет достаточно инфы, могу лишь предположить что для проекта на анриле, если это не демка, а полноценная игра с графоном и разнообразным геймплеем, нужно ощутимо больше времени и более крутых чуваков в команде, а на юнити можно сделать графон чуть попроще, но быстрее. Т.е. создать клон уровня АА с юнити анрил будет дольше чем с анрила на юнити, но если это ААА, то на юнити возможно придется урезать графон или чуть дольше повозиться с оптимизацией.
-Ждать пока перебилдиться код в анриле нужно вечность. Код движка менять это долго, а потом нужно закомитить чтобы другие разрабы подцепили. Да, там есть hot reload, но он у меня криво работал, частенько вылетал. В юнити с этим на много лучше. Это наверное касается именно для тех кто меняет код, а для тех кто только в редакторе что-то делает, то анрил наверное шустрее.
Но опять же C++ vs C# думаю очевидно C# проще, но C++ быстрее. Писать блюпринтами думаю не серьезно. Быстрее кодом.
-Система контроля версий и анрил, это ад. Можно работать с ассетами только внутри движка. Я не могу нормально посмотреть какие изменения были в том файле того коммита. Ты просто обязан смириться с тем что есть. Да и плагин этот с багами. А нормальные не работают с анрилом. Поменял файл, и весь файл нужно комитить а не только измененный кусок, потому что бинарный. Не понимаю почему не сделают текстовый формат...
-Графон без сомнения шикарен и работает лучше чем юнити, но это на ПК. Когда мы доходим до мобилок, то все эти преимущества сразу исчезают. Приходится писать оптимизированные шейдеры/материалы всё так же как и на юнити.
-Если говорить про то что есть "из коробки": в юнити есть DOTS, а в анриле нет. Хотя и к анрилу можно что-то подобное подключить наверное. Не то чтобы DOTS это что-то незаменимое, но всё же.
Есть еще ML-Agents, а в анриле нет. Так же Unity Simulations, Build Server(хотя тут не уверен может и в анриле есть готовое решение).
-В юнити на много удобнее работать со связями между объектами. К слову в анриле нельзя свойствах объекта указать ссылку на компонент(свой или чужой). Это нужно делать через код, иначе никак. Не то чтобы это критично, тут вопрос к архитектуре движка, но всё же в юнити просто перетащил компонент в нужное поле в инспекторе и радуешься, меньше зависимостей в коде, хотя и этот подход не идеален.
Unreal не идеален, к сожалению. Пользоваться готовыми решениями легко, но редко когда хватает того что там уже есть и очень часто хочется расширить редактор, но из-за того что это сложно, проще просто забить и чуть страдать в замен на плюшки в виде Nanite, Lumen,...
Если проект на ПК и готовы смириться со сложностями выше(или у вас есть специально обученный человек по решению этих проблем), то смело юзайте анрил. Но если мобилки, а еще другие платформы, или игра которая не требует крутого графона, то на юнити будет проще, удобнее и быстрее даже с учетом его минусов.
Новичку сделать демку на анриле наверное будет проще. Но поработав в юнити с разными прикольными/полезными плагинами, анрил покажется не таким удобным.
Я сам после юнити страдал в анриле, потому что там не было всего того что было в юнити(в том числе мои плагины). И эти плюшки в виде быстродействия кода, красивого графона, не пересилили недостатки которые там есть по сравнению с юнити и я бросил анрил. Хотя хочется вернуться, залезть еще разок в исходники анрила и приблизить движок к идеалу :)
Думаю в статье имеется ввиду улучшение к примеру теней, освещения, детализации объектов за счёт уменьшения количества пикселей. Пиксели немного поломаются, но в сумме картинка будет лучше.
Я в полной тишине очень долго засыпаю(несколько часов). Сильно помогает включить на фоне видео с ютюба, где слышится монотонный разговор и под него засыпать. Музыка почему-то слабо помогает.
Пара вопросов:
1. Что думаете по поводу Bolt? На мой взгляд он лучше чем Playmaker и быстрее. Почему его не выбрали?
2. Почему решили перейти на Unity3d 2018.3 оставив поддержку старых версий? Учитывая что нет кодогенерации, и не используете напрямую компилятор Roslyn, вроде не проблема было писать на старой версии C#.
3. Как обстоят дела с производительностью? Как-то кешируете вызовы или каждый раз дергаете функции через Reflection?
Но теперь при загрузке или создании сцен, можно указать параметр(LocalPhysicsMode), который позволяет создать отдельный физический мир, независимо от основного. Объекты в этом новом мире существуют отдельно от основного, т.е. шарик из новой сцены не будет взаимодействовать с основным миром.
Но есть нюансы:
Они еще обновили PhysX, об этом забыли упомянуть в статье. Теперь можно симулировать физику для отдельных сцен. Это тоже важное обновление для синхронизации физических объектов в мультиплеерных играх.
Visual Effect Graph тоже очень классная штука, правда работает вроде как только в HDRP.
Добавлена поддержка C# 7.3 и оптимизировали рекомпиляцию отдельных файлов(Incremental C# Compiler теперь вроде как встроен по умолчанию).
Профайлер памяти, без этого раньше было тяжело находить утечку памяти.
В общем обновлений достаточно много и это всё полезные улучшения. В статье многое не описывается, советую почитать в блоге юнитеков.
Я не против туториалов и советов, но не стоит писать статью с советами после первой пробы.
Знающие люди не получили новой информации, а новички вряд ли поймут как решать эти проблемы, потому что Вы так и не написали как решить их, а просто пожаловались и предложили вариант как бы Вы хотели чтобы было удобно.
Все проблемы в статье решаемы, если почитать документацию и немного знать математику.
Не нужно ругаться на юнити, при изучении других технологий Вы наверняка тоже тратили время. Это нормально.
blogs.unity3d.com/ru/2018/11/12/physics-changes-in-unity-2018-3-beta