Ray/Tri Intersection for Directional Light

Анализируя код пересечения луча и треугольника из Fast, Minimum Storage Ray/Triangle Intersection, я понял что применительно к ортографической проекции или построению теней от направленного источника света (Солнца) путём трассировки лучей, мы можем оптимизировать функцию пересечения. Идея оптимизации основана на том, что все лучи от направленного источника имеют одно направление, в отличие от, скажем, точечного источника. Зная, что вектора dir, edge1 и edge2 являются константами для всего примитива, вектор p и параметр det можно предрассчитать заранее и хранить в памяти вместе с вершинными данными. В противном случае, для каждого пикселя тени будут рассчитываться cross и dot операции с одинаковым результатом. Здесь встаёт вопрос о tradeoff между чтением из памяти и вычислениями, но мне была интересна хотя бы теоретическая возможность вычислительной оптимизации.

Я написал шейдер и демо, которые применяют эту идею. Если использовать самый радикальный, векторизованный вариант пересечения луча и 4-х треугольников, на выхлопе получается 28 dxasm инструкций, т. е. 7 инструкций на треугольник. Думается, это рекордный показатель среди всех функций пересечения с треугольником (конечно, беря во внимание ограничения, свойственные методу).

Думается, метод подойдёт для статичной геометрии (например, здания города, отбрасывающие тени от Солнца). В случае, если солнце должно двигаться (меняется вектор dir), нужно делать отдельный проход, в котором значения пересчитываются для каждого треугольника и сохраняются в памяти перед проходом теней.