Png иконки цифры: Цифры – Бесплатные иконки: формы

Можно применить параметры обводки ко всему объекту или использовать группы с быстрой заливкой и применить разные обводки к разным краям объекта.

В этом руководстве сотрудник журнала Layers Magazine Дэйв Кросс (Dave Cross) показывает, как применять заливку и обводку в Illustrator, а также пользоваться удобными комбинациями клавиш для работы с заливкой и обводкой.

Применение цвета, ширины или выравнивания обводки

1. Выделите объект. (чтобы выделить край в группе с быстрой заливкой, используйте инструмент «Выделение быстрых заливок»).

2. Нажмите поле «Обводка» на панели «Инструменты», «Цвет» или «Управление». Это действие подразумевает, что будет применена обводка, а не заливка.

   Поле «Обводка»

3. Выберите цвет на панели «Цвет» или образец на панели «Образцы» или «Управление». Либо дважды нажмите поле «Обводка», чтобы выбрать цвет с помощью инструмента «Палитра цветов».

   Если необходимо использовать текущий цвет в поле «Обводка», можно просто перетащить этот цвет из поля на объект. Перетаскивание цвета не работает для групп с быстрой заливкой.

4. Выберите толщину обводки на палитре «Обводка» или панели «Управление».

5. Если объект представляет собой замкнутый контур (а не группу с быстрой заливкой), выберите параметр на панели «Обводка», чтобы выровнять обводку относительно контура.

   •  Обводка по центру линии 

   •  Обводка внутри линии 

   •  Обводка снаружи линии 

   Примечания.

   • В текущей версии Illustrator опция Обводка внутри линии применяется по умолчанию при создании веб-документа. В некоторых более ранних версиях Illustrator по умолчанию используется Обводка по центру линии.
   • Контуры, для которых используются разные варианты выравнивания обводки, могут быть выровнены неточно. Если необходимо добиться точного совпадения краев при выравнивании, убедитесь в том, что настройки выравнивания обводки для контуров совпадают.

Создание обводок с переменной шириной

Инструмент «Ширина» на панели «Инструменты» позволяет создавать обводку с переменной шириной и сохранять переменную ширину в виде профиля для последующего применения к другим обводкам. Теперь можно легко настраивать или расширять обводки с переменной шириной с меньшим количеством опорных точек, поскольку Illustrator применяет упрощенные контуры к обводкам.

При наведении инструмента «Ширина» на обводку, на контуре появляется значок в виде бриллианта и маркеры. С помощью этих элементов пользователь может изменить ширину обводки, а также перемещать, дублировать и удалять точку ширины. При наличии нескольких обводок инструмент «Ширина» применяется только к активной обводке. Если требуется изменить обводку, убедитесь, что она задана «Оформление» на панели как активная.

Чтобы создать или изменить ширину в точке в диалоговом окне «Изменение ширины в данной точке», дважды нажмите обводку инструментом «Ширина» и измените значения для точки. При выборе параметра «Скорректировать ширину в соседних точках» изменения, примененные к выбранной точке ширины, затрагивают и соседние точки.

Чтобы выбрать параметр «Скорректировать ширину в соседних точках» автоматически, дважды нажмите точку ширины, удерживая клавишу Shift. При изменении переменной ширины инструмент «Ширина» различает прерывные и непрерывные точки ширины.

Чтобы создать прерывную точку ширины, выполните следующие действия:

1. Создайте на обводке две точки с различными значениями ширины обводки.
   

   Две точки ширины созданы

2. Перетащите одну точку ширины на другую, чтобы создать прерывную точку ширины для обводки.
   

   Прерывная точка ширины, созданная перетаскиванием одной точки ширины на другую

При работе с прерывными точками в диалоговом окне «Изменение ширины в данной точке» отображаются два набора значений ширины.

Элементы управления для инструмента «Ширина»

Выполните любое из следующих действий:

• Перетащите маркеры, чтобы настроить ширину обводки в отдельных точках контура. Точки ширины, созданные на угловых опорных точках или на опорных точках с прямым выделением, фиксируются на них при базовом редактировании контура.
• Чтобы изменить положение точки ширины, перетащите ее вдоль контура.
• Чтобы выбрать несколько точек ширины, нажмите их, удерживая клавишу Shift. В диалоговом окне «Скорректировать ширину в соседних точках» укажите значения для параметров «Сторона 1» и «Сторона 2» нескольких точек. Любые внесенные изменения будут касаться всех выделенных точек ширины.
• Чтобы глобально изменить ширину обводки для всех точек, укажите значение ширины в раскрывающемся списке «Ширина» панели «Обводка».

