Крутой видос. Хотелось бы больше видео про хороший чистый код. Очень понравился твой цикл видео про архитектуру. Будут еще в дальнейшем похожие видео? Про ECS например? Такого просто мало на ютубе
Спасибо. Но нет нужды использовать offset, Создаешь родительский объект для камеры, и в родительском объекте вешаешь Follower. И можешь позицию ребенка(Camera) менять как хочешь, и крутить как хочешь...
Тоже согласен про Cinemachine - очень мощный инструмент, сам его использую. Однако, цель видео была в том, чтобы пояснить - почему дергается, и как это исправить. И бонусом - то, как можно абстрагировать некоторые скрипты.
Для чего использовался Абстрактный класс? я правильно понимаю, чтобы его нельзя было использовать, а можно было только унаследовать, создав новый класс и при этом в новом классе все [Serializefield] переменные видны?
Да, его незачем вешать на объект, т.к. он не будет ничего делать. А вот наследники, уже работают, и наследуют всю логику, которую нет смысла повторять в наследниках
@@gamedevlavka Получается, в не абстрактном классе, мы так же наследуемся от этого класса и получаем по сути тот же функционал. Отличие у абстрактного класса только одно? То что в абстрактном классе есть так сказать некая "защита" от вмешательства в структуру этого класса, которая не должна меняться?
Да дёргается камера через lerp,хоть 0,001выставляй значение.непонятно почему даже в книжках написано использовать lerp,а на деле рывками всё.через movetowards такая же беда.возможно и будет плавно через лерп,если расстояния огромные,хотя куда уже.будем сами допирать как надо.
Если делать камеру, которая будет следовать за игроком в 3д от 3-го лица, лучше использовать просто апдейт, правильно? Из-за того, что скорость движения игрока и камеры тогда будут всегда одинаковы?
Привет!) А почему не через LateUpdate? Видел много раз рекомендации использовать его если движение происходит в Update. Еще по скрипту движения получается, что инпут в FixedUpdate происходит - не будет пролагов?
1. Да, лучше в LateUpdate, это я нормально так косякнул! Болезнь сказывается. Конечно, если движение в Update, то движение камеры лучше в LateUpdate, хотя и так дерганий не будет. 2. Инпут в Update, это можно увидеть в показано скрипте, в FixedUpdate инпут может проскакивать)
@@gamedevlavka А если персонаж движется через rigidbody? Вроде бы камера не будет работать в LateUpdate? Нужно чтоб и персонаж и камера были в FixedUpdate? Или как правильно сделать? Недавно тоже с этой проблемой столкнулся...
Может быть вы знаете, почему в юнити часто встречается лаг камеры? К примеру в игре Oddworld: Soulstorm, даже на PS5 видны фризы камеры срегулярной частотой(примерно раз в 0.3с).
Автору видео спасибо. Несколько дней страдал. Знал что можно написать както так, но не мог уловить. Есть ли на ютубе теги для вставки кода? От себя дополню. Чтоб скорелировать скорость камеры и цели надо в третем аргументе добавить деление на дистанцию. Так же добавил оффсет на направление (куда смотрит цель). private void MoveCamera() { targetPosition = player.transform.position; switch (csDirection.buferdirection) { case 0: targetPosition.y += offsetDir; break; case -90: targetPosition.x += offsetDir; break; case -180: targetPosition.y -= offsetDir; break; case 90: targetPosition.x -= offsetDir; break; } transform.position = Vector3.Lerp(transform.position, targetPosition, Time.fixedDeltaTime * smoothing / Vector2.Distance(transform.position, targetPosition)); positionZcamera = transform.position; positionZcamera.z = camZ; transform.position = positionZcamera; }
Спасибо! Но когда я все перенес в фикседАпдейт у меня наоборот начало лагать)))) но не так чтобы постоянно, а только первые 0.5 секунды при начале движения.
Не очень понял, как это fixupdate происходит чаще чем update, мне кажется особенно в данном примере, с такой простой схемой фпс больше 50, а именно с такой частотой вызывается фиксапдэйт
Андрей же дальше говорит, что не чаще, а просто работает с фиксированной частотой. Да и частота FixedUpdate настраиваемая. Можно хоть 100 раз в секунду настроить.
@@StratoCatster, даже после того как он исправился, он все равно говорит, что дерганья происходят из-за того, что в один апдейт персонаж мог продвинуться 2 раза, в другой 4 раза и поэтому происходят дерганья. Но мне как раз таки непонятно, почему происходят дерганья, если в данном примере апдейт происходит чаще чем фикс апдейт. То что частоту можно выставить хоть 100фпс это замечательно, но вопрос был про конкретный случай, почему тут происходят дерганья
Это работает и в обратную сторону: если фпс выше чем FixedUpdate, то может быть такое, что за один апдейт происходит 0.5 FixedUpdate (то есть объект не подвинется), а за другой - 1 (объект подвинется)
@@evgeniic потому что update происходит не равномерно, и разница во времени между двумя кадрами может быть существенной, поэтому смещение относительно update и фиксированного обновления fixedupdate точно будет различаться. Из за этого и дёрганья. Получается камера двигается в одном временном пространстве, а тело за котором следят в другом. И тут никакие time.deltaTime не помогут.
@Лавка Разработчика теперь понятно, я если честно думал, что в фикс апдейте только физика столкновений и сил просчитывается. Тоесть думал условно положение считается с другой частотой основываясь на скорости, которая не меняется на протяжении фиксдельтатайма, чтобы по сути картинка была максимально гладкой, а физику считать не приходилось.
![📏Предсказание траектории и симуляция физики [Unity 3D] [Tutorial]](http://i.ytimg.com/vi/zue7-KAnHkg/mqdefault.jpg)
Благодарю за хорошее объяснение!) Долго не мог понять причину дергания персонажа...
Крутой видос. Хотелось бы больше видео про хороший чистый код. Очень понравился твой цикл видео про архитектуру. Будут еще в дальнейшем похожие видео? Про ECS например? Такого просто мало на ютубе
Подробности о скрипте персонажа конечно очень нужны!)
Моё почтение за твои уроки! Топчик!
Перемещение камеры по правилам Unity должно выполняться в LateUpdate()
Большое спасибо за урок, очень интересно
Отличное видео, большое спасибо!
Ура, новое видео!
Блин, классный код!🙂
Класс. Спасибо.
Пасиб очень помог)
Спасибо очень круто. А то мне приходилось увеличивать speed до 1000 чтобы камера не дергалась. ))))
Спасибо.
Но нет нужды использовать offset,
Создаешь родительский объект для камеры, и в родительском объекте вешаешь Follower.
И можешь позицию ребенка(Camera) менять как хочешь, и крутить как хочешь...
Да, можно сделать так, хороший вариант👍
Как по мне лучше использовать cinemachine, там все есть из коробки, плюс переключение камер для катсцен.
Согласен про CineMachine. Но шарик фолловер тут получился весьма неплохо.
Тоже согласен про Cinemachine - очень мощный инструмент, сам его использую. Однако, цель видео была в том, чтобы пояснить - почему дергается, и как это исправить. И бонусом - то, как можно абстрагировать некоторые скрипты.
@@gamedevlavka тогда не показали еще один вариант исправления, а именно включение интерполяции в rigidbody
Согласен, продвигайте коммент. Раньше не знал что можно использовать, одни проблемы. Поддерживается как 2д, так и 3д
@@gamedevlavka Ну так, камеру лучше перемещать в LateUpdate, так как он вызывается после Update и дергания пропадают
Еще можно затронуть тему smoothDamp
Эх... вот бы увидеть видео на темы TextMesh Pro, Zenject, NavMesh, Vuforia, Netcode от Андрея.... красота была бы....😋
Записал в блокнотик)
Для чего использовался Абстрактный класс? я правильно понимаю, чтобы его нельзя было использовать, а можно было только унаследовать, создав новый класс и при этом в новом классе все [Serializefield] переменные видны?
Да, его незачем вешать на объект, т.к. он не будет ничего делать. А вот наследники, уже работают, и наследуют всю логику, которую нет смысла повторять в наследниках
@@gamedevlavka Получается, в не абстрактном классе, мы так же наследуемся от этого класса и получаем по сути тот же функционал. Отличие у абстрактного класса только одно? То что в абстрактном классе есть так сказать некая "защита" от вмешательства в структуру этого класса, которая не должна меняться?
Да дёргается камера через lerp,хоть 0,001выставляй значение.непонятно почему даже в книжках написано использовать lerp,а на деле рывками всё.через movetowards такая же беда.возможно и будет плавно через лерп,если расстояния огромные,хотя куда уже.будем сами допирать как надо.
Если делать камеру, которая будет следовать за игроком в 3д от 3-го лица, лучше использовать просто апдейт, правильно? Из-за того, что скорость движения игрока и камеры тогда будут всегда одинаковы?
Лучше бы рассказали что существует Cinemachine и показа ли бы как его простенько настроить
Привет!) А почему не через LateUpdate? Видел много раз рекомендации использовать его если движение происходит в Update.
Еще по скрипту движения получается, что инпут в FixedUpdate происходит - не будет пролагов?
1. Да, лучше в LateUpdate, это я нормально так косякнул! Болезнь сказывается. Конечно, если движение в Update, то движение камеры лучше в LateUpdate, хотя и так дерганий не будет.
2. Инпут в Update, это можно увидеть в показано скрипте, в FixedUpdate инпут может проскакивать)
@@gamedevlavka я вроде видел в методе Move переменную direction, которая принимает Input.GetAxis =P
А метод Move в FixedUpdate крутится)
@@gamedevlavka А если персонаж движется через rigidbody? Вроде бы камера не будет работать в LateUpdate? Нужно чтоб и персонаж и камера были в FixedUpdate? Или как правильно сделать? Недавно тоже с этой проблемой столкнулся...
Ну если камера по иерархии ниже персонажа, можно и в апдейт
0:33 Очень очень хотим Обяснение.
Кстати чем отличается Public от Protected
public доступен снаружи класса, protected - внутри и в дочерних классах, а private - только внутри конкретного класса
@@gamedevlavka Дякую. Зразу питання: "Чи можеш записати відео про систему статусу (Stat System), і після про Editor Window , буду дуже вдячний"
пока
У меня всё ещё осталось дёргание. Какие могут быть ещё причины? Я использую HDRP и пакет Invector-3 из стора
Пообщались с Артёмом личке. Как выяснилось, проект битый. Создание нового и перенос ассетов из старого помогло. Возможно, хватило бы чистки Library.
у меня после начала игры прохидит секунд 10 и камера показывает только бг. Хотя во вкладке Scene всё нормально
Может быть вы знаете, почему в юнити часто встречается лаг камеры? К примеру в игре Oddworld: Soulstorm, даже на PS5 видны фризы камеры срегулярной частотой(примерно раз в 0.3с).
Автору видео спасибо. Несколько дней страдал. Знал что можно написать както так, но не мог уловить. Есть ли на ютубе теги для вставки кода?
От себя дополню. Чтоб скорелировать скорость камеры и цели надо в третем аргументе добавить деление на дистанцию. Так же добавил оффсет на направление (куда смотрит цель).
private void MoveCamera()
{
targetPosition = player.transform.position;
switch (csDirection.buferdirection)
{
case 0:
targetPosition.y += offsetDir;
break;
case -90:
targetPosition.x += offsetDir;
break;
case -180:
targetPosition.y -= offsetDir;
break;
case 90:
targetPosition.x -= offsetDir;
break;
}
transform.position = Vector3.Lerp(transform.position, targetPosition, Time.fixedDeltaTime * smoothing / Vector2.Distance(transform.position, targetPosition));
positionZcamera = transform.position;
positionZcamera.z = camZ;
transform.position = positionZcamera;
}
Сделай урок со скриптом управления таким персонажем. Пожалуйста)
Будет)
Спасибо! Но когда я все перенес в фикседАпдейт у меня наоборот начало лагать)))) но не так чтобы постоянно, а только первые 0.5 секунды при начале движения.
Привет, запиши новое видео по пулам using UnityEngine.Pool;
+ Пулинг нужная тема
Не очень понял, как это fixupdate происходит чаще чем update, мне кажется особенно в данном примере, с такой простой схемой фпс больше 50, а именно с такой частотой вызывается фиксапдэйт
Андрей же дальше говорит, что не чаще, а просто работает с фиксированной частотой.
Да и частота FixedUpdate настраиваемая. Можно хоть 100 раз в секунду настроить.
@@StratoCatster, даже после того как он исправился, он все равно говорит, что дерганья происходят из-за того, что в один апдейт персонаж мог продвинуться 2 раза, в другой 4 раза и поэтому происходят дерганья. Но мне как раз таки непонятно, почему происходят дерганья, если в данном примере апдейт происходит чаще чем фикс апдейт. То что частоту можно выставить хоть 100фпс это замечательно, но вопрос был про конкретный случай, почему тут происходят дерганья
Это работает и в обратную сторону:
если фпс выше чем FixedUpdate, то может быть такое, что за один апдейт происходит 0.5 FixedUpdate (то есть объект не подвинется), а за другой - 1 (объект подвинется)
@@evgeniic потому что update происходит не равномерно, и разница во времени между двумя кадрами может быть существенной, поэтому смещение относительно update и фиксированного обновления fixedupdate точно будет различаться. Из за этого и дёрганья.
Получается камера двигается в одном временном пространстве, а тело за котором следят в другом. И тут никакие time.deltaTime не помогут.
@Лавка Разработчика теперь понятно, я если честно думал, что в фикс апдейте только физика столкновений и сил просчитывается. Тоесть думал условно положение считается с другой частотой основываясь на скорости, которая не меняется на протяжении фиксдельтатайма, чтобы по сути картинка была максимально гладкой, а физику считать не приходилось.
offset . Я не то что бы придираюсь, но хочется поправить
Очень растянутый урок. Это можно в три минуты сжать.