работаю над новым методом антиалиазинга - contour_map

сцена 8. 8 часов 50 минут

рендер местами далёк от совершенства...

воплотил подобие path reuse, как было описано еще в документе 2002 года

Accelerating Path Tracing by Re-Using Paths
Philippe Bekaert, Mateu Sbert, and John H. Halton. Accelerating path tracing by re-using paths. In Rendering Techniques, pages 125–134, 2002

в vertexcm.hxx из SmallVCM
написано:


                // Vertex connection: Connect to light vertices
                if(!bsdf.IsDelta() && mUseVC)
                {
                    // For VC, each light sub-path is assigned to a particular eye
                    // sub-path, as in traditional BPT. It is also possible to
                    // connect to vertices from any light path, but MIS should
                    // be revisited.
                    const Vec2i range(
                        (pathIdx == 0) ? 0 : mPathEnds[pathIdx-1],
                        mPathEnds[pathIdx]);

я же переписал этот момент так:

                // Vertex connection: Connect to light vertices
                if(!bsdf.IsDelta() && mUseVC)
                {
                    // For VC, each light sub-path is assigned to a particular eye
                    // sub-path, as in traditional BPT. It is also possible to
                    // connect to vertices from any light path, but MIS should
                    // be revisited.

pathIdx123 = pathIdx;

// *экспериментально! range - здесь вписать пробную проверку на соседние пикселы
if(pathREUSE)
{
if(screenSample.x<(FLOAT)xx && xx>0)
pathIdx123--;
else
if(screenSample.x>(FLOAT)xx && xx<resx-1)
pathIdx123++;

if(screenSample.y<(FLOAT)yy && yy>0)
pathIdx123-=resX;
else
if(screenSample.y>(FLOAT)yy && yy<resy-1)
pathIdx123+=resX;
}


                    const Vec2i range(
                        (pathIdx123 == 0) ? 0 : mPathEnds[pathIdx123-1],
                        mPathEnds[pathIdx123]);

разница - проверять очередной семпл, к какому пикселу он ближе и использовать не самого пиксела light path, а пикселов, к которым семпл ближе.

эта техника даёт больше разброс лучей и, как пишут авторы вышеупомянутого документа, 

Metropolis Light Transport - экстремальная версия описываемой техники path reuse

вот несколько результатов для сравнения:
мой небольшой вывод - даёт уменьшение шума и больше деталей. почти без затрат

отличия между изображениями незначительные, но деталей больше в reuse-версиях и они точнее.
надо учитывать и центральный пиксел и соседний пропорционально.
SQRT((screenSample.x-xx)*(screenSample.x-xx)+(screenSample.y-yy)*(screenSample.y-yy)) - коэффициент для соседнего пиксела, (1-SQRT) - для центрального.

сравнение методов антиалиазинга

http://moo.ho.ua/aaa.html
hybrid - это из 5 итераций 3 - distib, 2 - akari

pepelac render. альфа-версия

мой рендер можно СКАЧАТЬ и запустить!

в этой версии:
* несколько заготовленных сцен
* vertex connection and merging
* hybrid adaptive sampling/antialiasing
* многопоточно и прогрессивно показывает рендеренное в окно
* а еще он умеет вот так:

для того чтобы получить рендер этой сцены, запустил bench-8.bat

СКАЧАТЬ альфа-версию pepelac render
после того, как скачаете, запустите один из bench-файлов

полный список команд рендера можно увидеть, запустив pepelac.exe -h в консоли

std::vector и openMP что-то не поделили

переписать некоторые блоки пора начисто и вместо std::vector использовать обычные массивы.
как раньше, vertices *verts = new vertices[numVertices]
да и работает стабильнее.
долой эти дурацкие std::vector!

akari aaa прийде, порядок наведе

min и max семплов - высокое значение, но разбросаное по всему изображению, в среднем даёт 10-11 семплов на пиксель.
это - чудеса антиалиазинга, основанного на размытой черно-белой версии рендеринга с низким количеством семплов.

#my_weird_rendering AGAIN!!!

#my_weird_rendering
на этот раз - ошибка в просчете стекла

FIXED