Аппаратная трассировка лучей уже реальность. (5 стр)

Горе разрабы даже не могут показать что эти отражения сделаны именно ray-tracing'ом. Мол "поверьте нам наслово". Нужно слишком slow-motion видео чтобы можно было что-то проглядеть. Или надо иметь очки бога, что дать точную оценку.

А так, вот оценка под градусом рюмки коньяка:
Трата бабла: 20/10 (это уже финансовый перебор)
Доказательность: 3/10 (плохо работаем, ребятки, очень плохо)
Возможность подделать: 8/10 т.е. высокая (что-то аргументация толком не убедила)
Зрелищность: 8/10 (ну сказать честно, так себе)
Менеджмент: 1/10 (очень плохо, где ваши менеджеры вообще?)
На скорую руку: очень вероятно
Индусы с поддельными удостоверениями: вероятно вся команда разрабов состоит из таковых

Общая оценка: -2 (даже не два с минусом, а минус два, бюджеты то надо экономить, или хотя-бы распределять поумнее)

gamedevfor
> Всё что не куб или сфера так сразу же затык.
san
> Хм... Эта сцена как раз довольно простая. Вот например нечто похожее:
Где вы видите кубы и сферы (на том же shadertoy), это всё по сути ray marching на signed distance function в различных вариациях, там процедурная геометрия задана (вшита) напрямую в шейдере, по этому её так мало и она простая по форме, но зато она не требует чтения из глобальной памяти и работаешь ты с ней просто как с "встроенной функцией генерации поверхности на лету"...

В случае обычных триангулированных моделей, загружаемых с харда, ты загоняешь их в глобальную память GPU, оттуда во время рендеринга читаешь треугольники каждой нитью шейдера и по сути, для нормального просчёта вторичного света тебе нужно много раз обращаться в глобальную память для чтения инфы о треугольниках (в отличии от классического рендера, где закрашиваешь как правило только один треугольник), что напрочь убивает весь FPS, т.к. обращение к глобальной памяти - !!!очень!!! дорогая операция. Для быстрого доступа к нужным треугольникам делают всякие деревья, типа kd-tree, regular grid, BVH и пр, что бы в шейдере не бежать циклом по всем треугольникам, а выбирать нужный за меньшее время, допустим за O(log N), тем самым сократив кол-во операций чтения из глобальной памяти, но в случае деревьев:
1. Читать приходится random access-ом, то есть ширина шина памяти вообще никак не поможет, а так же можно забыть про оптимизацию по memory coherence /coalesced reads, да и вообще про warp shared memory.
2. Читать всё равно приходится много... Если уж совсем грубо сказать и округлить всё... ну максимум 20 чтений на нить из глобальной памяти инфы средней размерности о треугольнике потянет нормальное железо, а для трассировки лучей чтений должно быть намного больше...
3. Чем круче дерево, тем сложнее операции вставки/модификации и удаления треугольников из него, то есть теряется динамика сцены.

™­•-=MASTER=-•™
> Там процедурная геометрия задана (вшита) напрямую в шейдере, по этому её так мало и она простая по форме, но зато она не требует чтения из глобальной памяти и работаешь ты с ней просто как с "встроенной функцией генерации поверхности на лету"
Ты похоже не понимаешь... Для того, что бы нарисовать такую картинку, сначала надо вести луч от камеры К КАЖДОМУ ПИКСЕЛЮ НА ЭКРАНЕ, на каждом шаге вычисляя ВСЮ геометрию и проверяя, столкнулся луч с чем-то или нет (сотни таких шагов для каждого пикселя), т.е. каждый раз вычисляя ВСЮ геометрию, потом вести два луча (отраженный и преломленный) до пересечения или с источником света либо с другой поверхностью.  Вычисление по формуле всей картинки, это операция "!!!очень!!! дорогая". По сравнению с этим "чтение глобальной памяти" это сущие пустяки...

интересно , потянет ли такую графику GeForce RTX ? :D

san
> Для того, что бы нарисовать такую картинку, сначала надо вести луч от камеры К
> КАЖДОМУ ПИКСЕЛЮ НА ЭКРАНЕ
для построения первичных лучшей? lol ) ну да, сначала нужно вести лучи от камеры до near plane в кол-ве, равном кол-ву пикселей на экране разумеется :)