Сохранение профилей ширины

После определения ширины обводки сохраните профиль переменной ширины с помощью панели «Обводка», «Управление» или «Свойства».

A. Параметр «Равномерный профиль ширины» B. Значок «Сохранить профиль ширины» C. Значок «Удалить профиль ширины» D. Значок «Сбросить профиль ширины» 

Выполните любое из следующих действий:

• Чтобы применить к контурам профили ширины, выберите их в раскрывающемся списке «Профиль ширины» на панели «Управление» или «Обводка». Если выбрана обводка, которая не имеет переменной ширины, в списке отображается параметр «Равномерный». Чтобы удалить профиль переменной ширины из объекта, выберите параметр «Равномерный».
• Чтобы восстановить набор профилей ширины по умолчанию, нажмите кнопку «Сбросить профили», расположенную в нижней части раскрывающегося списка «Профиль».

При восстановлении набора профилей ширины по умолчанию в диалоговом окне «Параметры обводки» удаляются все сохраненные пользовательские профили.

При применении профиля переменной ширины к обводке она помечается символом «звездочка» (*) на панели «Оформление».

После редактирования контура кисти с использованием инструмента «Переменная ширина» или применения стиля «Профиль ширины» в диалоговом окне «Параметры обводки» параметр «Точки/профиль ширины» устанавливается автоматически для размера объектной и узорчатой кистей. Чтобы удалить все изменения профиля ширины, выберите параметр «Фиксировано» для размера или один из каналов данных планшета, например «Нажим», это позволит сбросить параметры данных планшета.

Создание точечных или пунктирных линий

Можно создать точечную или пунктирную линию, изменив атрибуты обводки объекта.

1. Выделите объект.

2. На панели «Обводка» выберите параметр «Пунктирная линия». Если параметр «Пунктирная линия» не отображается, выберите в меню панели «Обводка» пункт «Показать параметры».

3. Щелкните значок «Совместить пунктиры с углами и концами контуров путем изменения длины пунктиров» . Этот параметр позволяет делать штрихи на углах и концах контуров согласованными и корректно выглядящими. Если требуется сохранить внешний вид пунктиров и не выравнивать их, выберите значок «Сохранить точные значения длины штрихов и пробелов» .

   Настройка пунктиров на концах контуров

   A. Сохранение точной длины пунктиров и пробелов B. Выравнивание пунктиров относительно углов и концов контуров путем изменения длины пунктиров 

4. Задайте последовательность штрихов пунктирной линии, указав длину штрихов и пробелов между ними.

   Введенные числа повторяются в выбранной последовательности, поэтому нет необходимости заполнять все текстовые поля, чтобы применить заданный узор.

5. Выберите вариант оформления концов линии, чтобы изменить внешний вид концов штрихов. Параметр «Срезанные концы»  создает штрихи с квадратными концами. Параметр «Скругленные концы»  обеспечивает создание штрихов со скругленными концами или круглых точек, а параметр «Выступающие концы» вытягивает концы штрихов.

   Пунктирные линии толщиной 6 пт с зазорами между штрихами шириной 2, 12, 16, 12

   A. Срезанные концы B. Скругленные концы C. Выступающие концы 

   Просмотрите это видео, чтобы научиться создавать идеальные пунктирные штрихи.

Изменение концов или стыков линии

Под концом подразумевается конец разомкнутой линии; стык — это точка, в которой прямая линия изменяет направление (поворачивает). Можно изменить вид концов и стыков линии с помощью атрибутов обводки объекта.

1. Выделите объект.

2. На панели «Обводка» выберите вариант внешнего вида для концов и стыков линии.

   Если параметры не отображаются, выберите в меню панели пункт «Показать параметры».

   Срезанные концы

   Создаются обведенные линии с квадратными концами.

   Скругленные концы

   Создаются обведенные линии с полукруглыми концами.

   Выступающие концы

   Создаются обведенные линии с квадратными концами, выступающими на половину ширины линии за крайнюю точку линии. Этот параметр обеспечивает одинаковую толщину обводки во всех направлениях относительно линии.

   Угловые стыки

   Создаются обведенные линии с острыми углами. Введите значение для предела среза от 1 до 500. Этим значением определяется переключение между срезанным (остроугольным) стыком и скошенным (квадратным) стыком. По умолчанию предел среза имеет значение 10, при этом программа переключается со срезанного стыка на скошенный стык, когда длина точки в десять раза превышает толщину обводки. Значение 1 для предела среза соответствует скошенному стыку.

   Скругленные стыки

   Создаются линии обводки со скругленными углами.

   Скошенные стыки

   Создаются линии обводки с квадратными углами.

