exit() в библиотечном коде не даст почти ничего сделать вызывающему коду, не кинет исключение, не вернет ошибку, не вызовет деструкторы у переменных на стеке. Даже в лог ничего осмысленного записать не выйдет. Плюс если это мультитред, то судя по этому: www.cplusplus.com/reference/cstdlib/exit это может еще и к race condition привести
Метод в gpugems работает для плоских фигур со сплайновыми границами. Для сплайновых поверхностей можно использовать патчи, тесселируемые в геометрической части конвеера, но там только прямоугольные патчи и это в итоге все равно получается триангуляция, просто динамически создаваемая (ну и геометрические шейдеры не слишком дешевые). Трехмерный BREP с произвольными сплайновыми патчами растеризовать без триангуляции это уже крайне нетривиальная задача, даже в кадах таким не заморачиваются, разве что если качественный рендеринг потребуется, но там вообще рейтрейс и не реалтайм. Короче, слишком много приседаний ради неочевидного профита. (количество информации сокращается конечно, но все равно текстуры съедят гораздо больше, если говорить об играх, а вычислительная нагрузка возрастет) Но вообще не треугольная растеризация в играх есть, можно в пример привести тот же Claybook, но там идет трассировка SDF, а не brep
Ну тут спорный вопрос, обычно нужно смотреть документацию к конкретной функции, бывает, что для семантики «тут ничего нет» нужно указывать не NULL, а вообще какой-нибудь INVALID_HANDLE_VALUE, который даже нулю не равен.
Вот, например, ярчайший пример: docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-createfilemappinga
Функция на вход принимает handle, указатели и dwordы, возвращает тоже handle. При этом на входе просят передавать не NULL, а INVALID_HANDLE_VALUE в семантике, когда хэндла нет вообще. А на выходе при ошибке для того же типа возвращается NULL. Где здесь логика, я так и не понял. При этом в качестве дефолтного значения для флагов указывается конкретно целочисленный ноль, а не NULL. Легаси во всей красе, как по мне
13 * 4 = 52 проверки переменной на ноль за кадр это не просто быстро, это фактически бесплатно на данный момент. Я даже не уверен, что поддержка мэпа не обойдется дороже, если там будут постоянно добавляться/удаляться элементы, не знаю, как быстро в шарпе память для элементов мэпа аллоцируется. Пока там не будет хотя бы сотни эффектов на пару десятков персонажей, влияние на производительность даже из статистической погрешности не выберется. Т.е. как способ уменьшения лапши в коде продуманная система баффов/дебаффов это хорошо и удобно, но с т.з. перфоманса скорее всего лучше будет сконцентрировать силы на чем-то еще
Ну зачем же сразу так грубо, как будто я вас тут обидеть хочу. Где здесь связь между hdr и fps? Если речь о видео потоке, то причем тут вообще фпс. Если про реалтайм рендер, то обычно как-то принято в милли/микросекундах давать время работы, но 23 миллисекунды на тонмэп это крайне щедрый бюджет получается. Отсюда и вопрос, что конкретно вы имеете ввиду.
Немного не понял про 100 и 30 фпс, если честно. Это перекодирование видео из 100 фпс в 30, реалтайм обработка генерируемого на ходу видеопотока, которая ест по 3 кадра или еще что-то?
У локальных алгоритмов тоже свои проблемы есть, при неаккуратном обращении вылезают различные артефакты, вроде гало. Видел статью про тон мэппинг в god of war, там пришлось скопировать настраиваемые алгоритмы из адобовского лайтрума, которые очень хорошо работают, и все равно были артефакты, ради которых пришлось делать специальные источники освещения, влияющие на тонмэппинг (https://bartwronski.com/2016/08/29/localized-tonemapping/).
Да и зрительная система человека проводит слишком мудреную работу при наблюдении реальной сцены, идеально ее смоделировать очень сложно. И к тому же, очень часто тон мэппинг относится вообще к ответственности художника по освещению, потому что разная коррекция ведет к разному ощущению от сцен. Это я все к тому, что при отсутствии ясной художественной цели обычный глобальный тон мэппинг вполне подойдет, разве что среднюю яркость по сцене учесть бы надо, ну и вообще если уж работать в hdr, то яркость источников неплохо было бы привязать к реальным физическим параметрам, хотя бы примерным, а не к магическим константам вроде 1, 5 или 15
The scene is made up of 20 elements containing meshes with more than 90 million unique
quads and triangles along with 5 million curves. Many of the primitives are instanced many
times giving rise to a total of more than 28 million instances of everything from leaves and
bushes to debris and rocks. When everything is fully instantiated the scene contains more than
15 billion primitives.
90 миллионов квадов/треугольников. 20 действительно маловато для фильмовой сцены. Плюс все это хранится в .obj (геометрия всмысле), который текстовый, что тоже увеличивает вес по сравнению с бинарными форматами
Способ конечно забавный, но неужели рендер и последующее чтение из текстуры получается быстрее и лучше чем простой рейкаст до источника? Получается 1 рейкаст до каждого источника, источников конечно может быть в сцене много, но не запредельное количество. 40 мс на 1 детектор выглядит как оверкилл, даже если делать это раз в секунду. Это же все равно скачок времени на рендер одного кадра получается. Рейкасты хотя бы можно раскидать по разным фреймам, чтобы сгладить просадку. Я юнити ковырял мало, но там разве над коллайдерами внутри нет какой-то ускоряющей структуры для рейкастов? Это же вроде бы не должно быть дорогой операцией.
Это перевод, разработчика наверное где-то здесь можно спросить: allenchou.net
Учитывая, что это first-party студия для sony, вероятность появления их игр на пк почти нулевая. Про внутренние дебажные билды на пк за naughty dog говорить не могу, но наверняка есть. Для того же horizon zero dawn от guerrilla games точно есть, у них в каком-то видео мелькало, да и не думаю что на девкитах ps4 удобно дебажить. Другое дело что эти билды наверняка не оптимизированы совсем на нижних уровнях, да и выпускать их точно не будут, разве что утекут как-то.
Я думаю имеется ввиду, что при чтении из кэша L1 (где уже все хранится в линиях) можно, например, замувать 64 бита в rax, а можно 128 в sseшный регистр. И вопрос в том, будут ли обе эти инструкции выполняться одинаковое время при прочих равных, если данные уже находятся в одной кэш линии? То, что внутрь кэша быстрого из кэша медленного/ram читается кэш-линиями вроде бы и так понятно
Не совсем, счетность множества предполагает, что каждому элементу множества можно проставить в соответствие натуральное число. Pi/4 в таком алгоритме не имеет натурального числа в принципе, как раз потому что этот алгоритм дает числу конечный номер только в том случае, если дробь конечная
Возник вопрос по поводу самоосвещения. Направление полусферы конусов расчитывается исходя из локальной нормали, взятой из g-buffer'а, в которой уже учтены нормал мапы. Отсюда выходит, что при заметном отклонении локальной нормали от нормали к треугольнику меша часть конусов пойдет трассироваться прямиком внутрь меша. Не лучше ли будет фильтровать такие конусы, ведь ничего корректного мы из них все равно не получим?
Попробовал сам сделать это, но разница в результатах получается недостаточно очевидная, плюс я не уверен, что не накосячил с ambient occlusion при правках шейдеров.
Можно поменять местами id.x и id.y внутри kernel'а и делать так: var = buffer[id.y * height + id.x]
Правда, в таком случае надо об этом везде помнить, да и разные алгоритмы могут требовать разной укладки многомерного буффера в памяти. В некоторых случаях выгода от локальности данных внутри варпа может быть настолько большой, что имеет смысл в рантайме менять раскладку данных внутри буффера.
Вот, например, ярчайший пример:
docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-createfilemappinga
Функция на вход принимает handle, указатели и dwordы, возвращает тоже handle. При этом на входе просят передавать не NULL, а INVALID_HANDLE_VALUE в семантике, когда хэндла нет вообще. А на выходе при ошибке для того же типа возвращается NULL. Где здесь логика, я так и не понял. При этом в качестве дефолтного значения для флагов указывается конкретно целочисленный ноль, а не NULL. Легаси во всей красе, как по мне
Для DirectX11: docs.microsoft.com/en-us/windows/desktop/direct3d11/texture-block-compression-in-direct3d-11
Для OpenGl тоже поддержка есть
Да и зрительная система человека проводит слишком мудреную работу при наблюдении реальной сцены, идеально ее смоделировать очень сложно. И к тому же, очень часто тон мэппинг относится вообще к ответственности художника по освещению, потому что разная коррекция ведет к разному ощущению от сцен. Это я все к тому, что при отсутствии ясной художественной цели обычный глобальный тон мэппинг вполне подойдет, разве что среднюю яркость по сцене учесть бы надо, ну и вообще если уж работать в hdr, то яркость источников неплохо было бы привязать к реальным физическим параметрам, хотя бы примерным, а не к магическим константам вроде 1, 5 или 15
90 миллионов квадов/треугольников. 20 действительно маловато для фильмовой сцены. Плюс все это хранится в .obj (геометрия всмысле), который текстовый, что тоже увеличивает вес по сравнению с бинарными форматами
Учитывая, что это first-party студия для sony, вероятность появления их игр на пк почти нулевая. Про внутренние дебажные билды на пк за naughty dog говорить не могу, но наверняка есть. Для того же horizon zero dawn от guerrilla games точно есть, у них в каком-то видео мелькало, да и не думаю что на девкитах ps4 удобно дебажить. Другое дело что эти билды наверняка не оптимизированы совсем на нижних уровнях, да и выпускать их точно не будут, разве что утекут как-то.
Возник вопрос по поводу самоосвещения. Направление полусферы конусов расчитывается исходя из локальной нормали, взятой из g-buffer'а, в которой уже учтены нормал мапы. Отсюда выходит, что при заметном отклонении локальной нормали от нормали к треугольнику меша часть конусов пойдет трассироваться прямиком внутрь меша. Не лучше ли будет фильтровать такие конусы, ведь ничего корректного мы из них все равно не получим?
Попробовал сам сделать это, но разница в результатах получается недостаточно очевидная, плюс я не уверен, что не накосячил с ambient occlusion при правках шейдеров.
var = buffer[id.y * height + id.x]Правда, в таком случае надо об этом везде помнить, да и разные алгоритмы могут требовать разной укладки многомерного буффера в памяти. В некоторых случаях выгода от локальности данных внутри варпа может быть настолько большой, что имеет смысл в рантайме менять раскладку данных внутри буффера.