Войти
ПрограммированиеФорумГрафика

Архитектура GPU рейтрейсера.

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 Следующая »
#0
18:30, 18 мая 2012

Хочется реализовать следующую идею GPU рендера:
Шаги:
1. Генерируем сэмплы.
2. Рейтрейсим все сэмплы и точки пересечения добавляем в список.
    Т.е. у нас в итоге получается массив всех точек пересечения (храним нормаль, позицию, материал и т.п.)
3. Шейдинг всех точек пересечения. Применяем нужный шейдер для всех элементов списка, полученного на пред. этапе.
4. Сборка сэмплеров и их резолв на экран.

Вроде бы все просто. Но косяк очевиден в пункте 3, в случае, если шейдинг материала зависит от некоторой дополнительной трассировки, как для отражения или прозрачности. И вот тут не понятно как быть. По идее нам надо либо ко 2му этапу нагенерить все возможные вектора, которые надо трассировать, либо как-то по середине шейдера сохранить состояния, сгенерировать новый сэмпл, потом вернуться на шаг 2, затем уже востановить состояние каждого шейдера и продолжить работу (а это вообще как-то нереально сделать на ГПУ).

Может у кого-то есть идеи или он знает как надо делать?


#1
18:44, 18 мая 2012

Если рассматривать только отражения (или только преломления) то ты просто в отдельном буфере (или текстуре) сохраняешь коэффициент отражения.
Потом новые лучи трейсишь и добавляешь к результату новое значение, умноженное на этот коэффициент. То есть вся математика аддитивна и работает по принципу "+=".

float3 color(0,0,0);
float3 k(1.0f, 1.0f, 1.0f);
 
for(int i=0;i < MAX_REFLECTION_DEPTH;i++)
{
  Hit hit = RaySceneIntersection(ray);
  
  color += k*Shade(hit_point, hit.normal);  
 
  ray = reflect(ray, hit);
  k *= hit.material.reflection;
}
Если преломления и отражения одновременно нужно делать тогда все плохо.
Для первого баунса можно нарисовать 2 фулл-скрин квада. В одном из них трейсить отражения, в другом преломления. результат сблендить.
#2
20:36, 18 мая 2012

FROL
> То есть вся математика аддитивна и работает по принципу "+=".
Да, но это только в случае, когда шейдер заранее известен. Теряется универсальность.

Единственное решение, которое я вижу - это материалы по типу как в редакторе Unreal Engine'а. Т.е. мы добавляем в материал какой-то входной параметр и формулу по которой он считается, тогда мы можем составить дерево всех необходимых сэмплов для каждого материала. Это нас даст возможность сгеренить все необходимые трассировки перед 2м этапом.

#3
21:59, 18 мая 2012

VirT
> Да, но это только в случае, когда шейдер заранее известен. Теряется
> универсальность.
Да нет, почему? Приведи пример когда это не сработает.

#4
23:14, 18 мая 2012

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

#5
0:17, 19 мая 2012

VirT
> мне придется добавлять дополнительный пасс в рендер, который будет считать SSS
> и добавлять его к необходимым материалам.
Так как раз наоборот так универсальность не теряется. У тебя таких пассов может быть много и они могут даже отключаться по какой-нибудь галочке.
А каждый пасс будет просто добавлять цвет в результирующий буфер с учетом каких-то коэффициентов. То есть даже не придется фиксить код шейдеров.

#6
4:40, 19 мая 2012

Копай в этом направлении: http://iquilezles.org/www/material/nvscene2008/rwwtt.pdf
Да и вообще по сайту покопайся. Найдешь для себя все что нужно.
Вкратце объясню идею:
1) Есть сеймпловый рейтрейсер. Да. Все векторы трейса строятся непосредственно в шейдере.
2) Есть меш, который посредством CUDA или ещё чего при загрузке переформатируется в краткий массив точек удаления.
3) Пользуем так называемый distance-aided ray marching. Суть его в том, что мы высчитываем длину следующего шага по лучу как результат функции полей дистанции по принципу "А все равно никакой точки ближе чем по радиусу ближайшего расстояния - нет, ибо такова суть DF - она возвращает длину перпендикуляра к поверхности в любой проверяемой точке пространства".

DF0001 | Архитектура GPU рейтрейсера.

Вот пример. Импостинг в кавычках. На самом деле точно также трейсится по полной. Фпс где-то 80 было. На луч приходится где-то 16-20 шагов. Точность до 0,001.

Как вкусняшка идет сильное облегчение всех радостей написания шейдеров для меш-моделей. Вот так вычисляется AO:

float calcAO( in vec3 p, in vec3 n, float k, float d, float t )\
{\
  float s = 0.0f;\
  \
  for( float i = 1.0f; i < t + 1.0f; i += 1.0f )\
    s += (( i*d - map( p + n*i*d ).x)/pow( 2.0f, i ));\
  \
  return 1.0f - k*s;\
}\

Короче - все круто. XD

#7
16:02, 23 мая 2012

FROL
> Так как раз наоборот так универсальность не теряется. У тебя таких пассов может
> быть много и они могут даже отключаться по какой-нибудь галочке.
Ок, а как ты посчитаешь отражение? Т.е. тебе же для цвета отражения тоже надо подсчитать все компоненты в точке пересечения отраженного вектора, а там уже пассов нет никаких.

DinometaElasticGlass
> Короче - все круто.
Если я правильно понял ) То у тебя все трейситься прямо в шейдере материала. А я так не хочу ) Хочу отдельно протрейсить все лучи, потом в материалах уже считать финальный цвет.

> Фпс где-то 80 было.
Действительно круто, что аж не вериться ) Есть демка?

#8
16:09, 23 мая 2012

DinometaElasticGlass
Подтверждаю - реймарчинг (sphere tracing, если быть точным) отличная и очень легкая техника.
Видел огромное количество демок с её использованием.

Сам тоже пробовал.

VirT
> Есть демка?
Могу поскидывать демки с пуета (уже полностью законченные работы с этой техникой).
Мне не удавалось добиться большого фпс (на не очень сложных сценах), но в любом случае это было на порядок больше чем у обычных трейсеров.

П.С.
DinometaElasticGlass
Интересно было бы увидеть сам шейдер.

#9
16:20, 23 мая 2012

VirT
рейтрейсом на ГПУ еще не занимался, поэтому пока что просто вопрос:
почему на 2 шаге нельзя сразу же и шейдить?
ведь что бы сгенерировать абсолютно все лучи, все равно придется учитывать свойства материала \

#10
16:37, 23 мая 2012

horizonOffset
> Могу поскидывать демки с пуета (уже полностью законченные работы с этой
> техникой).
Да, давай ) было бы интересно потестить.

Ruslan
> почему на 2 шаге нельзя сразу же и шейдить?
Можно и многие так делают. Но по моему внутреннему ощущению, это не соответствует архитектуре GPU. Т.е. хочется решать одинаковые задачи, либо рейтрейсим, либо шейдим, и на каждый этап хочется иметь свою отдельную систему и шейдера. Иначе же получается, что один шейдер и шейдит и генерит сэмплы и рейтрейсит их. Хочется избежать большого стека вызовов и рекурсий, которые вообще не поддерживаются на DX11.

#11
16:42, 23 мая 2012

VirT
может тогда просто нагенерировать заранее заданное количество семплов для одного пикселя (по полусфере), а на 3 шаге отбрасывать те сэплы, которые не удовлетворяют условиям определенного материала?
на 2 шаге перерасход, зато однотипная задача, к тому же один раз посчитав сэмплы, можно будет менять материалы и их свойства без повторного рейтрейса сэмплов.

#12
16:57, 23 мая 2012

Ruslan
> может тогда просто нагенерировать заранее заданное количество семплов для
> одного пикселя (по полусфере), а на 3 шаге отбрасывать те сэплы, которые не
> удовлетворяют условиям определенного материала?
Нет, так не получится, т.к. тебе надо генерировать сэмплы не только для тех объектов, которые ты непосредственно видишь, но и для тех, которые видны в отражениях, например. Т.е. когда мы считаем отражение для нашего текущего материала, это не просто трейсим луч и берем диффуз составляющую для того объекта в который попали. Мы для каждого hit'а должны запустить шейдер материала, который опять может включать отражения и мы тогда снова генерируем сэмплы.
Надеюсь не слишком запутанно объясняю )

#13
17:01, 23 мая 2012

VirT
> Да, давай ) было бы интересно потестить.
http://pouet.net/prod.php?which=55758 - наверное лучшая (ИМХО) интра (кстати, как я понял - авторы наши соотечественники)
http://www.pouet.net/prod.php?which=53937
http://pouet.net/prod.php?which=52938 - тоже очень хорошая работа с достаточно хорошим фпс (намного больше чем в cdak)

Первое, что пришло на ум. Мне сейчас нужно уходить, может потом ещё скину, если вспомню.

UPD: http://glsl.heroku.com/ - много разных процедурных набросков в том числе и с марчингом.

#14
17:01, 23 мая 2012

VirT
я предположил, что можно сгенерировать все сэмплы, в том числе и для отражения (не учитывая тот факт, что материал не отражает.. а вдруг будет посже отражаь :))

horizonOffset
да, впечатляет sphere tracing
но это как же нужно извратиться при моделировании сцены? просто в 3dsMax уже не намоделишь :)

Страницы: 1 2 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.