Добавление указателей стрелок

В Illustrator пользователь может работать со стрелками на панели «Обводка» и задавать пропорции при настройке их размера. Типы стрелок по умолчанию располагаются в раскрывающемся списке «Указатели» панели «Обводка». С помощью панели «Обводка» можно легко поменять местами начальный и конечный указатели стрелок.

Используя параметр «Масштаб», можно независимо менять размер начального и конечного указателей стрелки. Если требуется связать масштаб конечного и начального указателей, щелкните значок «Связать масштаб начального и конечного указателей стрелки», расположенный рядом с параметром «Масштаб».

Кроме того, пользователь может настроить выравнивание контура относительно начального или конечного указателя стрелки с помощью параметра «Выровнять». Доступны следующие варианты:

• Наконечник стрелки за пределами контура

• Наконечник стрелки в пределах контура

  Примечание. Чтобы удалить стрелки из объекта, в раскрывающемся списке выберите параметр «Без стрелок».

Создание пользовательских указателей стрелок

Для определения пользовательских указателей стрелок откройте файл Arrowheads.ai, расположенный в папке ShowPackageContent\Required\Resources\<язык>\ (для Mac) или \Support Files\Required\Resources\<язык>\ (для Windows). Следуйте инструкциям по созданию пользовательских указателей стрелок, приведенным в файле.

Поместите обновленный файл Arrowheads.ai в папку: <Корневая папка Illustrator>\Plug-ins\; следите за тем, чтобы случайно не перезаписать имеющийся файл Arrowheads.ai.

Связанные материалы

• Раскрашивание с помощью заливок и обводок
• Группы с быстрой заливкой
• Основные сведения о рабочей среде

Вход в учетную запись

Войти

Управление учетной записью

22 342 кратное ускорение загрузки геометрии в Unity / Хабр

Немного истории

Меня зовут Артем Толстогузов, и я вхожу в группу анонимных Unity‑программистов.

У меня:

• навязчивое желание переложить всю работу с CPU на GPU;

• небольшой фетиш в области оптимизаций всего что только возможно;

• хронический интерес к шейдерам, графическому пайплайну и технологиям;

• патологический синдром самозванца.

Люблю тестировать разные алгоритмы, подходы и технологии, доводить до совершенства отдельные механизмы, искать нетрадиционные методы изобретения велосипедов, а также проверять имеющиеся на возможность усовершенствования под конкретные задачи.

Так уж вышло, что в конце 2014 года меня позвали на проект, в котором моя страсть к оптимизациям и хронический интерес к шейдерам сильно обострились.

Одно из направлений нашей работы — оперативная подготовка роликов. У нас есть отдел картографии, в задачи которого входит работа именно с геокартами. Если вы знакомы со спецификой работы студии дизайна, вы знаете, что совместить слова КАРТЫ, ВЫСОКОКАЧЕСТВЕННЫЕ РОЛИКИ и ОПЕРАТИВНО в одном предложении можно только использовав минимум 1 частицу НЕ.

Чтобы ускорить работу на эфире, в далеком 2012 был сделан прототип интерактивных карт Москвы на эфирном движке VizRt. В сцену подгружалась одна из крайне простых и маленьких областей Москвы, заранее подготовленная в 3D движке, и на ней можно было расставить лейблы и некоторые иконки. Подложка состояла из четырёх текстур, высота и угол обзора камеры были заблокированы, а из 3D элементов в сцене был только слой с домами одной высоты.

Из‑за ограничений VizRt, развивать такую карту было невозможно. Тогда мы решили перенести ее на игровой движок Unity. Все объекты из геоданных были выгружены в отдельные .obj‑файлы, и в Unity была собрана Alfa версия. В ней на высоте в несколько километров использовалась 2D подложка (четыре текстуры разрешением 8К), а при приближении к интересующему участку загружались 3D модели сразу для нескольких картографических слоев (вода, кварталы, зелень, дороги, ЖД, здания). Тут уж стало возможно работать с камерой (делать незначительные перелеты внутри загруженной области, менять высоту и угол обзора), добавлять подписи и выгружать готовую анимацию в ролик. Здания приобрели индивидуальную высотность.

