Russian Qt Forum

Всем добрый день.
Собственно вопрос вот в чем.
Какие на сегодняшний день современные и прогрессивные (фотореалистичные) есть методы и алгоритмы расчета глобального освещения?

Если просто нужен "обзор" - лучше почитать документацию на VRay, русский вариант легко найти. Ну а если что-то более предметно - уточните вопрос, отвечу. В 2 словах: несмотря на многие интересные попытки, пока ничего лучше Monte-Carlo не придумали. 

Сразу вопрос - в реальном времени, offline-рендер или промежуточные варианты (типа оффлайн предрассчет, но в картинке возможна какая-то динамика)?

Большое спасибо за Ваш ответ и конструктивные советы!:-) Хотелось бы по подробнее почитать про метод Монте-Карло, может Вы посоветуйте с чего начать лучше (с книги или со статьи), чтобы было написано доступным языком.

Вот еще что хотелось бы по подробнее почитать - это про метод расчета вторичного освещения.

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

Тогда надо смотреть в сторону photon maps и "запекать" их в геометрии (radiosity map). Супер-качества они конечно не обеспечивают, но если движется только камера - можно просчитать 1 раз и будет работать быстро. Если же и объекты движутся - забот намного больше. Ну а насчет hardware/OpenGL техник - надо послушать xop

Статейки не посоветуйте?

Тогда еще несколько уточнений:
1) какого плана сцены - ограниченные комнаты с небольшим количеством объектов или большие пространства?
2) могут ли двигаться отдельные мелкие объекты?
3) может ли сильно меняться геометрия сцены (типа убрали/поставили стену), которая может сильно повлиять на освещенность?
4) могут ли двигаться источники света?

После этого смогу посоветовать конкретные статейки :)

:) Так просто это не решается. Не существует какого-то одного решения, нужно выбирать ту или иную технику, часто несколько вместе. Поэтому максимально уточните задачу и ответьте на все вопросы xop. Иначе будет "стрельба по площадям" которая ничего не дает.

1. Ограниченные комнаты
2. Да могут как в режиме просмотра 3д, так и в режиме расстановки объектов.
3. Да может, но только в векторном редакторе (основной модуль в котором строиться контур помещения), после изменения контура можно перекл. в режим 3д и походить в ну три  помещения.
4. Да могут в обоих режимах.

Примерно понятно. Вам нужно определиться

- вообще будете ли делать ставку на OpenGL и возможности hardware или нет. Дальше только про sofware решения

-  реально выглядит хранить просчитанное освещение как "illumination map", в простейшем случае это амбиент текстура. Можно ограничиться этим полагая что все полигоны достаточно малы и гранулярны. Можно пойти дальше и для каждого полигона хранить разбивку спускаясь по barycentric. Можно вообще "запекать в текстуру". В любом случае качество "приблизительное", но это самый быстрый способ для пролетов камеры.

- просчет освещенности. Как ни крути надо иметь raytracer и связанные с ним структуры данных (часто BSP). Если я правильно понял, у Вас интерьеры и bouncing light Вам считать надо. Мое мнение - лучше начать с photon map. Ссылок масса, ознакомиться/прочитать можно за день. Если хотите "капитально" то есть классическая книга Jensen'а, ее трудно найти, дайте мне в личке ссылку куда заливать (20 Mb). Но это "если надо". Алгоритм kd-tree давно известен и он реально работает, просто гуглите PhotonMap.cpp (h) эти исходники можно использовать непосредственно.  А вот сам выброс фотонов - к сожалению, без raytracer'а никак. Заметим что с фотонами можно иметь и прямое освещение.

- очень много зависит от того какие источники света. Напр. для простых точечных источников относительно легко добиться приемлемого качества. А вот если свет от окна (Area Light) - тогда надо потрудиться намного больше.

- динамика (объекты с сцене движутся). Простой подход - пересчитать все с нуля. На хороший fps рассчитывать не приходится, но это просто и надежно. Оптимизировать - писали много, но я не могу сказать "да, вот это работает", поэтому от рекомендаций воздержусь.

- Др. ходы. Есть масса статей где обещается "real-time global illumination" но подходить к ним надо осторожно, всегда лучше попытаться понять "за счет чего".  И не забывать что статья/идея решения не обещает  :)

Конечно, все это мое личное мнение, интересно услышать др. подходы/советы.

Ну, значит так. Отправной точкой можете посмотреть статьи, выложенные здесь:
http://www.graphics.cornell.edu/~jaroslav/gicourse2010/
Там есть про современные и offline, и realtime методы.

Для вашего случая вроде как очень привлекательным выглядит вариант point-based (статьи от Bunnel), но если вдруг потом потребуются большие пространства, то может быть опс. Смысл примерно такой - представляем сцену в виде набора точек (в статьях предлагались либо вершины основной геометрии, либо вершины сильно упрощенной геометрии), и дальше тупо итеративными методами решается большая система линейных уравнений. На CPU. А потом данные заливаются в GPU. Плюсы - довольно хорошее качество, много "плюшек" (можно например легко сделать объемные источники света), минусы - на GPU плохо ложится, делать подозреваю очень-очень непросто, особенно чтобы в realtime уложить и скорее всего очень плохо с инстансингом (хотя если "комнаты", то может это и не проблема).

Как альтернатива - использовать для статической геометрии и источников света предрассчитанный point-based подход, плюс на основе его результатов генерить light probes, которые использовать для динамики. Где-то была статья на эту тему, но сходу не нашел. Плюсы - опять же высокое качество, большая скорость, относительная простота. Минусы - для некоторых вещей предрассчеты все-таки нужны.

