2013-08-16 4 views
2

Я работаю над проектом, который позволяет пользователям выбирать 3D-объекты в сцене, и мне было интересно, как все думают, что это лучший способ приблизиться к этому сценарию.3D Graphics Picking - Какой лучший подход для этого сценария

В принципе, у нас есть сцена с не менее чем 100 объектами (они имеют низкое значение, но не менее 12-15 треугольников) и до 1000-2000 объектов.

Не все объекты будут «подбираться» во все времена, потому что некоторые объекты будут закрывать других, поэтому «подбираемые» объекты, вероятно, приземляются в диапазоне между 800-1500 (в зависимости от сложности сцены).

Когда объект «выбран», мы хотим, чтобы он был выделен каким-то образом, так что это означает визуализацию его по-другому, это тривиально, но мы хотим, чтобы выбор выполнялся не только по одному клику, но и затягивался - что означает, что мы хотим для быстрого выполнения алгоритма сбора за короткий промежуток времени. В идеале пользователь будет видеть объекты, выделенные в то время, когда они все еще находятся в режиме «перетаскивания» (что означает, что сбор, вероятно, должен выполняться асинхронно, чтобы не отставать от основного рендеринга?).

Я пробовал простой выбор трассы лучей, но это, очевидно, довольно медленно, поскольку мы прокручиваем все треугольники в сцене, чтобы найти объект.

Я также пробовал сбор на основе GPU - рендеринг сцены с использованием пиксельного буфера, который придает уникальный цвет каждому объекту, но с помощью операции перетаскивания это означает, что передача нескольких изображений и передача данных на GPU-CPU невелика представление.

Есть ли какие-либо другие возможности, которые я мог бы изучить, чтобы попытаться получить производительность и функциональность, которые я хочу?

Спасибо за ваше время.

+0

Кроме подхода Octree, сначала необходимо проверить более простые ограничивающие тома. Например. тест на пересечение сфер-лучей очень дешев. Если луч не попадает в ограничивающий объем, вам не нужно пытаться, если луч попадает в сетку. –

+0

Итак, вы говорите, что было бы полезно создать октет сфер, а также ограничивающие прямоугольники и сначала проверить сферы? – poncho

+0

Нет, если вы обнаружили потенциальные удары в октете, вам нужно проанализировать, действительно ли есть хит. Это можно ускорить, сначала проверив ограничивающие объемы. –

ответ

1

Раньше я использовал Octree, и это казалось моим лучшим вариантом. Каждый объект может быть помещен в соответствующий узел и проверен обычным протоколом Octree. Реальные выгоды исходят от смещения луча до конца пространственного узла, когда текущий узел пуст. Это, безусловно, даст вам значительный выигрыш в борьбе с грубой силой.

Следующая ссылка должна дать вам базу с Octree «s и как он настроен: Introduction to Octrees

Хотя ссылка только дает вам базу, использование Octree просто для уменьшая необходимые проверки, поэтому, судя по вашему вопросу, у вас, похоже, уже есть знания, необходимые для выполнения фактического выбора.

+0

Ах, ладно, я не думаю, что я столкнулся с этим методом, у вас есть ссылка на что-то, что объясняет это красиво? – poncho

+0

@poncho Я не могу найти ссылки, которые предоставляют именно это, но вы когда-либо использовали октет? Если нет, как только вы познакомитесь с ним, вы обнаружите, что можете сузить тесты пересечения, которые вы выполняете.Для дальнейшей оптимизации вы можете «ускорить» лучевые пустые узлы, потому что знаете, что вам не нужно выполнять тесты там. –

+0

Ах, спасибо, нет, я никогда не использовал Octrees, но я нашел здесь довольно приятное объяснение (http://castle-engine.sourceforge.net/vrml_engine_doc/output/xsl/html/chapter.octree.html#section. octree_collision_detection), и поэтому я сейчас буду реализовывать его. – poncho