Улучшение производительности трассировщика лучей
В моем примере я хочу знать, когда SecondWord отсутствует, когда FirstWord был написан ранее.
Если у вас есть
[110 ]grep, который понимает регулярные выражения perl, вы можете напрямую указать шаблон для FirstWord, за которым не следует SecondWord где-либо до конца строки :Это приводит к приведенным примерам:
File1.txt:3:... FirstWord ... File1.txt:5:FirstWord ... ... File2.txt:2:FirstWord ...Чтобы переставить это в желаемый формат вывода, вы можете передать его через
awk -F: '{print $2,":",$1}'
8 ответов
Типичным улучшением скорости трассировки лучей первого порядка является своего рода схема пространственного разделения. Основываясь только на странице схемы вашего проекта, кажется, вы этого не сделали.
Вероятно, самый обычный подход - это октодерево, но наилучшим подходом может быть комбинация методов (например, деревья пространственного разделения и такие вещи, как почтовый ящик) , Тесты с ограничивающими рамками / сферами - это быстрый дешевый и неприятный подход, но вы должны отметить две вещи: 1) они мало помогают во многих ситуациях и 2) если ваши объекты уже являются простыми примитивами, вы не получите много пользы (и может даже проиграть). Вы можете легче (чем octree) реализовать регулярную сетку для пространственного разделения, но он будет действительно хорошо работать только для сцен, которые распределены несколько равномерно (с точки зрения расположения поверхностей).
Многое зависит от сложности объектов, которые вы представляете, от вашего внутреннего дизайна (т.е. разрешаете ли вы локальные преобразования, ссылки на копии объекты, неявные поверхности и т. д.), а также то, насколько точно вы пытаетесь быть. Если вы пишете алгоритм глобального освещения с неявными поверхностями, компромиссы могут быть немного другими, чем если бы вы писали базовый трассировщик лучей для объектов сетки или чего-то еще. Я не рассмотрел ваш дизайн подробно, поэтому я не уверен, что, если таковое имеется, из вышеперечисленного, о котором вы уже думали.
Как и при любом процессе оптимизации производительности, вы должны будете сначала измерить, чтобы найти, где вы на самом деле проводите время, а затем улучшать вещи (алгоритмически по предпочтению,
Могу ли я еще что-нибудь сделать, чтобы ускорить его?
D, в зависимости от реализации и компилятора, дает достаточно хорошую производительность. Поскольку вы не объяснили, какие методы трассировки лучей и оптимизации вы уже используете, я не могу вам в этом сильно помочь.
Следующий шаг - запустить анализ синхронизации программы и перекодировать ее. наиболее часто используемый код или самый медленный код, который больше всего влияет на производительность в сборке.
В общем, ознакомьтесь с ресурсами по следующим вопросам:
I don't know D at all, so I'm not able to look at the code and find specific optimizations, but I can speak generally.
It really depends on your requirements. One of the simplest optimizations is just to reduce the number of reflections/refractions that any particular ray can follow, but then you start to lose out on the "perfect result".
Raytracing is also an "embarrassingly parallel" problem, so if you have the resources (such as a multi-core processor), you could look into calculating multiple pixels in parallel.
Beyond that, you'll probably just have to profile and figure out what exactly is taking so long, then try to optimize that. Is it the intersection detection? Then work on optimizing the code for that, and so on.
Некоторые предложения.
- Используйте ограничивающие объекты, чтобы быстро потерпеть неудачу.
- Проецируйте сцену на первом шаге (как это делают обычные графические карты) и используйте трассировку лучей только для легких вычислений.
- Распараллелить код.
Мой первый вопрос: пытаетесь ли вы оптимизировать трассировку одного неподвижного экрана, или речь идет об оптимизации трассировки нескольких экранов для расчета анимации?
Оптимизация для одного кадра - это одно дело, если вы хотите рассчитать последовательные кадры в анимации, есть много новых вещей, над которыми стоит подумать / оптимизировать .
Вот пара обсуждений, объясняющих, почему Dispose не требуется для DataSet.
Метод Dispose в DataSet существует ТОЛЬКО из-за побочного эффекта наследования - другими словами, он на самом деле не делает ничего полезного при финализации.
Следует ли вызывать Dispose для объектов DataTable и DataSet? включает некоторые пояснения от MVP:
Пространство имен system.data (ADONET) не содержит неуправляемые ресурсы. Следовательно, нет необходимости утилизировать какие-либо из них как Я получил что-то вроде ускорения на 30% в моем тесте на пересечение лучей и многоугольников, переписав его с минимальными условными переходами.
Иногда лучший подход противоречит интуиции. Например, я обнаружил, что многие сцены с несколькими большими объектами выполнялись намного быстрее, когда я разбивал их на большое количество более мелких объектов. В зависимости от геометрии сцены, это может позволить вашему алгоритму пространственного разделения выполнить множество тестов на пересечение. И давайте посмотрим правде в глаза, тесты на перекрестки можно проводить только так быстро. Вы должны устранить их, чтобы добиться значительного ускорения.
Иерархические ограничивающие объемы очень помогают, но я, наконец, попробовал дерево kd и получил ОГРОМНОЕ увеличение скорости. Конечно, построение дерева имеет стоимость, которая может сделать его недопустимым для анимации в реальном времени.
Следите за узкими местами синхронизации.
Вы '
Raytrace каждый второй пиксель. Получите цвет между ними путем интерполяции. Если цвета сильно различаются (вы находитесь на краю объекта), проследите лучом пиксель между ними. Это обман, но на простых сценах это может увеличить производительность почти вдвое, при этом вы немного потеряете в качестве изображения.
Отрендерите сцену на GPU, затем загрузите ее обратно. Это даст вам первый луч/сцену на скорости GPU. Если у вас в сцене не так много отражающих поверхностей, это сведет большую часть работы к простому рендерингу. Рендеринг CSG на GPU, к сожалению, не совсем прост.
Почитайте исходный код PovRay для вдохновения. :)
.Сначала вы должны убедиться, что используете очень быстрые алгоритмы (их реализация может быть настоящей головной болью, но что вы хотите сделать, как далеко вы хотите зайти и как быстро это должно произойти). быть, это своего рода компромисс).
еще несколько советов от меня - не используйте методы почтового ящика, в документах иногда обсуждается, что они не очень хорошо масштабируются с реальными архитектурами из-за накладных расходов на подсчет - не используйте BSP/Octtrees, они относительно медленные. - не используйте графический процессор для трассировки лучей, он слишком медленный для продвинутых эффектов, таких как отражение, тени, преломление, фотонное картирование и т. д. (я использую его только для затенения, но это мое пиво )
Для полной статической сцены kd-деревья непобедимы, а для динамических сцен есть умные алгоритмы, которые очень хорошо масштабируются на четырехъядерном процессоре (я не уверен в приведенной выше производительности).
И, конечно же, для действительно хорошей производительности вам нужно использовать очень много SSE-кода (конечно, не слишком много прыжков), но для не «такой хорошей» производительности (я говорю здесь о 10-15%, может быть) компилятор- встроенных функций достаточно для реализации ваших материалов SSE.
И несколько приличных статей о некоторых алгоритмах, о которых я говорил:
«Ограничивающая рамка Fast Ray/Axis-Aligned Bounding Box — Тесты перекрытия с использованием Ray Slopes» (очень быстро, очень хорошо, паралелизизуемый (SSE) тест на попадание AABB-Ray) (обратите внимание, код в документе не весь код, просто погуглите название статьи, вы его найдете)
http://graphics. tu-bs.de/publications/Eisemann07RS.pdf
«Трассировка лучей в деформируемых сценах с использованием динамических иерархий ограничивающих объемов»
http://www.sci.utah.edu/~wald/Publications/2007///BVH /download//togbvh.pdf
Если вы знаете, как работает приведенный выше алгоритм, то это гораздо более совершенный алгоритм:
«Использование предварительно вычисленных треугольных кластеров для ускоренной трассировки лучей в динамических сценах»
http:/ /garanzha.com/Documents/UPTC-ART-DS-8-600dpi.pdf
Я также использую тест pluecker, чтобы определить быстро (не точен, но ну, вы не можете иметь все), если я попал в полигон, очень хорошо работает с SSE и выше.
Итак, мой вывод таков: существует так много отличных статей по стольким темам, которые действительно связаны с трассировкой лучей (как построить быстрые, эффективные деревья и как затенить (модели BRDF) и т. д. и т. д.), это это действительно удивительная и интересная область "экспериментирования", но вам также нужно иметь много свободного времени, потому что это чертовски сложно, но забавно.