san
> Вычисление по формуле всей картинки, это операция "!!!очень!!! дорогая". По
> сравнению с этим "чтение глобальной памяти" это сущие пустяки...
Да...вычислять нормаль к одной сфере, заданной выражением

float sdSphere( vec3 p, float s ) {  return length(p)-s; }

проверять дистанцию - это оооОочень дорогая операция, ничего не скажешь...  что за чушь ты городишь, ладно, проехали...  [я не новичок в процедурной графике]

™­•-=MASTER=-•™
> для построения первичных лучшей? lol )
Именно так. Посмотри исходник. Я занимаюсь этой технологией лет десять, так что я знаю о чем говорю. Ты - нет.
Хоть ты и нацепил себе имя "Мастер" да еще с двумя знаками "торговая марка", но похоже до мастера тебе еще очень далеко.

san
> Ты похоже не понимаешь... Для того, что бы нарисовать такую картинку, сначала
> надо вести луч от камеры К КАЖДОМУ ПИКСЕЛЮ НА ЭКРАНЕ
да ну, правда что ли? ))  [вспомогательная фраза]
™­•-=MASTER=-•™
> для построения первичных лучшей? lol ) ну да, сначала нужно вести лучи от
> камеры до near plane в кол-ве, равном кол-ву пикселей на экране разумеется :)
san
> Именно так. Посмотри исходник. Я занимаюсь этой технологией лет десять, так что я знаю о чем говорю. Ты - нет.
ты как бы не понял, что это был сарказм? хмм... что ж позанимайся ещё лет 10 "этими технологиями" и быть может тогда для тебя построение первичных лучшей перестанет быть сверх секретным знанием, ради которого нужно даже рекомендовать посмотреть твой исходник :)

itmanager85
> интересно , потянет ли такую графику GeForce RTX ? :D
Тут как бы нечего тянуть. Такую графику вероятно даже GeForce 256 1999 года выпуска потянет. Вот аналогичные "отражения".

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

™­•-=MASTER=-•™
> для построения первичных лучшей? lol ) ну да, сначала нужно вести лучи от
> > камеры до near plane в кол-ве, равном кол-ву пикселей на экране разумеется
Нет, мой необразованный друг. В данном случае нет никаких "near plane", равно как нет и отдельных обьектов. Есть формула описывающая всю сцену целиком. И ее нужно считать полностью при каждом шаге по лучу. Вот тебе пример картинки сделанной рейтессингом (реймарчингом), найди там отдельные обьекты: 

или:

san
> Ты похоже не понимаешь... Для того, что бы нарисовать такую картинку, сначала
> надо вести луч от камеры К КАЖДОМУ ПИКСЕЛЮ НА ЭКРАНЕ
да ну, правда что ли? ))  [вспомогательная фраза]
™­•-=MASTER=-•™
> для построения первичных лучшей? lol ) ну да, сначала нужно вести лучи от
> камеры до near plane в кол-ве, равном кол-ву пикселей на экране разумеется :)
san
> Именно так. Посмотри исходник.
san
> Нет, мой необразованный друг.

ты там под кайфом что ли? :)

san
У тебя от фракталов голова не болит? Меня через неделю втыкания в эти "формы" потянуло бы на блевотину.

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

Что касается этого рейтрейсинга (который в RTX представили), то, имхо, главное, что он улучшит сейчас - это тени и GI, а отражения с преломлениями не так важны.

v1c
> У тебя от фракталов голова не болит? Меня через неделю втыкания в эти "формы" потянуло бы на блевотину.
Ну так не втыкайся, дело то хозяйское. Что до фракталов, то то, что называют "3D фракталы" к манделброту у джулии имеют очень отдаленное отношение. Там нет четкого самоподобия и губина рекурсии часто всего 3-6. При этом картинка получается удивительно сложной. Собственно на картинках видно. Ну и я привел эти картинки просто что бы показать "мастеру" что его понятия о рейтресинге нуждаются в серьезном улучшении. По этой технологии делаются не обязательно фракталы, но и вполне себе реалистичные сцены типа той, что он привел в качестве эталона.
Что до темы сабжекта, то мое мнение, что рейтресинг через несколько лет будет основным методом вывода графики. Поскольку он имитирует тот физический процесс благодаря которому мы видим мир. Пока в силу слабости железа приходилось идти на упрощения, но скоро прогресс электроники сделает это ненужным.

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

Всю сцену открытого мира на одном RT думаю еще лет 100 не потянет.