Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Software rendering/ occlusion culling (3 стр)

Software rendering/ occlusion culling (3 стр)

Advanced: Тема повышенной сложности или важная.
Страницы: 1 2 3
}:+()___ [Smile]Постоялецwww5 авг. 201819:04#30
FordPerfect
> Делим на w. Получаем координаты в NDC-space.
Это делать не обязательно. Можно сразу из однородных координат получать коэффициенты для полуплоскостей.
FordPerfectПостоялецwww5 авг. 201820:09#31
}:+()___ [Smile]
Я вообще-то и пишу:
> Проводим отсечение: -w<=x,y,z<=+w для OpenGL, -w<=x,y<=+w, 0<=z<=+w для DirectX.
> Делим на w. Получаем координаты в NDC-space.
Отсечение, ясен пень, в clip-space.
Или ты о каких-то других полуплоскостях?
FordPerfectПостоялецwww5 авг. 201820:13#32
А, полуплоскости, а не полупространства.
В смысле, ты об экранных прямых, edge functions?
}:+()___ [Smile]Постоялецwww5 авг. 201820:15#33
FordPerfect
> Или ты о каких-то других полуплоскостях?
Я о полуплоскостях для растеризации треугольника.
Вообще, весь рендеринг можно сделать без явного получения screen-space координат.
eDmkУчастникwww5 авг. 201823:11#34
>Вообще, весь рендеринг можно сделать без явного получения screen-space координат.
Это как? Без приведения к NDC понимаю, а без screen-space как? Это же фактически не используя проекцию получается?
}:+()___ [Smile]Постоялецwww6 авг. 20187:49#35
eDmk
> Это как?
Это без деления на w.

Т. е. все коэффициенты в уравнении [cht]Ax+By+C[/cht] для edge-функций, обратной глубины, текстурных координат (деленных на глубину), получаются напрямую через однородные координаты.
Такой метод обладает тем преимуществом, что точки с отрицательной глубиной за камерой являются штатным случаем не требующим никакой специальной обработки.

innuendoПостоялецwww6 авг. 20188:26#36
}:+()___ [Smile]
> Вообще, весь рендеринг можно сделать без явного получения screen-space
> координат.

растеризовать в screen-space не проще ?

eDmkУчастникwww6 авг. 201811:52#37
>Это без деления на w.

Я тоже на этом застрял.
Никак перевернуть не могу треугольник в -Z, чтобы матрица переноса корректно отобразила.
Она рисует его с вывернутой нормалью. Наизнанку короче.

+ Показать

Правка: 6 авг. 2018 11:55

BernsПостоялецwww6 авг. 201817:50#38
Для отсечения задних граней:
  float ax = x1 - x0;
  float ay = y1 - y0;

  float bx = x2 - x0;
  float by = y2 - y0;

  float z = ax * by - ay * bx;
  z = (x1 - x0) * (y2 - y0) - (y1 - y0) * (x2 - x0);
  if (z >= 0) return;

Правка: 6 авг. 2018 18:08

BernsПостоялецwww7 авг. 201817:05#39
В общем, такие результаты по времени прохождения 100 циклов этой сцены в разрешении 900x512:

0.85 сек (полный рендер), формат буфера индекса unsigned short.
0.7 сек (без записи в буфер индекса).
0.25 сек (без depth-текста с буфером индекса в формате byte.

судя по всему, сосет пропускная способность оперативки DDR3-1333. Так же, производительность при приближении к чайнику в упор страдает катастрофически.

eDmkУчастникwww7 авг. 201817:47#40
>судя по всему, сосет пропускная способность оперативки DDR3-1333.
От скорости памяти не зависит пропускная способность. Она зависит от строения шины.
У меня DDR-4 2666. Теоретическая пропускная способность около 21 Гб/с, а на деле всего 15 Гб/с.
В вашем случае должно быть раза в ~2 медленнее.

Для сравнения:
GTX 980 Ti - 336.5 Гб/с.
GTX 1080 Ti - 484.0 Гб/с.
GTX Volta - 900 Гб/с.
AMD Vega10 - 1 Тб/с.

Скорость памяти у CPU и GPU примерно одинаковая,
а шина на видеокарте пропускает в десятки и сотни раз больше.
Ибо там куча параллельно работаюших блоков.

Я тоже с софтрендером бился долго - пустая трата времени. Только для отладки или учебы для понимания процессов.
Максимум, который я смог выжать из своего Core-i7 G6950X-Extreme 3.00GHz - это, 2560×1600×32 × ~60 fps 300к полигонов в 20 потоках.
Это примерно ~8 млн полигонов в секунду.
Это с XMM-оптимизацией. Обмен данными через регистры. Почти без переменных.

Правка: 7 авг. 2018 18:12

BernsПостоялецwww7 авг. 201821:02#41
Из курса ассемблера и системного программирования, я помню, что на x86-64 очередной mov в память занимает 3 такта процессора, будь он хоть из 8-битного регистра, хоть из 64-х  - параллельно влетит в память. Может будет разумнее запаковывать в какой-нибудь 32 или 64-битный формат и записывать в массив одновременно - нужно проверить. Для задач вроде occlusion culling софтверный рендер должен подойти - там разрешение куда ниже, нужен только буфер глубины (и тот можно сделать 16-битным) + индексный буфер, да простейшие оклюдеры по 100 полигонов максимум. В battlefield размер сфотверного буфера 256 x 114, у меня эта игрушка вполне 80-120 кадров выдает
А ваши цифры сходятся.  Теоретически, 35-50% времени в моем случае тратятся на очистку буфера глубины
BernsПостоялецwww7 авг. 201821:43#42
Поколдовал с этим еще немного.  Подсунул какую-то константу и уже рисует 270 раз в секунду.
BernsПостоялецwww8 авг. 201821:49#43
Прокачал рендер до 300 рисовок в секунду. Таки одномерные массивы рулят.
BernsПостоялецwww10 авг. 201822:15#44
Закончил с оптимизациями, вышло 350 рисовок в секунду при разрешении 900x500. Без многопоточки. Сравнил с рендером Directx - в принципе идентично. Что дальше? Просканить и сгенерировать список индексов? В мануале DICE окклюдеры  чуть меньше реальной геометрии, но какой в этом смысл?
Страницы: 1 2 3

/ Форум / Программирование игр / Графика

2001—2018 © GameDev.ru — Разработка игр