Есть же возможность пускать райкасты в каждом кадре на ограниченное расстояние. Которое вычислить как паролетаемое полей за кадр. Итого, и райкаст проверяет столкновение и визуальная физика не страдает. А ещё можно сделать вот так RaycastHit hit; if (Physics.Linecast(previousPosition, newPosition, out hit, hitLayers)) { Здесь Physics.Linecast используется для определения, произошло ли столкновение между предыдущей и текущей позицией пули.
Проверь профилировщиком загрузку цп, частый просчёт рэйкаста может прилично загрузить сцену. Как альтернатива, сделать rigit body у пули длинной в 2 метра, а визуальный меш короткий, обычный. Т.е. получается ты метаешь невидимое копьё со шкуркой пули и в каким то из кадров 100% будет пересечение с поверхностью.
Хорошо, со стеной у тебя всё работает, но что по поводу врагов? Смоделируем ситуацию: Ты выстреливаешь в бегущего врага. Перед выстрелом рейкаст попадает во врага и передает startPoint и endPoint пуле. Затем, когда пуля долетает до endPoint, враг уже успел убежать => тоесть пуля не зарегистрирует врага Я чего то не догоняю?
Так и есть , у оружия надо лишь в стены попадать , но мы сделаем ещё проще , будем передавать пуле стартовую позицию , а конечная точка будет стартовая позиция + стартовая позиция.forward * 500f и даже рейкаст не нужен первый. Он у оружия остался так как стрельба до этого была при помощи обычного рейкаста)
@@DILLINGER_PUPS Ну я полагаю тогда можно обойтись без корутин. Если мы в пуле в старте пропишем Destroy(gameObject, 5f); А в Update будем просто передвигать пулю при помощи transform.Translate(transform.forward * speed * Time.deltaTime); Ну и там же делать проверку рейкастом Я полагаю эффект будет тот же)
А зачем вообще заранее конечную позицию определять? Достаточно же просто направления выстрела пули, и в этом направлении с постоянной скоростью мы ее перемещаем.
Bullet bulletC = Instantiate(bullet, _shootPosition.position, _shootPosition.Ratation).GetComponent(); а теперь представьте у вас миниган с 6000 выстрелов в минуту т е 100 выстрелов в секунду и например их в игре 5 одновременно. Что будет с игрой на телефоне кто угадает?
Слишком много "если" , "может" , "наверное". Все выбирают тот способ который им в данной ситуации подходит , для такой стрельбы которую ты "Представил" - никакой способ кроме обычных рейкастов и парочки спецэффектов которые имитируют такой массивный огонь не подойдёт. Таким образом можно хоть миллиард выстрелов в минуту представить , а толку? Если нигде такого нету , а реализацию стрельбы каждый выбирает исходя из ситуации. Моим методом можно сделать какой-либо рогалик , снайпера или что-то типо того.
@@flugenkehhannen под капотом unity берет такой же get component при передаче аргументом что-то отличное от gameObject. Это можно проверить самостоятельно. Заспавнить 1000000 game object, а потом взять компонент, сразу заспавнить "компонент". Разница будет во времени обращения к нативному коду * на количество итераций * на издержеку вызова метода.
Стараюсь , но пока выходит скверно , скорей всего в с следующих роликах начну эту шляпу править редактированием вручную, пока не избавлюсь от этой привычки.
Да нормально он все произносит. Тут тебе не филологический кружок. Можно поставить скорость на 1.5 и вообще незаметно будет. Автор, лучше почаще выпускай такие видосы, и не слушай всяких доморощенных филологов. А дикция сама со временем натренируется. А шляпа, это такие комменты, которые сбивают с цели и вместо полезного контента заставляют заниматься ненужными правками. Для настоящих фанатов игр содержание всегда намного важнее формы
9:30 - ахахаах, вынесло с этого момента xD
Но видос всё равно полезный, спасибо
Я ж сказал заранее) - ступор мозговины иногда ловлю. Написать написал, пока тяжеловато с объяснением)
@@DILLINGER_PUPS ахахаха
Есть же возможность пускать райкасты в каждом кадре на ограниченное расстояние.
Которое вычислить как паролетаемое полей за кадр.
Итого, и райкаст проверяет столкновение и визуальная физика не страдает.
А ещё можно сделать вот так
RaycastHit hit;
if (Physics.Linecast(previousPosition, newPosition, out hit, hitLayers))
{
Здесь Physics.Linecast используется для определения, произошло ли столкновение между предыдущей и текущей позицией пули.
Видео с исправлением всех ошибок данной реализации уже есть на канале)
Каеф, вот это магия! Спасибо! а мона еще вот такихвота прикольных механик!!))
Мона)
Не знал, что есть компонент trail render. Хорошая реализация визуала пули. Спасибо за видос
В целом очень даже годная реализация, хорошее видео.
Шикарный видос, все понятно и доходчиво🎉
Отличный видос, удачи тебе в продвижение 👍
Проверь профилировщиком загрузку цп, частый просчёт рэйкаста может прилично загрузить сцену. Как альтернатива, сделать rigit body у пули длинной в 2 метра, а визуальный меш короткий, обычный. Т.е. получается ты метаешь невидимое копьё со шкуркой пули и в каким то из кадров 100% будет пересечение с поверхностью.
Круто, контент в кайф
Офигенный ролик,Сделай пожалуйста инвентарь в юнити:)
Поддерживаю идею с инвентарём
Видео же есть на канале : ua-cam.com/video/AuO43-Lyrf4/v-deo.html
чувак ты гений
само видео как гайд, зачетное. + тебе в карму. но есть вопрос, - Что за точка попадения?
Это называется - безграмотность)
0:58 совет исплзуй 100% екрана
Скрипты из урока t.me/unity_assets_free_main/1819
У тебя сейчас от fps завист как далеко пролетит пуля + лучше использовать лайнкаст и лайнить предыдущую позицию и текущую
Как называется редактор из видео?
попадАние, бро :D
Хорошо, со стеной у тебя всё работает, но что по поводу врагов?
Смоделируем ситуацию:
Ты выстреливаешь в бегущего врага. Перед выстрелом рейкаст попадает во врага и передает startPoint и endPoint пуле. Затем, когда пуля долетает до endPoint, враг уже успел убежать => тоесть пуля не зарегистрирует врага
Я чего то не догоняю?
Забыл про эту условность в данном ролике , в следующем ролике про улучшение стрельбы поясню за это.
@@DILLINGER_PUPS Я бы предложил первым рейкастом проверять только объекты на определенном слое, которые точно не будут двигаться (стены например)
Так и есть , у оружия надо лишь в стены попадать , но мы сделаем ещё проще , будем передавать пуле стартовую позицию , а конечная точка будет стартовая позиция + стартовая позиция.forward * 500f и даже рейкаст не нужен первый. Он у оружия остался так как стрельба до этого была при помощи обычного рейкаста)
@@DILLINGER_PUPS Ну я полагаю тогда можно обойтись без корутин. Если мы в пуле в старте пропишем Destroy(gameObject, 5f);
А в Update будем просто передвигать пулю при помощи transform.Translate(transform.forward * speed * Time.deltaTime);
Ну и там же делать проверку рейкастом
Я полагаю эффект будет тот же)
А зачем вообще заранее конечную позицию определять? Достаточно же просто направления выстрела пули, и в этом направлении с постоянной скоростью мы ее перемещаем.
Зачем нужен тернарный оператор в 26 строчке?
Гарантия того что не будет NullReference Exception
Bullet bulletC = Instantiate(bullet, _shootPosition.position, _shootPosition.Ratation).GetComponent(); а теперь представьте у вас миниган с 6000 выстрелов в минуту т е 100 выстрелов в секунду и например их в игре 5 одновременно. Что будет с игрой на телефоне кто угадает?
Слишком много "если" , "может" , "наверное". Все выбирают тот способ который им в данной ситуации подходит , для такой стрельбы которую ты "Представил" - никакой способ кроме обычных рейкастов и парочки спецэффектов которые имитируют такой массивный огонь не подойдёт. Таким образом можно хоть миллиард выстрелов в минуту представить , а толку? Если нигде такого нету , а реализацию стрельбы каждый выбирает исходя из ситуации. Моим методом можно сделать какой-либо рогалик , снайпера или что-то типо того.
Блин чувак, если ты не понимаешь, почему не надо делать GetComponent каждый выстрел, то сорян. Для справки - ты можешь спавнить не только Gameobject.
@@flugenkehhannen под капотом unity берет такой же get component при передаче аргументом что-то отличное от gameObject. Это можно проверить самостоятельно. Заспавнить 1000000 game object, а потом взять компонент, сразу заспавнить "компонент". Разница будет во времени обращения к нативному коду * на количество итераций * на издержеку вызова метода.
Извинитесь, пожалуйста поработайте над своей речью, что бы когда думаете не произносить звук (э), спасибо
Стараюсь , но пока выходит скверно , скорей всего в с следующих роликах начну эту шляпу править редактированием вручную, пока не избавлюсь от этой привычки.
Да нормально он все произносит. Тут тебе не филологический кружок. Можно поставить скорость на 1.5 и вообще незаметно будет. Автор, лучше почаще выпускай такие видосы, и не слушай всяких доморощенных филологов. А дикция сама со временем натренируется.
А шляпа, это такие комменты, которые сбивают с цели и вместо полезного контента заставляют заниматься ненужными правками. Для настоящих фанатов игр содержание всегда намного важнее формы
Полностью поддерживаю коммент Артура