Когда концепция подтвердила жизнеспособность, студия решила развивать это направление и нанять отдельного Unity‑программиста. Именно в этот момент я попал на проект.

Начальные параметры

Первое с чем я столкнулся, это крайне медленная загрузка требуемой области и очень низкая производительность. Перед началом работ я выбрал некоторую тестовую область в центре Москвы и провел контрольные замеры. Вот они:

• Объектов в кадре 37 500

• Кол-во △ 450 000

• Рендер 14 fps

• Загрузка сцены 130 500 ms

• Скорость загрузки 450 000△ / 130 500ms  =   3,45 △/ms

Как видите, чтобы просто подлететь к нужной точке Москвы и дождаться загрузки 3D подложки, приходилось ждать 2–3 минуты. После чего нужно было настраивать анимацию в приложении с 10–15 fps. И в финале для просчета минутного ролика требовалось еще 3–4 минуты. Это несколько не соответствовало критерию ОПЕРАТИВНО.

Оптимизация скорости рендера

Перед тем как заняться оптимизацией загружаемых в сцену карт, я решил разобраться со скоростью рендера. Естественно, что при общем объеме рендера в 0,5 миллиона △, скорость в 14 fps была, мягко говоря, неадекватной. Производительность упиралась в те самые пресловутые 37 500 объектов в сцене, которые CPU каждый кадр обрабатывал и посылал на рендер. Самым логичным выходом было минимизировать количество объектов сцены, объединив объекты из 1 слоя в более крупные меши. Т.к. предстояло заняться созданием более крупных мешей, решили в первую очередь протестировать различные способы добавления в сцену новой геометрии.

А. Первым шагом любых оптимизаций, как всегда, является тест текущего состояния. Профилирование создания новых объектов (new GameObject(), new MeshRenderer(), new MeshFilter(), new Mesh()) показало, что 37 500 объектов добавлялись в сцену за 1 350 ms.

B. Первым тестом стала попытка не создавать каждый раз новый объект, а клонировать уже существующий объект‑прототип и изменять его геометрию на нужную. В итоге, скорость создания уменьшилась до 1150 ms, но на скорость рендера это никак не повлияло. В принципе, и не должно было — количество объектов в сцене осталось таким же.

C. Следующий тест заключался в том, что при загрузке новой геометрии я комбинировал её в большие меши, сократив таким образом кол‑во объектов в сцене и увеличив скорость рендера до 1500 fps. При этом загрузка геометрии уменьшилась до 900 ms.

D. Финальным этапом была проведена оптимизация. В сцене имелся один объект с мешем большого фиксированного размера (около 20 000 △), в момент загрузки создавался его клон, с диска подгружались только данные расположения точек и подготовленные нормали, в меше клонированного объекта подменялись соответствующие данные на загруженные с диска. Таким образом, удалось сократить время создания объектов до 45 ms, а скорость рендера увеличить до рекордных 1800 fps.

Оптимизация загрузки с HDD

Обращение к внешними данными часто является самой медленной операцией в программировании, а двукратная оптимизация процесса, который занимает 90% времени, гораздо выгоднее 100-кратной оптимизации оставшихся 10%.

Что меня крайне смутило в Alfa версии, так это работа с огромным количеством мелких файлов. Каждый объект карты был выгружен в свой собственный .obj файл. Сами объекты представляли из себя очень простые примитивы (чаще всего четырехугольные), и файл с описанием подобной геометрии занимал меньше 1 Кб. Таких объектов были сотни тысяч, и попытка зайти в их папку приводила к подвисанию Windows. Для дальнейших оптимизаций надо было существенно уменьшать количество файлов, объединяя их содержимое — что также требовалось и для оптимизации скорости рендера.

Чтобы понять оптимальный объем требуемых файлов, был написан маленький тест. Он считывал с диска множество файлов разного размера и замерял время доступа. Проведя этот тест на нескольких компьютерах, мы вывели, что оптимальный размер файла должен быть не менее 3 Мб.

