Раньше, когда ещё можно было обращаться напрямую к rigidbody вот так
Код
rigidbody.velocity = new Vector(1,1,0);
разработчики юнити, говорили, что надо кэшировать transform, то есть писать на старте
Код
MyTransform = transform;
иначе доступ к transform.position был медленнее, чем MyTransform.position (почему-то)
Но в новых версиях избавились вроде от лишнего мусора, и теперь к rigidbody нужно обращаться как к компоненту, через GetComponent, но я до сих пор кэширую по привычке transform, мой код выглядит примерно так:
Код
Transform trans; void Start() { trans = transform; } void Update() { trans.position = new Vector3(1,1,0); }
Стоит ли кэшировать Transform теперь, ведь скорее всего код юнити давно претерпел какие-то критические изменения?!
PS А я только сейчас об этом задумался, лол)
Сообщение отредактировал alexsilent - Четверг, 11 Октября 2018, 18:47
Да, досих пор имеет смысл кешировать трансформ как и в общем любой компонент юнити и вообще обращаться к ним как можно реже. Кешировать будет иметь смысл всегда в виду того что обращение к трансформу идет через нейтив код ( тоесть идет обращение из managed C# в C++ ) - это всегда издержка.
Это справедливо только если мягко говоря у тебя очень много обращений к трансформу. Очень много это тысячи обращений в кадр : )
Я например делаю класс Monocached : Monobehavior - и там пишу selfTransform. Все мои классы уже наследуются от Monocached. Ну это если следовать по ООП )
PS - гораздо страшнее Time.DeltaTime XDD
Код
public void Tick() { delta = Time.DeltaTime; for (int i = 0; i < groupMove.length; i++) { var dMove = groupMove.component[i]; var body = dMove.transform; var v = body.position; v.x += dMove.nextStep.x; v.y += dMove.nextStep.y; v.z += dMove.nextStep.z; body.position = v; body.rotation = dMove.nextRotation; } }
обычно как то так выношу дельту ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 11 Октября 2018, 18:59
По-моему это оптимизация из того же ряда что sqrMagnitude вместо нормального расстояния или избегание if в шейдерах На современных компах увеличивает производительность примерно на 0.000001%
Сообщение отредактировал drcrack - Четверг, 11 Октября 2018, 21:47
public class ProcessingMove : ProcessingBase, ITick { public Group<DataMove> groupMove; public Group<DataTorque> groupTorque;
private float delta;
public ProcessingMove() { Timing.RunCoroutine(_Tick()); }
public IEnumerator<float> _Tick() { while (true) { for (int i = 0; i < groupMove.length; i++) { var dMove = groupMove.component[i]; dMove.nextRotation = dMove.transform.rotation; }
yield return Threading.SwitchToExternalThread(); for (int i = 0; i < groupMove.length; i++) { var dMove = groupMove.component[i]; var speed = Maths.Min(dMove.speed += dMove.acceleration * delta, dMove.template.speed)*delta; var pos = dMove.nextRotation * new Vector3(0.0f, 1f, 0.0f);
public void Tick() { delta = Time.DeltaTime; for (int i = 0; i < groupMove.length; i++) { var dMove = groupMove.component[i]; var body = dMove.transform; var v = body.position; v.x += dMove.nextStep.x; v.y += dMove.nextStep.y; v.z += dMove.nextStep.z; body.position = v; body.rotation = dMove.nextRotation; }
Согласен с drcrack в том что это все микрооптимизации. Они имеют смысл только при очень частом использовании и это редкие случаи. Если в игре от силы сотня сущностей одновременно что-то делают ( что в общем то не мало ) - то смысла в этом нет + дело вкуса. Например я получил уже магнитуду вектора, а потом мне где-то дальше по методу потребовалось его нормализовать. Если использовать юнитивский метод нормалайз то можно увидеть что внутри он опять таки считает магнитуду. Зачем мне это делать повторно если я уже провел эту операцию? : ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 12 Октября 2018, 10:03
Зачем мне это делать повторно если я уже провел эту операцию? : )
с другой стороны, зачем писать лишний код, ухудшая читаемость и повышая риск допустить ошибки при рефакторинге?.. лучше наоборот весь часто используемый бойлерплейт вынести в расширения/в методы базового класса/в статический класс/еще куда-то, лишь бы не писать это каждый раз все-таки ты игру будешь не на бобине крутить, современное железо такие оптимизации даже не заметит в большинстве случаев
Код
var v = body.position; v.x += dMove.nextStep.x; v.y += dMove.nextStep.y; v.z += dMove.nextStep.z; body.position = v;
так, а это что
Сообщение отредактировал drcrack - Пятница, 12 Октября 2018, 06:14
с другой стороны, зачем писать лишний код, ухудшая читаемость и повышая риск допустить ошибки при рефакторинге?.. лучше наоборот весь часто используемый бойлерплейт вынести в расширения/в методы базового класса/в статический класс/еще куда-то, лишь бы не писать это каждый раз
Ну так и есть, опять таки - все эти магнитуды, расчеты углов и прочую муть можно вынести в свои библиотеки. Как по мне вызов рассчета магнитуд два раза и есть лишний код : )
Цитатаdrcrack ()
так, а это что crazy :D
Ты этого не видел XDD, рудиментарный код, можно отрефакторить XD ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Мне хочется попробовать сделать игру из разряда they are billions с большим кол-вом ВСЕГО на экране : ) На скринах 2500 истребителей нападают на базу игрока.
Ну как по мне экономия ~100 фпс существенна. Я могу их использовать где-то еще. Это безу учета того что АИ обрабатывался все равно в системе ( поиск цели, расчеты, выбор поведения ) - если и аи вынести в апдейты то фпс бы дропнулся еще больше.
Насчет современных компов - я вижу моду на miniITX, которые часто собирают не оч мощными. Для инди опять таки сейчас хорошая платформа- nintendo switch, далеко не самая мощная машина. В общем если есть возможность на чем то экономить и это не мешает работе ( реально, код что я выше показал не настолько сложен, жуток или неудобен) - то почему бы и нет. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 12 Октября 2018, 11:31
лишь бы не писать это каждый раз все-таки ты игру будешь не на бобине крутить, современное железо такие оптимизации даже не заметит в большинстве случаев
Одно из убеждений, результатом применения которого является сложившийся стереотип о том, что игры на юнити тормозные. Все эти микрооптимизации в итоге и приводят к искомым улучшениям производительности, создающим комфортный и плавный геймплей в играх. И всё-таки да, гораздо чаще важнее читабельность кода и порой даже скорость его создания (в конце концов, всегда можно зарефакторить), нежели -0.01 мс к результату.
Одно из убеждений, результатом применения которого является сложившийся стереотип о том, что игры на юнити тормозные.
Куда большей проблемой является отсутствие нормальной архитектуры на 99% проектов, речь не только о Unity, а в принципе о любых проектах. В определенный момент все скатывается к невероятному числу обращений за кадр к, хорошо если несколькоим, а то и одному классу и тут уже далеко не до микрооптимизации. Просто тут можно пойти дальше и начать оптимизировать цикла в стиле заменить < на !=, работать с приоретизацией операторов и заниматься разными другими сомнительными вещами. Однако, про архитектуру забывать нельзя никогда, это фундамент, как никак, и тогда все будет отлично и без едва заметных микрооптимизаций (и я сейчас действительно говорю о микро и низкоуровневых оптимизациях, шейдера с несколькими проходами и тьмой условий сюда не входят, но это уже не тема разговора). Backend Developer ESIS Client Side Developer Room8Studio Technical Leader Lucid Reality Labs Chief Technology Officer The Intruders