Вы каждый тик обновляете значение прогресс бара, даже тогда, когда изменений - нет. Сделайте простой свич для обхода вычислений если изменений не произошло.
Lerp по тику плох тем, что он не компенсирует частоту кадров. У людей в с FPS 120 этот переход будет в 4 раза быстрее чем у людей с FPS 30. Хорошо если вы делаете это для однопользовательской игры, или в части которая не влияет на мультиплеер. (FInterp как раз для этого требудет Delta)
лучше уж тогда Action и UI подписать на изменение параметра. Ну и можно ж сделать шаг, ака Time.deltatime в Юнити, что по идее должно скомпенсировать разность фпс, в анриале должно быть так же. ну и вообще функций кривых много, и под каждые визуальные задачи можно найти свой изинг анимации вот как пример. http://easings.net/ru
Я в свое время тоже столкнулся с подобной задачей. Но я сделал проще хотя и костыльно. Когда происходило изменение параметра, я вызывал макрос и передавал значение к которому надо придти. В макросе циклично прибавлялся прогресс с шагом в 0.005 и delay'ем в 0.01. Таким образом можно контролировать плавность и скорость заполнения, и не приходится запрашивать значение параметра на каждом тике.
Очень странно, что эта задача вызывает проблемы, в свое время кучу баров написал. Обычно под такие штуки создается кривая безье, которая настраивается аниматорами по их прихоти. Кривая лежит в 2д пространстве. x - время, y - значение. Эта кривая и используется для контроля заполнения бара. Отскоки, ускорения, замедления все что душе угодно. Либо используется твиновый движок, с готовыми анимационными функциями, например dot tween.
Тут же речь идёт не об отображении текущего значения, а о твининге между предыдущим и будущим положениями. Если вы предлагаете Function Bind и в нём делать расчёт то это ещё хуже чем делать его по тику. Т.к. бинд опрашивается 1-2 раза за тик.
Смысл в том, что надо менять значение плавно, в прогресс баре. Просто бинд тут не поможет, т.к. он будет менять значение по факту изменения, а делать плавные изменения параметров в игровой механике ради визуала ну так себе идея, ИМХО. В целом, представленные советы считаю полезными в купе с советами Alexey Mak.
Типа того, хотя есть принципиальное различие в системе ивентов, которое очень сильно меняет ту элегантную основу, которую предлагает Reigns. Пока мучаюсь с тем, что придумала, клон всегда успею сделать)
Вы каждый тик обновляете значение прогресс бара, даже тогда, когда изменений - нет. Сделайте простой свич для обхода вычислений если изменений не произошло.
Lerp по тику плох тем, что он не компенсирует частоту кадров. У людей в с FPS 120 этот переход будет в 4 раза быстрее чем у людей с FPS 30. Хорошо если вы делаете это для однопользовательской игры, или в части которая не влияет на мультиплеер. (FInterp как раз для этого требудет Delta)
лучше уж тогда Action и UI подписать на изменение параметра.
Ну и можно ж сделать шаг, ака Time.deltatime в Юнити, что по идее должно скомпенсировать разность фпс, в анриале должно быть так же.
ну и вообще функций кривых много, и под каждые визуальные задачи можно найти свой изинг анимации вот как пример.
http://easings.net/ru
Да, это не для мультиплеера.
О том, о чем вы рассказывает, я не думала. Спасибо большое за эту информацию)
Эти проблемы решается через СОП и линейную интерполяцию на основе дельты времени
Плюшевое гауссово распределение - это супер! :)
Привет. Спасибо за текст. Чутка отредактировали и перетащили в Gamedev. Если что-то поправить захотите — пишите.
Спасибо большое)
Я в свое время тоже столкнулся с подобной задачей. Но я сделал проще хотя и костыльно. Когда происходило изменение параметра, я вызывал макрос и передавал значение к которому надо придти. В макросе циклично прибавлялся прогресс с шагом в 0.005 и delay'ем в 0.01. Таким образом можно контролировать плавность и скорость заполнения, и не приходится запрашивать значение параметра на каждом тике.
Очень странно, что эта задача вызывает проблемы, в свое время кучу баров написал. Обычно под такие штуки создается кривая безье, которая настраивается аниматорами по их прихоти. Кривая лежит в 2д пространстве. x - время, y - значение. Эта кривая и используется для контроля заполнения бара. Отскоки, ускорения, замедления все что душе угодно. Либо используется твиновый движок, с готовыми анимационными функциями, например dot tween.
Lerp? А не проще ли было в progress bar создать бинд и привязать к ней переменную Money и тд.
https://docs.unrealengine.com/latest/INT/Engine/UMG/UserGuide/PropertyBinding/index.html
Тут же речь идёт не об отображении текущего значения, а о твининге между предыдущим и будущим положениями.
Если вы предлагаете Function Bind и в нём делать расчёт то это ещё хуже чем делать его по тику. Т.к. бинд опрашивается 1-2 раза за тик.
Смысл в том, что надо менять значение плавно, в прогресс баре. Просто бинд тут не поможет, т.к. он будет менять значение по факту изменения, а делать плавные изменения параметров в игровой механике ради визуала ну так себе идея, ИМХО. В целом, представленные советы считаю полезными в купе с советами Alexey Mak.
Moral(e). Спасибо, извините, глаз режет.
После прототипирования, всё вычитаю и исправлю. Извините за порезанные глаза :3 это непредумышленно.
Reigns: Unknown Project делаете?)
Типа того, хотя есть принципиальное различие в системе ивентов, которое очень сильно меняет ту элегантную основу, которую предлагает Reigns.
Пока мучаюсь с тем, что придумала, клон всегда успею сделать)
Чтобы закрыть вопрос
http://www.gizma.com/easing/