Третий вариант - на самом деле довольно универсальный, и относительно просто реализуемый - light propagation volumes. Но качество и точность подозреваю будет хуже. Основная идея - делаем 3D-текстуру, охватывающую всю сцену. В ней храним пространственное распределение освещенности с помощью сферических гармоник. Дальше туда фигачим вторичные источники света, посчитанные с помощью reflective shadow map (можно погуглить, на эту тему много написано), и итеративно считаем распространение. По этому методу кроме статьи Капланяна на siggraph есть еще куча его же презентаций непосредственно на сайте crytek, где он работает: http://crytek.com/cryengine/presentations. Ну и можно погуглить сам термин light propagation volumes - там много чего выплывет. Где-то в чьем-то блоге видел даже демку с исходниками, но опять же - ссылку сходу найти не смог.

В общем, вот варианты, читайте, думайте какой вам лучше подходит по качеству/сложности, может вообще какой-нибудь гибрид сами придумаете на основе этих идей :)

Ну так-то оно так, но позвольте пояснить для автора темы:

никто не пытается Вас "запугать" ни похвалиться своими знаниями, не об этом речь. Просто Вы ввязались в тему которая фундаметальна/капитальна в течение последних 15 лет (на моей памяти) и над которой бьются лучшие умы.. Ответ xop может показаться "заумным" но он совершенно адекватен - такова специфика. Никто не заставляет использовать новейшие разработки, есть методики со стажем 10 и более лет (photon maps одна из них ). По крайней мере они хорошо изучены, от них знаешь чего ожидать и чего нет. Но в любом случае это очень "недешево" - в смысле реализации и усилий.  Так что подумайте/прикиньте. Это точно не то что можно решить "на ходу". Может даже имеет смысл вернуться к "первобытной radiosity" на уровне вертексов - смотрите по задаче/бюджету.

Ну, как бы point-based global illumination - это все-таки попроще фотон-мапинга. В сущности это тот же radiosity, просто геометрия в очень удобной (для проца) форме представлена. Настолько удобной, что сделав ряд упрощений можно вообще в реальном времени считать :) Light propagation volumes - тоже абсолютно ничего сложного на самом деле, плюс еще очень подробно в куче статей разжевано. Единственный сложный момент - представление функции освещенности в сферических гармониках, но если разобраться - тоже ничего сверхестесственного. Кстати, как появится время думаю попробовать реализовать LPV у себя в проекте. Новизна тут не в сложности, а в заточке алгоритмов под современное железо.

Ну типа как операция умножение (*) все ж сложнее операции суммирования (+)  :)

Да выход-то всегда простой - иначе он не имеет смысла для рендера. А вот как избавиться - или хотя бы минимизировать артефакты метода (а они всегда есть) - ото капитальный геморррой

Фотон-маппинг настроить чтобы хорошо выглядел и при этом считал разумное время - тоже задача не из простых ;) В LPV артефакты кстати все задокументированы и методы борьбы с ними подробно расписаны. В действии их я так понимаю можно будет посмотреть в Crysis 2 :) Про PBGI литературы меньше, но метод тоже вполне рабочий. Насколько я понимаю его же (с поправками) внедрили в Bad Company 2, который тоже скоро должен выйти.

Спасибо всем за ответы! По ходу разбора буду писать вопросы.

Кстати, по поводу вот этого:


Таки вспомнил где:
http://advances.realtimerendering.com/s2010/Martin-Einarsson-RadiosityArchitecture(SIGGRAPH%202010%20Advanced%20RealTime%20Rendering%20Course).pdf
http://advances.realtimerendering.com/s2010/Martin-Einarsson-RadiosityArchitecture(SIGGRAPH%202010%20Advanced%20RealTime%20Rendering%20Course).avi

UPD. И кстати, я чуть ошибся - там тоже все можно в реальном времени обновлять :)

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

Пока только одно пожелание для конечного продукта - кроссплатформенность.
Стоит ли только из-за этого склоняться только в сторону OpenGL?

И стоит ли склоняться в сторону DirectX только из-за скорости разработки с его помощью?

В общем, прошу Ваших советов, рассуждений и рекомендаций.

Насчет OpenGL:
+ кроссплатформенный
+ есть функционал до DirectX 11, и это доступно в том числе и под Windows XP (а не только Vista и Win7)
+ если сравнивать с DirectX 9, то нет такого мерзкого являения, как "device lost"
+ есть некоторые вещи, которых нет ни в одной версии DirectX :)
- крайне желательно ставить последние драйверы, иначе могут быть проблемы
- если видеокарта Intel - не помогут даже последние драйвера. под виндами там все ооочень печально, хотя под линуксами жить еще можно
- больше проблем с менеджментом комбинаций шейдеров, плюс нет возможности их предкомпиляции
- многий реально полезный функционал, реализованный в DirectX еще лет 5 назад в OpenGL появился только относительно недавно (и это еще одна причина, по которой нужны свежие драйверы)
- не очень хорошо с документацией и внутренней организацией, но в последнее время с этим становится намного лучше

Примерно так. Если какие-то вещи интересуют подробнее - могу раскрыть :)

xop -можешь книгу (OpenGL) посоветуй какую ни будь желательно для начала на русском, чтобы по человечески было написано. :-)

Каких именно нет вещей в Directx-е и в чем их достоинства?

P.S.
Так как я считаю себя еще пока новичком в этом вопросе, так сказать только начинаю вливаться в эту тему.

Посоветуйте статьи или книги по аппаратному raytracing-гу.

Кто нибудь работал с вот этим NVIDIA® OptiX™ 2 ray tracing engine? Что можите сказать?