Мы часто используем этот метод для динамического создания атласа, когда, например, мы загружаем аватарки игроков, а какие они будут мы заранее не знаем. Или мы формируем атлас для боя, когда игроки могут выбрать какие-нибудь скины юнитов, а нам все еще нужен 1 draw call ;)
Позволяет комбайнить меши, которые находятся на GameObject. Довольно удобно, чтобы не ползать по иерархии и не собирать их там.
Есть способ комбинировать меши и без этого: mesh.CombineMeshes.
Но придется передавать туда уже структуры, в которых описываются матрицы и мешки.
Мы такое часто использовали для 3D, когда мы создавали одну мешку и вместо 1к объектов получали всего один. Есстественно, нужно понимать, что батчить нужно по-материально, т.е. какой-то код с этой логикой нужно будет все же написать.
Давайте сначала разберемся что такое Lerp. Это линейная функция, которая задается двумя точками B и C (см изображение), а третье значение t - это как значение между 0 и 1, где 0 - это B, а 1 - это C.
Таким образом получается, что перемещение по линии - это и есть lerp или интерполяция. А вот LerpUnclamped - это экстраполяция, т.е. когда мы не обрезаем значение t до 0..1.
b + (c - b) * clamp01(t);
Т.е. по сути мы сначала сдвигаем сетку координат в ноль (c - b), а потом умножаем получившийся вектор на t, а после сдвигаем получившийся вектор назад.
С Unclamped мы просто не делаем операцию clamp, тем самым можем позволить результату выходить за границы b-c.
История произошла совсем недавно: мне нужно было понять почему у нас крашился слабый девайс на загрузке одной конкретной игровой карты, при этом на других он вел себя хорошо. У меня сразу подозрение пало на память, т.к. поведение характерно именно для такого кейса. Проверил логи - действительно память закончилась.
А теперь самое инетерсное, начал разбираться и оказалось, что наш картоделатель посадил по 5к юнитов в домики "за картой", чтобы потом оттуда пускать их по триггеру. А рендер работает таким образом, что ему нужно знать верхнее ограничение по отрисовке количества юнитов. Для нормальной игры это вычислялось по формуле: "берем сумму всех юнитов во всех домиках на карте и умножаем на количество игроков (т.к. в теории каждый игрок может применить какой-нибудь скилл, который сдублирует юнитов, например)". Но если вдруг мы что-то не учли - мы просто не рисуем юнитов и все, что в принципе ок, т.к. когда у тебя 1к юнитов на экране - ты уже не понимаешь где кто, а когда 4к - так и подавно.
Так вот этому коду уже 7 лет и понятное дело, что его никто не трогал все это время, но когда в 2015 году мы писали этот код - юнити мало чего умела нормально рисовать в больших количествах, и мы оптимизировали и микрооптимизировали все что видели.
Так вот мы жили с такой игровой картой уже месяца 3 и только сейчас заметили проблему на девайсе с памятью, хотя у нас вместо того, чтобы рисовать и обрабатывать 4к юнитов максимум (+рендер на 20к), мы вдруг начали обрабатывать 220к и никто этого не заметил... И, наверное, если бы не этот девайс - так бы и пошли в релиз 🙂
А вы все "преждевременная оптимизация, преждевременная оптимизация..." 😂
Дело касается в основном мобилок, но вообще принцип тот же везде. Overdraw - это по сути метрика, с помощью которой можно понять сколько раз вы закрашиваете один и тот же пиксель. Во-первых, красить пиксель дважды - плохая примета. Во-вторых, видяхи на мобилах довольно слабые и каждый новый проход по одному месту может сильно просаживать производительность.
На практике легко получить такую проблему партикл системой с тысячами частиц. Может казаться, что производительность падает из-за количества частиц, но на самом деле проблема на 99% в overdraw. Кстати, для этого в настройках рендера партикл системы есть параметр, который ограничивает максимальный размер частицы относительно размера экрана, т.к. чем больше площадь - тем хуже. Поэтому 100 больших частиц у камеры хуже, чем 10к, но далеко.
Надеюсь, что вы все в курсе, что операция деления выполняется намного медленнее операции умножения. Если нет, то имейте ввиду.
Я часто встречаю вот такой код:
a += b / 2f;
И мне все время хочется такой код написать так:
a += b * 0.5f;
Еще можно заменять по тому же принципу и любые другие константы. Но что делать, если у нас деление не на константу, а на x? Да все просто, делаем y = 1f / x и используем уже y.
Мы часто используем для редактора поля вида:
UnityEngine.Object dir;
для того, чтобы в инспекторе перетащить туда папку. Это очень удобно, чтобы не писать константы в коде.
Их нет, да, но как тогда работают дженерики, которые мы делаем в C#? Там то они есть;) а мы используем il2cpp почти всегда для продакшена. В итоге под каждый тип, который мы вызываем, будет создан метод. Это стоит учитывать, когда вы создаете дженерик метод и делаете миллион разных вариантов вызовов, то ожидайте код в размере миллиона копипастных методов;)
Допустим, что вам нужно найти середину связного списка, как это быстрее всего сделать? Завести 2 указателя, один будет шагать через один элемент, а второй - по каждому элементу. Таким образом когда первый указатель доберется до конца такого списка - второй будет указывать на середину. Так вот первый указатель называют "быстрым".
Недавно встретил такую задачку и хотел бы с вами поделиться:
На вход нашему методу передается некий граф, который содержит ноды вида
Node {
int value;
Node next;
}Нам нужно найти ноду в этом графе, которая начинает бесконечный цикл.
Например:
1 -> 2 -> 3 -> 4 -> 2
Тут нода со значением 2 начинает цикл.
Если же ноды нет, то метод должен вернуть null.
Решение этой задачи довольно простое, если бы не одно условие: нужно найти решение без использования дополнительной памяти.
Насколько я помню, я встретил ее по теме "какие задачи не нужно задавать на собесах", т.к. если решения ты не знаешь - решить ее практически невозможно, но все равно - подумайте, ну а вдруг 🙂
p.s: задача была задана на собесе в компанию Apple.
Довольно простой вопрос, который решается банальной проверкой (v2.sqrMagnitude <= radius * radius). Мы такой вопрос часто задаем на собесах, но не только для того, чтобы выяснить считает ли человек через квадрат радиуса, а скорее для того, чтобы задать второй вопрос: "а в эллипс?". И вот на этом вопросе люди начинают сами себя закапывать. Кто-то придумывает несуществующие правила и теоремы, кто-то говорит, что мол "да я это не помню, там высшая математика, кому это вообще надо", ну а кто-то предлагает решение.
А самое интересное, что решение довольно простое, которое не требует никаких знаний и формул:
Изменяем Y проверяемой точки на фактор соотношения Rx к Ry, а дальше проверяем на попадание в радиус Rx. То есть мы вытягиваем эллипс таким образом, чтобы он стал кругом и считаем уже относительно круга.
Он сравнивает не точное значение, а приблизительное, с учетом погрешности:
var v = new Vector3(0f, 0f, 0f); var v2 = Vector3.one - Vector3.one; v == v2