Раньше, когда ещё можно было обращаться напрямую к 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 Chief Technology Officer RoyalePlay Games