Стоит упомянуть, что файловая система имеет свой размер кластера. Если остаток файла в нее не помещается, то это место остается физически зарезервировано системой, но в реальности данные там отсутствуют. Поэтому, если сохранить 1 млн файлов в 1Кб на диске с файловой системой, у которой указан размер кластера 16Кб, в свойствах папки будет написано «Размер: 976.56 Мб На диске: 15,25 Гб».

Таким образом, для оптимальной работы с внешним хранилищем данных требовалось выбрать размер файла, занимающего не меньше 3 Мб. Если же мы хотим оставлять размер файла минимально возможным, то желательно делать его не меньше 95% и не больше 100% от размера кластера ФС, чтобы дисковое пространство не пропадало зря.

Использование SHP файлов

Первая попытка отказаться от кучи мелких файлов заключалась в том, чтобы полностью избавиться от посредников в виде кучи мелких . obj файлов и воспользоваться картографическими данными, на основании которых эти файлы были сгенерированы. Большой плюс.shp файлов в том, что один файл хранит сразу все данные для одного картографического слоя в бинарном виде. Конечно, бинарные данные занимают гораздо меньше места чем текст, но т.к. это формат хранения не 3D геометрии, а 2D проекций, для него требовалось гораздо больше расчетов. Был написан парсер для.shp файлов и простой генератор 3D объектов из 2D проекций (с возможностью выбора нескольких типов итоговой геометрии).

Итоги по загрузке тестовой области:

• Объектов в кадре 24

• Кол-во △ 481 000

• Рендер 1800 fps

• Загрузка сцены 6 528 ms
  

  • Чтение 805 Мб с диска 270 ms

  • Выборка данных 170 ms

  • Просчет геометрии 6 040 ms

  • Clone Big Mesh & Change 48 ms

• Скорость 481 000△/6 528 ms   =   73,7 △/ms (x21)

Как видите, при таком подходе уже удалось ускорить загрузку в 21 раз, сократить время ожидания загрузки тестовой с 2 минут до 6 секунд и увеличить скорость рендера в 120 раз.

Но как же обойтись без ложки дегтя в этом бочонке меда оптимизации? Помимо своих преимуществ, данный метод также имеет и свои недостатки:

• Еще до начала работы необходимо загрузить в память все SHP файлы и хранить их там все время. т. е. мы резервируем 2–3 Гб в памяти под данные, из которых в реальной работе может использоваться всего 20–30 Мб;

• Если настраивать работу не с локального диска, а из сети с единой базой данных, то загрузка 2 Гб может занять не секунды, а минуты времени;

• При подгрузке, где‑то 0,2 сек времени занимает выборка данных из слоя. Если слоев будет больше, то выборка может занять уже 0,5 сек. И эта выборка будет происходить каждый раз при изменении положения камеры в пространстве.
  т. е. каждый раз при просчёте кадра или настройке анимации будет происходить микрофриз;

• 6 секунд из всего процесса загрузки и построения занимает подготовка геометрии на основании географических данных. Если предыдущие пункты можно было каким‑то образом оптимизировать, то данный пункт, к сожалению, оптимизации почти не подлежит. Так как этот пункт занимает 90% от всего процесса, мы уже не сможем существенно ускорить загрузку.

Оптимизация работы с OBJ

Как сказано выше, чтобы ускорить загрузку .obj файлов, нам в первую очередь необходимо объединить их в .obj файлы бóльшего размера. Конкретно в этом случае нам уже были известны конкретные 37 500 файлов, которые необходимо модифицировать. Сам процесс объединения проходил почти таким же способом, что в тестах по комбинации геометрии в большие меши. Я установил ограничение в 32 760△ для 1.obj файла и получил и итоге 14 файлов. Все дальнейшие рассуждения будут идти при работе с одним таким файлом, и лишь в конце будет проведен финальный тест со всеми файлами.

Размер реальных данных при банальном слиянии геометрии уменьшился в среднем в 1,6 раза (10,5 Mb → 6,4 Mb). Думаю, из‑за того, что в изначально маленьких файлах присутствовали тэги и комментарии, которые в больших файлах исчезли или стали присутствовать всего 1 раз. А вот время загрузки файла с диска уменьшилось в 50 000 раз (115 875 ms → 2.2 ms) по сравнению с загрузкой 2680 отдельных микро файлов.

Следующим делом, я убрал из .obj файлов UV развертку, т.к. она не использовалась в Unity. На этом же шаге я сделал тест по загрузке и просчету нормалей:

