Воскресенье, 24 Ноября 2024, 10:32

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 1
  • 1
кэширование Transform в 2018-м
alexsilentДата: Четверг, 11 Октября 2018, 18:42 | Сообщение # 1
почти ветеран
Сейчас нет на сайте
Раньше, когда ещё можно было обращаться напрямую к 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
pixeyeДата: Четверг, 11 Октября 2018, 18:56 | Сообщение # 2
Red Winter Software
Сейчас нет на сайте
Да, досих пор имеет смысл кешировать трансформ как и в общем любой компонент юнити и вообще обращаться к ним как можно реже. Кешировать будет иметь смысл всегда в виду того что обращение к трансформу идет через нейтив код ( тоесть идет обращение из 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
WiteДата: Четверг, 11 Октября 2018, 18:58 | Сообщение # 3
постоянный участник
Сейчас нет на сайте
Вроде как была статья что они его теперь сами кэшируют но все равно советуют кэшировать blink
seamanДата: Четверг, 11 Октября 2018, 20:46 | Сообщение # 4
старожил
Сейчас нет на сайте
Цитата
обычно как то так выношу дельту )

В коде она вообще не используется...
drcrackДата: Четверг, 11 Октября 2018, 21:45 | Сообщение # 5
старожил
Сейчас нет на сайте
По-моему это оптимизация из того же ряда что sqrMagnitude вместо нормального расстояния или избегание if в шейдерах
На современных компах увеличивает производительность примерно на 0.000001%


Сообщение отредактировал drcrack - Четверг, 11 Октября 2018, 21:47
pixeyeДата: Пятница, 12 Октября 2018, 00:20 | Сообщение # 6
Red Winter Software
Сейчас нет на сайте
Цитата seaman ()
В коде она вообще не используется...


если ты так настаиваешь


Согласен с drcrack в том что это все микрооптимизации. Они имеют смысл только при очень частом использовании и это редкие случаи. Если в игре от силы сотня сущностей одновременно что-то делают ( что в общем то не мало ) - то смысла в этом нет + дело вкуса. Например я получил уже магнитуду вектора, а потом мне где-то дальше по методу потребовалось его нормализовать. Если использовать юнитивский метод нормалайз то можно увидеть что внутри он опять таки считает магнитуду. Зачем мне это делать повторно если я уже провел эту операцию? : )


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю



Сообщение отредактировал pixeye - Пятница, 12 Октября 2018, 10:03
drcrackДата: Пятница, 12 Октября 2018, 06:10 | Сообщение # 7
старожил
Сейчас нет на сайте
Цитата
Зачем мне это делать повторно если я уже провел эту операцию? : )

с другой стороны, зачем писать лишний код, ухудшая читаемость и повышая риск допустить ошибки при рефакторинге?..
лучше наоборот весь часто используемый бойлерплейт вынести в расширения/в методы базового класса/в статический класс/еще куда-то, лишь бы не писать это каждый раз
все-таки ты игру будешь не на бобине крутить, современное железо такие оптимизации даже не заметит в большинстве случаев

Код
var  v = body.position;
v.x += dMove.nextStep.x;
v.y += dMove.nextStep.y;
v.z += dMove.nextStep.z;
body.position = v;

так, а это что crazy :D


Сообщение отредактировал drcrack - Пятница, 12 Октября 2018, 06:14
pixeyeДата: Пятница, 12 Октября 2018, 11:01 | Сообщение # 8
Red Winter Software
Сейчас нет на сайте
Цитата drcrack ()
с другой стороны, зачем писать лишний код, ухудшая читаемость и повышая риск допустить ошибки при рефакторинге?..
лучше наоборот весь часто используемый бойлерплейт вынести в расширения/в методы базового класса/в статический класс/еще куда-то, лишь бы не писать это каждый раз


Ну так и есть, опять таки - все эти магнитуды, расчеты углов и прочую муть можно вынести в свои библиотеки. Как по мне вызов рассчета магнитуд два раза и есть лишний код : )

Цитата drcrack ()
так, а это что crazy :D

Ты этого не видел XDD, рудиментарный код, можно отрефакторить XD


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

pixeyeДата: Пятница, 12 Октября 2018, 11:07 | Сообщение # 9
Red Winter Software
Сейчас нет на сайте
Мне хочется попробовать сделать игру из разряда they are billions с большим кол-вом ВСЕГО на экране : )
На скринах 2500 истребителей нападают на базу игрока.






Ну как по мне экономия ~100 фпс существенна. Я могу их использовать где-то еще. Это безу учета того что АИ обрабатывался все равно в системе ( поиск цели, расчеты, выбор поведения ) - если и аи вынести в апдейты то фпс бы дропнулся еще больше.

Насчет современных компов - я вижу моду на miniITX, которые часто собирают не оч мощными. Для инди опять таки сейчас хорошая платформа- nintendo switch, далеко не самая мощная машина. В общем если есть возможность на чем то экономить и это не мешает работе ( реально, код что я выше показал не настолько сложен, жуток или неудобен) - то почему бы и нет.


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю



Сообщение отредактировал pixeye - Пятница, 12 Октября 2018, 11:31
InsaneSystemsДата: Пятница, 12 Октября 2018, 16:54 | Сообщение # 10
участник
Сейчас нет на сайте
Цитата
лишь бы не писать это каждый раз
все-таки ты игру будешь не на бобине крутить, современное железо такие оптимизации даже не заметит в большинстве случаев

Одно из убеждений, результатом применения которого является сложившийся стереотип о том, что игры на юнити тормозные. Все эти микрооптимизации в итоге и приводят к искомым улучшениям производительности, создающим комфортный и плавный геймплей в играх. И всё-таки да, гораздо чаще важнее читабельность кода и порой даже скорость его создания (в конце концов, всегда можно зарефакторить), нежели -0.01 мс к результату. :D
masb8ly-GCДата: Пятница, 12 Октября 2018, 21:57 | Сообщение # 11
постоянный участник
Сейчас нет на сайте
Цитата InsaneSystems ()
Одно из убеждений, результатом применения которого является сложившийся стереотип о том, что игры на юнити тормозные.

Куда большей проблемой является отсутствие нормальной архитектуры на 99% проектов, речь не только о Unity, а в принципе о любых проектах. В определенный момент все скатывается к невероятному числу обращений за кадр к, хорошо если несколькоим, а то и одному классу и тут уже далеко не до микрооптимизации.
Просто тут можно пойти дальше и начать оптимизировать цикла в стиле заменить < на !=, работать с приоретизацией операторов и заниматься разными другими сомнительными вещами. Однако, про архитектуру забывать нельзя никогда, это фундамент, как никак, и тогда все будет отлично и без едва заметных микрооптимизаций (и я сейчас действительно говорю о микро и низкоуровневых оптимизациях, шейдера с несколькими проходами и тьмой условий сюда не входят, но это уже не тема разговора).


Backend Developer ESIS
Client Side Developer Room8Studio
Technical Leader Lucid Reality Labs
Chief Technology Officer The Intruders
Chief Technology Officer RoyalePlay Games
  • Страница 1 из 1
  • 1
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг