- The Andreyp
- Постоялец
Каких других техник?
The Andreyp
> 2015 году - SSAO на фоне других техник
SSAO есть SSAO, а всякие HBAO, HDAO - это один из способов реализации SSAO, назвали по другому для удобства просто.
Sergio
если реалтайм как ссао - то
cone tracing , Light Propagation
forhaxed
> Сколько не читал пайперы - так ничего и не понял :(
Да, разбираться в чужом коде\пейпере то еще занятие. Но с другой стороны, это же интересно, следить за мыслью другого человека, вместе с ним пройти путь по реализации той или иной техники, взглянуть на задачу его глазами. Порой много интересного и полезного для себя можно почерпнуть, занимаясь этим на первый взгляд тяжелым делом. Но оно того стоит. Я сам чайник еще в этих 3д графиках)). Образование художника, но природное любопытство да и род деятельности подвигло меня на изучение компьютерной графики. Свой ssao пилил долго и мучительно и не с первого раза он получился приемлемого качества, но в процессе творчества я выработал для себя несколько простых правил. Они не новы, многие их знают, я просто напомню их самому себе и заодно поделюсь ими с теми, кто еще не дошел до них сам. Они очень помогают мне не только в программировании но и в других областях жизнедеятельности(правила достаточно общие) и перед началом восхождения на очередную непокоренную вершину стараюсь держать их в голове.
1. Важно вначале вникнуть в основную концепцию, метод, с помощью которого добиваемся нужного результата. Проще говоря - что делать то нужно. Очень помогает на данном этапе рисование схемок.
2. Параллельное изучение теоретической части и практическая реализация техники. Сколько схемок не рисуй, или пайперов и чужих шейдеров не читай, но пока ты сам не напишешь рабочий код программы, считай - ты ничего не понял окончательно на 100 процентов.
3. Разбиение большой задачи на промежуточные шаги. Так проще и быстрее отследить место ошибки если она\они будут допущены.
4. Часто в самом начале изучения вопроса от сильного желания побыстрее все сделать самому мы забываем про народную мудрость - "семь раз отмерь, один-отрежь", "без труда не выловишь и рыбку из пруда", и наконец "держи ноги в тепле, а голову - в холоде". Как говорят американцы - будь спокоен. Большое желание освоить незнакомую технику может как помочь, так и навредить, поскольку слишком сильное эмоциональное перевозбуждение мешает мыслить логично и конструктивно, а значит плодотворно.
5. Неизвестно как много времени уйдет на реализацию метода. В любом случае, никто не мешает отложить на время один вопрос, чтобы отдохнуть от него, чтобы в голове все упорядочилось, и заняться другими вопросами. Кто знает - возможно занимаясь другой техникой, мы вдруг осознаем те детали, незнание которых не позволяло нам решить возникшую проблему.
Тебе данная то статья помогла разобраться в вопросе, или так и не понял. Если честно, то я сам пока в метод от Sergio не слишком вникал. Это связано с тем, что с этим вопросом я более или менее разобрался. Хотя кое-что из этой статьи я для себя отметил и использовал в своей реализации.
Zar
> Если честно, то я сам пока в метод от Sergio не слишком вникал.
Так тут метода никакого и нет по сути. Тут самая простая имплементация.
TheGrayWolf
+1 :)
А есть аналогичные реализации, где в viewspace считают?
g-cont
это как?
скринспейс в данной ситуации это просто факт юзания экранных глубины/нормалей, а дальше эти данные можно переводить в тот же ворлдспейс и вычислять.
Che@ter
> Советую сделать multiresolution ssao - там можно без размытия с лучшим
> качеством и/или скоростью.
Я так понимаю, при таком подходе для пикселей, лежащих на глубине с небольшой разницей, берутся меньшие по разрешению мип копии G-буффера, а для пикселей лежащих на границах большого перепада глубины - оригинальные или хальф сайз текстуры, верно?
TheGrayWolf
> Хрена ты мыслитель ваще крсвчк.
=3 Да бывает находит иногда.
Sergio
> Так тут метода никакого и нет по сути. Тут самая простая имплементация.
Это верно, вот как раз посидел сегодня, почитал повнимательнее и подразобрался. Основное отличие твоей имплиментации от виданных мною раньше в том, что ты не используешь отдельного массива для определения вектора при расчете семплов от исходного пиксела , а юзаешь всё ту же текстуру шума. Это прикольно - я оценил. В других вариациях, которые мне попадались, чтобы найти новую позицию образца от нормали шумовой текстуры отражали случайный вектор, хранящийся в массиве (в том же Crysis например), либо собирали матрицу вращения исходя из нормали в текущем пикселе и вектора из шумовой текстуры. Но вот по поводу сравнения глубины семпла и прочитанной глубины из текстуры - тут возникают сомнения по поводу эффективности данного способа. Сейчас объясню почему. Дело в том, что при использовании такой проверки мы конечно избавляемся от нежелательного затенения тех участков поверхности, которые не должны быть затенены. Но для красивого мягкого результата требуется большое количество выборок на пиксель(64 и выше), так как большое количество выборок просто не пройдут теста и не дадут никакого вклада в затенение. Куда логичнее использовать метод, описанный вот здесь http://steps3d.narod.ru/tutorials/ssao-tutorial.html. Конкретнее - у нас есть позиция пикселя, для которого рассчитываем затенение и позиция проекции семпла. Вычитаем из одной позиции другую, получаем вектор от пикселя к образцу. Далее считаем скалярное произведения этого нормализованного вектора(предварительно сохранив его длину для проверки расстояния)и нормали центрального пикселя и помножаем вклад в затенение на полученный коэффициент.
float3 samplePosMap=tex2D(Texture4,sampleUV);
//вычтем из позиции обрабатываемого пикселя
//позицию из текстуры
float3 ToCenter=samplePosMap.xyz-Pos.xyz;
//чтобы избежать эффекта хало
//измерим расстояние между пикселом
//и окклюдером
float d=length(ToCenter);
//нормализуем вектор
ToCenter/=d;
//рассчитаем скалярное произведение нормали в точке
//и полученного вектора и умножим на полученное значение
//вклад затенения
//это позволит избавится от затенения тех точек которые
//не нависают над обрабатываемой точкой
float normAtten=clamp(dot(Normal,ToCenter),0,1);
//если расстояние меньше максимального значения вклада в затенение
//то считаем затенение
if(d<maxOcclusionDist)
{
//чем дальше окклюдер тем меньше затенение
ao+=(1-(d/maxOcclusionDist))*normAtten*OcclusionScale;
}
}
ao/=NUM_SAMPLES;
return 1-ao;Demiurg-HG
> Executor
> > Это совершенно разные вещи.
> Нет, как раз они очень близки.
Согласен с демиургом. Что тут трассировка глубины, что там.
Sergio
Модернизируй метод до многопроходного.
Например 4 прохода по 8 выборок. 8^4 ->4096 условно выборок на точку.
Просто при расчете освещенности от выборки учитываешь ее освещение от предыдущего прохода.
При учете самой точки учитываешь освещенность от выборок и освещенность самой от предыдущего прохода.
Выборки должны распределены быть нормально как по отдельности на проход так и все вмести.
Я еще дальше делал, брал для первого прохода из предыдущего кадра, точку переводил в пространство на предыдущем кадре и проецировал.
Но там надо иметь хотя бы 2набора выборок чтобы их чередовать.
Потом добавил микро сдвиг камеры по треугольнику, получил еще и сглаживание.
Сделал "interleaved rendering" по вот этой доке:
https://developer.nvidia.com/sites/default/files/akamai/BAVOIL_Pa… cientPost.pdf
Получилось вот так (без размытия) - 64 семплов на пиксель, 124 кадра в секунду на NVidia 750M
Sergio
> 124 кадра в секунду на NVidia 750M
Указать % ускорения требуется по сравнению c non interleaved
Тема в архиве.