Татарин
> сейчас набирает обороты
> https://projects.markkellogg.org/threejs/demo_gaussian_splats_3d.php
Выглядит качественно, но малополезно
Татарин
> сейчас набирает обороты
> https://projects.markkellogg.org/threejs/demo_gaussian_splats_3d.php
Там 3 картинки, а чем они отличаются от обычных?
Это что, онлайн-майнер?
v1c
> Сделай 1000 лучей на пиксель и усреднение даст плавный сигнал. Но где взять
> производительность на всё это?
#2
Вот-вот, значит, проблему ты понимаешь. Хотя и 1000 лучей на пиксель не хватит! Представь на лунном горизонте абсолютно белую башню ОЧЕНЬ малой толщины, и движение камеры туда-сюда. Иногда она вообще "пролезет" между твоими 1000 лучами... и будет всё чёрное. А иногда серое (когда в несколько попадёт). 1000 это всего лишь матрица 30*30 лучей, такое мельтешение вполне может быть. Например, она попадёт в 1 вертикальный ряд из твоей матрицы, т.е. в 30 лучей. Тогда изменение яркости будет одна тридцатая (1/30). Вполне видимо глазу, особенно на фоне чёрного космоса. Где-то rgb#090909 против #000000. И это за тысячекратное увеличение производительности-то!
На самом деле, году в 1999 или даже 1992 (Вольф 3D), с их слабенькой мощностью (и 100% софт-рендерерами), люди бы тоже про современную графику сказали: "Но где взять производительность на всё это?!"
Однако производительность нашли. Алгоритмы (неверный путь), ведущие к муару и глюкам, перенесли на "железо", сделав железо очень дорогим, распараллелили, научились подо всё это писать софт и готовить данные...
#3
Давайте подробней разберём, в чём неадекватность современного подхода?
Сейчас есть как бы "лучи" НУЛЕВОЙ ТОЛЩИНЫ - это важно! - идущие параллельным пучком от фокальной плоскости. Или равномерно расходящимся пучком. Возможно, шейдерами их можно вообще кинуть как угодно, но все понимают, что за лучи и какие их свойства.
Ну и как раньше подразумевал v1c, есть анти-алиалиасинг - пустить 16 лучей вместо одного: пучочком 4*4 (соответственно расходящимся, параллельным или ещё каким). И взять среднее. Что из этого получается, я уже выше показал.
Ну, а я предлагаю немного другой подход, который вместо ошибки "классического" подхода (#000000 вместо #090909 при 1000 лучах на пиксель!!!) даёт АБСОЛЮТНО ТОЧНОЕ значение цвета пикселя. Конечно, с учётом погрешности чисел с плавающей точкой, но это точно не одна тридцатая (по крайней мере, для достаточно простых сцен).
Вы, наверное, уже догадались, как это сделать? Представьте, что вам начальник на работе дал задание: написать рендерер (данные можно хранить в памяти как угодно, совершенно не классическими моделями, вершинами и текстурами, если надо), который АБСОЛЮТНО ТОЧНО (ну хотя бы с погрешностью не более 1/256) дал бы цвет точки. ОТВЕТЫ ДАЛЕЕ
spoiler:
Скажу сразу, модели и вершины (особенно для одноцветных моделей) можно хранить обычным способом
ОТВЕТ (продолжение):
https://gamedev.ru/code/forum/?id=279909&page=2&m=5814033#m26
На самом деле ч. глаз видит четко только небольшое пятно. Если вы в монитор вмонтируете камеру слежения за глазом и будете рендерить только это пятно, а все вокруг "так себе" - то у вас высвободиться 90% мощности карты и проца которую можно направить куда пожелаете.
aleksij
> Если вы в монитор вмонтируете камеру слежения за глазом и будете рендерить
> только это пятно
Да эта тема с gdev-а нашлась у меня вчера, когда гуглил. Было замечено, что границу между "чётким пятном" и остальным экраном глаз, скорее всего, будет видеть как артефакт.
https://gamedev.ru/code/forum/?id=52569
И лучше это отложить для VR-технологий, когда ясно, куда именно смотрит игрок.
Там ещё указывали, что сбоку зато "частота обновления" должна быть, наоборот, больше, т.е. с краю не полностью слабое зрение, а в чём-то и лучше.
Вообще это параллельно моей методике. Немного не о том :)
Ну и, кстати, предположим, что мы говорим о случае выше. Надо в 1000 раз увеличить количество лучей (а лучше в 100 000). И что? Поможет 90%-я экономия? Надо просто алгоритм менять.
Та "башня", о которой я говорю, и весь муар и дрожание, виден именно в туннеле наилучшего зрения.
(особенно мерзко выглядит, если по бокам прямой гоночной трассы одного цвета поставить столбики-чурбачки другого цвета и смотреть в её самую дальнюю точку, в перспективу. Чуть двигаясь, понятное дело, вправо-влево. Ближние чурбачки ещё ничего, а дальние будут пошло мерцать и муариться - всё в тоннеле наилучшего зрения. Пиксель, куда спроецируется вся дальняя часть трассы, будет непредсказуемо менять цвет. Этот эффект обычно подавляют тем, что вообще не рендерят дальние чурбачки. Да, не от хорошей жизни не рендерят дальние мелкие объекты! Не только из экономии!!! Но и ради того, чтобы они там смешно не прыгали, не мерцали и не муарились).
Дезанизатор
> Представь на лунном горизонте абсолютно белую башню ОЧЕНЬ малой толщины, и движение камеры туда-сюда. Иногда она вообще "пролезет" между твоими 1000 лучами... и будет всё чёрное.
Всего лишь проблема каустики, причем в самой тривиальной форме. Соответственно, решается так же тривиально: целенаправленным семплингом источника. Насколько я понимаю, такое, например, Имбирная Ведьмочка
в своем трейсере делал. Вот полноценная проблема каустики уже гораздо сложнее решается.
Если вы в монитор вмонтируете камеру слежения за глазом и будете рендерить только это пятно, а все вокруг "так себе" - то у вас высвободиться 90% мощности карты
А Суслик не против ? :)
}:+()___ [Smile]
> Всего лишь проблема каустики
Я ту проблему, о которой пишу, во множестве игр встречал. И там её не решили.
А где об этой каустике можно почитать?
Интернет выдаёт что-то невразумительное:
https://render.ru/xen/threads/kaustika-problema-s-tenju-pri-ee-raschete.45335/
Ведьмочк сделал, судя по всему, какое-то рандомное отклонение лучей (так сказать, шум). Она при добавлении антиалиасинга даст достаточно приемлемую картинку, но, видимо, это совсем не то, что я предлагаю - у него там опять бесконечно тонкие лучи!
(зато такие лучи могут зеркало отобразить, или сделать подповерхностное рассеивание, а в моём алгоритме пока с этим проблемы).
Дезанизатор
> Я ту проблему, о которой пишу, во множестве игр встречал. И там её не решили.
Разве уже есть игры с 100% трассировкой? Насколько я понимаю, железо еще не тянет в реалтайме.
> у него там опять бесконечно тонкие лучи!
Только бесконечно тонкие лучи дают свойство несмещенности.
Но толстые лучи тоже давно придумали, называется Voxel Cone Tracing.
Ну вот, видимо, я придумал толстые лучи. Почему их не используют везде, а особенно в железе?
И как они работают с зеркалами, текстурами и тенями?
И почему интернет говорит про какое-то Voxel Cone Tracing применительно к lighting?! Это всё же не полноценный рендер, а, наоборот, лишь только для освещения?
ОТВЕТ
#4
Как вы понимаете, на самом деле во Вселенной (или в фотоаппарате...) точке на изображении соответствует вовсе не ЛУЧ или N лучей (как в классическом подходе), а расходящееся "корыто" или прямоугольный параллелепипед (от фокальной плоскости до границы рендеринга либо бесконечной длины). Отсюда и растут ноги всех тех бед и расхождений между фото и рендерингом, которые я пытаюсь устранить. Или между видимой глазом картинкой и отрендеренной.
Т.е. надо ВЫЧИСЛИТЬ ВКЛАД в цвет результирующего пикселя КАЖДОГО объекта, попавшего в "корыто". Проводя полный анализ по всей площади сечения!!! Без упрощений!!! (Никаких "лучей" заместо полного математического анализа поверхности!) Например, одноцветный треугольник целиком заслонил собой всё "корыто". Ставим этот цвет - результирующим. (У нас пока нет никаких освещений, углы обзора неважны, нет текстур, теней). Выяснилось, что 56,235777% от этого треугольника попало в "корыто", а 43,764223% досталось другому треугольнику - смешиваем цвета.
Треугольники могут друг сквозь друга частично проходить, входить, при этом по-хитрому обрезаться... возможно, придётся их бить на подчасти. Теоретически в одно "корыто" могут попасть все треугольники сцены (если это типа рулетки казино из разноцветных треугольников, а наше корыто прилетело в её центр).
С текстурами сложнее.
Зато это ПОЛНОСТЬЮ устраняет проблему "муара" и мерцания!!!
А из зеркала может полететь несколько "корыт", если наше корытце попало частью на зеркало, а частью - нет... такие дела.
Кстати, на пиксель можно пускать не одно прямоугольное в сечении "корыто", а два "треугольных". Если это даст упрощение в вычислениях. Потом их цвета в пропорции 50%-50% слить.
Короче, светлый гений нашего Ильича я предлагаю вам антиалиасинг БЕСКОНЕЧНОЙ МОЩНОСТИ! Ну, по крайней мере, на несколько порядков лучше того, что доступно человеческому глазу. Путём некоторых затрат и лишений, да. Но практически БЕСКОНЕЧНОЙ!
А вот у Ведьмочки в его рейтрейсере алиасинг во все поля. Так что там совсем-совсем другая тема.
Гугли тайловую архитектуру и кластерный шейдинг. Ты же аредлагаешь сделать кластер размером с тайл.
Дезанизатор
> я предлагаю вам антиалиасинг БЕСКОНЕЧНОЙ МОЩНОСТИ!
Требующий бесконечной памяти. Предположим в один пиксель попадают 1000000 треугольников на большом расстоянии, что будешь делать? Собственно, поэтому подобный бред никто всерьез и не рассматривает. Как раз алгоритмы трассировки методом Монте-Карло тем и примечательны, что умеют разруливать миллион треугольников без серьезных потерь в точности и производительности (но, к сожалению, до реалтайма пока не дотягивают).
> А вот у Ведьмочки в его рейтрейсере алиасинг во все поля.
У него нет алиасинга, в принципе, ибо несмещенность. Ты путаешь шум с алиасингом.
}:+()___ [Smile]
> Предположим в один пиксель попадают 1000000 треугольников на большом
> расстоянии, что будешь делать?
Далеко не в каждый пиксель будут попадать 1000000 треугольников! На такой крайний случай можно и предусмотреть пропуски какие-нибудь. Нашли 10000 треугольников - стоп, берём тот цвет, что вычислен на данный момент. Будет не хуже 1 теперешнего луча! Или придётся сделать LOD-ы. Или что-то похожее.
А в перспективе, увидев, что картинка на порядки лучше, можно представить, что и производители харда подтянутся. Им же хочется иметь картинку лучше.
Давайте начнём всё с начала.
Представим, что сейчас ламповые девяностые.
Сцены простые - несколько тысяч треугольников. Пока без освещения. Пока не будем делать сцены на 1000000 треугольников. Можем мы это отрендерить? Можем. Вот и давайте писать софт-рендерер.
1000000 треугольников какой-нибудь Dark Basic в 90-х убили бы вообще.
>Предположим в один пиксель попадают 1000000 треугольников на большом расстоянии, что будешь делать?
Да и вообще. Держит видеокарта/рендерер миллион треугольников или не держит, одно из двух. Если не держит, не надо делать такие сцены!
Если же держит, то затраты на ВЕСЬ КАДР, если эти 1000000 треугольников РАВНОМЕРНО раскиданы по экрану, на каждый пиксель по паре треугольников, будут РАВНЫ затратам на весь кадр, если весь этот миллион треугольников в одном пикселе, а остальные смотрят на один треугольник скайбокса. Я это проверял и с тех пор не боюсь.
Тема в архиве.