суббота, 31 декабря 2016 г.

one more adaptive anti-aliasing

sunflow\src\org\sunflow\core\renderer\BucketRenderer.java
когда akari-based antialias залипает на одинаковом количестве мин и макс семплов, то я включаю антифриз - другой алгоритм антиалиазинга - AdaptiveDistributedRender. можно его дополнить алгоритмом антиалиазинга из sunflow render
или более простым, который сравнивает соседние пикселы и если резкая разница, добавляет количество семплов

HDRI освещение, Image Based Lighting, Environment mapping, UPBP, pbrt и благодарности

Сводка недоступна. Нажмите эту ссылку, чтобы открыть запись.

пятница, 30 декабря 2016 г.

наследие smallvcm

так как мой рендер на основе smallvcm, то внимательно читая исходники, нахожу нелепости и упрощения.
например, цвет фона - если луч не попал ни в один обьект - почему-то голубой.
может Tomas Davidovic так определял, что дырка в обьекте или Environment map не покрытое место.
как бы там ни было, там нужен чёрный-пречёрный цвет


UPDATE. Как оказалось, тот голубой BackgroundLight освещал сцену 3.


Записал установку такого цвета BackgroundColor при создании сцены - так вернее.
ибо в конструкторе BackgroundLight цвет устанавливать не гоже.

понедельник, 12 декабря 2016 г.

как ускорить free pascal/lazarus программу в 2 раза

в free pascal/lazarus есть удивительная опция. называется она целевая платформа.
если выбрать ту платформу, под которой будет работать программа, или достаточно выбрать x86_64 и скомпилировать, то программа заработает в 2 раза быстрее.
в исходном коде не нужно для этого ничего менять
а вот 2 скриншота, показывающие результат

воскресенье, 11 декабря 2016 г.

small mlt на free pascal

пришла мне идея проверить скорость работы free pascal compiler по сравнению с gcc на с++.
напишу pascal-версию small mlt для проверки на скорость.
для проверки раньше использовал другие рендеры на lazarus/free pascal и включение одной опции компилятора добавило 690 кб к размеру exe и невиданую доселе скорость работы получившейся программы - всего на 20% медленнее c++ версии алгоритма.
алгоритм был реализован неаккуратно и с точностью тех тестов согласиться не могу.
поэтому напишу своё. может пригодиться впоследствии.
заодно проверю перезагрузку операторов

понедельник, 5 декабря 2016 г.

hash maps

оказывается, ассоциативные массивы с ключом-строкой могут быть быстрее unordered_map <std::string, int>
unordered_map <std:string, int> map1;
 
    printf("std hash func... ");
 
    clock_t t0=clock();
 
    for(i=0;i < n;i++)
        str = ltoa(i);
        map1[str]=i;
    } 

если хранить индекс, как int со значением из хэш-функции, то можно достигать до 4х-кратного повышения скорости работы
unordered_map <uint32_t, int> map3_3;
 
    printf("X31_hash_string hash func... ");
 
    clock_t t20_3=clock();
 
    for(i=0;i < n ; i++)
        str = ltoa(i);
        map3_3[X31_hash_string((char*)str.c_str())]=i;
    }

и функция расчета хэша, которую я взял из проекта khash.h, выглядит просто и работает быстро и создаёт мало коллизий:
typedef uint32_t khint_t;
 
uint32_t X31_hash_string(const char *s)
{
 
    khint_t h = *s;
    if (h) for (++s ; *s; ++s) h = (h << 5) - h + *s;
    return h;
} 

xxhash оказался не очень быстрым, хоть и качественный, почти как и другие сравниваемые алгоритмы хеширования
sz означает количество элементов
если их меньше 5000000 - количество добавляемых элементов - то коллизии-наложения и ошибки
fletcher32 оказался не очень быстрым и к тому же создаёт много коллизий. не нужен!
X31_hash_string оказалась и быстрее, и хороша - мало коллизий(0)

скачать source code of tests on c++

пятница, 2 декабря 2016 г.

сначала связать, затем оптимизировать

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

данный принцип похож на непрерывную интеграцию - одно из правил экстремального программирования