Russian Qt Forum

Добрый день

Есть прямоугольник в пространстве, удобно описать его так

C++ (Qt)
struct CRect3D {
 QVector3D cntr;     // центр прямоугольника
 QVector3D u, v;    // вектора (половинной длины) вдоль осей прямоугольника
 QVector3D N;       // нормаль к прямоугольнику (все равно понадобится) 
};
 

Задача: для произвольной целевой точки p найти упрощенный вектор "направления на прямоугольник". Ясно что если прямоугольник "достаточно далеко" (его размеры достаточно малы по сравнению с расстоянием до целевой точки), то просто берем вектор "центр минус точка", и все дела. А вот что делать если прямоугольник "достаточно близко"?

Др. словами: есть комната, в ней окно, нужно упрощенно рассчитать как это окно светит. Почему "упрощенно"? Конечно, полное аналитическое решение есть/реализовано, но оно совершенно неприемлемо по скорости для интерактивного preview.

В общем, типичная задачка типа "близок локоть да не укусишь"  :) Гуглить можно довольно долго, много "чего-то похожего", но готового решения (a la Assistent) нет - буду только рад если ошибся. Поэтому не стыдящиеся "изобретать велосипед"  - welcome (ну если такие еще остались  :))

Спасибо

Не силен я вообще в компьтерной графике.

Источник света точка, или недопустимое упрощение?
Я так понимаю необходимо начертить световое пятно на полу? Тогда скорее всего определить уравнения прямых АТ1, АТ2, АТ3, АТ4, где А - источник света(точка), Тn - координаты углов окна. Ну и после этого определить точки пересечения прямых АТn с плоскостью пола. На полу получаем вершины светового пятна. Дальше наверное дело техники.

Хмм... ну давайте я попробую "перевести" в стандартные термины, а Вы поправьте если я не так понял.

Источник светящий пятном хорошо известен ("spot", прожектор) и он есть даже в OpenGL. По существу Вы предлагаете поставить такой в центр окна и задать ему угол 180 градусов. Никаких пересечений там считать не нужно, все получается гораздо проще, и по скорости для preview все нормально. Но, к сожалению, он дает слишком уж грубое приближение вблизи окна - там получается темно, а должно быть светло. Если интересно могу показать картинки.

Окно нужно рассматривать как источник направленного (типа бьет солнце, и на полу явный прямоугольник видно) или рассеянного (за окном только облака) освещения? И что именно нужно освещать - комнату, или раздельные объекты в комнате, по размерам существенно меньше комнаты?

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

Ясно - просто ненаправленный источник света, имеющий площадь. Ну, как вариант - сэмулировать его влоб массивом точечных. Если считать только диффузное освещение, и в вершинном шейдере, а не пиксельном - то вполне будет работать в реальном времени. Можно еще вклад каждого точечного еще домножать на max( 0.0, dot( Na, D ) ), где Na - нормаль "окна", а D - направление из данного источника на вершину, которую освещаем - будет еще реалистичнее. Можно вообще попробовать посчитать аналитически интеграл, если получится вменяемая формула - использовать ее.

Формула (если такой источник достаточно далеко) очень проста

L = L0 * S / (PI * 2 * distance * distance) * dot(-light_Normal, dir2LightCenter) * dot(surface_Normal, dir2LightCenter);

Где
S - площадь прямоугольника
L0 - интенсивность (задаваемая пользователем)
distance - расстояние от точки до центра
ну и 2 очевидных косинуса

Но какой-то приличный результат получается начиная примерно со 100 самплов, причем самплить лучше адаптивно. Аналитическое выражение тоже есть, но оно довольно обширно, поэтому скажу просто: по скорости еще хуже. Нужно считать побыстрее снижая качество - это preview

Edit:: забыл в формуле самое главное  :) (distance) - он же падает квадратично. Подправился