Узнав, что посчитать нормали по геометрии в 35 раз быстрее, чем распарсить их, я выкинул и их тоже.

Следующим шагом я заметил, что 90% из всей геометрии — это 4 угольные квады, представляющие из себя боковые грани домов и других объектов. Заменив треугольники на квады, в .obj файле стали сохраняться четыре ссылки для каждого квада вместо 6 ссылок для двух △. Конечно, в этом случае, если у объекта имелись △, не образующие квады, на них закладывалась геометрия с пустым △. Но такие незначительные пустышки никак не повлияли на скорость рендера и почти не внесли вклад в увеличение файла.

Удалив все лишнее и оптимизировав формат хранения, я уменьшил размер данных еще в 2,7 раза (6,4 Mb → 2,4 Mb). Т.к. в оптимизированном файле было меньше данных для парсинга, он ускорился в 3,5 раза (3 317 ms → 944 ms).

Скомбинировав данные до приемлемого уровня и уменьшив размеры полученных файлов до минимально возможного значения, я взялся за оптимизацию парсинга этих файлов на стороне Unity. Замечу, что .obj файл представляет из себя текстовый файл с описанием геометрии, и на тот момент для парсинга использовался скрипт ObjImporter.cs. Банальной заменой построчного считывания через StringReader в имеющемся скрипте, на считывание сразу всего файла и работой с string[], я повысил скорость парсинга в 2,4 раза (944 ms → 390 ms).

Следующим шагом был поиск альтернативных парсеров:

Как видите, самым быстрым оказался бесплатный парсер из AssetStore. Он сократил время парсинга еще в 2,9 раза (390 ms → 136 ms).

Если вы думаете, что, уменьшив размер файлов в четыре раза, время загрузки в 50 000 раз и время парсинга в 24 раза, я остановился, то нет. К тому моменту мой фетиш к оптимизациям уже перешел в острую фазу. Я проверил время загрузки имеющихся файлов разными методами:

Я обратил внимание, что считывание .obj файла как массива байт занимает 58 раз меньше времени, чем чтение того же файла как массива строк.

Я задался вопросом: «А может и парсинг этого файла как бинарного файла тоже будет идти в десятки раз быстрее?».

Дело в том что .obj является текстовым файлом, но текст — это лишь форма представления байт в удобном для человека виде. Для компьютера же работа с текстом является крайне медленной операцией. Я стал считывать .obj файл как массив байт и написал парсер как конечный автомат, в котором каждый последующий байт меняет состояние 3D модели, добавляя или уточняя имеющиеся данные. В итоге, код избавился от всех string и получившийся парсер ускорил парсинг еще в 2,5 раза (136 ms → 55 ms). На тот момент я остановился с оптимизацией работы через . obj файлы, хотя в данный момент думаю, что смог бы провести еще парочку тестов и улучшить полученный результат.

Результат тестирования:

• Объектов в кадре 14

• Кол-во △ 450 000

• Рендер 1800 fps

• Загрузка сцены 800 ms

  • Чтение 33 Мб с диска 9 ms

  • Парсинг .obj файлов 747 ms

  • Clone Big Mesh & Change 44 ms

• Скорость 450 000△/800 ms   =   562,7 △/ms (x163)

Первые результаты и новые вызовы

Как вы заметили, мне удалось снизить объем хранящихся данных и увеличить скорость загрузки тестовой сцены в 163 раза. Если раньше приходилось ждать больше двух минут, пока прогрузятся тестовая сцена, то сейчас она подгружалась за 0,8 секунды. Казалось бы, теперь можно масштабировать полученную технологию на весь проект и полностью забыть про дальнейшие оптимизации. Но мы люди, нам всегда нужно больше.

Как только мы смогли рендерить 0,5 миллиона △ c 1800 fps, мы захотели добавить деталей домам и другим объектам. Как только мы смогли почти мгновенно загружать 37 500 объектов, мы захотели показывать не только часть карты сверху, но и панорамные виды с взглядом вдаль. Как только мы добавили всю Москву, мы захотели добавить и всю Московскую Область.

Для понимания дальнейшей проблематики нужна некоторая статистика.

Красным контуром отмечен МКАД, ограничивающий 900 км². Московская Область занимает более 160 000 км².

Если же говорить даже о незначительном отлете камеры, то увеличение высоты на 300 метров может означать увеличение количества геометрии в кадре в десятки раз.

