Докуметация Cтарт Статьи Форум Лента Вход
Не официальное русскоязычное сообщество
Главная
    Документация jMonkeyEngine
        jMonkeyEngine Уроки и Документация
            Документация для продвинутых пользователей
                Оптимизация вашей игры с использованием статистики

Оптимизация вашей игры с использованием статистики

Опубликованно: 08.04.2017, 18:19
Последняя редакция, Andry: 26.09.2017 13:36

Когда вы создаете SimpleApplication, вы видите в левом углу DefaultView и FpsView по умолчанию. StatsView отображает статистику объекта, которая используется во время разработки, например для отладки и оптимизации. Ниже StatsView есть FpsView, который отображает количество кадров, которые jMonkeyEngine может визуализировать в секунду. Основное применение этих статистических данных — выяснить, почему приложение может работать медленно и с чего стоит начать исправление производительности. StatsView + FpsView выглядит следующим образом:

[quote]FrameBuffers (M) = 2
FrameBuffers (F) = 2
FrameBuffers (S) = 2
Textures (M) = 7
Textures (F) = 3
Textures (S) = 3
Shaders (M) = 6
Shaders (F) = 3
Shaders (S) = 4
Objects = 24
Uniforms = 31
Triangles = 582
Vertices = 1148
Frames per Second: 30[/quote]

On/Off

Вы переключаете StatsView во выключенное/выключенное состоянии в методе simpleInitApp(), устанавливая значение boolean:

setDisplayFps(false);       // Скрыть FPS
setDisplayStatView(false);  // Скрыть статистику

Терминология

Обсчитываемые типы элементов:

  • FrameBuffers: Общее количество поверхностей рендеринга, используемых для внеэкранного рендеринга и рендера в текстуру.
  • Textures: Общее число различных текстур, используемых в сцене.
  • Shaders: Общее количество шейдеров, используемых для эффектов (затенение, размытие, освещение, свечение и.т.д.).
  • Objects: Общее число объектов в конвейере OpenGL. То есть, объекты прикрепленные к rootNode и guiNode и.т.д.
  • Uniforms: Общее количество юниформ шейдеров. Юниформы — это предопределенные переменные, используемые в качестве параметров в вычислениях шейдеров, содержащие такие данные, как матрицы, векторы, время и цвета.
  • Triangles: Общее число треугольников (граней) ячеек всех объектов.
  • Vertices: Общее число вершин (угловых точек) на сетках всех объектов.

Виды статистики:

  • (M) = Memory – Количество элементов в памяти OpenGL.
  • *(F) = Frame * – Количество элементов, используемых в текущем кадре (видимые).
  • (S) = Switches – Количество элементов, состояние которых было изменено в последнем кадре.

StatsView не включает статистику по физике.

Как интерпретировать FPS при оптимизации

FPS (количество кадров в секунду) показывает, как быстро jME запускает цикл обновления. Если значения FPS опускаются ниже 30, игра замедляется и запускается рывками, что делает игру либо неудобной, либо невозможной для игры. Вам необходимо либо уменьшить количество операций в цикле обновления, либо уменьшить использование памяти (уменьшить количество объектов). Если ваше приложение становится все более и более вялым, дезактивируйте или уменьшите один набор функций за раз: деактивируйте тени, физику, сглаживание… Попробуйте меньше источников света, меньше NPC(персонажей), меньше образцов в сферах (то есть менее гладкие сферы). Временно замените сцену (или ее части) более простой тестовой сценой, чтобы проверить, имеет ли сцена множество треугольников и.т.д. Следите за FPS и StatsView и узнайте, какой элемент оказывает наибольшее влияние на производительность. Здесь вы начинаете оптимизацию.

Как интерпретировать статистику

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

Чего вы должны избегать?

  1. FrameBuffers: если вы не используете никаких эффектов постобработки (FilterPostProcessor), этот счет должен быть равен нулю. Чем больше эффектов вы используете, тем больше FrameBuffers используется. Если это значение велико, в то время как другие нормальные, а ваша игра вялая, вы можете ускорить работу приложения, используя меньшее количество эффектов постобработки.
  2. Количество объектов (количество индивидуальных) является очень важным значением, которое показывает, сколько геометрий было отображено в последнем кадре. В общем, если вы держите количество объектов около 100-200, ваша игра будет быстрой и отзывчивой. Если количество обычно выше, рекомендуется в ручную кодом, отсоединять удаленные объекты, или оптимизировать сложную многокомпонентную сцену, используя: GeometryBatchFactory.optimize(complexNode, true); Или Текстурный Атлас.
  3. Количество Треугольников. Если ваша игра вялая, а количество треугольников (полигонов) велико, вы обрабатываете слишком много, слишком детализированных сеток. Попросите ваших графических дизайнеров создавать модели с меньшим количеством полигонов или использовать оптимизацию уровня детализации (LOD). Предел составляет около 100 000 вершин для сцены, считается, что самые медленные в настоящее время используемые видеокарты не могут обработать больше этого.
  4. Если наблюдается непрерывное нарастание величины каких то статистических значений, прямо перед тем как игра замедляется или заканчивается память? Проверьте, не добавляете ли вы случайно объекты в каждом цикле, а не только один раз.
  5. Убедитесь, что числа правдоподобны. Если вы думаете, что создали тестовую сцену из «нескольких коробок», но StatsView показывает десять тысяч треугольников, то у вас, вероятно, есть где-то лишние объекты (из едва видимых материалов, перекрывающихся другими объектами, масштабированный слишком большим или слишком малым, чтобы быть видимым, и.т.д.).
    • Пример: В тестовой сцене, состоящей из квадратов, вы ожидаете соотношение вершина(vertex):треугольник(triangle):объект(object) как 8:12:1.
    • В зависимости от размера и уровня детализации (LOD), у ландшафтов, моделей и сфер будут более высокие значения. Высокополигональная модель выглядит довольно хорошо в Blender, но вы должны найти компромисс с низким полигоном, низким LOD, если вам нужно несколько больших объектов в одной сцене!
  6. Если S (объекты переключаются) являются высокими по сравнению с F (используемые объекты), то вы используете или генерируете слишком много разных Материалов (и т. Д.). Вы излишне заставляете jME повторно загружать и повторно привязывать объекты (= Switches), что плохо для производительности. Также, если у вас много прозрачных материалов в вашей сцене, это приводит к увеличению количества переключателей, и вы должны использовать меньше прозрачных материалов.
  7. Если значения M (объекты в памяти) являются высокими по сравнению с F (используемые объекты), это означает, что в памяти хранится гораздо больше объектов GL, чем фактически используется. Это может произойти в больших сценах со многими материалами. Рассмотрите возможность разбить сцену и отсоединить объекты, пока они вне зоны видимости, такая встроенная отбраковка может оптимизировать сцену.

Какие цели вы должны пытаться достичь в целом?

  1. Значения для (M) и (F) должны быть в пределах одного порядка величины. Это означает, что ваш код загружает только те объекты, которые ему действительно нужны, и что на самом деле оборудование может обрабатывать.
  2. Это нормально, если переключатель (S) ниже, чем используется в текущем кадре (F).
  3. FPS должен быть 30 или более на самом медленном оборудовании, на которое вы нацеливаетесь.
  4. 10’000-50’000 вершин — типичное среднее значение для сцены. » ‘

См. также:


Переведено для jmonkeyengine.ru, оригинал
Автор перевода: Andry

Добавить комментарий

Содержание

jMonkeyEngine.ru © 2017. Все права сохранены.