2013-09-19 2 views
6

Я наблюдаю странное явление с моей OpenGL-программой, которая написана в C#/OpenTK/core-profile. При отображении данных mandelbrot из карты высот с вершинами ~ 1M производительность отличается в зависимости от масштабного значения моих матриц вида (это орфографический, поэтому да, мне нужен масштаб). Данные выводятся с использованием VBO. Процесс рендеринга включает в себя освещение и теневые карты.OpenGL - плохое исполнение с высокими значениями шкалы

Мое единственное предположение - это что-то в «ошибках» шейдеров при низких значениях шкалы и есть некоторая обработка ошибок. Любые подсказки для меня?

Примеры:

Example 1 Example 2

+0

Возможно, вам стоит опубликовать этот вопрос на сайте [Game Development] (http://gamedev.stackexchange.com/) для получения наилучших ответов. Я не говорю, что на этом сайте нет страстных программистов, которые могут вам помочь, просто у вас будет больше шансов на успех. Для чего это стоит: я помню что-то вроде: лучше всего хранить все ваши объекты в пределах поля [2 x 2 x 2]. То есть самая низкая координата для любого измерения должна быть -1, а самая высокая должна быть 1 для достижения наилучших результатов. Это должна быть ваша «тропосфера». Вы можете поместить skybox (если есть) вне этой «тропосферы». –

+0

Ну, это может быть одна причина. Значения находятся в диапазоне 0: 1024, поэтому я изменю их размер и повторю попытку. Есть ли возможность переместить вопрос в разработку игры? –

+0

Я думаю, это может помочь [Что такое миграция и как она работает?] (Http://meta.stackexchange.com/questions/10249/what-is-migration-and-how-does-it-work) , Я не имею права выполнять миграцию, так как у меня еще нет 3000 очков. Во всяком случае, у сайта назначения уже есть такой вопрос, сначала посмотрите его. –

ответ

15

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

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

+1

Это имеет смысл в моей голове ;-) Честно говоря, я бы назвал фрагментарный шейдер одинаково часто; независимо от масштабного коэффициента матрицы представлений. –

+2

Нет, это определенно не так. Если бы фрагментарные шейдеры работали на равной частоте, независимо от того, насколько маленькая точка была на экране, это устранило бы много псевдонимов, но нам пришлось бы переосмыслить, что такое фрагмент. Фрагменты на самом деле являются всего лишь строительными блоками пикселей в буфере кадров, поэтому количество фрагментов, генерируемых некоторым объектом, пропорционально количеству пикселей, которые он покрывает в пространстве экрана :) –

+0

Теперь я понимаю. Спасибо за подробное объяснение! –

Смежные вопросы