Для увеличения детализации, домам был добавлен поребрик и на фасады наложены окна. Там, где раньше хватало 10△, сейчас требуется 26△. Там, где мы раньше обходились без UV развертки, сейчас она понадобилась.

Как только мы убрали ограничение на угол поворота камеры относительно горизонта, количество геометрии в кадре еще раз скакнуло на порядок.

Сцена со смотрящей вдаль камерой включает в себя 22 000 000△. Если сейчас взять эту сцену за тестовую, то на ее загрузку у нас уйдет: 22 000 000 / 562,7 = 39 097 ms = 39 сек. Это конечно не те 2 минуты, с которых мы начинали, но и приемлемым ожидание 39 секунд при каждом повороте камеры тоже не назовешь.

Оптимизация через шейдеры

Как всегда, при оптимизации тех или иных механизмов следует в первую очередь сделать профилирование всех шагов, а также поискать и протестировать все возможные альтернативы каждого из них.

Уменьшать размер.obj файлов я уже не мог (а с учетом новых запросов на фасады домов мне еще требовалось добавить в них UV). Увеличить скорость работы с диском тоже не представлялось возможным, т. к. файлы уже были больше 2 Мб.

Для работы над парсингом .obj файлов я потратил уже достаточно времени и считал, что выжать из него еще больше скорости я уже не смогу (сейчас я так не думаю). Т.к. эти шаги занимали 95% от общего времени, как бы я ни оптимизировал последний шаг, я бы не смог существенно ускорить процесс на .obj файлах. Соответственно, надо было менять формат хранения — на открытый бинарный или самописный.

Из проведенных ранее тестов было установлено, что быстрее всего создавать новую геометрию в сцене и хранить в ней некую большую заготовку, делая ее копию и меняя позиции финальных точек. Когда же я разбил и этот процесс на этапы и провел более глубокий анализ, я наткнулся на удивительный факт. Из 45 ms процесса создания геометрии непосредственно клонирование занимало всего 0,35 ms. Фактически, можно за очень короткий срок «забить» сцену одинаковой геометрией, находящейся в разных местах. И тут я вспомнил одну очень интересную технику, когда в вертексный шейдер прописывается какое‑либо смещение финальных точек меша, в зависимости от входных параметров и некой текстуры. Я решил попробовать клонировать большой меш за 0,35 ms, установить в него материал с моим шейдером и текстурой, которые поменяют положение ее вертексов на нужное мне, и проверить скорость данного подхода.

Как всегда, я начал с тестов различных вариантов создания текстуры внутри Unity. Стоит пояснить, что в качестве формата хранения я выбрал .png , т.к. он позволял хранить 4 байта данных в 1 пикселе, и использовал сжатие без потери качества, что уменьшало размер хранимых данных на 65%.

Как видно из результатов, быстрее всего создать текстуру и инициализировать ее, задав цвета как массив байт. Но .png не хранит массив байт — это сжатый формат данных. Соответственно, у меня встал выбор: либо хранить png и тратить около 30 ms на его декомпрессию, либо хранить «чистые» данные и создавать текстуру за 3 ms. С учетом, что png сжимал данные приблизительно в 3 раза, то можно было посчитать скорость работы со обоими подходами:

• 2 Mb .png файла считываются с диска за 0,6 ms + 30 ms на декомпрессию = 30,6 ms

• 6 Mb «чистых» данных считается с диска за 1,8 ms + 3. 3 ms на создание текстуры = 5,1 ms

Думаю, выбор очевиден.

Следующим шагом было написание умного шейдера и компрессора, который сжимал имеющиеся дома с UV разверткой до минимально возможной текстуры.

Получилась подобная текстура, в которой хранились данные для отображения сразу нескольких рядом стоящих регионов. Размеры полученной текстуры были 1342 x 1342 px, и в чистом виде данные для нее занимали 7 032 Kb. В результаты мы определяли, какие из регионов попадали в камеру, загружали их, делали клоны большого меша и назначали каждому новому мешу эту текстуру. Т.к. в текстуру дома́ объединялись по пространственному признаку, часть из них выходила за пределы камеры, общий объем рендера немного увеличился относительно предыдущего теста.

Результат тестирования:

• Объектов в кадре 36

• Кол-во △ 458 640

• Рендер 1650 fps

