Эти методы работают при точном определении параметров камер. Но как откалибровать сами камеры? Ведь в реальности картинки искажены линзами(напр. эффект 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-ы существует не для оптимизаций и что шейдерный блок всё равно будет ждать другие блоки где условие сработало. Замеряли время рендера до и после?
Надо будет попробовать этот вариант, спасибо)
Я в полной тишине очень долго засыпаю(несколько часов). Сильно помогает включить на фоне видео с ютюба, где слышится монотонный разговор и под него засыпать. Музыка почему-то слабо помогает.
Да не, я просто спросил :)
С детства термин «миг» я понимал неправильно, вот и решил уточнить.
Если миг это не самая маленькая единица времени, то сколько проходит времени между двумя состояниями(кадрами) вселенной? Сиг занимает 30 колебаний электромагнитной волны атома цезия, а значит не минимальная единица.
Респект за проделанную работу, всё выглядит довольно хорошо! Правда название 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 теперь вроде как встроен по умолчанию).
Профайлер памяти, без этого раньше было тяжело находить утечку памяти.
В общем обновлений достаточно много и это всё полезные улучшения. В статье многое не описывается, советую почитать в блоге юнитеков.
Статья якобы дает советы, а по сути советы дают автору.
Я не против туториалов и советов, но не стоит писать статью с советами после первой пробы.
Знающие люди не получили новой информации, а новички вряд ли поймут как решать эти проблемы, потому что Вы так и не написали как решить их, а просто пожаловались и предложили вариант как бы Вы хотели чтобы было удобно.
Все проблемы в статье решаемы, если почитать документацию и немного знать математику.
Не нужно ругаться на юнити, при изучении других технологий Вы наверняка тоже тратили время. Это нормально.
Не хватает превью для удобства.
У медузы битая ссылка.
Эти методы работают при точном определении параметров камер. Но как откалибровать сами камеры?
Ведь в реальности картинки искажены линзами(напр. эффект 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,...
Если проект на ПК и готовы смириться со сложностями выше(или у вас есть специально обученный человек по решению этих проблем), то смело юзайте анрил. Но если мобилки, а еще другие платформы, или игра которая не требует крутого графона, то на юнити будет проще, удобнее и быстрее даже с учетом его минусов.
Новичку сделать демку на анриле наверное будет проще. Но поработав в юнити с разными прикольными/полезными плагинами, анрил покажется не таким удобным.
Я сам после юнити страдал в анриле, потому что там не было всего того что было в юнити(в том числе мои плагины). И эти плюшки в виде быстродействия кода, красивого графона, не пересилили недостатки которые там есть по сравнению с юнити и я бросил анрил. Хотя хочется вернуться, залезть еще разок в исходники анрила и приблизить движок к идеалу :)
Думаю в статье имеется ввиду улучшение к примеру теней, освещения, детализации объектов за счёт уменьшения количества пикселей. Пиксели немного поломаются, но в сумме картинка будет лучше.
Я в полной тишине очень долго засыпаю(несколько часов). Сильно помогает включить на фоне видео с ютюба, где слышится монотонный разговор и под него засыпать. Музыка почему-то слабо помогает.
С детства термин «миг» я понимал неправильно, вот и решил уточнить.
Если миг это не самая маленькая единица времени, то сколько проходит времени между двумя состояниями(кадрами) вселенной? Сиг занимает 30 колебаний электромагнитной волны атома цезия, а значит не минимальная единица.
Пара вопросов:
1. Что думаете по поводу Bolt? На мой взгляд он лучше чем Playmaker и быстрее. Почему его не выбрали?
2. Почему решили перейти на Unity3d 2018.3 оставив поддержку старых версий? Учитывая что нет кодогенерации, и не используете напрямую компилятор Roslyn, вроде не проблема было писать на старой версии C#.
3. Как обстоят дела с производительностью? Как-то кешируете вызовы или каждый раз дергаете функции через Reflection?
Но теперь при загрузке или создании сцен, можно указать параметр(LocalPhysicsMode), который позволяет создать отдельный физический мир, независимо от основного. Объекты в этом новом мире существуют отдельно от основного, т.е. шарик из новой сцены не будет взаимодействовать с основным миром.
Но есть нюансы:
Они еще обновили PhysX, об этом забыли упомянуть в статье. Теперь можно симулировать физику для отдельных сцен. Это тоже важное обновление для синхронизации физических объектов в мультиплеерных играх.
Visual Effect Graph тоже очень классная штука, правда работает вроде как только в HDRP.
Добавлена поддержка C# 7.3 и оптимизировали рекомпиляцию отдельных файлов(Incremental C# Compiler теперь вроде как встроен по умолчанию).
Профайлер памяти, без этого раньше было тяжело находить утечку памяти.
В общем обновлений достаточно много и это всё полезные улучшения. В статье многое не описывается, советую почитать в блоге юнитеков.
Я не против туториалов и советов, но не стоит писать статью с советами после первой пробы.
Знающие люди не получили новой информации, а новички вряд ли поймут как решать эти проблемы, потому что Вы так и не написали как решить их, а просто пожаловались и предложили вариант как бы Вы хотели чтобы было удобно.
Все проблемы в статье решаемы, если почитать документацию и немного знать математику.
Не нужно ругаться на юнити, при изучении других технологий Вы наверняка тоже тратили время. Это нормально.