• Загрузка сцены 5,95 ms

  • Чтение 7 Мб с диска 1,9 ms

  • Создание текстуры 3,5 ms

  • Назначение материала 0,2 ms

  • Clone Big Mesh 0,35 ms

• Скорость 458 640△/5. 95 ms   =   77 082,4 △/ms  (x22 342)

Как видите скорость рендера немного упала из-за использования более сложного шейдера. Но финальное ускорение загрузки в 22 342 раза с лихвой окупает столь незначительные изменение в производительности. 

Результаты

Не существует серебрянной пули оптимизации, подходящей всем всегда и во всех ситуациях. Ну, по крайней мере, я о такой не знаю. Например, технология Unity Dynamic batching, по своей сути также объединяющая геометрию на лету и увеличивающая за счет этого fps в данном проекте, наоборот лишь замедляла рендер.

Могу лишь дать несколько общих советов по оптимизации, которыми пользуюсь сам:

• Перед любой оптимизацией определите, какой параметр вы хотите улучшить и создайте тест, который бы мог измерить объективные показатели интересующего вас параметра. Нельзя управлять тем, что невозможно измерить;

• К любой оптимизации можно подходить сразу с нескольких сторон, иногда очень неожиданных и не обязательно программных. В аэропорту Хьюстона пассажиры постоянно жаловались на долгое ожидание багажа. Когда администрация увеличила штат грузчиков (увеличив свои затраты), жалобы не исчезли. Когда же они стали сажать самолеты на дальнем конце (0 затраты), и пассажирам приходилось намного дольше идти к лентам, жалобы упали почти до 0;

• Разбивайте интересующий вас процесс на мелкие отрезки и оптимизируйте каждый из них по‑отдельности;

• Помните, что 20% оптимизация шага, занимающего 80% общего времени, выгоднее 2х кратного ускорения процесса, занимающего всего 10%;

• Цели можно достичь разными путями. Чем больше тропинок вы знаете, тем больше у вас вариантов для оптимизации. Поддерживайте в себе любопытство и интересуйтесь, какими еще способами можно делать те вещи, которые вы годами делали привычным способом;

• Одна из самых долгих операций — это обращение к внешним данным. Старайтесь избегать ее, удаляйте неиспользуемые данные, сжимайте то, что можно сжать, разбейте большие данные на более мелкие и обращайтесь к ним по необходимости, используйте отдельные потоки и растягивайте эти процессы по времени;

• Если данные уже в памяти, то всеми силами старайтесь избегать работы со строками. Они удобны для человека, но не для компьютера. Каждая конкатенация создает новую строку и выделят в памяти дополнительное место — если без этого не обойтись, используйте StringBuilder;

• Шейдерами можно не только менять цвета, но и ОЧЕНЬ быстро манипулировать геометрией. Зачастую, скорость рендера никак не изменится, если вы добавите в вертексный шейдер простое смещение или анимацию;

• Иногда замена алгоритма или используемой библиотеки на аналогичную может улучшить результаты в несколько раз;

• Если у вас в проекте есть сложные расчеты, использование Burst compiler и Job System может ускорить их десятки раз;

• Помните, что у CPU с десяток ядер, которые используются для поддержки работы всей системы, ядра Unity и вашего кода. У GPU до 10 000 процессоров. Если у вас есть задачи, которые могут быть распараллелены и выполнены на GPU — сделайте это. Иногда такой подход может дать x100 вашей задаче.

В финале скажу ещё одну, казалось, очевидную вещь. Оптимизировать можно много, долго и очень продуктивно, но «можно» не значит «нужно».

Перед тем как что‑либо оптимизировать, убедитесь, что эта оптимизация нужна вам/проекту/бизнесу, иначе может получиться, что вы будете полгода оптимизировать проект и добьетесь самой красивой графики, самого быстрого запуска, самых высоких fps, НО это ничего не будет значить, если ваша игра не будет опубликована/заказчик откажется от проекта/бизнес закроет направление/сессия закончится и вы не успеете дописать дипломную работу. Тут, как в принципе и во всем программировании, лучше идти по итеративной схеме с промежуточными шагами и постоянным фидбеком от конечного пользователя вашего продукта:

1. Находите самое проблемное место.

2. Оптимизируете его (хотя бы минимально).

3. Собираете готовый проект с улучшением.

4. Получаете фидбек по изменениям от реальных пользователей.

5. Если пользователей все устраивает продолжаете разработку, если нет — возвращаетесь на п.

   No related posts.